Home Security Onion experiences – Part 1

Recently my partner was complaining about very poor internet performance from her computer. I looked at it for a while but without a baseline to compare it to I had no idea what was normal. I thought it was time I starting using security onion to do some snooping on my home network. I had a few spare Mac Mini’s but they were all much older 32bit CPU models. That was fine but I really wanted to play with ELK as well. Looking on eBay I saw that the Mac Mini were holding their value way to well for what I wanted. So I purchased an Intel NUC, Celeron J3455 (4 Core @ 1.5Ghz) with 8GB RAM. I dropped a spare 500gb SSD in to it. I figure for a 3 user house hold that should have more than enough grunt to do the job. I do classify my house hold as a high-tech house. Each person with smart phones, tablets, work/study computers and gaming rigs, etc.

Being a Mac user at home I needed to find a app to convert the .iso file into a bootable USB. I found that UNetbootin (https://unetbootin.github.io) did the job rather nicely. I did have some initial problems with the Verbatim 8GB USB stick. It would not boot. Having a look at the USB stick it appeared there was only 80MB of files on it. Which didn’t seem right. I used a SanDisk 8GB with UNetbootin and there was 2GB of files and it installed Security Onion all ok. So just a warning about old & cheap USB drives.


Installed and rebooted, I called my host seconion. Then ran the Setup, which configured the networking. I was going to admin the NUC over wireless and have it capture everything over the copper. I just needed to figure out which interface was which. I opened up the ‘Network’ window under the top right hand corner. This showed me a Wi-Fi connection but didn’t name the interface. Checking the wired connection displayed the MAC address for it. Opening up a terminal window I typed ‘ifconfig’ to display the available networking. I could see that the copper was enp3s0 and the wireless had to be wlp2s0. It recommended a static IP so I set it to After setting the subnet mask, gateway, DNS I was prompted for the sniffing interface which I set as enp3s0. After that it was another reboot.

After the reboot the wireless no longer connected to my wireless network. A quick bit of googling and I found that was expected. The network configuration script doesn’t handle wireless. Which makes sense in a way because of SSID / passwords etc. Still being new I needed to do a lot more searching before I found a few handy posts.
https://askubuntu.com/questions/330026/configure-connect-wireless-network-through-the-command-line-in-ubuntu-12-04 and https://prupert.wordpress.com/2010/06/25/how-to-configure-wireless-wifi-networking-in-ubuntu-via-the-command-line-cli/ were the two posts I needed. What I did was

sudo su -

I then copied the result hex string. I was going to need that shortly

vi /etc/network/interfaces
iface wlan0 inet static # dhcp or static
netmask #change this as appropriate for your network, this value is usually right
gateway #change this as appropriate for your network
address #only needed for a static IP address
dns-nameservers #only needed for a static IP address
wpa-driver wext #you shouldn’t need to change this
wpa-ssid YOURSSID #just type the name of your SSID here
wpa-ap-scan 1 #if the name of your SSID is hidden usually, type 2 instead of 1
wpa-proto RSN #if you use WPA1 type WPA (why are you using WPA?!), if you use WPA2 type RSN
wpa-key-mgmt WPA-PSK #usually WPA-PSK (if you share a key) but sometimes WPA-EAP (for enterprises)
wpa-psk YOURHEXKEYFROMABOVE #the hex key that you generated earlier

I then did a reboot and I could now access the wireless network again. I could ping out and other hosts could ping it. That was good enough for now.

Running the setup again it detects that networking has been configured. It then prompted me to select ‘Evaluation mode’ or ‘Production mode’ for a home network Evaluation mode sounded perfect. I selected enp3s0 as the interface to be monitored.

The setup script then had me setup a user for Kibana, Squert and Sguil.2

A polite pop up at the end of the install let me know that setup logs where in /var/log/nsm/sosetup.log, and that bro logs would be hiding in /nsm/bro/
A sostat will give detailed info about service status, sostat-quick will give me a guided tour of the sostat output, sostat-redacted will give me redacted info to share with the Security Onion mailing list.
The location for downloaded rules from Pulledpork were in /etc/nsm/rules/downloaded.rules local rules should be added to /etc/nsm/rules/local.rules and that I could have PulledPork modify the rules by modifying the files in /etc/nsm/pulledpork/ and that the rules would be updated every morning and I could do a manual update rule-update. Also I could tune sensors by modifying the files in /etc/nsm/name-of-sensor/
The 3rd last message was very important and I had glossed over it the first time. The local ufw firewall is configured to only allow port 22. If I needed to connect over other ports I needed to run sudo so-allow.
The 2nd last pop-up was a reminder to check out the website, FAQ,Wiki, IRC channel etc for help. The very last pop-up of what felt like about 10 was a reminder that professional support was provided if required.

I then modifed the firewall. I wanted my host to be a syslog device and I wanted to be able to manage it from my local network.

justin@seconion:~$ sudo so-allow
This program allows you to add a firewall rule to allow connections from a new IP address.

What kind of device do you want to allow?

[a] - analyst - ports 22/tcp, 443/tcp, and 7734/tcp
[b] - Logstash Beat - port 5044/tcp
[c] - apt-cacher-ng client - port 3142/tcp
[f] - Logstash Forwarder - Standard - port 6050/tcp
[j] - Logstash Forwarder - JSON - port 6051/tcp 
[l] - syslog device - port 514
[o] - ossec agent - port 1514/udp
[s] - Security Onion sensor - 22/tcp, 4505/tcp, 4506/tcp, and 7736/tcp

If you need to add any ports other than those listed above,
you can do so using the standard 'ufw' utility.

For more information, please see the Firewall page on our Wiki:

Please enter your selection (a - analyst, c - apt-cacher-ng client, l - syslog, o - ossec, or s - Security Onion sensor, etc.):
Please enter the IP address of the analyst you'd like to allow to connect to port(s) 22,443,7734:
We're going to allow connections from to port(s) 22,443,7734.

Here's the firewall rule we're about to add:
sudo ufw allow proto tcp from to any port 22,443,7734

We're also whitelisting in /var/ossec/etc/ossec.conf to prevent OSSEC Active Response from blocking it. Keep in mind, the OSSEC server will be restarted once configuration is complete.

To continue and add this rule, press Enter.
Otherwise, press Ctrl-c to exit.

Rule added
Rule has been added.

Here is the entire firewall ruleset:

UFW Rules

To Action From
-- ------ ----
22,443,7734/tcp ALLOW 
22/tcp ALLOW Anywhere 
22,443,7734/tcp ALLOW 
22/tcp (v6) ALLOW Anywhere (v6)

Docker IPTables Rules

To Action From
-- ------ ----

Added whitelist entry for in /var/ossec/etc/ossec.conf.

Restarting OSSEC Server...

I selected a. It was going to open the ports 22,443,7734 but I needed to put in an IP address. I didn’t want a single IP, I wanted a range. So I put

justin@seconion:~$ sudo ufw status
Status: active

To Action From
-- ------ ----
22,443,7734/tcp ALLOW 
22/tcp ALLOW Anywhere 
22,443,7734/tcp ALLOW 
22/tcp (v6) ALLOW Anywhere (v6)

I then re-ran it and allowed syslog connections as well.

I was up and running. Now time to plug in between my switch and router.




Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s