[Snort-sigs] Suggestions for new attack response rules

Nick nick at ...2174...
Sun Dec 5 06:10:01 EST 2004

Joe Patterson said the following on 03/12/2004 11:38:
> The primary utility I'm trying to get to here is this.  Looking at one of my
> apache webservers, in the last two weeks I've gotten 70 requests for
> /scripts/..%%35c../winnt/system32/cmd.exe?/c+dir.  They all got a 400
> response.  They all triggered an IDS alert.  Those alerts weren't really
> false positives.  It was a real attack, but the server wasn't vulnerable.  I
> certainly can't ignore those alerts, but I can take my time getting to them.

Just to put a different slant on this, in the above example I alert in a low 
state (changing the categories) for this rule and it gets kept in the DB for the 
stats each month. BUT if I see the actual shell header coming back from port 80 
(ie. the backdoor they created) then this rings the all the alarm bells at a 
high state and gets me out of bed.  Of course this does give some FPs if you 
have webpages that contain windows shell headers.  I guess you could then match 
these to the original alert with flowbits?



More information about the Snort-sigs mailing list