=^.^=

Bad Snort Rules

karma

Protecting a busy web platform or ISP with snort is made challenging due to the large number of false positives it generates in these environments. This post will serve as a compilation of snort rules I think should be disabled or tuned out of the box, it will be updated as I find new ones. The only way to tell if snort is interfering with legitimate traffic is to monitor its logs over a long period and look up the rules which appear most often. Make sure these rules don't do anything that could interfere with your regular operations - for example a rule to block the slammer worm that hits a dozen times a day probably has nothing to do with your e-mail troubles but a rule for an outdated MTA might explain why Blackberry's servers are being blocked every time a client tries to check their mail.

On ClearOS systems snort rules are located in /var/lib/suva/services/intrusion-protection/rules/ (formerly /var/lib/suva/services/snort/rules/).  To find a rule change to that directory then

# grep sid:number *

and the file name and line number will be printed next to the rule's line. Disabling a rule is as simple as prefixing it with a hash mark (#) and restarting snort:

# /etc/init.d/snort restart

I've started a thread in the Clear forums so everyone can share and discuss their false positives: http://www.clearfoundation.com/component/option,com_kunena/Itemid,232/catid,7/func,view/id,12205/

SID 1091:
False positive on any request containing ?????????? in the URL

SID 1233:
"I noticed, what I believe to be a false positive in rule 1233 (Outlook EML access).: a user was accessing hotmail and the GET was for /i.p.emlips.gif. Since the rule is looking for uricontent:".eml", an alert was triggered. "
http://www.networksecurityarchive.org/html/Snort-Signatures/2005-06/msg00008.html

SID 1390:
False positive on payloads containing CCCCCCCCCCCCCCCCCCCCCCCC, brought to my attenti0n on the ClearOS forums (thanks Kevin and Tim)
http://www.clearfoundation.com/component/option,com_kunena/Itemid,232/catid,8/func,view/id,9967

SID 1394:
False positive on payloads containing 'aaaaaaaaaaaaaaaaaaaaa'

SID 1807:
False positive on any request where the string "chunked" preceeds the Transfer-Encoding header. A fix is available at:
http://osdir.com/ml/security.ids.snort.sigs/2004-07/msg00018.html

SID  2109:
False positive on any attempt to retrieve e-mail from BlackBerry servers. An interesting note about this, I had dozens of users with blackberries on the network running just fine for years then all at once a few months ago - without even touching the software - snort started blocking the BlackBerry pop3 IP pool and the complaints came flooding in. When I researched it at the time it seemed as though this false positive was reported on at least one mailing list between 2004-6, perhaps RIM switched "back" to the would-be offending platform.

SID 2229:
This rule is false positive for ANY request to viewtopic.php, taking out any visitors to a phpBB installation. There is a fix for this rule outlined in this e-mail from 2004:
http://www.webservertalk.com/archive253-2004-11-452217.html

SID 2000540:
False positive on SSL connections with Google Gmail web servers
It appears to be generating false positives for fragmented ACK packets intended to match a form of Nmap scan
http://www.clearfoundation.com/component/option,com_kunena/Itemid,232/catid,8/func,view/id,19544/#19551

SIDs 1000000211, 1000000212, 1000000213, 1000000214:
"These are known to cause issues with Gallery2 (part of the web PHP rulesets)"
Tim Burgess supplied these on Clear's forum, I think the 1000000000-range rules may be unique to ClearOS.
http://www.clearfoundation.com/component/option,com_kunena/Itemid,232/catid,7/func,view/id,12205/#12227

SID 966
This rule has caused me a lot of problems when uploading large binary files, though I'm not sure why since only the URI should be scanned and not entire POST variables. May be a bad one for me only.

Comments

There are no comments for this item.