Alerts are not in order

Help
, ,
1

I use docker image jasonish/suricata:7.0.6-profiling to test and develop some signatures

I run it something like this

docker run --rm -it \
    jasonish/suricata:7.0.6-profiling \
    -c /nsm/suricata.yaml \
    -s /nsm/dev.rules \
    -r /nsm/data.pcap \
    --runmode autofp \
    -k none \
    -vvvv

Recently i try to create two signature and try to connect them with flowbits

alert tcp any any -> any 389 (msg:"Cleartext password in LDAP"; flow: established, to_server; content:"|60|"; content:"|02 01 03 04|"; distance:1; within:4; byte_jump:1,0,relative; content:"|80|"; distance:0; within:1; content:!"|00|"; distance:0; within:1; flowbits: set, ldap-simple; sid:1; rev:1;)

alert tcp any 389 -> any any (msg:"Cleartext LDAP auth"; flow: established, to_client; dsize:<200; content:"|61 84|"; content:"|0a 01 00|"; distance:4; within:3; flowbits: isset, ldap-simple; sid:2; rev:1;)

ldap-simple-auth.pcap (1.1 KB)

When I try this signatures against recorded pcap - only sid:1 is alerted -
with-flowbits.zip (8.2 KB)

But if i remove flowbits from second signatrure i get 2 alerts -
without-flowbits.zip (8.7 KB)

From alert-debug i can observe that SIG-1 is alerted on packet 11 that is last “to_server” packet in stream (expected is packet 4 - bindRequest) and SIG-2 is alerted on packet 5 (bindResponce) this is work as expected.

I think this can be the problem, but i cant figure out is this my missconfig or code issue

I found simillar issue on forum already, but without solution

2

I manage to make this work by adding no_stream to first signature, i guess its prevent engine from trying to analyze past packet that i need, but I am still not sure is this a bug or a feature

alert tcp any any -> any 389 (msg:"Cleartext password in LDAP"; flow: established, to_server, no_stream; content:"|60|"; content:"|02 01 03 04|"; distance:1; within:4; byte_jump:1,0,relative; content:"|80|"; distance:0; within:1; content:!"|00|"; distance:0; within:1; flowbits: set, ldap-simple; sid:1; rev:1;)
3

Suricata does not guarantee that rules will be evaluated in order as they are in the rule file. If you want to analyze on the packets directly, perhaps you can replace alert tcp with alert tcp-pkt

4

Yeah I understand about rule evaluation order, but i dont understand why sig1 match at the end of the stream (according to alert-debug), and sig 2 match at correct packet resulting in flowbits dont working without flow: no_stream

5

One more thing to note which may or may not be related is that the match happens in the IDS mode on the ACK packet w/o any special options.