Re: PCRE and uricontent anchor

[Joel Esler <joel.esler () me com>]

You are correct it would work because the content match of the uri is  
longer than the content match of POST.

--
Joel Esler
Sent from my iPhone

On Mar 26, 2010, at 4:13 PM, "evilghost () packetmail net" <evilghost () packetmail net 
> wrote:

> My understanding is no, because in this case the uricontent match is  
> the
> fast_pattern match, so the uricontent would match first then upon  
> match
> the content match would fire as well as the PCRE engine.  The ordering
> I'd need some clarification on and Joel and the others could likely
> better explain it than I.  My impression is that the uricontent fires
> first, then the content match constrained to the http_header, the
> finally the PCRE engine is invoked.
>
> Either way, the PCRE engine is necessary in this case to anchor cast  
> to
> the "id=" query_string value since we're expecting an integer value  
> and
> it's needed to not fire on false positives.  So even if my engine
> ordering is incorrect the performance cost is still necessary in my  
> eyes.
>
> So, as I perceive it the question you're asking is "Are we inspecting
> every HTTP POST method for the matching uricontent" and my answer is
> "No" we're only inspecting HTTP POST if the URI is as specified then
> invoking the PCRE engine for cast.
>
> I'll take a back seat to any corrections and would appreciate them  
> if I
> am incorrect.
>
> -evilghost
>
> evejou wrote:
> > Would the "POST" content result in an undue number of partial  
> > matches?
> > Just wondering, as I have heard several reactions that using  
> > thousands
> > of signatures that using HTTP commands like "HEAD" and "POST" can
> > really slow a machine down.
> >
> >
> >
> > On Fri, Mar 26, 2010 at 2:52 PM, evilghost () packetmail net
> > <mailto:evilghost () packetmail net> <evilghost () packetmail net
> > <mailto:evilghost () packetmail net>> wrote:
> >
> >    There's no reason that Joel's wouldn't work but like all things
> >    there's
> >    multiple solutions.  I'd write it like this:
> >
> >    alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"Evil
> >    stuff";
> >    flow:established,to_server; content:"POST"; nocase; http_method;
> >    uricontent:".aspx?id="; nocase; pcre:"/\.aspx\?id=\d+$/Ui";  
> > classtype:
> >    bad-unknown; sid:2010xxx; rev:1;)
> >
> >    Please note the preceding period in ".aspx" uricontent match as
> >    well as
> >    the PCRE and the end of string/buffer anchor in the URI
> >    constrained PCRE
> >    which matches the cast of the id= query_string.
> >
> >    Hope this helped.  Replace $HTTP_PORTS with 443 if you're really  
> > only
> >    concerned with an HTTPS endpoitn.
> >
> >    -evilghost
> >
> >    Curt Shaffer wrote:
> > > I am attempting to write a rule that would capture a POST event
> >    to a url with a specific file. Here is an example:
> > > https://www.example.com/abc.aspx?id=459184950
> > >
> > > The id section is always different. We also want to look for any
> >    similar POSTS to any address. With that in mind, here is the basis
> >    of what we came up with.
> > > alert tcp $home_net any -> $external_net 443 (msg:"Bad stuff
> >    potentially going on"; pcre:"a.\.aspx\?id=.*"; classtype:
> >    trojan-activity; sid:10000015; rev:1;)
> > > My question is, I suppose can we use a pcre match with no
> >    content or uricontent anchor, but that would be a pretty slow rule
> >    most likely. Does anyone have a suggestion on how I could anchor
> >    this to make it more efficient?
> > > Thanks
> > >
> > > Curt
> >     
> > --- 
> > --- 
> > --- 
> > ---------------------------------------------------------------------
> > > Download Intel&#174; Parallel Studio Eval
> > > Try the new software tools for yourself. Speed compiling, find bugs
> > > proactively, and fine-tune applications for parallel performance.
> > > See why Intel Parallel Studio got high marks during beta.
> > > http://p.sf.net/sfu/intel-sw-dev
> > > _______________________________________________
> > > Snort-sigs mailing list
> > > Snort-sigs () lists sourceforge net
> >    <mailto:Snort-sigs () lists sourceforge net>
> > > https://lists.sourceforge.net/lists/listinfo/snort-sigs
> >
> >     
> > --- 
> > --- 
> > --- 
> > ---------------------------------------------------------------------
> >    Download Intel&#174; Parallel Studio Eval
> >    Try the new software tools for yourself. Speed compiling, find  
> > bugs
> >    proactively, and fine-tune applications for parallel performance.
> >    See why Intel Parallel Studio got high marks during beta.
> >    http://p.sf.net/sfu/intel-sw-dev
> >    _______________________________________________
> >    Snort-sigs mailing list
> >    Snort-sigs () lists sourceforge net
> >    <mailto:Snort-sigs () lists sourceforge net>
> >    https://lists.sourceforge.net/lists/listinfo/snort-sigs
> >
> >
> >
> >
> > -- 
> > ---
> > girl () techn0ev3 net <mailto:girl () techn0ev3 net>
> >
> > Finché c'è vita, c'è speranza.
> > As long as there is life, there is hope.
>
> --- 
> --- 
> --- 
> ---------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Snort-sigs mailing list
> Snort-sigs () lists sourceforge net
> https://lists.sourceforge.net/lists/listinfo/snort-sigs

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Snort-sigs mailing list
Snort-sigs () lists sourceforge net
https://lists.sourceforge.net/lists/listinfo/snort-sigs