I have several developments to report from the
Snort front. First, Jeremy Hewlett
announced Thursday the release of
Snort 2.3.2. This version is a quick response to the problem parsing
Bleeding Snort rules
reported shortly after Snort 2.3.1 arrived. I think this release was quickly pushed out the door to demonstrate that Sourcefire was not trying to lock out Bleeding Snort users. This is smart; there's no need to repeat a Microsoft-style "DOS isn't done until Lotus won't run" situation with Snort!
Speaking of Bleeding Snort, Matt Jonkman
announced Friday work on a new "Open Source Snort Rules Consortium." He says:
"The OSSRC will be a group that any company or organization will be welcome to join. The members will share research on new threats and rules to handle those threats, with the goal of creating a unified community-based ruleset. Each member may post these rules wherever they choose, distribute them to their clients or customers, or use them in their own subscription services according to the provisions in the GPL. The goals of the group are still forming, but initially will be to:
1. Maintain a fast moving and GPL-licensed Snort ruleset
2. Avoid rule duplication amongst community rulesets, both in terms of content and SIDs
3. Improve and enforce quality standards for rules (documentation, etc.)
4. Possibly move to a Stable and Unstable rule 'vetting' process"
It will be interesting to see how this rule set progresses. If you visit the
Snort rules download page you'll see three sets of rules:
- Sourcefire VRT Certified Rules - The Official Snort Ruleset (subscription release)
- Sourcefire VRT Certified Rules - The Official Snort Ruleset
- Community Rules
The first are the latest and greatest, available to subscribers. The second are the five-day-delay version of the first set, available to registered users. The third are new, and include:
- community-exploit.rules
- community-ftp.rules
- community-game.rules
- community-inappropriate.rules
- community-mail-client.rules
- community-sql-injection.rules
- community-virus.rules
- community-web-cgi.rules
- community-web-client.rules
- community-web-dos.rules
- community-web-misc.rules
A look at the sid-msg.map summarizes the rules included in this first community rule set. Observe that some of the files (community-web-dos.rules, for example) are empty:
# Copyright 2005 Sourcefire, Inc. All Rights Reserved.
# This file is licensed under the GNU General Public License.
# Please see the file LICENSE in this directory for more details.
# Id SID -> MSG map
100000100 || COMMUNITY EXPLOIT Windows Acrobat Reader Activex Overflow Flowbit || cve,2004-0629 || bugtraq,10947
100000101 || COMMUNITY EXPLOIT Windows Acrobat Reader Activex Overflow Exploit || cve,2004-0629 || bugtraq,10947
100000102 || COMMUNITY GAME Halocon Denial of Service Empty UDP Packet || bugtraq,12281
100000103 || COMMUNITY GAME Breed Game Server Denial of Service Empty UDP Packet || bugtraq,12262
100000104 || COMMUNITY GAME Amp II 3D Game Server Denial of Service Empty UDP Packet || bugtraq,12192
100000105 || INAPPROPRIATE lolita sex
100000106 || COMMUNITY SQL-INJECTION Microsoft BizTalk Server 2002 rawdocdata.asp || bugtraq,7470 || cve,2003-0118 || url,www.microsoft.com/technet/security/bulletin/MS03-016.mspx
100000107 || COMMUNITY SQL-INJECTION Microsoft BizTalk Server 2002 RawCustomSearchField.asp || bugtraq,7470 || cve,2003-0118 || url,www.microsoft.com/technet/security/bulletin/MS03-016.mspx
100000108 || COMMUNITY SQL-INJECTION OpenBB board.php || bugtraq,7404
100000109 || COMMUNITY SQL-INJECTION OpenBB member.php || bugtraq,7404
100000110 || COMMUNITY VIRUS Dabber PORT overflow attempt port 5554 || MCAFEE,125300
100000111 || COMMUNITY VIRUS Dabber PORT overflow attempt port 1023 || MCAFEE,125300
100000112 || WEB-CGI Readfile.tcl Access || bugtraq,7426
100000113 || COMMUNITY WEB-CGI HappyMall Command Execution member_html.cgi || bugtraq,7530 || cve,2003-0243
100000114 || COMMUNITY WEB-CGI HappyMall Command Execution normal_html.cgi || bugtraq,7530 || cve,2003-0243
100000115 || COMMUNITY WEB-CGI PHP-Nuke Web_Links Path Disclosure Null CID || bugtraq,7589
100000116 || COMMUNITY WEB-CGI PHP-Nuke Web_Links Path Disclosure Non-Numeric CID || bugtraq,7589
100000117 || COMMUNITY WEB-CGI VBulliten Remote Command Execution Attempt || bugtraq,12542
100000118 || WEB-CLIENT Internet Explorer URLMON.DLL Content-Type Overflow Attempt || bugtraq,7419 || cve,2003-0113 || url,www.microsoft.com/technet/security/bulletin/MS03-015.mspx
100000119 || WEB-CLIENT Internet Explorer URLMON.DLL Content-Encoding Overflow Attempt || bugtraq,7419 || cve,2003-0113 || url,www.microsoft.com/technet/security/bulletin/MS03-015.mspx
100000121 || COMMUNITY WEB-MISC Test Script Access
100000122 || COMMUNITY WEB-MISC mod_jrun overflow attempt || bugtraq,11245 || cve,2004-0646
100000123 || INAPPROPRIATE preteen sex
100000124 || INAPPROPRIATE girls gone wild
That's only 24 rules at the moment. Let's look at the first two:
alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS
(msg:"COMMUNITY EXPLOIT Windows Acrobat Reader Activex Overflow Flowbit";
flow:to_server,established; pcre:"/.{1050,}/U"; flowbits:set,uri.size.1050;
flowbits:noalert; reference:cve,2004-0629; reference: bugtraq,10947;
classtype:attempted-user; sid: 100000100; rev:1;)
alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any
(msg:"COMMUNITY EXPLOIT Windows Acrobat Reader Activex Overflow Exploit";
flow:to_client,established; content:"Content-Type|3A|"; nocase;
pcre:"/^Content-Type\x3a\s*application\x2f(pdf|vnd\x2efdf|
vnd\x2eadobe\x2exfdf|vnd\x2eadobe\x2exdp+xml|vnd\x2e\ adobe\x2exfd+xml)/smi";
flowbits:isset,uri.size.1050; reference:cve,2004-0629; reference:bugtraq,10947;
classtype:attempted-user; sid:100000101; rev:1;)
When I met with Marty on Thursday, he said that rules like the first one that invoke PCRE but do not use a content match really slow down the detection engine. The second rule also uses (complicated) PCRE, but there is a content match.
Given the limited number of rules in this community set, I can see why a company like
StillSecure decided to
sponsor Bleeding Snort. StillSecure's IDS is built on Snort, so they have an incentive to sponsor signature research.
This weekend the 
Last night I attended the northern Virginia 
Today I visited the Columbia, MD headquarters of 
Besides helping to pay rule developer salaries, revenue from the new rules system will also help pay for the equipment Sourcefire uses to develop and test Snort. At right is a picture of one of the racks of networking and testing infrastructure Sourcefire owns. The racks holds $500,000 worth of 
At left is a picture of some of the racks containing servers Sourcefire uses to develop Snort and associated components. Marty said the company has over 26 racks with more than 300 servers. They maintain gear for every version of their appliance they've shipped. They also have target ranges and plenty of development systems. When Sourcefire develops a new rule, for example, they perform 6.8 million regression tests to ensure the new rule does not adversely affect the rest of the rule base. Sometimes these tests take up to four hours per change, even with the load distributed across multiple servers. Sourcefire takes great care to ensure that their rules will not cause Snort to waste excessive time processing packets. Marty told how a rule developed by an external Snort user once made such poor use of 
After looking at Sourcefire's server room, we toured the workspace. Marty employees over 60 people in his Columbia, MD location at over 100 worldwide. In addition to meeting with Judy Novak, who works on the VRT, we also spoke with Snort rule uber-creator Brian Caswell. I mentioned that the Snort 2.3.1 ruleset had 
After touring the floor we spoke to Marty about the future of Sourcefire. He is excited about the new 
Near the end of our visit Marty made some interesting points about market pressure on the security scene. He said Sourcefire felt the heat from Gartner's declaration that 
