Re: Using within after http_headers

[Will Metcalf <william.metcalf () gmail com>]

> On Fri, Apr 30, 2010 at 2:31 PM, Joel Esler <jesler () sourcefire com> wrote:
> http_client_body and http_uri aren't normalizers though, they are just
> pointers to locations, the way that I read it.
http_uri is normalized... Not sure about http_client_body..

> As far as the distance:0; that's simply saying that the subsequent content
> must be after the uricontent.  not any distance "away" from the end of it,
> just after the previous match succeeded.

I understand but this can lead to false negatives. If the uricontent
has to be decoded, using the uricontent,content,distance:0 combo
causes the rule not to fire completely....

Regards,

Will

> J
> On Fri, Apr 30, 2010 at 3:21 PM, Will Metcalf <william.metcalf () gmail com>
> wrote:
> > > Correct.  Since this is a normalized field (similar to uricontent), you
> > > can't have a relative statement to a normalized http field like that.
> > > This is as designed.
> > This is not entirely accurate ;-)...  For example some of the
> > spyware-put rules mix uricontent,content and distance:0
> >
> > Also from my tests you can mix http_client_body and http_uri with
> > distance and within, but it fails always for cookie and header.  Also
> > with http_uri just like uricontent if you encode the url distance and
> > within doesn't work.
> >
> > Regards,
> >
> > Will
> >
> > On Fri, Apr 30, 2010 at 11:47 AM, Joel Esler <jesler () sourcefire com>
> > wrote:
> >
> > > On Fri, Apr 30, 2010 at 12:35 PM, Mike Cox <mike.cox52 () gmail com> wrote:
> > > > I'm testing some rules and it seems that using the within content
> > > > modifier on a content match that is relative to a previous content
> > > > match and uses the http_headers content modifier does not work.  For
> > > > example, this is the original rule that is not alerting:
> > > >
> > > > alert tcp any any -> $HOME_NET $HTTP_PORTS (msg:"Testing Referer";
> > > > flow:established,to_server; content:"|0d 0a|Referer\: "; nocase;
> > > > http_header; content:!"google.com"; nocase; within:50;
> > > > classtype:bad-unknown; rev:1; sid:7500010;)
> > > >
> > > > But if I remove the within OR the http_header content modifiers, the
> > > > rule alerts.  So both these alert:
> > > >
> > > > alert tcp any any -> $HOME_NET $HTTP_PORTS (msg:"Testing Referer";
> > > > flow:established,to_server; content:"|0d 0a|Referer\: "; nocase;
> > > > content:!"google.com"; nocase; within:50; classtype:bad-unknown;
> > > > rev:1; sid:7500010;)
> > > >
> > > > alert tcp any any -> $HOME_NET $HTTP_PORTS (msg:"Testing Referer";
> > > > flow:established,to_server; content:"|0d 0a|Referer\: "; nocase;
> > > > http_header; content:!"google.com"; nocase; classtype:bad-unknown;
> > > > rev:1; sid:7500010;)
> > > >
> > > > Is there some weird stuff going on with the HTTP header buffer such
> > > > that subsequent within content modifiers don't work?  If so, is this
> > > > as designed?
> > > >
> > > > Thanks.
> > > >
> > > > -Mike Cox
> > > >
> > > >
> > > >
> > > > ------------------------------------------------------------------------------
> > > > _______________________________________________
> > > > Snort-sigs mailing list
> > > > Snort-sigs () lists sourceforge net
> > > > https://lists.sourceforge.net/lists/listinfo/snort-sigs
> > >
> > >
> > >
> > > ------------------------------------------------------------------------------
> > >
> > > _______________________________________________
> > > Snort-sigs mailing list
> > > Snort-sigs () lists sourceforge net
> > > https://lists.sourceforge.net/lists/listinfo/snort-sigs

------------------------------------------------------------------------------
_______________________________________________
Snort-sigs mailing list
Snort-sigs () lists sourceforge net
https://lists.sourceforge.net/lists/listinfo/snort-sigs