This guide is NOT aimed at the advanced Security Onion user.
The amount of information and documentation available from the official SO WIKI is very impressive and comprehensive. Therefore this guide has been created mainly to extract and present some key information on installing and running SO in a different light, maybe in a more layman's way. It also combines information from many different sources, hoping to save time for the reader who may be faced with some similar hurdles as the author faced when setting up SO the first time.
There is also a very active support forum, available here , where Doug Burks himself seems to be spending a lot of his time answering questions very quickly and always being very helpful. Please note this guide was written with a Home Network in mind, with only one instance of SO running within a VM and therefore not using any nodes. Some information are still relevant to a commercial environment but the basic SO and Network configuration section would be different.
Installing SO is fairly straightforward; there are also many guides out there on how to configure it. However, getting value out of it takes some time and effort, especially if your network/security/linux skills are a bit rusty.
We have been using SO for some time and found it extremely useful in detecting and understanding risks related to surrounding network activities. It has helped us detect malware, miss-configured applications, ad-aware/monitoring activities, vulnerable clients/servers, etc. Obviously, at the core of it, there is Snort or suricata, but what SO provides is a nicely bundled framework to quickly and easily deploy those technologies and visualize their results in a meaningful way.
How meaningful and useful SO can be, will depend on 3 factors:
In order to achieve the above, this guide will cover the following topics:
- 1. Define a suitable network infrastructure
- 2. Define a suitable server configuration
- 3. Install and configure a basic SO instance
- 4. Rules Tuning
- 5. Get automated daily and weekly Snorby report emails
- 6. Get "live" automated emails sent for specific alerts
- 7. Install Splunk as a complementary mean to inspect/search data
- 8. Remotely Connect to Splunk and Snorby
- 9. How to clean SO data if you want to start afresh whilst keeping your settings
- 10. How to go further
All the information discussed below is available in some shape or form in the Security Onion WIKI and by doing a few Google searches. Hopefully, having it all centralized into one article/guide will help some of you to go from a nice ISO image sitting in your download folder to a fully functioning NSM providing relevant alerts.
1. Define a suitable network infrastructure
You need to be able to see as much network traffic as possible in order for SO to analyze it. The best, and probably only option!, is to create a network TAP or SPAN port on your router.A typical home setup is either one of the following environments:
B. Internet -> (Optional Fibre Router) -> ISP Modem Router -> WIFI Router -> Client (Ethernet and WIFI)
In either case you want to see the network traffic from/to the Internet and the Clients.
In an ideal world you would also want to see traffic between WIFI clients. However, despite all the tests we have done and the different routers we have tested, there were no solutions to see INTRANET Wifi traffic, simply because such traffic is usually going through a dedicated local bridge that is not possible to duplicate. If anyone has managed to do that, we would love to hear from you! And yes, we did play with DD-WRT/Tomato, iptables, mangle rule, etc.
One area to explore would be to use some kind of MiM server pretending to be your WIFI MAC address but that will be for a future article :)
There are different ways to create such TAP/SPAN, below are two possible examples:
B. Internet -> (Optional Fibre Router) -> TAP: Modem Router-> WIFI Router with NAT Disabled -> Clients (Ethernet and WIFI)
The 2 key elements are for your NAT to be disabled on your WIFI router and for you TAP to be installed between your WIFI router and the Internet. The TAP will, of course, have to be connected to your SO instance.
The reason we need NAT disabled is to see individual IP from your WIFI network rather than just the WIFI gateway IP (likely to be 192.168.X.1)
We have had some success with option A by using the Netgear GS-105E as a TAP, it can easily be configured to duplicate its ethernet ports to a dedicated SPAN Ethernet port and cost only about £20. Note that if you are using an Apple TimeCapsule/Router it implements a slightly different version of NAT and you should be able to keep NAT ON and still see individual WIFI client IP addresses. It is the only router we witnessed this behavior.
With Option B, the best Modem Router we found is the Mikrotik RB2011Ui . It is an amazing router which has an incredible array of options, it might be a bit daunting for some as it requires quite a few tweaks and manual configuration but at around £80 it is still quite cheap. Did we mentioned it has a touch screen too? ;)
You can configure that router to duplicate an ethernet port to a SPAN port which you would have to connect to your SO instance.
With such setup you should be able to see individual traffic from/to the internet and your network clients, as well as being able to see each individual IP.
2. Define a suitable server configuration
Although you can run SO on a dedicated server, it is quite convenient to actually run it on a Virtual Machine and this is what we will be doing for this guide, using VMWARE.
Whatever environment you choose, the hosting server must have 2x network interfaces: 1x for Management (i.e: WIFI connection) and 1x for monitoring (i.e.: Ethernet connection).
For better efficiency, and less packet drops, the monitoring interface should not have any IP addresses assigned to it. On a MAC this means turning off IPv4 configuration.
Further Hardware requirements information is available on the Security Onion Wiki
We assume your hosting environment is connected to the Internet via a WIFI connection and that you have an ethernet port which is enabled but not setup (no IP configuration)
In VMware, the steps required are:
3. Install and configure a basic SO instance
If you have time and want more detailed information, the following 3x links will explain all the steps you need to install and configure SO:If you are in a hurry, below is a summary of the steps we used to install SO version 12.04.5.1:
You should also Install VMWARE Tools, with more details available in this install guide
Below is a summary of the steps we used to install VMwaretools on SO:
NOTE that you are very likely to get an error message when trying to compile the VMwaretools and enabling host file sharing. Look out for error messages involving the vmhgfs.ko file. If this occurs, interrupt the installation and then follow the instructions from a previous post we recently published explaining how to fix that problem .
Configure your installation
You may want to also check the post installation recommendation from the SO WIKI
Customise your network settings (needs root access)
Edit the following 3 files in /etc/nsm/yourMONITORINGinterface/ (likely eth1) snort.conf
suricata.yaml (in case you use it later)
prads.conf
To apply the changes run: nsm_sensor --restart
To quickly and visually confirm your installation is working, from a terminal as root run the following command: etherape (to install: apt-get install etherape)
Select the Capture interface to be eth1, and you should see network traffic from all the active clients on your network.
etherape value is limited, but it has a nice eye candy feel to it, and provides a very visual cue as to how much activity is occurring on your network.
4. Rules Tuning
The best place to tune your IDS alerts is to read the relevant SO WIKI Section
Snort tuning
The key for SO to be effective is to eventually remove as much false positives as possible and only get alerted of new or real warnings.
To do so, you need to update the following file: /etc/nsm/rules/threshold.conf
Suppress those noisy/false positive rules by adding some "suppress lines" to the threshold.conf file
You can suppress those rules in different ways:
Disable the rule for every client:
suppress gen_id 1, sig_id 2002334
Disable the rule for a specific IP (by_src or by_dst)
suppress gen_id 1, sig_id 2002334, track by_src, ip 192.168.2.45
Disable the rule for an ip range (by_src or by_dst)
suppress gen_id 1, sig_id 2002334, track by_src, ip [192.168.2.45, 192.168.2.56]
You can also use a subnet such are 192.168.2.0/24
Note that for the changes to take effect you need to run the following command:
$ sudo rule-update
Finally, to test your SO instance can detect and alert when signatures are detected, you can create a local rule which will generate a warning if a ping traffic is detected originating from SO:
Edit the file /etc/nsm/rules/local.rules, and add the following line where SO_IP is the IP of your SO instance:
alert icmp SO_IP any -> any any (msg:"ICMP test"; sid:10000001;)
To trigger the alert, from your SO machine, ping google.com or any other external IP address (remember you are unlikely to see internal WIFI traffic, so pinging another WIFI client would not be detected)
Sguil tuning
You should inspect and manage the events in Sguil everyday, its database doesn’t grow too big.
Another way is to auto categorize events:
More information and examples are available in this article.
5. Get automated daily and weekly Snorby report emails
Snorby generates great and easy to read reports: daily/weekly/monthly. They provide a quick overview of your top IDS signatures as well as your source and destination addresses.$ sudo su www-data -c "cd /opt/snorby; bundle exec rake snorby:update RAILS_ENV=production"
6. Get "live" automated emails sent for specific alerts
In addition to receiving daily/weekly/monthly report, you may want to receive an email alert when a specific signature is found on your network. This can be very useful in helping identify what triggers an alert by being notified when it happens.The following steps will allow you to configure the same GMAIL account used in the previous Snorby section. The information has been taken from this runabove article and this SO WIKI article
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl/sasl_passwd
smtp_sasl_security_options = noanonymous
smtp_tls_CAfile = /etc/postfix/cacert.pem
smtp_use_tls = yes
$ sudo postmap /etc/postfix/sasl/sasl_passwd
If the above file is empty, it is because you have ELSA enabled. So instead, launch ELSA, click in the left-menu on "Host Logs -> Syslog-NG (program) -> postfix/smtp"
If you really want to get logs (duplicated) in /var/log/ then you should read this article
You can also read the runabove article which contains further information and is where the above steps were taken from.
You can now forward local emails
Following instructions from this webpage, lets forward all emails sent to root@localhost to your gmail account:
$ sudo service postfix restart
Configure Sguil to send emails against specific detected signatures
set SMTP_SERVER localhost
set EMAIL_RCPT_TO "root@localhost"
set EMAIL_FROM "root@localhost"
set EMAIL_CLASSES "successful-admin trojan-activity attempted-admin attempted-user"
set EMAIL_PRIORITIES "0"
set EMAIL_DISABLE_SIDS "0"
set EMAIL_ENABLE_SIDS "10000001"
The SID "10000001" is the test rule we created earlier and generated with a ping
You can also specify different classes and priorities (1 to 5) if you want broader email alerts
Note that emails will only be sent for new *type* of events in Sguil.
Thus if you notice you don't receive any emails but the signature do get logged: logon into Sguil, locate the event you were expecting an email for, select it and press F8.
This will expire the event, basically clearing it from Sguil which means next time it occurs it will generate an email. You have to repeat this "F8" step if you want to receive further emails on a specific event.
Reducing the number of automated emails:
Bro can be quite noisy, to reduce the number of automated emails its sends, you can opt to remove the hourly connection summary report by editing “/opt/bro/etc/broctl.cfg” and add the following line:
mailconnectionsummary = 0
Then restart Bro:
sudo nsm_sensor_ps-restart --only-bro
7. Install Splunk as a complementary mean to inspect/search data
SPLUNK is a great log management tool, it does not come with SO but installing it is a great addition. It will allow you to search/mine data further against a specific IP address you might be interested in, as a result of a Snort/suricata alert.It has an SO module that integrates really well to an SO instance
To download Splunk you will need to register first, but that's free!
Below are the steps required to install Splunk on SO:
$ cd /opt/splunk/bin
$ sudo ./splunk start —accept-license
$ sudo ./splunk enable boot-start
Installing Flash
To get some of the nice (but maybe pointless) animation in the Security Onion App for Splunk, you need to install Flash and use Firefox
The reason you need to use Firefox is because there isn't a flash version for Chrome in 64 bits available.
Installing the Splunk Security Onion App
Before configuring Splunk, we are also going to download a few "apps" for it, remember where you save those files as we will be using them later.
Log back in Splunk by going to http://localhost:8000 in a FIREFOX browser. You can use Chrome but the Flash animation will not work, especially the nice SOStats data flow. If the SOStats dashboard is empty, it is easy to recreate an impressive one by creating 4 splitters and daisy chain them: (traffic flow) -> src_port -> src_ip -> dst_ip -> dst_port
If you click on the Splunk logo on the top left corner of your browser, on the left you will see the Security Onion App with all your network data ready to be inspected!
Set retention policy
The default retention time is 6 years with a default index size of 500Gb.
This is not fit for our VM configuration, we will therefore change it to 32 days and 10Gb
Upgrading Splunk
From time to time you might want to install new Splunk versions. You will be notified of new versions when you logon to the Splunk Web Interface
When you see such an upgrade notice:
If you ever get a problem with geoip after an upgrade, complaining it cannot find GeoLiteCity.dat, you can do the following:
We only witnessed this error once when upgrading from a previous version of Splunk. The newer version should not have that problem.
8. Remotely Connect to Splunk and Snorby
The following instruction were taken from this EyeIS article and will allow you to remotely connect to the Splunk, SO Home and Snorby Web Interface from a different system (computer, tablet, or even phone!)The approach uses an SSH tunnel and is really easy to setup. On your Security Onion/Splunk server you’ll want to make sure SSH is enabled in Uncomplicated Firewall (ufw).
https://localhost:443 – SO Home/Squert
https://localhost:444 – Snorby
9. How to clean SO data if you want to start afresh whilst keeping your settings
Database wipe (This is quite a drastic option)To wipe most of the traffic/log data you just need to restart the setup procedure, by clicking on the SETUP icon on the desktop.
You can use all the default options and skip the initial network setup.
This process will keep your Snort rules, Sguil and Snorby email settings.
You will have however to re-upload your hostname list in Snorby
Sguil data wipe
Edit the file: /etc/nsm/securityonion.conf
Change the value of DAYSTOKEEP to a low number (i.e. 1 or 7, for 1 or 7 days)
$ sudo sguil-db-purge
Change back the DAYSTOKEEP in /etc/nsm/securityonion.conf to whatever value you had
Snorby data wipe
You will only save a bit of disk space by doing that after doing the previous steps.
This will also remove any custom configuration you may have had in Snorby, including asset names.
The command to run as root is: so-snorby-wipe
Splunk data wipe
Locate spunk folder by running the following command:
$ whereis spunk
Go to the binary folder of spunk (most likely /opt/splunk/bin)
$ sudo ./splunk stop
$ sudo ./splunk clean eventdata
10. How to go further
Add Asset names to Snorby
When looking at your local network traffic in Snorby it is easier to see hostnames rather than just IP addresses.
You have 2 options to do this, either use static IP addresses for each of your clients on your network, or reserve DHCP addresses.
Whatever option you choose, you should maintain a text file with the following format for each entry/line:
IP,Hostname
i.e.: 192.168.0.5, Laptop_son
You can import that list in Snorby by going to Administration -> Asset Manager -> Upload Name Data -> Choose File -> Upload CSV
Alerts will now display the hostnames, if known, rather than just an IP. On a local network you should know each active IP, making it easier to investigate alerts. And if you detect a local IP without a hostname, this may be the sign of a rogue device (or guest!)
Add Asset names to /etc/host
You can also add an IP to hostname mapping at the OS level, this may be useful with etherape and other network tools.
The format for the /etc/host file is:
IP (tab) Hostname
i.e.: 192.168.0.5 Laptop_son
Other useful tools/commands provided by SO (and from the post setup screen)
Random useful unix commands
du -h (folder)
Blogger Comment
Facebook Comment