[Snort-sigs] Suggestions for new attack response rules

Joe Patterson jpatterson at ...2901...
Fri Dec 3 07:07:04 EST 2004


The problem is that it's not just a new snort rule.  It's a new snort rule
*plus* a modification to a whole bunch of existing snort rules.  The rules
as I wrote them will never trigger, because there's nothing to ever set that
flowbit (and snort will helpfully warn you that you have a rule that's
checking for a flowbit that no rule ever sets)

-Joe

> -----Original Message-----
> From: Matthew Jonkman [mailto:matt at ...2436...]
> Sent: Friday, December 03, 2004 8:54 AM
> To: Joe Patterson
> Cc: snort-sigs at lists.sourceforge.net
> Subject: Re: [Snort-sigs] Suggestions for new attack response rules
>
>
> I would go along with this myself. I tend to err on the side of more
> information being a good thing, up to the threshold of saturation of
> course.
>
> Lets put these up in the bleeding rules for a while and see how they go
> eh? Worst thing that can happen is get get slammed with falses for a few
> minutes and have to take them back out.
>
> I'll post the rule below shortly. Any ideas for modification welcome.
>
> Matt
>
> Joe Patterson wrote:
>
> > I wouldn't say it necessarily breaks down.  In situation 1, you
> don't care,
> > because you don't care about these rules anyway.  In situation 2, an
> > attacker has to, in their initial attack, not only compromise
> the server,
> > but cause the server to change its handling of the cgi that it
> is *currently
> > running* to non-parsed-header mode, and then send back a 4xx/5xx header.
> > That may be possible, but I would say that it *really* raises the bar.
> > Situation 3 raises the bar a bit less.  An attacker has to do
> all the normal
> > work of compromising a server, and has to make sure that all of
> the replies
> > he gets include that custom 404 message.
> >
> > 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.
> >
> > -Joe
> >
> >
> >>-----Original Message-----
> >>From: snort-sigs-admin at lists.sourceforge.net
> >>[mailto:snort-sigs-admin at lists.sourceforge.net]On Behalf Of Jason
> >>Sent: Thursday, December 02, 2004 10:33 PM
> >>To: Joe Patterson
> >>Cc: Brian; snort-sigs at lists.sourceforge.net
> >>Subject: Re: [Snort-sigs] Suggestions for new attack response rules
> >>
> >>
> >>The concept breaks down the moment the attacker instructs the server to
> >>return a HTTP 404 error document with the content you need and then
> >>spawns a shell to you.
> >>
> >>Joe Patterson wrote:
> >>
> >>>It's not simple, and it's certainly not perfect.  (if we only allowed
> >>>perfect rules, we'd have a lot fewer rules than we do)  But
> >>
> >>even given that,
> >>
> >>>I think it could be usefull.  The primary utility lies in setting the
> >>>flowbit for the http-based attacks.
> >>>
> >>>Given the following situations:
> >>>1) you don't have any web servers, you're just monitoring
> >>
> >>traffic out to the
> >>
> >>>net in general.
> >>>Then you would probably want to disable the 4 attack response
> >>
> >>rules, because
> >>
> >>>the web servers "out there" aren't under your control, and you don't
> >>>necessarily care if they're actually compromised, you primarily care if
> >>>someone in the network that *is* under your control is trying
> >>
> >>to hack other
> >>
> >>>people's boxes.
> >>>
> >>>2) you do have webservers, all of which are well-behaved and
> >>
> >>use http status
> >>
> >>>codes in appropriate ways.
> >>>Wonderful, now you'll not only know when people attack, but when they
> >>>succeed.
> >>>
> >>>3) you have webservers that aren't quite standards compliant.
> >>
> >>For instance,
> >>
> >>>I believe that IIS servers with a custom 404 page actually give
> >>
> >>a status of
> >>
> >>>200, but return the custom 404.
> >>>This isn't too big a deal.  Edit the 4 signatures for attack
> >>
> >>responses so
> >>
> >>>that they will match anything that isn't your custom 404 page.  Perhaps
> >>>something like 'content:!"404 page not found"' or whatever suits your
> >>>environment.
> >>>
> >>>4) most of your webservers are compliant, but one or two are
> >>
> >>smoking crack,
> >>
> >>>and can't be trusted to return meaningful status codes for anything.
> >>>Add a suppression by_src for these rules, and only care about
> the alerts
> >>>from your more well-behaved webservers.
> >>>
> >>>I just can't think of a case where these rules would actually
> >>
> >>be *bad*, and
> >>
> >>>there are certainly quite a few places where they would be usefull.
> >>>
> >>>I guess the alternative is to use oinkmaster with a
> >>
> >>modification map for the
> >>
> >>>1K or so rules that I think need it to add the flowbits chunk.
> >>
> >>But I felt
> >>
> >>>like this was a usefull enough thing that it would be worth
> >>
> >>adding to the
> >>
> >>>main distribution.
> >>>
> >>>-Joe
> >>>
> >>>
> >>>
> >>>>-----Original Message-----
> >>>>From: Brian [mailto:bmc at ...95...]
> >>>>Sent: Wednesday, December 01, 2004 4:02 PM
> >>>>To: Joe Patterson
> >>>>Cc: snort-sigs at lists.sourceforge.net
> >>>>Subject: Re: [Snort-sigs] Suggestions for new attack response rules
> >>>>
> >>>>
> >>>>On Wed, Dec 01, 2004 at 03:51:25PM -0500, Joe Patterson wrote:
> >>>>
> >>>>
> >>>>>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;)
> >>>>
> >>>>Yes, I've thought about this for a long time.  Its not anywhere near
> >>>>as simple as you suggest.
> >>>>
> >>>>Look at how nessus handles error codes.  MANY websites no longer use
> >>>>200s for "good", and 300s & 400s for various errors, they use 200s for
> >>>>EVERYTHING.
> >>>>
> >>>>Sure, you might get a good feeling for the one or two sites you are
> >>>>looking at for reducing false positives.  In the rest of the world,
> >>>>just looking at HTTP codes is NOT enough.
> >>>>
> >>>>Brian
> >>>>
> >>>>
> >>>
> >>>
>
>
>
>





More information about the Snort-sigs mailing list