Re: PCRE and uricontent anchor

["evilghost () packetmail net" <evilghost () packetmail net>]

Right, and if this were not the case I could specify fast_pattern to the 
uricontent match.

For example, same scenario except (very poor example) that I'm matching:

uricontent:"?id";

I should specify fast_pattern; after the uricontent match since the 
string is less in length than the content match of "POST" constrained to 
the http_header;.  This way I only inspect every URI matching "?id" for 
the HTTP method of POST, not every HTTP POST for the URI of "?id".

Joel correct me if I'm wrong, I think you see what I'm trying to get at.

-evilghost

Joel Esler wrote:
> 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