9.3 Initial Configuration and Tuning

Spending some time pruning the rules and features that Snort uses pays dividends. Your decisions in this phase of tuning have the potential to make your life as an administrator much easier. Be careful, though. Mistakes at this point have serious consequences. There are some easy, low-risk things you can do, however. The suggestions below provide a place to start and will help address the majority of the sources of false positives. As an administrator is able to establish a baseline for what is "normal" for the way their network is used, further tuning and customization is possible. It should be mentioned that when you make changes to the snort.conf file or the rules, you must stop the Snort process and restart it for the changes to take effect.

9.3.1 Tailoring the Decoder and Preprocessors

Anyone who watches a network with a connection to the Internet will tell you that the volume of port-scanning traffic, worm-related attempted exploits, and scripted attacks against arbitrary ranges of addresses is constantly increasing. A Snort sensor watching this traffic generates many alerts—particularly the portscan components. While the alerts generated as a result of this traffic might be an indicator of the initial phazes of an attack, the usefulness of these alerts is questionable given their volume. Tracking down the source may be difficult, too—particularly if the system is located in another country. Sometimes the source is a worm-infected workstation sitting behind a shared IP address. While it might be possible to track the source to a particular organization, the work involved in notifying that organization of the infected system (and the time that you spend explaining how you noticed and how to find the offending system) is a drain on your resources.

When configured to monitor the Internet connection for an organization, many Snort preprocessor settings are vestigial and really only serve to generate false (or relatively low-value) alerts. Some of the preprocessors alert on packet anomalies that are not of significant concern when trying to detect attackers. Many of these alerts can be eliminated by making changes to the preprocessor options in the snort.conf file. (These alerts can be useful when the Snort sensor is being used for more than just intrusion detection.)

In Chapter 6, sensor placement strategies were discussed that can help manage the type of traffic the sensor watches. For instance, if the sensor is placed behind the firewall instead of on the public side, the firewall will de-fragment packets (fragmenting packets is a common IDS evasion technique). One of the most CPU-intensive preprocessors is the frag2 preprocessor, which rebuilds these fragmented packets. If the sensor is behind the firewall, this preprocessor can be disabled.

Below are some changes that can be made to the snort.conf file to eliminate many common false positives.

9.3.1.1 The Snort decoder configuration

To enable these options, delete the # at the beginning of the line in the snort.conf file. These entries are a way to enter command-line options that will be the same every time you run Snort. The majority of alerts generated by leaving these alerts enabled are false. It is recommended that the config entries below be uncommented, which enables them. It seems strange to say, "enable the disabling of these alerts," but there you go.

config disable_decode_alerts

config disable_tcpopt_experimental_alerts

config disable_tcpopt_obsolete_alerts

config disable_tcpopt_ttcp_alerts

config disable_tcpopt_alerts

config disable_ipopt_alerts

9.3.1.2 The flow preprocessor

The flow preprocessor is used to unify all flow-related plug-ins and preprocessors. As of Snort 2.1.0, the only functionality built into this preprocessor is some portscan detection routines. This preprocessor must be enabled for the flow-portscan preprocessor to work. If an administrator is not interested in watching portscan activity, this preprocessor can be disabled. If you choose to disable flow, the line should look like this:

# preprocessor flow: stats_interval 0 hash 2

9.3.1.3 The frag2 preprocessor

If the Snort sensor is positioned behind a firewall or router that does fragment reassembly (most firewalls, including Linux-based ones and the Cisco PIX, do fragment reassembly), the frag2 preprocessor can be disabled. To disable this preprocessor, comment out the line. If you decide to disable frag2, the line should look like this:

# preprocessor frag2

9.3.1.4 The stream4_reassemble preprocessor

A variety of non-security-related issues can cause stream4 reassembly errors. To disable notification of these errors, add the noalerts configuration to the default line. It should look something like this:

preprocessor stream4_reassemble: noalerts

9.3.1.5 The http_inspect preprocessor

While the alerts that this preprocessor generates can be interesting when troubleshooting some web proxy server or network infrastructure problems, it is largely just noisy. It is best not to just disable the preprocessor, though. The suggestions in Chapter 5 shows how to tune this component for the web servers in your environment. The assistance it provides in allowing web traffic to be inspected is very valuable, but some network configurations result in thousands of false positives. To disable alerting for this preprocessor, add the no_alerts configuration to the line. The modified default line from snort.conf file is below:

preprocessor http_inspect_server: server default \

    profile all ports { 80 8080 8180 } oversize_dir_length 500 no_alerts

9.3.1.6 The flow-portscan preprocessor

The flow-portscan preprocessor is the first (and currently only) flow-based plug-in. If the flow preprocessor is disabled to allow the administrator to ignore portscan alerts, this configuration line should be disabled, as well. This preprocessor is disabled by default (it can still be considered test code). The lines will look something like this:

# preprocessor flow-portscan: \

#       talker-sliding-scale-factor 0.50 \

#       talker-fixed-threshold 30 \

#       talker-sliding-threshold 30 \

#       talker-sliding-window 20 \

#       talker-fixed-window 30 \

#       scoreboard-rows-talker 30000 \

#       server-watchnet [10.2.0.0/30] \

#       server-ignore-limit 200 \

#       server-rows 65535 \

#       server-learning-time 14400 \

#       server-scanner-limit 4 \

#       scanner-sliding-window 20 \

#       scanner-sliding-scale-factor 0.50 \

#       scanner-fixed-threshold 15 \

#       scanner-sliding-threshold 40 \

#       scanner-fixed-window 15 \

#       scoreboard-rows-scanner 30000 \

#       src-ignore-net [192.168.1.1/32,192.168.0.0/24] \

#       dst-ignore-net [10.0.0.0/30] \

#       alert-mode once \

#       output-mode msg \

#       tcp-penalties on

9.3.2 Tailoring the Rule Set

Here are some guidelines for tailoring your rule sets.

9.3.2.1 General rule set pruning (trimming high noise rule sets)

By default, the following rules are disabled (as mentioned in Chapter 7, you can disable a set of rules contained in a .rules file by using a # as the first character of the line or deleting the entire line in the snort.conf file). For most applications, it is best to leave these disabled.

# web-attacks.rules

# backdoor.rules

# shellcode.rules

# policy.rules

# porn.rules

# info.rules

# icmp-info.rules

# virus.rules

# chat.rules

# multimedia.rules

# p2p.rules

The following are sources of false positives and can be disabled in most deployments. Before disabling the misc.rules file, read through it. Some of the alerts provide warnings for suspected worm activity. You may elect to disable individual rules themselves, leaving the worm-related rules operational (see Section 9.3.2.2, below):

# icmp.rules

# misc.rules

# nntp.rules

# finger.rules

If you are not running a Coldfusion application server, disable the following rule set:

# web-coldfusion.rules

If you are not running FrontPage Extensions on any web servers in your environment, disable the following rule set:

# web-frontpage.rules

If you are not running PHP application services in your environment, disable the following rule set:

# web-php.rules

If you are not running an Oracle database in your environment, disable the following rule set:

# oracle.rules

If you are not running a mySQL database in your environment, disable the following rule set:

# mysql.rules

If you are not running a Microsoft SQL Server in your environment, disable the following rule set:

# sql.rules

If you do not have Unix systems in your environment, disable the following rule sets:

# rpc.rules

# rservices.rules

# x11.rules

If you do not have Microsoft Windows systems in your environment, disable the following rule set:

# netbios.rules

If you do not run an Apache web server in your environment, disable the following rule set:

# web-cgi.rules

If you do not run a Microsoft Internet Information Services (IIS) web server in your environment, disable the following rule set:

# web-iis.rules

The following rules sets are useful and result in false positives less often than most (keep these enabled in most environments):

exploit.rules

dos.rules

ddos.rules

attack-responses.rules

9.3.2.2 Tuning individual rules

Further tuning may be performed by disabling individual rules inside the .rules files. Disabling individual rules in a rules files is the same as disabling rule sets in the snort.conf file (by using a # or deleting the entire line). This should not be done without careful consideration. You risk missing valid alerts if you do not fully understand the rule being disabled.

Many administrators disable the misc.rules file in their first tuning pass. It's normally a good idea, since there are many high-noise signatures in this rule set. But there are some excellent Internet worm-detection signatures. Consider disabling the high-noise signatures and leaving the worm-related signatures enabled.

When you're running Snort behind a firewall and using it primarily to watch an Internet connection, you can tune it to watch just the services allowed through the firewall. Most corporate firewalls do not allow the bulk of network traffic through to the internal network. Disabling these rules decreases your ability to detect malicious activity outbound from their environment, however. And detection of attacks sourced from inside the network can be important.