Linux Blog

Tuning Snort

Snort can be a very useful tool in any network environment. However it's not enough to just install it and monitor the events. After Snort is installed and operational you will no doubt notice a lot of so called "false positives" - Snort alerts that are set off by a legitimate traffic. You will also notice legitimate events that repeat over and over again, filling up the logs. Example of such event could be FTP brute force attack, when a malicious user is running brute forcing tools such as "hydra" to try and guess FTP accounts and passwords.

With all of this in mind, it is important to tune the Snort installation in order to reduce the noise, or "false positive" to legitimate alert ratio. Here are some steps that you can follow to accomplish the task.

Follow up:

Reducing reporting frequency

A single source IP address can be responsible for a lot of alerts. For example someone trying to brute force FTP or SSH credentials can set off hundreds of alerts a minute, filling up the logs. This noise can distract you from legitimate alerts making the IDS system less useful.

Adding the following line to your threshold.conf will significantly reduce the noise in your logs, reporting only one event per every rule of every generator, triggered by a specific source IP. It could potentially safe you from going through hundreds of log entries every day.

threshold gen_id 0, sig_id 0, type limit, track by_src, count 1, seconds 60

 

Filtering false positives

The second largest source of noise in the logs are "false positives". False positive can be roughly classified as an alert that repeats frequently, and is raised in response to what appears to be legitimate traffic. For example, if you are running a Web server you may see a lot of these alerts:

WEB-MISC robots.txt access

Access to robots.txt is a normal behavior practiced by many search engines. There is little to no possibility for a compromise based on access to this file, therefore it can be filtered out to reduce the noise ratio. The easiest way to accomplish this is by utilizing threshold.conf file again. But this time instead of using "threshold" feature you can use "suppress" feature to stop the reporting of the event.

Before we add a line to accomplish this task we need to find out the SID of the event. This can be accomplished either from BASE web interface, by going into the event and clicking on "snort" link, or by using search form located at http://www.snort.org/pub-bin/sigs.cgi. For the above mentioned event search "by message" will return an SID of 1852.

Now we can add the following line to threshold.conf:

suppress gen_id 1, sig_id 1852, track by_dst, ip [dest ip]

Replace [dest ip] with the relevant web server or a network range where web servers are hosted.

 

Dealing with annoying attackers

The noise can also be produced by brute force attempts. For example an FTP brute force attempt can go on over a period of hours and set off a lot of alerts even when logging threshold is set to one event in 60 seconds.

You can fight these attacks by using snort's flex response feature. Flex response allows snort to actively close offending connections.

In order to enable this feature you have to compile or recompile Snort after running "configure" script with the following additional option:

--enable-flexresp

Flex response then can be used to send reset or other ICMP packets to the offending party, effectively terminating the session.

I use local.rules files to create my own custom reset rules. You need to create this file under your "rules" directory and also include it in the main snort.conf file.

The following rule allows me to detect failed FTP login and terminate the session:

alert tcp $HOME_NET 21 -> $EXTERNAL_NET any (msg:"INFO FTP Bad blood"; flow:from_server,established; content:"530 "; pcre:"/^530\s+(Login|User)/smi"; classtype:bad-unknown;resp:rst_rcv;sid:200000;)

This rule will detect "530" error within the flow from the protected FTP server and send a Reset packet to the client, requiring the malicious person to establish a new FTP connection for every login attempt, and making the attack much less practicle. Multiple FTP sessions over a period of time can then be detected using a rule like:

alert tcp $EXTERNAL_NET-> $HOME_NET 21 any (msg:"INFO Too many FTP attempts"; flags: S; threshold: type threshold, track by_src, count 5, seconds 120; classtype: suspicious-login;resp:icmp_all;sid:200000;)

This rule will detect more than 5 FTP sessions in 120 seconds and send "ICMP_NET_UNREACH", "ICMP_HOST_UNREACH" and "ICMP_PORT_UNREACH" back to the client.

All possible response values are:

rst_snd send TCP-RST packets to the sending socket
rst_rcv send TCP-RST packets to the receiving socket
rst_all send TCP_RST packets in both directions

icmp_net send a ICMP_NET_UNREACH to the sender
icmp_host send a ICMP_HOST_UNREACH to the sender
icmp_port send a ICMP_PORT_UNREACH to the sender
icmp_all send all above ICMP packets to the sender

Enjoy!