[Oisf-users] distance, uricontent

[Geoff Whittington]

Nevermind my #3 comment. I officially retract it :)

On Thu, Mar 18, 2010 at 1:01 PM, Will Metcalf <william.metcalf at gmail.com> wrote:
>> Re: 3.  Ignoring the modifiers could change the behaviour of existing
>> signatures.
>
> Essentially this is what happens in snort now, if you are using a
> uricontent1:/foo; uricontent2:bar; distance:0; cocktail to match on
> /foobar
>
> 1. match uricontent1:/foo from the beginning of the normalized buffer
> 2. match uricontent2:bar from the beginning of the normalized buffer
> even though distance:0 is set because it always starts from the
> beginning of the normalized buffer.
>
> You could set uricontent1:/foo; uricontent2:bar; distance:4; and the
> sig would still match.  Or are you trying to say support distance but
> do as snort does and treat it like depth starting from beginning of
> the normalized buffer?
>
> Regards,
>
> Will
>
> On Thu, Mar 18, 2010 at 11:46 AM, Geoff Whittington
> <geoff.whittington at gmail.com> wrote:
>> Re: 1. Since snort currently does not fail the signature, then
>> rejecting the rule could create headaches for users.
>>
>> Re: 2.  I would agree - accept the rule and use the modifiers with the
>> normalized buffer.
>>
>
>>
>> I don't really like this idea but: create a configuration switch that
>> spells out the behaviour of the distance/within modifier to support
>> older signatures.
>>
>> On Thu, Mar 18, 2010 at 11:20 AM, Will Metcalf
>> <william.metcalf at gmail.com> wrote:
>>> IMHO the implementation in snort is broken. From what I have seen
>>> distance always starts at the beginning of the normalized buffer
>>> rather than from the end of the last uricontent match.  I don't think
>>> this is right....
>>>
>>> We should do one of the following...
>>>
>>> 1. Reject the rule because in snort it really doesn't work.
>>> 2. Accept the rule and setup distance and within to work against the
>>> normalized buffer(my vote).
>>> 3. Accept the rule and ignore distance as in snort it really doesn't work.
>>>
>>> Things get weirder when you start to mix and match uricontent,content
>>> and within/distance. but we will save that for later.
>>>
>>> What does the community think?
>>>
>>> Regards,
>>>
>>> Will
>>>
>>> #test 32 uricontent with distance modifier
>>> #This is broken the sig still fires using two uricontent matches
>>> distance always starts at the beginning of normalized buffer
>>> #
>>> #file allworkandnoplayplain.pcap and allworkandnoplayencoded.pcap
>>> #alert tcp any any -> any any (msg:"uricontent match against
>>> /AllWorkAndNoPlayMakesWillADullBoy with distance";
>>> uricontent:"/AllWorkAndNoPlay"; uricontent:"MakesWillADullBoy";
>>> distance:17; classtype:bad-unknown; sid:32; rev:1;)
>>>
>>> On Thu, Mar 18, 2010 at 9:52 AM, Geoff Whittington
>>> <geoff.whittington at gmail.com> wrote:
>>>> Hello,
>>>>
>>>> Can someone confirm whether there was a decision about the
>>>> interpretation of uricontent as a "pattern match"? i.e.
>>>>
>>>> uricontent:"BAAD"; uricontent:"FOOD"; distance:0;
>>>>
>>>> According to snort:
>>>>
>>>> "The distance keyword allows the rule writer to specify how far into a
>>>> packet Snort should
>>>> ignore before starting to search for the specified pattern relative to
>>>> the end of the previous
>>>> pattern match."
>>>>
>>>> Cheers,
>>>>  - Geoff
>>>> _______________________________________________
>>>> Oisf-users mailing list
>>>> Oisf-users at openinfosecfoundation.org
>>>> http://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users
>>>>
>>> _______________________________________________
>>> Oisf-users mailing list
>>> Oisf-users at openinfosecfoundation.org
>>> http://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users
>>>
>>
> _______________________________________________
> Oisf-users mailing list
> Oisf-users at openinfosecfoundation.org
> http://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users
>