Step 4. Configure Snort
Snort stores its primary configuration in snort.conf, which is in the %systemdrive%\snort\etc directory by default. You can leave the file in this location or place it somewhere else, as long as you let Snort know where to find it by providing the appropriate path on the command line.
I could easily fill up this issue with details about all the intricate configuration options available in snort.conf. Snort is an amazingly powerful application. But, for now, let's stick with some of the basic options.
For Snort to determine the traffic coming into your network versus the traffic going out, you've got to tell Snort the hosts and IP addresses in your network. To provide this information, you set the HOME_NET variable in the snort.conf file. Find the line
var HOME_NET any
and replace any with your IP address range. You can specify one range, such as
var HOME_NET 192.168.0.1/24
or you can specify multiple ranges. For multiple ranges, you need to enclose the set of ranges in square brackets and separate each range with a comma. Don't include any spaces between the IP address ranges. For example, the line
var HOME_NET
[10.0.1.0/24,10.0.2.0/24,10.0.3.0/24]
tells Snort that subnets 10.0.1.0/24, 10.0.2.0/24, and 10.0.3.0/24 belong to your network. By default, Snort considers everything else outside the network. You can explicitly tell Snort the networks it should consider external by setting the EXTERNAL_NET variable. In the snort.config file, find the line
var EXTERNAL_NET any
and replace any with the IP address of the network you want Snort to consider external. Generally, though, I've found that leaving the EXTERNAL_NET variable set to any is a good place to start.
If you want to take the time, you can go so far as to tell Snort the types of servers you have in your environment and where to find those servers. You provide this information by setting the DNS_SERVERS, SMTP_SERVERS, HTTP_SERVERS, SQL_SERVERS, and TELNET_SERVERS variables in the snort.conf file. Find the lines
var DNS_SERVERS $HOME_NET
var SMTP_SERVERS $HOME_NET
var HTTP_SERVERS $HOME_NET
var SQL_SERVERS $HOME_NET
var TELNET_SERVERS $HOME_NET
var SNMP_SERVERS $HOME_NET
By default, all six server variables are set to $HOME_NET, which means that Snort will monitor all systems defined within your HOME_NET range for all types of attacks. If you have a small network and you don't mind a bit of extraneous noise, this configuration should work fine. However, if you have a large traffic stream to monitor, you'll want to fine-tune the Snort configuration so that Snort checks for only appropriate signatures against specific hosts. After all, there's no need to check for SQL buffer overrun attacks against a Web server that's running only Microsoft IIS. If you want to define specific classes of hosts, you need to replace $HOME_NET with the IP address range of the target servers, following the same format that you used for the HOME_NET variable. For example, for the DNS_SERVERS variable, you replace $HOME_NET with the IP address range for your DNS servers.
If you'd like to get even more specific, you can define which ports your servers use for specific applications. For example, if your Web servers use custom port 8080 for HTTP traffic instead of port 80 (the port typically used for Web servers and browsers), you can tell Snort to watch port 8080 by modifying the HTTP_PORTS variable. In snort.conf, find the line
var HTTP_PORTS 80
and change it to
var HTTP_PORTS 8080
Similarly, you can change the ports for Oracle (which you define with the ORACLE_PORTS variable) and other applications. Like the HTTP_PORTS variable, the ORACLE_PORTS variable is set to 80 by default. If your server uses port 1521 instead, you can change the line to
var ORACLE_PORTS 1521
As you can see, you can configure many options in snort.conf. You should look through snort.conf to find which values are most relevant to your environment and set them appropriately.
Step 5. Configure the Rules
One line that you'll see in snort.conf mentions the RULE_PATH variable. This line should look something like
var RULE_PATH ../rules
The ../rules option tells Snort that it can find the rules (i.e., signatures) in the directory called rules, which is at the same directory level as the Snort binaries. So, for example, if you install Snort in the default location F:\snort, the Snort binaries are in F:\snort\bin and the rules are in F:\snort\rules. If you want to change the RULE_PATH variable you can, but the default installation should be fine.
Rules are the heart of Snort. They're the byte patterns, attack signatures, and other data types that trigger alerts when detected. By default, Snort comes with more than 1500 signatures right out of the box.
What does a rule look like? Here's what the cmd.exe rule, which you violated earlier with your Snort test, looks like: alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"WEB-IIS cmd.exe access"; flow:to_server, established; content:"cmd.exe"; nocase; classtype:web-application-attack; sid:1002; rev:5;). Let's look at this rule's main components. The reference to $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS specifies that you're interested in seeing only the traffic coming from the outside world (as interpreted by EXTERNAL_NET) toward your network. The content: parameter tells Snort to search for the existence of the string cmd.exe in the data stream. If Snort finds this string, it generates the alert message that the msg: parameter specifies.
As the cmd.exe rule shows, rules are generally straightforward. You can create your own rules as needed to detect any type of traffic. For example, if you need to detect whether someone is remotely accessing a directory on your system through the command interpreter, you might search for the string volume in drive or volume serial number on ports where you wouldn't expect to see them, such as ports that handle traffic going out of your network. Numerous configuration options are possible with Snort because of its flexible rule-set approach.
Snort's 1500 rules are in various files according to the type of data being checked. For example, the cmd.exe rule is in the web-iis.rules file. If you don't have IIS running in your environment, you don't need to have Snort looking for IIS attacks. You can easily remove the entire web-iis.rules file from the configuration by finding and commenting out the line
include $RULE_PATH/web-iis.rules
in snort.conf. To comment out the line, you place a number sign (#) in front of it:
# include $RULE_PATH/web-iis.rules
By default, several types of rules files (e.g., icmp-info.rules, chat.rules) are already commented out in snort.conf. I've found that the default rule configuration in snort.conf works well. Enabling the rules that are disabled by default typically generates far too much useless noise.
Perhaps a rules file has a lot of valuable rules that you'd like to use, but a few individual rules are particularly noisy and generate too many useless alerts. You can disable a specific rule by commenting out that rule in the rules file. Snort will ignore that rule the next time it executes the file.
As new attacks are released, you'll need to update your rules files. The best resource for new Snort rules is the Snort.org Web site. That Web site doesn't have an automatic update, so you'll need to check for updates regularly and whenever a new serious vulnerability or exploit appears.
Prev. page
1
2
[3]
4
next page 
