[Snort-sigs] [Emerging-Sigs] what s the real difference here?

Joel Esler jesler at ...435...
Tue Jul 13 20:06:52 EDT 2010


On Jul 13, 2010, at 8:03 PM, evilghost at ...3397... wrote:
> 
>>> Riddle me this.  If I constrain a content match to the URI buffer (ala http_uri;) can I now use content modifiers which do not work with a uricontent match?  Some of these being
>>> depth, distance, isdataat, etc?
>> 
>> I'd like the Snort team to comment on this one, as I don't want to give you a wrong answer, but since it's reading a normalized field, my knee jerk reaction is to say "no."
>> 
>> 
> 
> Thanks Joel, the reason I ask is I think I ran into this issue with a content match following another content match constrained to 'http_cookie;' which attempted to be relative to
> the previous content match with a modifier (from what I recall it was 'distance'). AFAIK it doesn't work this way and 'content:"spice"; http_uri;' is a pseudonym for
> 'uricontent:"spice";' and any content modifiers aren't applicable.  I'm not sure that's going to be implied in the manual with regard to many of the content modifiers... Make sense?

Yes, I do understand.  Like I said, I'd like a Snort team comment on this one, just so we can be clear.  Are you saying that we should make it clear in the manual?

> Essentially, confining to the http_uri; isn't as "useful" as http_cookie; and http_header; due to the existence of uricontent.

Yeah, let me defer to comment from the dev.  I am sure there was a reason for the separate development, even if it's planning for future use.





More information about the Snort-sigs mailing list