Tuning Snort with Host Attribute Tables

Your Snort implementation may need a tune up. Here's how to do it.

By Joel Esler, CSO |  Software, network security, snort

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:

<p><SNORT_ATTRIBUTES>

<ATTRIBUTE_MAP>

<ENTRY>

<ID>1</ID>

<VALUE>Windows</VALUE>

</ENTRY>

<ENTRY>

<ID>2</ID>

<VALUE>http</VALUE>

</ENTRY>

</ATTRIBUTE_MAP>

<ATTRIBUTE_TABLE>

<HOST>

<IP>10.1.2.3</IP>

<OPERATING_SYSTEM>

<NAME>

<ATTRIBUTE_ID>1</ATTRIBUTE_ID>

</NAME>

<VENDOR>

<ATTRIBUTE_VALUE>Microsoft</ATTRIBUTE_VALUE>

</VENDOR>

<VERSION>

<ATTRIBUTE_VALUE>XP</ATTRIBUTE_VALUE>

</VERSION>


Originally published on CSO |  Click here to read the original story.
Join us:
Facebook

Twitter

Pinterest

Tumblr

LinkedIn

Google+

SoftwareWhite Papers & Webcasts

See more White Papers | Webcasts

Join us:
Facebook

Twitter

Pinterest

Tumblr

LinkedIn

Google+

Ask a Question
randomness