First off, what exactly is Security Onion and why do I care about this? From their website, it is described as: “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, Wazuh, Sguil, Squert, CyberChef, 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!”
Sounds awesome right? And the best part of all of this is that it’s free!
There are a couple different ways (that I know of) that you can set this up. If you have a spare computer that you don’t mind dedicating to becoming your Security Onion, or if you have a system dedicated to being an ESXI server. Luckily for you, I’ve done both!
Before we get started, it is important that you have the capability to create a SPAN port on your local network. A SPAN port, for those that don’t know is a port that is set up to mirror other ports on a switch. If you don’t have a switch and are looking to purchase one, here is what I’m currently using. You’re going to want a managed switch for this task.
Another thing that you’ll need is at least two network interface cards (NICs) on your system. If you’re using an old computer just laying around that only has one, you can use USB NICs! When I had this set up on a spare laptop these are the ones I used.
Once you have these things you’re ready to start setting everything up! First, you have to decide which way you’re choosing to set this up.
A dedicated Security Onion computer is the easiest, but not the most beneficial in terms of losing an entire computer for one task.
Setting up ESXI is a little more daunting to most, but overall a simple process! You may be wondering, “but why can’t I set this up in Workstation Pro and virtualize it that way!?”. The simple answer is, you can. But you won’t be able to properly read traffic from throughout the network. Workstation does not allow you to properly create SPAN ports unfortunately.
Dedicated Computer Solution
For a dedicated computer solution you’re going to want to start with downloading the Security Onion ISO. Once this is complete we’re going to flash this data to our HHD/SSD. I used etcher to accomplish this.
After this step is done we just need to install the drive back into our computer and power it on. If everything worked correctly you should be booting into Security Onion and you can begin the setup process.
ESXI Server Solution
Like the dedicated computer solution, first we need to change what our computer boots into. We’re going to boot into ESXI which can be downloaded here. You’ll have to register for an account (it’s free) and then you can download an ISO. They’ll also give you a free license key! Though, there are some limitations, but they more than likely won’t effect you. Unlike our dedicated computer installation, the ISO you download will be an installer. I would use a USB for this process, especially if you only have one HDD/SSD installed on the designated computer.
Once everything is installed for ESXI we need to configure the settings needed for Security Onion. The first thing we need to do is add another virtual switch which allows for port mirroring. Once logged in, on the left hand panel click on <networking> and then <Virtual Switches>. There should be an option to add a standard virtual switch.
Once our switch is created, we need to create a port group. This is done by clicking <networking, and then <port groups>. We add a new group and assign it to the virtual switch we created in the previous step.
The next step is to upload our Security Onion ISO to the datastore. If we hit <storage> and <datastore browser> we can see everything currently inside of our datastore. If this is a fresh install it should only contain a folder called “.sdd.sf”. So we’re going to create a new directory for our ISO’s and upload our Security Onion ISO using the <upload> button within the datastore browser.
Once everything uploads we’re ready to create our VM! If we hit <virtual machines> followed by <Create / Register VM> we’re able to define everything we want for our project. Once you get to where you are able to define what settings are used in the VM you’re going to want to assign your second network adapter as well as specify to use a Datastore ISO file.
Setting up Security Onion
Now that we’ve got everything up to this point, the next step is to install the operating system. There should be an icon on the desktop that just needs to be double-clicked.
Once completed, we can begin our actual setup process. At this point, it’s important to know which interface is assigned to our SPAN port. I like to check MAC addresses to ensure everything is proper. We can begin by hitting that Setup icon. Through a series of prompts you will get to one which asks whether or not you want to configure your network interfaces. The answer is yes, and next it will ask which interface you would like to use as a management interface. This is NOT going to be our interface plugged into our SPAN.
The setup will then ask whether or not you’d like a static IP vs one assigned via DHCP. The setup suggests a static IP, this is because that IP will always be reserved for this device instead of DHCP where the IP can change based on how our network is set up. We’ll set this up with a static IP of <192.168.1.125>, a netmask of <255.255.255.0> and a gateway of <192.168.1.1>. Your settings can be different based off of your network. These are just settings that work with mine.
After this, we will enable our sniffing interface, this is the interface which is connected to our SPAN port. If you only have two NICs then there should only be one device left to choose. Once completed we are prompted to restart our system, which we do. Following our restart we can begin the second phase of the setup process. Once again, we hit the setup button.
Since we’ve already completed the network configuration we’re going to skip this task. For ease of use, we’re going to also choose <Evaluation Mode> instead of <Production Mode>. If you would like more granular control over your system I would recommend <Production Mode>. Feel free to continue on with the setup process until you create your user account. This will be the account that is used to access Kibana, Squert, and Sguil.
Once we confirm these are the settings that we wish, the system will go about configuring everything for us. This process can take a bit of time, so feel free to grab a coffee or something. Now we’re good to go right!? Sort of. Now we need to allow access to our management network so we can access it outside of the security onion machine.
We see that there are a ton of different options that we can choose from. Though the one we care about right now is option a. So we choose that and allow anything on our network to talk to the management interface.
Now we are pretty much all set up. We can access our Kibana interface and see everything that is coming through our network now.
But wait! There’s more!
We can take this a step further and forward our Windows event logs to our Security Onion machine automagically! This can be done with a combination of Sysmon and Winlogbeat. We’re going to install both Sysmon and Winlogbeat on any/all Windows machines on our network that we wish to monitor.
Sysmon all the things
For our Sysmon setup, we’re going to go with the setup done by InfoSec Taylor Swift via the resource setup on their Github. We just need to drop the sysmonconfig-export within our Sysmon folder like so. Here’s a great article on how to install Sysmon!
Winlogbeat for the win!
Now that we have Sysmon set up, we need to configure Winlogbeat to send our data off to our Security Onion. We can also add in different event logs to forward. Here is a sample of what the winlogbeat.yml should look like. You should be able to just copy and paste this over your existing file and be good to go. Here’s a great article on how to install Winlogbeat!
###################### Winlogbeat Configuration Example ########################### This file is an example configuration file highlighting only the most common
# options. The winlogbeat.reference.yml file from the same directory contains all the
# supported options with more comments. You can use it as a reference.
#
# You can find the full configuration reference here:
# https://www.elastic.co/guide/en/beats/winlogbeat/index.html#======================= Winlogbeat specific options ==========================# event_logs specifies a list of event logs to monitor as well as any
# accompanying options. The YAML data type of event_logs is a list of
# dictionaries.
#
# The supported keys are name (required), tags, fields, fields_under_root,
# forwarded, ignore_older, level, event_id, provider, and include_xml. Please
# visit the documentation for the complete details of each option.
# https://go.es.io/WinlogbeatConfig
winlogbeat.event_logs:
— name: Application
ignore_older: 72h- name: Security- name: System- name: Windows PowerShell- name: Internet Explorer- name: OpenSSH/Operational- name: OpenSSH/Admin- name: Microsoft-Windows-Winlogon/Operational- name: Microsoft-Windows-Windows Defender/WHC- name: Microsoft-Windows-Windows Defender/Operational- name: Microsoft-Windows-PowerShell/Operational- name: Microsoft-Windows-PowerShell/Admin- name: Microsoft-Windows-LSA/Operational- name: AMSI/Operational- name: Microsoft-Windows-Sysmon/Operational
processors:
-script:
lang: javascript
id: sysmon
file: ${path.home}/module/sysmon/config/winlogbeat-sysmon.js#==================== Elasticsearch template setting ==========================setup.template.settings:
index.number_of_shards: 3
#index.codec: best_compression
#_source.enabled: false#================================ General =====================================# The name of the shipper that publishes the network data. It can be used to group
# all the transactions sent by a single shipper in the web interface.
#name:# The tags of the shipper are included in their own field with each
# transaction published.
#tags: [“service-X”, “web-tier”]# Optional fields that you can specify to add additional information to the
# output.
#fields:
# env: staging#============================== Dashboards =====================================
# These settings control loading the sample dashboards to the Kibana index. Loading
# the dashboards is disabled by default and can be enabled either by setting the
# options here, or by using the `-setup` CLI flag or the `setup` command.
#setup.dashboards.enabled: true# The URL from where to download the dashboards archive. By default this URL
# has a value which is computed based on the Beat name and version. For released
# versions, this URL points to the dashboard archive on the artifacts.elastic.co
# website.
#setup.dashboards.url:#============================== Kibana =====================================# Starting with Beats version 6.0.0, the dashboards are loaded via the Kibana API.
# This requires a Kibana endpoint configuration.
#setup.kibana:# Kibana Host
# Scheme and port can be left out and will be set to the default (http and 5601)
# In case you specify and additional path, the scheme is required: http://localhost:5601/path
# IPv6 addresses should always be defined as: https://[2001:db8::1]:5601
#host: “192.168.1.125:5601”# Kibana Space ID
# ID of the Kibana Space into which the dashboards should be loaded. By default,
# the Default Space will be used.
#space.id:#============================= Elastic Cloud ==================================# These settings simplify using winlogbeat with the Elastic Cloud (https://cloud.elastic.co/).# The cloud.id setting overwrites the `output.elasticsearch.hosts` and
# `setup.kibana.host` options.
# You can find the `cloud.id` in the Elastic Cloud web UI.
#cloud.id:# The cloud.auth setting overwrites the `output.elasticsearch.username` and
# `output.elasticsearch.password` settings. The format is `<user>:<pass>`.
#cloud.auth:#================================ Outputs =====================================# Configure what output to use when sending the data collected by the beat.# — — — — — — — — — — — — — Elasticsearch output — — — — — — — — — — — — — — —
#output.elasticsearch:
# Array of hosts to connect to.
#hosts: [“localhost:9200”]# Enabled ilm (beta) to use index lifecycle management instead daily indices.
#ilm.enabled: false# Optional protocol and basic auth credentials.
#protocol: “https”
#username: “elastic”
#password: “changeme”# — — — — — — — — — — — — — — — Logstash output — — — — — — — — — — — — — — — —
output.logstash:
# The Logstash hosts
hosts: [“192.168.1.125:5044”]
#loadbalance: true# Optional SSL. By default is off.
# List of root certificates for HTTPS server verifications
#ssl.certificate_authorities: [“/etc/pki/root/ca.pem”]# Certificate for SSL client authentication
#ssl.certificate: “/etc/pki/client/cert.pem”# Client Certificate Key
#ssl.key: “/etc/pki/client/cert.key”#================================ Processors =====================================# Configure processors to enhance or manipulate events generated by the beat.processors:
— add_host_metadata: ~
— add_cloud_metadata: ~#================================ Logging =====================================# Sets log level. The default log level is info.
# Available log levels are: error, warning, info, debug
#logging.level: debug# At debug level, you can selectively enable logging only for some components.
# To enable all selectors use [“*”]. Examples of other selectors are “beat”,
# “publish”, “service”.
#logging.selectors: [“*”]#============================== Xpack Monitoring ===============================
# winlogbeat can export internal metrics to a central Elasticsearch monitoring
# cluster. This requires xpack monitoring to be enabled in Elasticsearch. The
# reporting is disabled by default.# Set to true to enable the monitoring reporter.
#xpack.monitoring.enabled: false# Uncomment to send the metrics to Elasticsearch. Most settings from the
# Elasticsearch output are accepted here as well. Any setting that is not set is
# automatically inherited from the Elasticsearch output configuration, so if you
# have the Elasticsearch output configured, you can simply uncomment the
# following line.
#xpack.monitoring.elasticsearch:
Last step!
Now we just need to head back to our Security Onion and run the <so-allow> command again! But we’re going to select option <b> to allow Logstash Beat through the firewall. It should look something like this.
Now, if everything is up and running properly. You should be able to monitor your home network using Security Onion. Hopefully you found this helpful!
