[Snort-sigs] Using within after http_headers

Joel Esler jesler at ...435...
Fri Apr 30 15:48:16 EDT 2010


Roger.  I'll defer to Olney/$vrt, they've tested and used those modifiers
for a lot longer than I.

On Fri, Apr 30, 2010 at 3:44 PM, Will Metcalf <william.metcalf at ...2420...>wrote:

> >On Fri, Apr 30, 2010 at 2:31 PM, Joel Esler <jesler at ...435...>
> 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 at ...2420...
> >
> > 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 at ...435...>
> >> wrote:
> >>
> >> > On Fri, Apr 30, 2010 at 12:35 PM, Mike Cox <mike.cox52 at ...2420...>
> 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 at lists.sourceforge.net
> >> >> https://lists.sourceforge.net/lists/listinfo/snort-sigs
> >> >
> >> >
> >> >
> >> >
> ------------------------------------------------------------------------------
> >> >
> >> > _______________________________________________
> >> > Snort-sigs mailing list
> >> > Snort-sigs at lists.sourceforge.net
> >> > https://lists.sourceforge.net/lists/listinfo/snort-sigs
> >> >
> >> >
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.snort.org/pipermail/snort-sigs/attachments/20100430/0f728df2/attachment.html>


More information about the Snort-sigs mailing list