[Oisf-users] Issue with negated isdataat?

[Harley H]

Interesting. I can open another ticket if needed.

On Thu, Apr 20, 2017 at 4:29 PM, Jason Williams <
jwilliams at emergingthreats.net> wrote:

> Perhaps this may have to do with https://redmine.
> openinfosecfoundation.org/issues/1412
>
> Maybe someone can chime in here to validate this issue with the buffer
> order inspection issue?
>
> On Thu, Apr 20, 2017 at 1:35 PM, Harley H <bobb.harley at gmail.com> wrote:
>
>> With that settled I'm running into another issue.
>>
>> Take these rules for example:
>> #rules
>>
>> alert tcp any any -> any any (msg:"It's Alive!!! 1";
>> byte_extract:1,0,size; content:"123"; isdataat:!size; sid:1102014; rev:1;)
>> alert tcp any any -> any any (msg:"It's Alive!!! 2";
>> byte_extract:1,0,size; content:"123"; isdataat:size; sid:1102015; rev:1;)
>> alert tcp any any -> any any (msg:"It's Alive!!! 3";
>> byte_extract:1,0,size; content:"123"; isdataat:!size,relative; sid:1102016;
>> rev:1;)
>> alert tcp any any -> any any (msg:"It's Alive!!! 4";
>> byte_extract:1,0,size; content:"123"; isdataat:size,relative; sid:1102017;
>> rev:1;)
>> alert tcp any any -> any any (msg:"It's Alive!!! 5"; content:"123";
>> isdataat:!8; sid:1102018; rev:1;)
>> alert tcp any any -> any any (msg:"It's Alive!!! 6"; content:"123";
>> isdataat:8; sid:1102019; rev:1;)
>> alert tcp any any -> any any (msg:"It's Alive!!! 7"; content:"123";
>> isdataat:!8,relative; sid:1102020; rev:1;)
>> alert tcp any any -> any any (msg:"It's Alive!!! 8"; content:"123";
>> isdataat:8,relative; sid:1102021; rev:1;)
>>
>> In Snort, the following hit:
>> 1102014
>> 1102016
>> 1102018
>> 1102020
>>
>> In Suricata:
>> 1102015
>> 1102017
>> 1102018
>> 1102020
>>
>> Is this an expected discrepancy? Seems like it has something to do with
>> the byte_extract.
>>
>>
>> The packet data is:
>> "\x0812334567"
>>
>> PCAP: https://packettotal.com/cgi-bin/view-analysis.cgi?id=d
>> afb74032ed3c43806d5eea0a1e7d6c0
>>
>> -Harley
>>
>> On Thu, Apr 20, 2017 at 12:48 PM, Jason Williams <
>> jwilliams at emergingthreats.net> wrote:
>>
>>> I ran your rules on my test rig and received the expected results:
>>>
>>> I believe it's the spaces in your "isdataat" portion causing the rules
>>> to fire unexpectedly in suricata. We (ET) never separate fields with spaces
>>> such as in the rules provided.
>>>
>>> #rules
>>>
>>> alert tcp any any -> any any (msg:"It's Alive!!!"; content:"Here";
>>> isdataat:!114; sid:1102010; rev:1;)
>>> alert tcp any any -> any any (msg:"It's Alive!!!"; content:"Here";
>>> isdataat:114; sid:1102011; rev:1;)
>>> alert tcp any any -> any any (msg:"It's Alive!!!"; content:"Here";
>>> isdataat:!113; sid:1102012; rev:1;)
>>> alert tcp any any -> any any (msg:"It's Alive!!!"; content:"Here";
>>> isdataat:113; sid:1102013; rev:1;)
>>>
>>> #results
>>>
>>> 02/23/2017-15:48:51.024811  [**] [1:1102010:1] It's Alive!!! [**]
>>> [Classification: (null)] [Priority: 3] {TCP} 10.211.55.3:49800 ->
>>> 10.211.55.2:80
>>> 02/23/2017-15:48:51.024811  [**] [1:1102013:1] It's Alive!!! [**]
>>> [Classification: (null)] [Priority: 3] {TCP} 10.211.55.3:49800 ->
>>> 10.211.55.2:80
>>>
>>> Thanks,
>>>
>>> Jason
>>>
>>> On Thu, Apr 20, 2017 at 10:25 AM, Harley H <bobb.harley at gmail.com>
>>> wrote:
>>>
>>>> Hello,
>>>>  I'm noticing a potential issue with a negated isdataat check. I'm
>>>> testing the following four rules against the pcap linked below:
>>>> alert tcp any any -> any any (msg: "It's Alive!!!"; content: "Here";
>>>> isdataat: !114; sid: 1102010; rev: 1;)
>>>> alert tcp any any -> any any (msg: "It's Alive!!!"; content: "Here";
>>>> isdataat: 114; sid: 1102011; rev: 1;)
>>>> alert tcp any any -> any any (msg: "It's Alive!!!"; content: "Here";
>>>> isdataat: !113; sid: 1102012; rev: 1;)
>>>> alert tcp any any -> any any (msg: "It's Alive!!!"; content: "Here";
>>>> isdataat: 113; sid: 1102013; rev: 1;)
>>>>
>>>> The packet simply contains the following 114 byte string:
>>>> "Here is a 114 byte packet to test how a negated isdataat checks works
>>>> in Suricata. Seems something may be amiss..."
>>>>
>>>> I'd expect rules 1102010 and 1102013 to alert, and that is what happens
>>>> in Snort. In Suricata, only 1102012 and 1102013 cause an alert. I'm using
>>>> Suricata 3.2.1.
>>>>
>>>> PCAP: https://packettotal.com/cgi-bin/view-analysis.cgi?id=4
>>>> 38c8f1a3041b5908a20bf3e7e8e3063
>>>>
>>>> Has anyone else noticed this or am I misunderstanding something?
>>>>
>>>> -Harley
>>>>
>>>> _______________________________________________
>>>> Suricata IDS Users mailing list: oisf-users at openinfosecfoundation.org
>>>> Site: http://suricata-ids.org | Support: http://suricata-ids.org/suppor
>>>> t/
>>>> List: https://lists.openinfosecfoundation.org/mailman/listinfo/ois
>>>> f-users
>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openinfosecfoundation.org/pipermail/oisf-users/attachments/20170421/4d7632af/attachment-0002.html>