[Oisf-users] Issue with negated isdataat?
Jason Williams
jwilliams at emergingthreats.net
Thu Apr 20 16:48:00 UTC 2017
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=
> 438c8f1a3041b5908a20bf3e7e8e3063
>
> 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/916ba3dc/attachment-0002.html>
More information about the Oisf-users
mailing list