[5] Snort Tuning: Reduce False Positives

Fine Tuning: Reducing False Positives

You can fine-tune your Snort installation to reduce false positives. The single largest, easiest way to approach that goal is to turn off unneeded rule processing.

Removing unnecessary rules

Thousands upon thousands of rules come standard with Snort, and that number doesn’t include any that you may have borrowed from elsewhere or created yourself. Probably less than half of these rules are relevant to what is running around your shop.

Cataloging your network

Probably the best place to start when you want to remove rules is with your network topology map. If you have a gigantic ocean-crossing organization, you have lots of network diagrams laying about giving you the placement of your technology assets with specific details on the hardware in use, operating system, installed applications, available services, and such access credentials as the user and group.

 Tip  The best filters to strip unneeded rules from your setup are operating systems and installed network applications.

Scanning your network

Scanning your network is a quick way of finding out whether any rogue services or rogue computers are lurking on your IP network. Looking through the eyes of the enemy is often rewarding from a planning and understanding standpoint.

Your favorite tools for network or service mapping are ideal for collecting this info. For example, NMAP (a popular open-source network mapping tool, found at http://www.insecure.org/) produces a very quick understanding of how curious passers-by see your network.

Commenting out any unneeded rules

Your goal in creating this network audit is to find rules in your Snort rules directory, open them, and place a “#” before them, which disables them from being found or logged.

 Tip  If you have a network of only Windows 98 workstations and those platforms don’t offer any services, you can safely disable all the Linux and Unix exploits, probes, and other attacks within Snort. It’s a waste of time to see them in your logs or have Snort look for them.

Coming up with an action plan

Let’s say you’re running a 30-person insurance claims-processing office, with lots of medical and financial records stored on four different file servers (all four running Windows 2003 Server). The company processes its own e-mail and Web services, outsources spam and virus-filtering to a third-party, and runs a few custom applications to handle the ordinary course of business. Staff members also use Windows XP Professional computers and laptops for daily activities. The office does not have any Macintosh or Unix computers (although e-mail may be moved to an open-source solution, time permitting). There’s a firewall for NAT. Access Control Lists (ACLs) block everything except inbound mail to the mail server and Web traffic to the Web server.

This office’s system administrator first needs to organize what’s known about the network into a report. Table 9-2 summarizes the most important points from the preceding example network.

Table 9-2: Network Summary

Host IP Address	O/S	Exposed Services (Ports)
10.0.0.1	Cisco Routers & Switches	None
10.0.0.2	Windows 2003	25, 80
10.0.0.3	Windows 2003	25, 110, 143, 993, 995
10.0.0.4	Windows 2003	80, 443, 3218
10.0.0.5	Windows 2003	80
10.0.0.6-	Windows XP Professional	Not available through the firewall 10.0.0.28

The network summary is your roadmap for removing unneeded junk from your rules and configuration files. For example, most of the rules in web-cgi.rules still apply. However, you can comment out almost half of the lines in shellcode.rules and everything in rservices.rules.

Usually, you decide which rules to remove based on several factors: The source and destination ports, the protocol, and the message body of the rule, which should give you an extra bit of explanation of whether the rule applies.

For example, check the following rule from the exploit.rules file:

alert tcp $EXTERNAL_NET any -> $SMTP_SERVERS 25 (msg:"EXPLOIT x86 windows 
               MailMax overflow"; flow:to_server,established; content:"|eb45 eb20 
               5bfc 33c9 b182 8bf3 802b|"; reference:bugtraq,2312; 
               reference:cve,CVE-1999-0404; classtype:attempted-admin; sid:310;  
               rev:5;)

• The header of the rule indicates that it’s designed to catch an exploit directed at an SMTP (mail) service listening on the well-known port 25.

• The message part of the body of the rule suggests that the exploit was engineered to operate on an Intel x86 processor running the Windows operating system and the MailMax application server software.

Many of the stars align for this rule to match the example network, but not all of them. For example, if the mail implementation is offered using the Microsoft Exchange service instead of MailMax, the buffer overflow indicated by this rule isn’t a threat. You can safely comment it out.

Using a security audit tool

A security auditing tool is an excellent way to tune your Snort installation. A vulnerability scanning tool produces a detailed view of the specific vulnerabilities that each host on your network may be susceptible to.

We recommend investigating a very robust and capable tool called Nessus (http://www.nessus.org/), which was written by developers guided by the same principles that drove Snort’s creation:

• An extensible client-server architecture using plug-ins.

• An up-to-date set of vulnerabilities in its testing database.

• A robust scripting language.

The Nessus server runs on Linux and Unix systems, and a client is available for Windows systems (NessusWX).

Once Nessus has been executed against your internal network, you can use its output to locate machines that are vulnerable to attacks. If you can patch the vulnerabilities Nessus found, then by all means patch them. If you can’t patch the vulnerabilities, then your Nessus output is a list of attacks you need to watch out for.

Nessus can test thousands of attacks (all developed as plug-ins). Once a Nessus report is available, we found that the most ideal method for locating and editing your Snort rules is to compare one of the unique identification tags that both systems share:

• The Common Vulnerabilities and Exposures (CVE) database (http:// cve.mitre.org)

• The BugTraq Vulnerability Mailing List (http://www.securityfocus. com/archive/1)

• The arachNIDS signature database (http://www.whitehats.com/ids/)

For example, after running Nessus, you find that hackers can use CVE-1999-0494 against one of your mail servers. A little shorthand Unix grep- ping easily locates that rule within Snort’s rule files:

# cd /usr/local/snort/rules
# grep "CVE-1999-0494" *.rules
pop3.rules:alert tcp $EXTERNAL_NET any -> $HOME_NET 110 (msg:"POP3 USER overflow attempt"; flow:to_server,established; content:"USER"; nocase; content:!"|0a|"; within:50; reference:bugtraq,789; reference:cve,CVE-1999-0494; reference:nessus,10311; classtype:attempted-admin; sid:1866; rev:5;)

 Warning   You found a vulnerability. Make sure that you patch it and update your Snort rules.