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/
False positive on any request containing ?????????? in the URL
"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. "
False positive on payloads containing CCCCCCCCCCCCCCCCCCCCCCCC, brought to my attenti0n on the ClearOS forums (thanks Kevin and Tim)
False positive on payloads containing 'aaaaaaaaaaaaaaaaaaaaa'
False positive on any request where the string "chunked" preceeds the Transfer-Encoding header. A fix is available at:
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.
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:
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
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.
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.