[Oisf-users] having trouble byte_extract and isdataat

[Victor Julien]

On 21-10-17 00:16, Jason Williams wrote:
> Yea, I see this work in snort 2.9.6 and not in suri 4.0.0. I would open
> a ticket on this.

I've opened https://redmine.openinfosecfoundation.org/issues/2250

It's a bit embarrassing. Rule parsing for mixing byte_extract/isdataat
is implemented, but the matching side is not.

I will address this in the next version.

Regards,
Victor

> 
> Thanks!
> 
> On Fri, Oct 20, 2017 at 2:17 PM, Harley H <bobb.harley at gmail.com
> <mailto:bobb.harley at gmail.com>> wrote:
> 
>     Would it be better if I filed a bug report on this?
> 
>     On Wed, Oct 18, 2017 at 2:18 PM, Harley H <bobb.harley at gmail.com
>     <mailto:bobb.harley at gmail.com>> wrote:
> 
>         Hello,
>           I'm trying to write a rule which extracts a size field (single
>         byte) using byte_extract then checks to make sure there is no
>         data at that size by using a negated isdataat check. 
> 
>         I contrived a pcap where byte offset 12 is the packet size and
>         offset 13 is the packet size + 1. So, I'd expect the following
>         rules to cause alerts:
> 
>         alert tcp any any -> any any (msg:"isdataat data_size 103 -
>         should alert";  byte_extract:1,12,data_size;
>         isdataat:!data_size; sid:123129; rev:1;) 
>         alert tcp any any -> any any (msg:"isdataat data_size 104 -
>         should alert";  byte_extract:1,13,data_size;
>         isdataat:!data_size; sid:123130; rev:1;) 
> 
>         However, they do not cause alerts. An alert is caused by
>         removing the negation on isdataat. 
> 
> 
>         Attached is the sample pcap, the fast.log output, and the rules
>         file. The rules file contains some additional rules than where
>         described in this email to help illustrate the problem. 
> 
>         I also added some SCLogDebug() output in detect-byte-extract.c
>         and detect-engine-content-inspection.c to help give a better
>         idea of the what the extracted and isdataat value checks are. It
>         looks like the correct value is being extracted but when checked
>         with isdataat it is zero. Although, I'm not entirely confident
>         I've done that correctly but am happy to share and discuss if
>         there is interest. 
> 
>         Thanks,
>           Harley
> 
> 
> 
>     _______________________________________________
>     Suricata IDS Users mailing list:
>     oisf-users at openinfosecfoundation.org
>     <mailto:oisf-users at openinfosecfoundation.org>
>     Site: http://suricata-ids.org | Support:
>     http://suricata-ids.org/support/ <http://suricata-ids.org/support/>
>     List:
>     https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users
>     <https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users>
> 
>     Conference: https://suricon.net
>     Trainings: https://suricata-ids.org/training/
>     <https://suricata-ids.org/training/>
> 
> 
> 
> 
> _______________________________________________
> 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
> 
> Conference: https://suricon.net
> Trainings: https://suricata-ids.org/training/
> 


-- 
---------------------------------------------
Victor Julien
http://www.inliniac.net/
PGP: http://www.inliniac.net/victorjulien.asc
---------------------------------------------