Setting up SecurityOnion for monitoring home networks

This is a simple post to explain how to set up a SecurityOnion instance for monitoring a home network.

NOTE: Do not use this guide for setting up a SecurityOnion instance for monitoring production environments!

About SecurityOnion

I could write something here myself but the SecurityOnion Github page does this better:

Security Onion is a free and open source Linux distribution for intrusion detection, enterprise security monitoring, and log management. It includes Elasticsearch, Logstash, Kibana, Snort, Suricata, Bro, OSSEC, Sguil, Squert, NetworkMiner, and many other security tools. The easy-to-use Setup wizard allows you to build an army of distributed sensors for your enterprise in minutes!


The requirements for a home network monitoring setup are not too outrageous, however there is an ElasticSearch instance running which requires some RAM to function properly.

Make sure the machine running the SecurityOnion instance has the following hardware resources at its disposal:

  • Minimum of 2 NICs;
  • 4 CPU cores (this is recommended, it might work with 2);
  • 8GB RAM;
  • 256GB HDD (128GB might be enough, I like to have some overhead);

Other than that you need a managed switch that allows the configuration of a SPAN.

Network Configuration

With the requirements in place it might be useful to visualize the network configuration, please note that the below image is just an example of how the network could be configured to allow the SecurityOnion instance to monitor the network connections.

Diagram of a small home network

The above image displays a very simple network diagram of how a small home network could be monitored with SecurityOnion. This scenario is using a switch with 5 ethernet ports (like the Netgear GS105E).

With SPAN (Port mirroring), all the network traffic that goes through the switch from the different appliances connected, is sent to the port that is configured as the SPAN. In the above image it is set to ETH5. The SecurityOnion instance will be configured to receive the traffic mirrored to ETH5 on its own monitoring port, this is the reason that there is a minimum of 2 NICs required for the SecurityOnion instance; 1 for monitoring and 1 for management purposes.

Installing and Configuring SecurityOnion

Please keep in mind that I will write this in the scenario of using a dedicated machine for the SecurityOnion instance.

With all of the above in mind and explained, continue to download the SecurityOnion installation image from the Github page.


After downloading the installation image you could proceed to create a bootable USB when you want to install the SecurityOnion instance on a dedicated machine, or load it into your Hypervisor of choice and continue the installation process from there.

When booted, click on the icon on the desktop that says Install SecurityOnion 16.04, this will start the installation process. The installation process is pretty straight forward, following this installation like you would if you were to install Ubuntu. When prompted for the installation type, DO NOT encrypt the SecurityOnion installation and DO NOT encrypt the home folder of the user.

After the installation process is finished, select Restart Now


Before you can start monitoring the network traffic there are some configuration steps that need to be completed:

  • Finish the SecurityOnion configuration;
  • Assign a static address to the workstation that will manage it;
  • Activate Analyst mode on the SecurityOnion instance;

SecurityOnion Configuration

To finish the SecurityOnion configuration, boot into the instance and click the icon on the desktop that shows Setup. It will ask for the password of the user since some of the configuration steps will require elevated privileges to successfully apply.

One of the first steps is the configuration of the NICs, check the output of


to see which interface will be the monitoring interface, and which interface will be used for management (this will be the interface that will allow to access the Kibana dashboard, Squert, Sguil, etc.).

In this example the interface with the name of ens33 will be the monitoring interface, and ens34 will be the interface used for management purposes.

Make sure to assign a static IP-address to the management interface that is in the same subnet as the workstation (or other appliance) from which you want to access the dashboards.

When the management interface is configured you can go ahead and configure the monitoring interface, click on Yes, make changes! when done, reboot after.

The second part of the configuration process goes about setting up all the monitoring services on the SecurityOnion instance, click on Yes, skip network configuration, and select Evaluation Mode, follow the steps of the configuration and pick a username and password for the dashboards (Kibana, Squert, Sguil, etc.). When the username and password are set you can click on Yes, proceed with the changes! to finish this configuration.

Before proceeding to enabling the ‘Analyst’ mode on the SecurityOnion, you should configure the machine you want to use for accessing the different dashboards with a static address.

The only thing left to configure is to allow access to the dashboards, this can be done by opening a new terminal and executing the following command:

sudo so-allow

Press ‘a’ to enable ‘Analyst’, this will open up the SSH, HTTPS and Sguil ports for external connections.

executing sudo so-allow

Next it will ask for the IP-address of the appliance that is allowed to connect to either of these ports, fill in the IP-address of the appliance you want to use for the management.

Congratulations, the SecurityOnion instance is now successfully installed and configured, the different dashboards should now be accessible from the machine with the static address you configured earlier.

Monitoring the Home Network

Now that everything is set up you can go ahead and access the different dashboards at https://[SecurityOnion-Address]/

Squert dashboard

The above image displays the Squert dashboard, this dashboard shows a quick overview of the alerts that are triggered with Snort and OSSEC.

Adding Snort Rules

The fun part starts with writing your own Snort rules to detect traffic you want to monitor specifically. I will not go into how to write Snort rules in this blog post, here is a link to the Snort documentation on rule writing.

I will however tell you how to add custom rules to the SecurityOnion instance. After analyzing the traffic you want to detect you can add a Snort rule by following these steps;

sudo vim /etc/nsm/rules/local.rules

Add the Snort rule and save the file with :wq

sudo rule-update

If you built the rule correctly, Snort should be back up and running, to test the rule you will need some traffic that will trigger the rule. You can replay a PCAP on the SecurityOnion instance with the following command:

sudo tcpreplay -i ens33 traffic_to_test_snort_rule.pcap

Check the Squert dashboard to see if the rule you wrote triggered correctly.