Tuning Snort with Host Attribute Tables

Having trouble finding malicious activity during Snort scans? Your Snort implementation may need a tune up. Joel Esler tells you how to do it using host attribute tables.

The question I receive most often in my consulting with Sourcefire and Snort clients is also the easiest to field. People generally think that tuning a Snort installation requires a mystical knowledge and a crystal ball. Being able to understand the inner-workings of an open-source product is generally speaking, a hard thing to do.

Snort is 11 years old this year. It's one of the most critically acclaimed, highly deployed, well documented, and highly praised pieces of network security software in the world. It's nearly ubiquitous. There is barely a security shop on the planet that hasn't heard of Snort now. So why does the question persist?

The truth is that there's an overwhelming amount of information -- some more useful than others -- and getting started can be daunting. If there is one tip that would make life easier it would be the use of Host Attribute tables, a feature that was introduced in Snort version 2.8.1.

Host Attribute tables give you, the Snort administrator, the ability to define what your network is to Snort. In the past, in order to tune Snort's fragmentation preprocessor (frag3 for you Snort heads), you'd have to make an entry into the snort.conf defining the OS of the target system so that Snort would reassemble fragmented packets correctly when they were headed towards the end host. Then along came the new target-based Steam preprocessor (Stream5) allowing you to do stream reassembly in a target-based mode.

The problem with these entries into the snort.conf is, when you upgrade your version of Snort you'd have to copy all these settings over to your new snort.conf file manually. Host Attribute tables gave you a way to permanently define your network in a file, allowing the administrator to copy just one file from an old installation to a new installation with all the host specific settings intact.

For example:

Snort's host attribute table is an XML formatted file that Snort will read in and auto-configure several aspects of the preprocessors and rule technology dependent on the definitions of this file. So I'm going to use two examples in the below table:












































In the above example we see a host defined as Attribute "1", at IP, and it's a Windows XP host running an http server on port 80. Notice under "PROTOCOL" where I call ATTRIBUTE_ID 2? I did it this way to illustrate that you can define multiple attributes at the beginning and you can simply call the attribute several times later in the file. Much easier than having to define an "ATTRIBUTE_VALUE" for 'http' every single time you want to specify it under the tag.

When Snort is compiled with the --enable-targetbased tag, it gives you the ability to have one master XML file that defines your entire network. The advantage is, the more you define this, the more ready you will be for future uses of the attribute table in Snort. You can already see the advantages of defining the operating systems for the fragmentation and stream preprocessors, but imagine being able to define what browser is running on your network, and your Snort rules automatically know which hosts are running which browser and if they should turn on the "Internet Explorer" rules for a given host? The possibilities are daunting, but let me get back to the above example.

You need three things to be able to run a Host attribute table. First, you need to define --enable-targetbased to ./configure when you compile Snort. Second, you need to tell Snort where to find your attribute table. The line in the snort.conf file looks simply like:

attribute_table filename /path/to/file

When Snort starts up, it will slurp in this file and autoconfigure preprocessors and rules for you.

The auto-configuration of rules is probably the best part here. If you have been a Snort administrator for a while, you know that you need to define variables like HTTP_PORTS in order for Snort to know to watch traffic on for HTTP traffic. The problem with that in the past was, not all traffic on ports included in HTTP_PORTS, network-wide, was actually HTTP traffic.

For example, let's say one of your web servers internally was running a web page on port 8080. So you defined port 8080 as an http port in your variable configuration. The problem with this is, 8080 can be used as an ephemeral port for any application and false positives could occur. With host attribute tables, this problem goes away. As you can see in the above example with ATTRIBUTE_ID 2, the definition for port 80 is http. That means that I use the "metadata" tag within a rule to run the rule on any port that is http, no longer do you need to define a great many ports in your variable configuration. By simply placing "metadata: service http;" in your web based rules, the rule will then run on any traffic going to the hosts that have been defined in your host attribute table as http, and only on the IP's that you have defined.

This one capability can simplify Snort implementations and management, while also helping ensure consistent protection throughout the enterprise. By allowing users to move all of their host specific settings from one system to another using a single file, Host Attribute Table feature enables Snort to pre-configure preprocessors and rules, and, as more and more capabilities are added to Snort that take advantage of the metadata keyword, the host attribute table becomes more and more important to maintain.

Joel Esler is a senior security consultant with Sourcefire and a volunteer at the SANS Internet Storm Center. His blog can be found at http://blog.joelesler.net and on Twitter at http://www.twitter.com/joelesler.

Copyright © 2010 IDG Communications, Inc.

7 hot cybersecurity trends (and 2 going cold)