Previous Section  < Day Day Up >  Next Section

5.1 Network and Configuration Variables

The first section of the file is devoted to recording some configuration information. Most of these variables are used by the Snort rules to determine the function of some systems and the location of others. The variables map out the layout of your environment so that Snort can make educated decisions about which events deserve an alert. The variables are looking for either IP addresses (one or several) or specific TCP ports on which a service is listening.

By default, the variables are declared with the value any. This matches any IP address. While this value works, it may cause a large number of false positive alerts.

To specify a single address, simply enter the IP address:


You can also specify multiple addresses. Enclose the group of addresses in square brackets and separate them with commas (no spaces):

var HOME_NET [,,]

You also have the ability to specify an entire RFC 1918 address space (CIDR blocks). This method specifies the number of bits in the subnet mask. To specify a subnet mask (24 bits of subnet), use a "/24":


You can mix and match specific IP addresses with the RFC 1918 subnet designations: square brackets, commas, and no spaces:

var HOME_NET [,,,]

Here's where it gets fun. You can use a "!" as a NOT. For example, if you have a range of addresses specified for your home network, you can designate all addresses that are not in that range as the external networks. Note that when setting the variables, you just use the variable name. When you are actually using the variable, you have to put a "$" before the variable name. The following example sets the EXTERNAL_NET variable to be all addresses that are not contained in the HOME_NET variable:


The "!" (NOT) directive indicates the inverse of what follows. This can get you into trouble if you are saying NOT for a variable that is set to any. The opposite of any is none. You would match no addresses in this case. Do not use this to say, for instance, that you do not have internal SMTP servers. Try to enumerate the SMTP servers that your internal systems utilize—or keep it any, since you will still want to watch for attacks sourced from inside your network against external SMTP servers. Setting this variable to "not any" may prevent those rules from doing their work.

Some of the variables are looking for port numbers instead of IP addresses. Snort currently does not support listing multiple, nonsequential ports. This functionality is planned for future versions. Right now, we can designate a single port, a contiguous range of ports, or the inverse of a port (using the "!" directive). Suggested settings are given below, in the description for the different variables.

To designate a single port:


To designate a range of ports (in this case, ports 8000 through 8080 inclusive):


We could also designate all ports up to a port (here we're saying all ports up to port 8080):


To designate all ports that are not 80:


5.1.1 Default Variables from snort.conf

The default variables from snort.conf are:


Use this to specify the IP addresses of the systems you are protecting.


If you specify IP addresses in HOME_NET, it's usually a good idea to use the "!" operator to specify everything that is not your internal network as the external network.

Let's look at a rule that uses the HOME_NET and EXTERNAL_NET variables. While we will go into a lot of detail on how rules are constructed in Chapter 7, we can get a preview by looking at this rule from the attack_responses.rules rule set. This rule looks for the content "Volume Serial Number" in a packet coming from the internal network ($HOME_NET) and going to the external network ($EXTERNAL_NET) as part of an established TCP session. Finding "Volume Serial Number" indicates someone getting a command-line directory listing of a Windows system, which usually indicates a response to a successful attack.

alert tcp $HOME_NET any -> $EXTERNAL_NET any (msg:"ATTACK-RESPONSES directory 

listing"; content: "Volume Serial Number"; flow:from_server,established; classtype:


There are many rules designed to watch specific services in your environment. Variables tell Snort where to expect to find the services. Setting specific addresses for these servers goes a long way towards reducing the number of false positives that Snort generates. Sometimes the servers you are enumerating are not on your network. For example, you may not have internal DNS servers. In that case, include the DNS server that your internal systems use on the Internet. The variables used to define the servers running services that have specific rules are:


Here is another rule from the attack_responses.rules rule set (my favorite batch of rules). It watches for the content "Command completed" traveling from the designated web servers to the outside network from the designated web server ports (as part of an established TCP session).


command completed"; content:"Command completed"; nocase; flow:from_

server,established; classtype:bad-unknown; sid:494; rev:6;)


Port 80 is the default HTTP port. Specifying port 443 (HTTPS) does you little good since traffic on this port is encrypted and triggers a signature match. Chapter 6 discusses strategies that may allow you to watch this traffic.


Commonly set to !80 (any port besides port 80). You can, in most cases, leave this alone.


Specifies the port that Oracle is listening on. By default, Oracle listens on port 1521. If you have changed this port, change the setting here.

These variables are looking for port numbers instead of IP addresses. Specifying ports here goes even further to targeting your rules more accurately (by reducing false positives).


The AIM_SERVERS variable is used by rules that watch peer-to-peer and instant messenger traffic. It is already configured with the latest list of AOL Instant Messenger server addresses. This list changes from time to time. The latest snort.conf included with the latest rules will have the latest list.


This variable needs to be set properly or Snort will not start. It should point to the location of the rules sets in your filesystem. This path can also be relative to where Snort is running from, which can be helpful if the same configuration file might be used on different systems with different directory structures. If the rules are located in /usr/local/share/snort_rules/march_2003/rules, set the variable like this:

var RULE_PATH /var/local/share/snort_rules/march_2003/rules

    Previous Section  < Day Day Up >  Next Section