[Snort-sigs] Suggestions for new attack response rules
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