[Snort-sigs] Suggestions for new attack response rules
chris at ...2461...
Fri Dec 3 07:14:02 EST 2004
Joe Patterson wrote:
> 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.
> However, if someone were to (unbeknownst to me) stick an unpatched IIS box
> in the DMZ, and that same request came in and received a 200 OK response, I
> would absolutely want to know about it immediately. That's what I see as
> the primary value of these rules.
Brian has a point in that you cant rely on the web-server return-code
being a certain value.
I think these type of rules are site-specific and best kept confined to
local.rules, and preferably, confined to specific machines.
You will get FPs again when somebody puts a webserver online that
doesn't return the anticipated 400 return code for the requests, but
that decision is left up to the sites administrator.
As Brian said, it is not uncommon to have a web-server return 200 OK for
This type of thing is better handled by technology such as Sourcefire's
RNA, which adds secondary intelligence to unify the alerts you get.
That's not to say other FPs cant be weeded out using rules, just this
particular one is not best done by rules.
More information about the Snort-sigs