These classnotes are depreciated. As of 2005, I no longer teach the classes. Notes will remain online for legacy purposes

UNIX03/Snort Configuration

Classnotes | UNIX03 | RecentChanges | Preferences

By default, Snort has no specified configuration file. This is because the configuration file is specified at run-time using the "-c" option. However, it is customary to place UNIX configuration files in /etc, so the Snort configuration usually winds up in /etc/snort.


The main configuration file for Snort is customarily the snort.conf file. Snort uses a simple configuration language consisting of variable declarations and options. Variable declarations look like this:
 var: <name> <value>

While options (many of which are also command-line options) look like this:

 config <directive> [: <value>]

We will only look at a small selection of possible values, and leave it up to you to research others (for more help, see

First, you will want to specify your home network. You can specify it explicitly as:


or use global variable $<interfacename>_ADDRESS which will be always initialized to IP address and netmask of the network interface which you run snort at.


You can specify lists of IP addresses for HOME_NET by separating the IPs with commas (MAKE SURE YOU DON'T PLACE ANY SPACES IN YOUR LIST!) like this:

 var HOME_NET [,]

or you can specify the variable to be any IP address like this:

 var HOME_NET any

Next, you will want to configure your server lists. This allows snort to only look for attacks to systems that have a service up. Why look for HTTP attacks if you are not running a web server? This allows quick filtering based on IP addresses These configurations MUST follow the same configuration scheme as defined above for $HOME_NET.

 # List of DNS servers on your network 
 # List of SMTP servers on your network
 # List of web servers on your network
 # List of sql servers on your network 
 # List of telnet servers on your network

Finally, you will want to configure your service ports. This allows snort to look for attacks destined to a specific application only on the ports that application runs on. For example, if you run a web server on port 8081, set your HTTP_PORTS variable like this:

 var HTTP_PORTS 8081

Port lists must either be continuous [eg 80:8080], or a single port [eg 80].

Preprocessor Configuration

General configuration for preprocessors is of the form
 preprocessor <name_of_processor>: <configuration_options>

frag2: IP defragmentation support

This preprocessor performs IP defragmentation. This plugin will also detect people launching fragmentation attacks (usually DoS) against hosts. No arguments loads the default configuration of the preprocessor, which is a 60 second timeout and a 4MB fragment buffer.
stream4: stateful inspection/stream reassembly
Use in concert with the -z [all|est] command line switch to defeat stick/snot against TCP rules. Also performs full TCP stream reassembly, stateful inspection of TCP streams, etc. Can statefully detect various portscan types, fingerprinting, ECN, etc.
http_decode: normalize HTTP requests
http_decode normalizes HTTP requests from remote machines by converting any %XX character substitutions to their ASCII equivalent. This is very useful for doing things like defeating hostile attackers trying to stealth themselves from IDSs by mixing these substitutions in with the request. Specify the port numbers you want it to analyze as arguments.
bo: Back Orifice detector
Detects Back Orifice traffic on the network. Takes no arguments in 2.0.
Portscan: detect a variety of portscans
This preprocessor detects UDP packets or TCP SYN packets going to four different ports in less than three seconds. "Stealth" TCP packets are always detected, regardless of these settings.
Portscan 2, detect portscans in a new and exciting way. You must enable spp_conversation in order to use this preprocessor. You can also tone down it's output by using it in conjunction with "portscan2-ignorehosts":
preprocessor portscan2-ignorehosts:

Output configuration

The final area of the configuration file we will be looking at is the section for configuring your output options.

Snort has many diverse choices for output. It can log to the system logs (the way we will be using today), log to a database (making searching and scanning for violations easier), or post them in a binary format for speed.

The standard way to log to system logs is to do the following:

 output alert_syslog: LOG_AUTH LOG_ALERT

Snort Rulesets

One of Snort's strengths is its ability to snap in new rulesets for different kinds of attacks. Learning how to write your own ruleset is complex and beyond the scope of this course. Fortunately, as we have mentionned before, there are many rulesets already to choose from, so we do not really need to come up with our own unless we have peculiar requirements.

Classnotes | UNIX03 | RecentChanges | Preferences
This page is read-only | View other revisions
Last edited June 28, 2003 12:35 am (diff)
(C) Copyright 2003 Samuel Hart
Creative Commons License
This work is licensed under a Creative Commons License.