Updating to Snort 2.9.2 and Barnyard2

After fixing hardware problems that had my home network sensor out of commission for the better part of a year, I recently got the system inline again. Because the sensor had been down for so long, I was running a fairly old version of Snort, 2.9.0.3, along with barnyard 0.2.0. I decided the first thing I should do after updating the OS itself was update Snort and Barnyard.

I won't go through the process in detail since there are many resources online for installing and configuring Snort. The main thing I will point out is that you should always look in the docs/ directory for information on installing and upgrading. If you're updating from a previous version, pay particular attention to changes and new features. Another important thing to do is look closely at the snort.conf provided with a given version in etc/ since it will have a lot of information on defaults and configuration directives that may be required. These won't always be the same as previous versions. It's also important to update to the latest rule sets, check for new rules files, and do all the other normal tuning to make sure certain rules are turned off or on.

I had two main problems when I updated, one with Snort and one with Barnyard2. Since Snort is the main piece of the puzzle here, I updated it prior to Barnyard. After updating to Snort-2.9.2.1 and fixing the configuration, I was able to run Snort successfully using the options I normally had previously. However, as soon as I put the sensor back inline and Snort started processing packets, Snort would exit with an error.

Can't acquire (-1) - ipq_daq_acquire: ipq_read=-1 error Failed to receive netlink message!

A quick search revealed that I had to remove the ip_queue module. JJ Cummings on the #snort channel pointed out to me that NFQ is the more recent option than IPQ. I am using Slackware-current, so even though it is a maintained distribution it is also not surprising that I was using an older option. Slackware also did not have a couple of the required libraries to compile DAQ with support for NFQ, so I went to Slackbuilds.org to get the files allowing me to create Slackware packages for libnetfilter_queue and libnfnetlink.

Once I got the new packages installed, made sure the ip_queue module wasn't loaded, recompiled DAQ to support NFQ, and changed my Snort init to use --daq nfq, my inline Snort was working once again.

Next, I updated from Barnyard-0.2.0.

$ barnyard2 -V

  ______   -*> Barnyard2 <*-
 / ,,_  \  Version 2.1.10-beta2 (Build 266) TCL
 |o"  )~|  By Ian Firns (SecurixLive): http://www.securixlive.com/
 + '''' +  (C) Copyright 2008-2011 Ian Firns


Barnyard2 is needed to process Snort's newer output mode, unified2. My snort.conf changed from:

output log_unified: filename unified.log, limit 128

to:

output unified2: filename unified.log, limit 128

When I got Barnyard2 up and running, it was obviously not successfully processing the unified2 files from Snort. Barnyard2 kept repeating the following error as it tried to process the files.

WARNING: No function defined to read header.

I found a thread on the snort-users list that indicated Barnyard2 was getting a file type it wasn't expecting, which made sense considering the warning message. This issue gave me more problems than it should have and I eventually realized it was because of an error in my barnyard.conf file. The input is supposed to read "input unified2" but I had somehow managed to include a colon after "input". Once I fixed that line, Barnyard2 started working, with alerts being properly processed and showing up in Sguil once again.

The next update will be to go from Sguil-0.7.0 to Sguil-0.8.0.

Tweet

Inline devices and fail open

There was a post to the sguil-users mailing list asking for recommended fail-open network cards in the hopes that it would be less expensive than alternatives. Richard Bejtlich pointed out that the long-term costs and lower downtime make bypass switches worth the initial expense. This make a lot of sense.

One thing people need to note when talking about inline devices and fail-open hardware is that many devices will only fail open in a powered off state. For example, if you're running Snort inline with a fail-open NIC and the Snort process dies, then the box will no longer pass traffic. Your link is down unless you fix the problem by restarting Snort or you shut off the system completely, which will then cause the fail-open NIC to cross-connect and pass traffic.

If a system only fails open when the power is off, you still need to be aware that an operating system or application failure can take down your link if the fail-open hardware remains powered on. NetOptics has some bypass switches that have a heartbeat feature to address this problem.

An exclusive Heartbeat feature monitors link status between the Bypass and monitoring tools for enhanced reliability. A configurable Heartbeat packet is injected into the monitor port link to help determine availability of attached monitoring tools. For instance, the Bypass Switch can automatically switch network traffic around an unresponsive IPS appliance – even if the IPS is still powered on. Once the IPS re-establishes a connection, traffic is re-routed to the monitor port for continued operation.

This is a better solution than a NIC that will only fail open when the power is off, but not all bypass switches have the feature. If anyone knows of other vendors or hardware that have a similar feature, please let me know.

It's also important to know that the use of the terms "fail open" and "fail closed" is not always consistent.

Tweet

IDS/IPS placement on home network

A coworker was asking me about setting up Snort at home so he could get some experience breaking things.

I put together some very rough diagrams with Dia. These are just common and inexpensive solutions for running Snort at home, either in passive (IDS) or active (Inline) modes. These configurations are all inexpensive. At most, you require an extra hub or switch. The only one that doesn't require anything other than the network cards on the sensor is an external inline sensor.

The first is a common home network configuration. This is basically how mine was before I installed Snort.

The second diagram shows an external sensor. An advantage to this is that you see everything. A disadvantage is that you see everything. The management interface is inside the firewall while the bridging interfaces are outside the firewall. Seeing all the traffic isn't the only disadvantage. Some other disadvantages:

• You can't see internal addresses to identify individual systems.
• You need a higher performance system. This is not usually a problem on a residential service, but it should be noted that a lot more traffic will pass through system since it's not behind the firewall. You will see a ton of automated scanning and exploit attempts even if the traffic won't make it past the firewall.
  

Placing the sensor outside the firewall is reasonable if you want to find out just how much activity is happening on the external segment, but it can be really noisy and you lose inside visibility.

The third image is using an extra switch. In this example, you will see all traffic going through the firewall, as well as all broadcast traffic on the private network. You won't see unicast traffic between internal hosts, but you will be able to identify which host is associated with any given traffic that is seen. Bridging is enabled on the sensor and you can run Snort inline. This is my preferred configuration unless you have a lot of wireless traffic.

The fourth diagram shows how to run Snort passively. There are two basic options. The first is a hub that will broadcast all traffic to all ports. This can hurt performance depending on how busy the internal network is. The second is with an inexpensive switch that supports port mirroring. I haven't used it, but I've seen an inexpensive Dell switch referenced that supports port mirroring. Note that it only supports monitoring four ports (PDF) at a time. In this configuration, you can see all traffic on the local segment in addition to Internet traffic. If using a switch with a mirror, you will probably need a separate management interface. If using a hub, the management interface can also do the sniffing.

You could also use a hub between the modem and the firewall if you wanted to run an external passive sensor.

EDIT: Based on Victor's comment, I added one other diagram. Diagram five shows the firewall and Snort inline on the same system. Victor uses iptables to filter the traffic first, then traffic that passes through the firewall goes to Snort running inline. He has separate Snort processes for the DMZ and the LAN.

This configuration is slightly more complicated. There are exceptions, but the places I've worked in the past would not have considered using this type of configuration mainly because they were quite large and wanted off-the-shelf networking products rather than rolling their own firewalls or routers. It is still a useful and usable configuration to learn, and setting it up would provide a lot of valuable experience.

Tweet