Helping the Seekers – how to place “security onion”

Monitoring activity on this site gives me a glimpse into what search terms are drawing people here and I’ve always found the results interesting. Search terms are hardly a cry for help, but they usually are a whisper in the dark and can highlight issues people are dealing with and particularly where they might be struggling to find answers.

So I bring you “Helping the Seekers.” As search terms bubble up the list in frequency, I’ll periodically spotlight a few and try to have something to help out the next person who comes along. Since the release of the Security Onion Splunk app, “how to place ‘security onion'” has bubbled towards the top. The fun part is going to be trying to cover all the possible intentions behind that search term.

The answer to the “how to place ‘security onion'” question, regardless of the size of your network, is first at your entry/exit points to the Internet (aka gateway or egress points) just inside your firewall or Internet router. Security Onion can then monitor all traffic coming into or out of your network. If you can get eyes on that traffic, you’ll quickly be able to assess the state of your network and be in position to respond if an incident did/does occur. Fronting critical servers is also highly recommended, such as authentication servers, DNS, SQL, Microsoft SCCM/SMS and anywhere else critical data rests or traverses.

Why wouldn’t you want to put it outside of your firewall? Well, you could, but you lose visibility of your internal hosts as the sensor will not see any of your private IP addresses, only the public IPs from the gateway router/firewall. The Internet is a very noisy place and by placing the sensor just inside the firewall, the sensor will only monitor traffic that is specific to and allowed by your network and firewall.

(This is where I get on my hobby horse about running Security Onion. Whether you know what you’re doing or not, it’s pretty easy and affordable to setup and maintain. Just pet Sguil and Snorby every now and again and most smaller deployments will hum once tuned a bit. If you EVER need to call in professional assistance responding to an incident, you will thank me for the bill because it will save you a fortune in money and time.)

That answers the “how” question in terms of location (or maybe that would’ve been for a “where” question?). Regardless, now you know where to put it, what do you do? For this example we’ll use a home or small office environment, but the difference between small and large is typically capacity and the ability to handle the load. The same concepts of getting traffic to the Security Onion host apply.

A basic home or small office setup will look something like this:

Your Internet connection enters through a cable or DSL type modem and typically a gateway router device, like a Netgear or Cisco/Linksys, which we’ll call the perimeter.  The modem and router can potentially be the same device and if there’s a network firewall at play it will be here too. In the setup above, the gateway router is typically the DHCP server. We need to see those private addresses so we can identify which hosts are generating events. So we need a way to get between the endpoints and that router.

One easy and affordable way to accomplish this is with a Mikrotik Routerboard 250GS. They can be had for around $40 and will give you a fully manageable 5 port gigabit switch  (example 1).

In this case, we’d want to drop the Mikrotik between the gateway router that is issuing IP addresses to the internal devices. The only connections to our gateway router will be the WAN connection going to your modem and a single LAN connection to the Mikrotik. The gateway router will continue to do what it’s been doing with the only difference being all network activity to or from it will pass through the Mikrotik first. If you want to add wireless to the above setup, you’d want to use a separate wireless access point device plugged into the Mikrotik.

Your Security Onion host will ideally have two network interfaces if you plan on managing/monitoring it from another host on the network. One interface is your management interface which gets an IP address and can be connected to remotely. The other interface is your sensor interface where you want to see mirrored traffic; this is the data that Security Onion will monitor and analyze.

We used to have hubs, which were dumb but great at the same time. They basically would pass all traffic across all ports connected to the hub. Just plug in your Security Onion sensor and it would automagically see the data. Hubs have given way to switched networking now, which is why we need one we can manage (like the Mikrotik). Most retail store type switches don’t allow for things like configuring port forwarding.

So this is what your Mikrotik switch setup might look like:

Plug your gateway router LAN port into Port 1 and using RouterOS configure it to span all traffic to Port 2, where you’ll plug your Security Onion sensor interface. Ports 3-5 are free for endpoints. You can connect another switch or a WiFi AP to extend access to additional devices if you need more port capacity. The key is that all traffic into and out of your network at this point will be going through Port 1 on the Mikrotik which will be mirrored to Port 2 where Security Onion is listening.

I’ll save the Mikrotik step by step guide to configuring it’s RouterOS for another day.

Mad props to @Diagramly ( for their awesome diagramming tool!

IDS Rule Reference for Splunk 1.0

I created a standalone version of IDS Rule Reference for Splunk for Snort/PulledPork users who are not running Security Onion. I’ve added a few dashboard views to provide a little more flexibility for searching or researching rule documents.

The initial IDS Rules view is what is included in the Security Onion for Splunk app. It can be used for researching rules and activity by filtering on enabled rules or by category, classtype or source file.

The first of the new additions is a more flexible search dashboard allowing for wildcard searches by rule name or sid. Simply enter keywords or some (or all) of a sid and you’re off and running.

Lastly, the IDS Rule Tome allows you to browse only the rules that have a matching rule reference document. Undocumented rules will not appear in these results.

Known issues: I’ve not sorted out how best to handle the small subset of rule documents that share a sid, so rule documents named genid-sid.txt will provide inconsistent results.

If you’re using IDS Rule Reference in Security Onion for Splunk and want the additional views, simply download this app and you’ll be good to go.

Setup is pretty simple if you’ve got Splunk rolling already.

Download the Snort Rule Documentation (opensource.gz) from then extract opensource.gz to the monitored path:

tar zxvf opensource.gz -C /opt/splunk/etc/apps/ids_ref/local/rules

Copy your Snort PulledPork *.rules files to the monitored path:

cp *.rules /opt/splunk/etc/apps/ids_ref/local/rules/

Restart Splunk.

Event Workflows:
You can modify the Event Workflows from Splunk Manager > Fields > Workflow actions. Edit the IDS Rule Reference “Apply only to the following fields” to apply the workflow link to your Snort sig_id field in Splunk). You’ll also want to edit the Search String variable field name ($sig_id$ is the default).

As always feedback and suggestions are welcome for improvements!