Ethical Hacking Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package. | Computer Forensics Training at InfoSec Institute Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors. |

| Subject: | [Snort-sigs] Suggestions for new attack response rules |
|---|---|
| Date: | Wed, 1 Dec 2004 15:51:25 -0500 |
I've got a suggestion for a set of rules, and I wanted to run it up the flagpole here and see what people think. What I'm trying to do (and it's working for me so far...) is to highlight successful attacks using flowbits. The suggestion I have is about 4 new rules, and a small modification to about 1K existing rules. First, the new rules: alert tcp any $HTTP_PORTS -> any any (msg:"ATTACK-RESPONSES DOS attack OK response"; flow:from_server,established; pcre:"/^HTTP/1.1 (2|3)\d\d/"; flowbits:isset,http-dos-attack; classtype:successful-dos;) alert tcp any $HTTP_PORTS -> any any (msg:"ATTACK-RESPONSES User attack OK response"; flow:from_server,established; pcre:"/^HTTP/1.1 (2|3)\d\d/"; flowbits:isset,http-user-attack; classtype:successful-user;) alert tcp any $HTTP_PORTS -> any any (msg:"ATTACK-RESPONSES admin attack OK response"; flow:from_server,established; pcre:"/^HTTP/1.1 (2|3)\d\d/"; flowbits:isset,http-admin-attack; classtype:successful-admin;) alert tcp any $HTTP_PORTS -> any any (msg:"ATTACK-RESPONSES recon OK response"; flow:from_server,established; pcre:"/^HTTP/1.1 (2|3)\d\d/"; flowbits:isset,http-recon; classtype:successful-recon-limited;) and 4 samples of existing rule modifications: #sid:1115 becomes alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"WEB-MISC ICQ webserver DOS"; flow:to_server,established; uricontent:".html/......"; nocase; reference:cve,CVE-1999-0474; classtype:attempted-dos; sid:1115; rev:6; flowbits:set,http-dos-attack;) #sid:805 becomes alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"WEB-CGI webspeed access"; flow:to_server,established; uricontent:"/wsisa.dll/WService="; nocase; content:"WSMadmin"; nocase; reference:arachnids,467; reference:cve,CVE-2000-0127; reference:nessus,10304; classtype:attempted-user; sid:805; rev:8; flowbits:set,http-user-attack;) #sid:2090 becomes alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"WEB-IIS WEBDAV exploit attempt"; flow:to_server,established; content:"HTTP/1.1|0A|Content-type|3A| text/xml|0A|HOST|3A|"; content:"Accept|3A| */*|0A|Translate|3A| f|0A|Content-length|3A|5276|0A 0A|"; distance:1; reference:bugtraq,7716; reference:cve,CAN-2003-0109; reference:url,www.microsoft.com/technet/security/bulletin/ms03-007.mspx; classtype:attempted-admin; sid:2090; rev:6; flowbits:set,http-admin-attack;) #sid:807 becomes alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"WEB-CGI /wwwboard/passwd.txt access"; flow:to_server,established; uricontent:"/wwwboard/passwd.txt"; nocase; reference:arachnids,463; reference:bugtraq,649; reference:cve,CVE-1999-0953; reference:nessus,10321; classtype:attempted-recon; sid:807; rev:9; flowbits:set,http-recon;) As a test, I took the 1000 or so rules that I think this could apply to and blindly modified them (sed is your friend) with the appropriate flowbits addition and added the 4 response rules to them. I then ran snort with just those rules (and supporting variables and preprocessors) on a 100Mbyte capture of pure http traffic that I had lying around. The performance difference isn't as much as I would have thought. My capture had: 4185 flows 145945 packets 100000483 bytes my machine was: P4 2.8Ghz 2G mem snort-2.3.0RC1 The average packet processing time over 3 runs without any changes was 0.664935 seconds. The average *with* the flowbits changes was 0.698618667, a difference of 0.033683667 seconds, or about a 5% slowdown. As far as I could tell, differences in memory usage were insignificant. Of course, a normal distribution of traffic will have something less than 100% http, so the performance impact should be somewhat less. What is really enlightening is looking through the alert file. I had 353 signature matches in the capture I had. Of those, there were 134 positive responses. Manual correlation of the attack to the response was fairly easy, and definitely made things a bit easier. So, what do people think? -Joe Patterson, CCNP, CISSP Senior Security Engineer SteelCloud, Inc. (954)318-3200x105 jpatterson@asgardgroup.com ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ Snort-sigs mailing list Snort-sigs@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/snort-sigs
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: [Snort-sigs] phpBB remote code execution detection rule (final), Tony Blackmon |
|---|---|
| Next by Date: | Re: [Snort-sigs] Suggestions for new attack response rules, Brian |
| Previous by Thread: | [Snort-sigs] DC++ p2p rules?, Tony Hernandez |
| Next by Thread: | Re: [Snort-sigs] Suggestions for new attack response rules, Brian |
| Indexes: | [Date] [Thread] [Top] [All Lists] |