[Oisf-users] Issue with negated isdataat?

[Harley H]

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=dafb74032ed3c43806d5eea0a1e7d6c0

-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/support/
>> List: https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openinfosecfoundation.org/pipermail/oisf-users/attachments/20170420/621000bb/attachment-0002.html>