Owlh

owlh_documentation Documentation
Release 0.4 - Cloud and Bro
owlh team
Feb 09, 2019

Contents
1 What is OwlH? 1
2 A few topics 3
i
ii
CHAPTER 1
What is OwlH?
This is OwlH, open source solution. OwlH is born to help security engineers to manage, visualize, analyze and respond
to threats detected from Open Source Network IDS like Suricata and BroIDS, offering:
• Manage Network IDS (suricata and broIDS) nodes at scale
• SoftwareTAP for cloud and on-premises environments
• Centralized Rule Management
• Centralized Visualization
• Network Data Collection and Big Data Storage
• Compliance Mapping and Dashboards
• Incident Response Automation
1
owlh_documentation Documentation, Release 0.4 - Cloud and Bro
2 Chapter 1. What is OwlH?

CHAPTER 2
A few topics
2.1 About OwlH
Security world is not related to a tool. It is related to a continuous process that must be able to evolve and adapt to
your network, systems, and software as they do.
Also, Security and cyber-security terms are a really big and complex world with a huge amount sub-worlds, regions,
areas, or whatever how you would like to call them
OwlH is born to help with one piece of this galaxy. We can summarize it as help to implement and maintain Network
Traffic Analysis process based in Network IDS open source solutions. But a process is not just a tool or a solution, it
will contain tasks, tools, solutions and it must evolve and adapt.
So, OwlH is about that, a platform to provide process definitions that will use 3rd party tools or solutions, our own
tools, and our tasks definition to successfully implement them.
This picture will summarize the process we are working in.
3
Our target right now is to provide help for:

• Network IDS integrated with Host IDS solution
• On-Premises Network IDS
• Cloud Network IDS Software TAP
• Network IDS Orchestration
• Alert Enrichment
• Data Visualization
• Adapt and response
4 Chapter 2. A few topics

2.1.1 If you need help:
• email our support team - support@owlh.net

• visit our mailing list - OwlH mailing list (owlh@googlegroups.com)
OwlH - current v0.7 - Jan : OwlH Node and Master API
documentation last updated - Feb 09, 2019
2.1. About OwlH 5

2.2 How does it work?
2.2.1 Main components
• OwlH NIDS node

• OwlH Master node
• Elastic stack
2.2.2 OwlH NIDS node
This appliance run the Network IDS software. OwlH supports Suricata Network IDS and will support BroIDS on next
releases. Usually, best approach is to run a network IDS node as only network IDS so there is no other services or
production environment tools working on it that are not related with traffic collection and analysis.
Main role of this appliance is to listen traffic, analyze captured traffic using the ruleset provided and send the alerts to
the master node. Also OwlH will include a capability to run actions in response to detected alerts.
With OwlH you can deploy this OwlH NIDS node from scratch or you can include an integrate any deployed Network
IDS node. Supported platforms are Debian Stretch and CentOS 7.
• deploy as appliance
• deploy as a service in a running Network IDS probe.
2.2.3 OwlH Master node
Centralized management will provide you an easy way to maintain your Network IDS probes. Among others, Master
node will provide centralized rule management based on Open Rules solution, probes status Monitoring, configuration

management, etc.
This should be an appliance, you can deploy different managers in parallel as a cluster. The OwlH master software
can also run into Wazuh Manager if you will use OwlH together with Wazuh.
2.2.4 Elastic Stack
Data Transport is done in two possible ways.

• By using Wazuh agent
• By using OwlH forwarder and collector tools
• By using Beat solutions like filebeat or logstash
If you need help:

2.3 OwlH - Suricata and Wazuh
2.3.1 How to easily integrate Suricata with Wazuh
This will introduce an easy way to integrate your Suricata output into Wazuh world. this is a one-way integration
process, from your Suricata node to your Wazuh Dashboard. OwlH will help also to manage your Suricata nodes
configuration and rules, and many other things. but right now, let’s integrate your Suricata node with Wazuh.
As usual, please keep in contact if there is any clarification or help needed.
Main steps
• Deploy Suricata or use a Current Suricata deployment

• Configure Suricata to store output in JSON format - EVE log configuration
• Install Wazuh stack if you are not done yet
• Install Wazuh Agent in the suricata system
• Configure Wazuh Suricata rules to create right alarms
• Configure Wazuh Agent to read the eve.json output file
• If you require PCI. Configure OwlH PCI mapping
• Modify Elastic template
And what’s next?
2.3. OwlH - Suricata and Wazuh 7

• OwlH Network IDS Dashboards

• OwlH Network IDS Configuration management
• OwlH Network IDS Rule management
2.3.2 Deploy Suricata or use a Current Suricata deployment
We assume that you will use a new Suricata deployment or you will use a current one. Both will work. In this
procedure, we relay on Wazuh agent to do the collection work, so if your platform supports wazuh agent you should
be able to integrate your Suricata too. Most usual environments are supported by both, but anyway, please, verify
Suricata and Wazuh-agent requirements to find the right match.
2.3.3 Configure Suricata to store output in JSON format - EVE log configuration
By default Suricata configuration file suricata.yaml has the EVE (Extensible Event Format) enabled and configured to
store the output in JSON format. But, anyway is a good idea to review that configuration and verify that we have all
the info we want in the output file.
Output file is usually - /var/log/suricata/eve.json
a tail -f /var/log/suricata/eve.json will help you to verify that configuration is
˓→working.
Here you have a SAMPLE eve-log configuration. Please, there are great configuration settings to use, so expend some
time, review your Suricata documentation and find the right configuration for your needs.
outputs:
- eve-log:
enabled: yes
filetype: regular #regular|syslog|unix_dgram|unix_stream|redis
filename: eve.json
types:
- alert:
metadata: yes
tagged-packets: yes
xff:
enabled: yes
mode: extra-data
- http:
extended: yes
- dns:
query: yes # enable logging of DNS queries
(continues on next page)

(continued from previous page)

answer: yes # enable logging of DNS answers
- tls:
extended: yes # enable this for extended logging information
- files:
force-magic: no # force logging magic on all logged files
- smtp:
extended: yes # enable this for extended logging information
- ssh
- flow
• Suricata eve-log sample file

Remember to restart your Suricata service after any change in your configuration file and check your Suricata logs.
2.3.4 Install Wazuh stack if you are not done yet
We are integrating Suricata with Wazuh, so we need to have Wazuh Manager and elastic stack running before to end
our configuration. At least we will need a Wazuh Manager connected to the elastic stack.
Please, follow Wazuh install guide to deploy manager and elastic stack. If you have this done, you can skip this step.
2.3.5 Install Wazuh Agent in the suricata system
Wazuh Agent will be the transporter of our Suricata output. It provides a secure communication channel between our
Suricata node and Wazuh Manager and the storage repository. Of course, Wazuh Agent does a lot more, it will help us
to take care of our Suricata security by providing FIM, OS and audit Log Monitoring, and many others. Check Wazuh
Agent doc if you are not familiar with its capabilities.
To install it please read and follow the install instructions from Wazuh. Or request our help.
2.3.6 Configure Wazuh Suricata rules to create right alarms
By default, Wazuh will use the JSON decoder to parse any JSON log entry from a wazuh agent. This decoder works
really great, so we don’t need to care about parsing.
To create an alert from collected logs, Wazuh uses rules. Each rule has an alert value so if the logs match with a rule
and the rule’s alert value is equal or higher than alert level umbral defined in wazuh manager, then you will have an
alert.
# Default alert level configuration defined in manager ossec.conf file

<alerts>
<log_alert_level>3</log_alert_level>
<email_alert_level>12</email_alert_level>
</alerts>
So, by default, most Suricata rules will have a 0 value level to prevent noisy events. we suggest to modify this values
just to be sure that everything is collected, you can then adjust the alert level as needed in the future, as well as you
can modify rules also as you may need.
If you are not familiar with decoders and rules, this may help - Wazuh decoders and rules.

# Sample rule modified to create an alert

<rule id="86600" level="4">
<decoded_as>json</decoded_as>
<field name="timestamp">\.+</field>
<field name="event_type">\.+</field>
<description>Suricata messages.</description>
</rule>
Remember to restart your Wazuh Manager service after any change in your configuration file and check your Wazuh
Manager logs.
2.3.7 Configure Wazuh Agent to read the eve.json output file
We need to tell our Wazuh Agent to read the Suricata output file. This will be done in the ossec.conf file under
/var/ossec/etc folder (Linux systems). Check your <ossec_config> tag and include following lines.
# Modify ossec.conf - read localfile suricata EVE json log

<localfile>
<log_format>syslog</log_format>
<location>/var/log/suricata/eve.json</location>
</localfile>
Remember to restart your Wazuh Agent service after any change in your configuration file and check your Wazuh
Agent logs.
2.3.8 If you require PCI. Configure OwlH PCI mapping
This must be run on every Wazuh logstash server and it will:

• Modify logstash configuration file to include OwlH PCI-DSS 3.2 mapping schema
• Copy OwlH suricata PCI-DSS mapping to config folder
• Restart logstash
Please, download configuration script
$ curl -so /tmp/owlhconfig.sh https://raw.githubusercontent.com/owlh/
wazuhenrichment/master/owlhconfig.sh
and then run it
$ sudo bash /tmp/owlhconfig.sh
Please, let us know if you need help.
2.3.9 Modify IP data mapping
Suricata json format includes fields like src_ip, src_port, dest_ip and dest_port. but wazuh elastic index is using srcip,
srcport, dstip and dstport.
so we will do the mapping modification in logstash by including the following in the wazuh logstash filter.

filter {
if [data][src_ip] {
mutate{
add_field => [ "[data][srcip]","%{[data][src_ip]}"]
remove_field => [ "[data][src_ip]" ]
}
}
if [data][dest_ip] {
mutate{
add_field => [ "[data][dstip]","%{[data][dest_ip]}"]
remove_field => [ "[data][dest_ip]" ]
}
}
if [data][dest_port] {
mutate{
add_field => [ "[data][dstport]","%{[data][dest_port]}"]
remove_field => [ "[data][dest_port]" ]
}
}
if [data][src_port] {
mutate{
add_field => [ "[data][srcport]","%{[data][src_port]}"]
remove_field => [ "[data][src_port]" ]
}
}
}
2.3.10 Modify Elastic template
Elasticsearch Wazuh index template is based on agent fields and doesn’t include all the new fields types that Suricata
will provide. This is not a real problem as an index refresh into kibana will allow you to manage Suricata without a
problem. But some useful things may happen if we use the right field type as for example an amazing flow dashboard
with useful traffic graphics.
These are some fields that will require template customization.
"flow": {
"properties": {
"bytes_toclient" : {
"type": "long",
"doc_values": "true"
},
"bytes_toserver": {
"type": "long",
"doc_values": "true"
}
}
},
Note: As there can be some issues when modifying elasticsearch indices and templates, please request our help to do
it. We are working to prepare a full index template and instructions.

If you need help:

2.4 OwlH - Zeek and Wazuh
2.4.1 Integration Logical Diagram
Components
• OwlH Node - Zeek IDS and Wazuh Agent

• Wazuh Manger
• Logstash Server
• Elastic and Kibana Server
Let’s see what we need to modify on each component to be able to manage this Bro and Wazuh integration.

2.4.2 Configure - Zeek - OwlH Node
This system will require Bro working of course, and Wazuh agent installed. OwlH instructions will help to configure
both Bro and Wazuh agent.
2.4.3 Zeek Logs Output format to JSON
Option 1 - Modify ASCII writer output
you can load the json_logs.bro configuration that will tell ASCII writer to write output in JSON format. You must
include following line in your .bro configuration files. It can be /etc/bro/site/local.bro or you can follow our recomen-
dation and write the configs in owlh.bro file (please, see below).
This will modify output and will store just json output, you won’t have ASCII output.
@load tuning/json_logs.bro
Option 2 - Use add-json package
Usually, you would like to have both outputs, ASCII and JSON. You can use add-json packet (https://github.com/
J-Gras/add-json) and load it in your local.bro or owlh.bro.
@load packages/add-json/add-json.bro
To install add-json package you can use bro-pkg tool

:: bro-pkg install add-json
Note: bro-pkg installation (http://bro-package-manager.readthedocs.io/en/stable/quickstart.html#installation)*
Note: Thanks to C.L.Martinez and Jan.Grashoefer
Zeek Event Enritchment to help Wazuh ruleset
It is a good idea to help wazuh rules to do their job, to include a field that will identify what kind of log line we are
analyzing. Bro output doesn’t include that info per line by default, so we are going to help wazuh by including the
field ‘bro_engine’ that will tell wazuh what kind of log is it.
We are using redef function to include a custom field for each ::Info record of each Protocol. Here are just a few of
them, we will include more by default in next releases.
redef record DNS::Info += {

bro_engine: string &default="DNS" &log;
};
redef record Conn::Info += {
bro_engine: string &default="CONN" &log;
};
redef record Weird::Info += {
bro_engine: string &default="WEIRD" &log;
};
2.4. OwlH - Zeek and Wazuh 13


redef record SSL::Info += {
bro_engine: string &default="SSL" &log;
};
redef record SSH::Info += {
bro_engine: string &default="SSH" &log;
};
Loading Zeek customizations at Zeek start
We include all OwlH customizations in OwlH_*.bro files, that helps to have a clear view of what OwlH does as well
as we hope it will simplify configuration management.
Under /etc/bro/site we will create two files
• owlh.bro - Will include JSON call and @load for bro_engine field definition.
• owlh_types.bro - Will include all redef statments
You will only need to load OwlH.bro at the end of your local.bro file to include all these configurations
@load /etc/bro/site/OwlH.bro
owlh.bro looks like:
# Select prefered output

#@load tuning/json-logs.bro
@load packages/add-json/add-json.bro
@load /etc/bro/site/owlh_types.bro
and owlh_types.bro:
redef record DNS::Info += {

bro_engine: string &default="DNS" &log;
};
redef record Conn::Info += {
bro_engine: string &default="CONN" &log;
};
redef record Weird::Info += {
bro_engine: string &default="WEIRD" &log;
};
redef record SSL::Info += {
bro_engine: string &default="SSL" &log;
};
redef record SSH::Info += {
bro_engine: string &default="SSH" &log;
};
2.4.4 Wazuh Agent configuration
Note: Remember we are on Bro Node component.*
Modify your Wazuh agent to read the Bro Logs files

<localfile>
<location>/path/to/bro/logs/*.log</location>
</localfile>
Note: if needed, You can specify files instead of all .log ones
<localfile>
<location>/path/to/bro/logs/weird.log</location>
</localfile>
<localfile>
<location>/path/to/bro/logs/conn.log</location>
</localfile>
2.4.5 Configure - Wazuh Manager
Good news is that Wazuh’s JSON decoder works really great, so using JSON output from BRO allow us to save time
developing an specific decoder for its standard ASCII out.
We only need to create a few rules to identify the Bro events and forward them to ELK.
2.4.6 Wazuh Zeek IDS Rules
Include the Wazuh rules into your /var/ossec/etc/rules/local-rules.xml file to manage your Zeek logs
<group name="zeek">
<field name="bro_engine">SSH</field>
<description>Zeek: SSH Connection</description>
</rule>
<field name="bro_engine">SSL</field>
<description>Zeek: SSL Connection</description>
</rule>
<field name="bro_engine">DNS</field>
<description>Zeek: DNS Query</description>
</rule>
<field name="bro_engine">CONN</field>
<description>Zeek: Connection detail</description>
</rule>
</group>
Note: remember restart your wazuh agent after change.*
2.4. OwlH - Zeek and Wazuh 15

2.4.7 Configure - Logstash Server
2.4.8 Logstash Filter
We need to modify Logstash filters (/etc/logstash/conf.d/) to allow JSON record cleaning from Bro to Wazuh-alert
index parsing. It is necesary because bro uses [id] field to group network src and dest addresses and ports info and
parsing will fail
Also, it is done so we can store IP-PORT data in the right fields for wazuh index
filter {
if [data][id][orig_h] {
mutate {
add_field => [ "[data][srcip]", "%{[data][id][orig_h]}" ]
add_field => [ "[data][dstip]", "%{[data][id][resp_h]}" ]
add_field => [ "[data][srcport]", "%{[data][id][orig_p]}" ]
add_field => [ "[data][dstport]", "%{[data][id][resp_p]}" ]
remove_field => [ "[data][id]" ]
}
}
}
2.4.9 Review your Kibana Dashboard
You will need to refresh your Wazuh-alerts-3.x indeces to include the new Zeek fields. from your kibana console, go
to Management -> index -> select right wazuh-alerts index -> click top-right refresh icon to refresh
And that’s all folks.
If you need help:


2.5 OwlH for PCI
2.5.1 OwlH can help you to demonstrate compliance with requirements:
Download OwlH PCI-DSS v3.2 Mapping - ‘owlh_pcidss_3.2.pdf‘_ .. _owlh_pcidss_3.2.pdf: https://drive.google.

com/file/d/1IfC23AHSULjY6GKmXG_S5ZIUWKEMyB33/view?usp=sharing
2.5.2 Define your custom rules to detect compliance related traffic:
OwlH team will help you to define rules that will identify traffic that can be related to PCI requirements like unen-
crypted traffic between PCI related systems. Use of unknown services from PCI network to external servers, Firewall
policy violations when publishing internal services.
2.5.3 How to apply Suricata PCI Mapping
This must be run on every Wazuh logstash server and it will:

• Modify logstash configuration file to include OwlH PCI-DSS 3.2 mapping schema
• Copy OwlH suricata ET ruleset PCI-DSS mapping to config folder
• Restart logstash
Please, download configuration script
$ curl -so /tmp/owlhconfig.sh https://raw.githubusercontent.com/owlh/
wazuhenrichment/master/owlhconfig.sh
and then run it
$ sudo bash /tmp/owlhconfig.sh
2.5.4 How to manage and custom your Suricata PCI Mapping
Please download the script that will allow you to manage your compliance mapping
$ curl -so /tmp/owlh-suri2pci.sh https://raw.githubusercontent.com/
owlh/owlhpci/master/owlh-suri2pci.sh
usage: ./owlh-suri2pci.sh -a|ls|lc|m|d -s sid -c pci-controls -b bulk_file pci_map_

˓→file
-a|--append - append sid and pci-dss related controls to map file

-d|--delete - sid and pci-dss related controls from map file
-ls|--listsid - list pci controlers related with a sid or group of sids
˓→(grep)
-lc|--listctrl - list sids that are associated with pci control

-m|--modify - modify sid and pci mapping
2.5. OwlH for PCI 17


-s|--sid - sid number
-c|--control - list of controls comma separated
If you need help:

2.6 Software TAP for AWS and GCloud
2.6.1 OwlH Software TAP to monitor traffic in AWS and GCLOUD environments
OwlH Software TAP (sTAP) will collect full or specific traffic from your instances and forward it to OwlH Master that
will run the Network IDS tool to do the analysis.
This doc will describe a basic configuration using CentOS instances, Bro and Suricata Network IDS and Wazuh
Integration. (other Linux distributions as well as Windows Support is available)
There are a lot of moving pieces, feel free to ask for help support@owlh.net. This doc will try to simplify deployment
but for sure it will need some customization as well as may need some architecture understanding.
Main steps:
• Introduction: How does it work?
• Prepare your environment
– Option: Create an administration network

– OwlH Master
– Suricata NIDS
– BRO NIDS
– Wazuh Integration
– Default configuration settings
• Register your instances
– Define Instances settings
– Configure your instance
• Enjoy it
2.6.2 Introduction: What does SotwareTAP do and how does it work?
Software TAP is for capture traffic in remote instances, transport captured traffic to a central analysis platform, analyze
the traffic and alert. It works in any environment, but it is really useful when you need this visibility in a cloud
environment.
2.6.3 Main Components
There are different components.

• OwlH Master
– Orchestration
– Dummy Interface
– Network IDS
• Target Instances
• Storage and Visualization
• Wazuh Integration
Note: For cloud like AWS or Google Cloud should be good idea to deploy our instances with two different network
interfaces, so we can use main interface as public service interface and secondary for management propouses, as traffic
forward from instances to OwlH system
2.6. Software TAP for AWS and GCloud 19

• A more detailed block diagram

2.6.4 OwlH Master Orchestration
Prepare OwlH Master software
# sudo curl https://raw.githubusercontent.com/owlh/owlhmaster/master/Software TAP/

˓→config.sh > /tmp/configure_OwlHmaster.sh
# sudo bash /tmp/configure_OwlHmaster.sh

# rm /tmp/configure_OwlHmaster.sh
OwlH Master ssh Key
• Copy your owlh master ssh key to your instances /tmp folder. Be sure it is in the right place.
# scp /home/owlh/.ssh/owlhmaster.pub user@1.1.1.1:/tmp/owlhmaster.pub
Note: change user and 1.1.1.1 as required or please, follow your own deployment process to ensure that the owlh
master pub key is in place on each instance.
Create Dummy interface for Network IDS
# sudo curl https://raw.githubusercontent.com/owlh/owlhostnettap/master/dummy.sh.

˓→centos7 > /tmp/dummy.sh
# sudo bash /tmp/dummy.sh

# rm /tmp/dummy.sh
2.6.5 Network IDS support
Continuous Network IDS monitor and sniffing
We will help to have a better continuous monitoring by using a configuration based on a dummy network interface
and running Network IDS solutions continuously. PCAPS will be injected using TCPREPLAY script in the dummy
interface.

Deploy Suricata as Network IDS
Suricata deployment script will help you to deploy Suricata 4.0.4 from source code in a CentOS 7 box.
If you prefer a different way to deploy suricata, please follow Suricata documentation.
Run Suricata IDS
Deploy Zeek as Network IDS
Zeek deployment script will help you to deploy Bro IDS from source code in a CentOS 7 box.
If you prefer a different way to deploy Bro, please follow Zeek documentation.
Run Zeek IDS
2.6.6 OwlH Master Configuration
OwlH Master Configuration for Software TAP

We call flock Controller the main process that will drive Software TAP functionality. This is the default configuration
file that you will find in your /etc/owlh/ folder.
{
"pidfile" : "/tmp/flock.pid",
"logfile" : "/var/log/owlh/flock.log",
"inventory" : "/etc/owlh/inventory.conf",
"owlh_user" : "owlh",
"owlh_user_key" : "/home/owlh/.ssh/owlhmaster",
"max_cpu" : "25",
"max_mem" : "25",
"max_storage" : "80",
"capture_time" : "60",
"default_interface" : "ens33",
"filter_path" : "/etc/owlh/filter.bpf",


"local_pcap_path" : "/usr/share/owlh/in_queue/",
"pcap_path" : "/usr/share/owlh/pcap/",
"owlh_interface" : "owlh",
"suricata_on" : "True",
"bro_on" : "True"
}
BPF filter
You can specify what traffic to be captured if you don’t want to capture everything. Main and default configuration
will provide filter to not collect management traffic from OwlH master to your agents.
Remember this filter must be deployed into each one agent. be sure it is on each one of your servers.
Your bpf filter should be at least something like this
not host 1.1.1.1 and not port 22
Where 1.1.1.1 must be replaced with your OwlH master ip that will connect to your server.
2.6.7 Target Instances
We will need some tools and a user in each one of your servers in order to coordinate the traffic capture functionality
• Create and configure owlh user in your servers
The owlh user will be use by OwlH Master Orchestrator to run traffic capture and collect pcap files. to create user and
configure it please follow this script:
#!/bin/bash
# Created 28.02.18
# v0.1 24.05.18 master@owlh.net
# tested in amazon Linux instance

# tested GCLOUD - centos7 - CIS version
# NOTE -- run this script in a server using

# sudo bash owluser-setup.sh
sudo adduser owlh

echo "create owlh user ssh folder"
sudo -u owlh mkdir /home/owlh/.ssh
echo "setting ssh folder permissions"
sudo -u owlh chmod 700 /home/owlh/.ssh
echo "create authorized keys file"
sudo -u owlh touch /home/owlh/.ssh/authorized_keys
echo "setting authorized keys permissions"
sudo -u owlh chmod 600 /home/owlh/.ssh/authorized_keys
echo "include owlmaster key"
echo "be sure you have your owlh master pub key in /tmp/owlhmaster.pub file"
sudo cat /tmp/owlhmaster.pub >> /home/owlh/.ssh/authorized_keys
echo "Allow owlh user to login with ssh"
sudo sed -i '/^AllowUsers/s/$/ owlh/' /etc/ssh/sshd_config
sudo systemctl restart sshd

echo "install tcpdump"

if ! sudo yum list installed tcpdump ; then
sudo yum -y install tcpdump
fi
# Allow owlh use tcpdump with sudo without password

echo "allow user owlh to use tcpdump and chown"
#sudo sed -i '/^%wheel/a owlh ALL=(ALL) NOPASSWD: /usr/sbin/tcpdump' /etc/
˓→sudoers
sudo echo "owlh ALL=(ALL) NOPASSWD: /usr/sbin/tcpdump, /usr/bin/chown" >> /

˓→etc/sudoers.d/owlh
# Prepare owlh related stuff folder

echo "prepare owlh stuff folders /etc, /var/log, /usr/share"
sudo mkdir /etc/owlh
sudo mkdir /var/log/owlh
sudo mkdir /usr/share/owlh
sudo mkdir /usr/share/owlh/pcap
sudo chown owlh /etc/owlh

sudo chgrp owlh /etc/owlh
sudo chown owlh /var/log/owlh
sudo chgrp owlh /var/log/owlh
sudo chown -R owlh /usr/share/owlh
sudo chgrp -R owlh /usr/share/owlh
#sudo echo "not host 10.164.0.4 and not port 22" > /etc/owlh/filter.bpf
# clean and end

echo "should be done. Enjoy your day."
Script also includes tcpdump installation as part of the traffic capture stuff. Please be sure you have tcpdump running
before continue. This step is only needed if you don’t have tcpdump installed yet.
echo "install tcpdump"

if ! sudo yum list installed tcpdump ; then
sudo yum -y install tcpdump
fi
# Allow owlh use tcpdump with sudo without password

echo "allow user owlh to use tcpdump and chown"
#sudo sed -i '/^%wheel/a owlh ALL=(ALL) NOPASSWD: /usr/sbin/tcpdump' /etc/
˓→sudoers
sudo echo "owlh ALL=(ALL) NOPASSWD: /usr/sbin/tcpdump, /usr/bin/chown" >> /

˓→etc/sudoers.d/owlh
Modify your bpf filter file.
2.6.8 Register your servers
We need to know a little bit about your network. At least, we need to know what are the servers that you want to
capture traffic from.
Please, include in your OwlH server inventory file all your servers /etc/owlh/inventory.json. Define them as needed

but keep json format.
[
{
"id" : "1",
"name" : "agent-1-openrules",
"ip" : "192.168.1.218",
"enabled" : "true",
"active" : "true"
},
{
"id" : "2",
"name" : "agent-2-217",
"ip" : "192.168.1.217",
"enabled" : "true",
"active" : "true"
}
]
2.6.9 Wazuh system
Be sure you have at least one Wazuh manager and elastic stack working before to continue. Please follow Wazuh
documentation.
2.6.10 Integrate OwlH master with Wazuh
Integrate OwlH master with Wazuh is pretty easy. We only need to deploy our Wazuh agent into the OwlH master.
Follow Wazuh agent deploy instructions for RPM packets to deploy the agent.
in summary, you will set up the repository by running the following command:
# cat > /etc/yum.repos.d/wazuh.repo <<\EOF

[wazuh_repo]
gpgcheck=1
gpgkey=https://packages.wazuh.com/key/GPG-KEY-WAZUH
enabled=1
name=Wazuh repository
baseurl=https://packages.wazuh.com/3.x/yum/
protect=1
EOF
and now, install wazuh agent
# yum install wazuh-agent
now, lest register agent into your Wazuh Manager. if you are using authd on your manager:
# register agent
/var/ossec/bin/agent-auth -m 1.1.1.1 -A owlhmaster
A few things here:

1.1.1.1 # is your wazuh manager ip

-A # option means that you want to specify a name other than hostname.
# This command suppose tcp/1515 port used,
# if not, you should change command to include the right port.
Please review, authd documentation or find a different way to register your agent. Register agent documentation
Finally, modify your ossec.conf file to monitor your suricata output
<localfile>
<location>/var/log/suricata/eve.json</location>
</localfile>
And restart your wazuh agent

$ systemctl restart wazuh-agent
2.6.11 Enjoy It
Start Software TAP
# is everything in place?
# start Wazuh
# start Suricata
# start Zeek
# start Flock Controller
2.6.12 If you need help:

2.7 If you need help:


Owlh

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Owlh

Uploaded by

Copyright:

Available Formats

owlh_documentation Documentation

Release 0.4 - Cloud and Bro

Feb 09, 2019

2 Chapter 1. What is OwlH?

2.1 About OwlH

Our target right now is to provide help for:

4 Chapter 2. A few topics

2.1.1 If you need help:

• email our support team - support@owlh.net

2.1. About OwlH 5

2.2 How does it work?

2.2.1 Main components

• OwlH NIDS node

2.2.2 OwlH NIDS node

2.2.3 OwlH Master node

6 Chapter 2. A few topics

2.2.4 Elastic Stack

Data Transport is done in two possible ways.

If you need help:

• email our support team - support@owlh.net

2.3 OwlH - Suricata and Wazuh

2.3.1 How to easily integrate Suricata with Wazuh

• Deploy Suricata or use a Current Suricata deployment

2.3. OwlH - Suricata and Wazuh 7

• OwlH Network IDS Dashboards

2.3.2 Deploy Suricata or use a Current Suricata deployment

8 Chapter 2. A few topics

(continued from previous page)

• Suricata eve-log sample file

2.3.4 Install Wazuh stack if you are not done yet

2.3.5 Install Wazuh Agent in the suricata system

2.3.6 Configure Wazuh Suricata rules to create right alarms

# Default alert level configuration defined in manager ossec.conf file

2.3. OwlH - Suricata and Wazuh 9

# Sample rule modified to create an alert

2.3.7 Configure Wazuh Agent to read the eve.json output file

# Modify ossec.conf - read localfile suricata EVE json log

2.3.8 If you require PCI. Configure OwlH PCI mapping

This must be run on every Wazuh logstash server and it will:

2.3.9 Modify IP data mapping

10 Chapter 2. A few topics

2.3.10 Modify Elastic template

2.3. OwlH - Suricata and Wazuh 11

If you need help:

• email our support team - support@owlh.net

2.4 OwlH - Zeek and Wazuh

2.4.1 Integration Logical Diagram

• OwlH Node - Zeek IDS and Wazuh Agent

12 Chapter 2. A few topics

2.4.2 Configure - Zeek - OwlH Node

2.4.3 Zeek Logs Output format to JSON

Option 1 - Modify ASCII writer output

Option 2 - Use add-json package

To install add-json package you can use bro-pkg tool

Note: bro-pkg installation (http://bro-package-manager.readthedocs.io/en/stable/quickstart.html#installation)*

Note: Thanks to C.L.Martinez and Jan.Grashoefer

Zeek Event Enritchment to help Wazuh ruleset

redef record DNS::Info += {

2.4. OwlH - Zeek and Wazuh 13

(continued from previous page)

Loading Zeek customizations at Zeek start

owlh.bro looks like:

# Select prefered output