Security Onion


The other day, I came across an interesting looking security suite called Security Onion. The author doesn't like the term distro, as it is more based on Ubuntu with extra packages, than a custom distribution like Kali. The main purpose of the distribution is a quick and easy distributed NSM platform.

NSM, or Network Security Monitor, is like an IDS. It differs by using multiple sources of information, and different analysis tools to find the bad packets. in addition, Security Onion is meant to become an IPS, so the rule-sets are never "dumbed down". This means you always see the alert, even if you do nothing. A false positive on an IPS is bad, but it may mean you miss something.

In Security Onion, there are three different types of  deployment, Standalone, Sensor or Server. A Standalone installation contains both a server and one or more sensors. After the break, I'll describe the parts in a bit more detail.

The server part of security onion is perhaps the easiest to describe. It is the hub and collection center of the alerts generated by the sensors. The server only receives alerts from the sensors, so the data between the sensors and the server is minimal. The bandwidth can be increased, as packet captures may be required, along with other data sources. This data is then view-able by a few different methods, including an application or a web page.

The sensors do the actual detection of the data, apply detection filters to the data and store the data. The alerts are also passed on to the server (or standalone). The main detection method is via packet capture, and then applying rules to the captures via the Bro or Snort / Suricata rule-set.

The standalone version is both parts combined, and is what I installed on my VMware ESXi home server. The VM has one leg in my Pen Test vlan, and another in my main DMZ, along with my Honeypot (running on Honeydrive) and web server. The second interface was configured to just start automatically, and not have an IP address. This set up allows me to manage the server remotely, via the pentest vlan and monitor the DMZ without either the DMZ knowing I'm there, or me interacting with the packets in anyway. The later is important, as if I want a forensically sound capture, I'm one step towards it. Whether the internal VMware switches are capable of providing a forensically sound capture, is another matter.

 Installation of the VM was easy. I booted the server initially as a live CD, then ran the installer from the desktop. Once complete, I ran the set up program to configure networking and set up services. Once the platform was installed, I waited for the packets to roll in. And roll in they did.

Within the first hour, I had my first 6 "high severity" alerts listed in Snorby. It seems that someone had decided to try the shell-shock vulnerability against my web-server. The attack appeared to be from an automated script. My web-server runs FreeBSD, and if the attacker knew anything about FreeBSD, they should know that Bash isn't the default shell. It's not even installed by default. They also seem to be looking for a particular location on the web-server for a vulnerable script. Initially, the attacker was looking at either the index page or /. The index page on the web-server is called "index.php" which should give a clue that isn't no a cgi program, and no bash, but they tried anyway.

The information was interesting, and provided me with a new fascination of what is happening on my home DSL line. For the next day, I watched the alerts come in. Mostly not so dramatic, but certainly lots of them. There were a few thousand alerts by the end of the first day. Mostly packets out of sequence, which leads me to question the soundness of the tap on the built in VMware switch.

Once I had clicked around Snorby, I then found how to pass the packet captures in to CapME! Once in CapME!, I was able to view the flow in the web browser as either packets, or how Bro sees the transactions. The packets themselves were available as a clickable link to download. This lets you look at them in either wireshark or Network miner. Both of these programs ship with Security Onion, and are available if you have web browser looking at the local host. 

 The fun also continued with the sguil interface. Again, this allows you to look at the alerts coming in, and classify them. Additional analysis can then be used to analysis them further.

For more information on Security Onion, have a look at the following links:

Security Onion Website

Security Onion Videos


Display comments as (Linear | Threaded)

    No comments

Add Comment

Enclosing asterisks marks text as bold (*word*), underscore are made via _word_.
Standard emoticons like :-) and ;-) are converted to images.
E-Mail addresses will not be displayed and will only be used for E-Mail notifications.
To leave a comment you must approve it via e-mail, which will be sent to your address after submission.
You can use [geshi lang=lang_name [,ln={y|n}]][/geshi] tags to embed source code snippets.
You can use [geshi lang=lang_name [,ln={y|n}]][/geshi] tags to embed source code snippets.

Submitted comments will be subject to moderation before being displayed.