|< Day Day Up >|
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.
var HOME_NET 10.120.25.135
var HOME_NET [10.10.10.20,192.168.1.23,172.16.30.25]
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 255.255.255.0 subnet mask (24 bits of subnet), use a "/24":
var HOME_NET 10.10.10.0/24
You can mix and match specific IP addresses with the RFC 1918 subnet designations: square brackets, commas, and no spaces:
var HOME_NET [192.168.1.12,172.16.0.0/16,10.10.10.10,10.10.20.0/24]
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:
var EXTERNAL_NET !$HOME_NET
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.
var ORACLE_PORTS 1521
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:
var SHELLCODE_PORTS !80
5.1.1 Default Variables from snort.conf
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: bad-unknown;
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).
alert tcp $HTTP_SERVERS $HTTP_PORTS -> $EXTERNAL_NET any (msg:"ATTACK-RESPONSES command completed"; content:"Command completed"; nocase; flow:from_ server,established; classtype:bad-unknown; sid:494; rev:6;)
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).
|< Day Day Up >|