Why not trigger rules in chronological order
Hello! Not sure how this is for others, but for me, it is a bit difficult to give an answer without more content (for instance, the full rules, or the eve.log, that carries more info on the traffic, or even a pcap)…
rules:
alert tcp any any → $HOME_NET any (msg:“LDAP link detected”;flow:established,from_server;content:“|30 0c 02 01 01 61 07 0a 01 00 04 00 04 00|”;nocase;classtype:exploit_kit;sid:50001;rev:1;metadata:created_at 2021_12_29,updated_at 2022_08_17;)
alert tcp any any → $HOME_NET any (msg:“Java suspicious class(LDAP) detected”;flow:established,from_server;content:“|ca fe ba be|”;nocase;classtype:exploit_kit;sid:50002;rev:1;metadata:created_at 2022_08_17,updated_at 2022_08_17;)
Uploading: image.png…
eve.json (46.1 KB)
jndi_ldap_104.pcapng (25.2 KB)
Hello, thanks for sharing those.
As the rules have a very similar structure, I don’t think that the order of alerts has to do with inspection steps (say, a rule being processed first due to its type).
So my other guess is that this may have to do with different threads processing different packets, and the alerts are shown based on how fast such processing is happening. I know this is not a definitive answer, but I did an experience with your info in my local environment, forcing Suricata to have only a single worker thread, and the alerts appeared in the same order as the inspected packets.
First of all, thank you very much. Because I want to use xbits to make an association rule, it is important to detect the rules in order. I would like to ask if this rule type refers to the protocol type? Because later I found that the second rule is switched to the writing method of HTTP protocol, and the rules can be triggered in order.
I’m not sure I can be of help here, as I am not very familiar with xbits, but…
- I think that indeed if you are able to write the rule using an applayer protocol (like HTTP), then the inspection will happen at a later stage, which could help with the order of the triggering/matches.
- It may be possible that the mere inclusion of a keyword like xbits (or hostbits) would also affect the inspection order (but I am not sure about that part).
I am basing these answers on this (yet unmerged) document that we are working on, to try to expose more to users how the engine handles rules and inspection: Document rules internals - v3 by jufajardini · Pull Request #7721 · OISF/suricata · GitHub
I hope this may shed some light on the question!
Not sure if it is the case, but if there are different flows and multithreading, you have no insurance as to the order in which the flows are processed
You can set autofp-scheduler to ippair if these 2 flows are between the same ip (or runmode=single)
1 Like
Indeed, there are different flows… I have overlooked this aspect entirely, thanks!
I tried both methods, not in order.
runmode=single
autofp-scheduler: ippair
I wonder if there is a problem with the pcap package, but so is the real-time traffic test.
I want to use xbits for rule Association. Rule 50001 detects the LDAP link, but in order to prevent false positives, use xbits to mark its destination address. Then rule 50002 detects malicious Java class transmission, and the destination address is marked by xbits, generating an alarm.
The rules I put in are not associated with xbits, because they are not triggered in sequence, so no alarm will be generated on the association. In fact, it can be written in the reverse direction. The destination address of rule 50002 is marked with xbits first, but it can only solve the problem this time.
I have met this problem many times. Sometimes only the pcap playback traffic is not in order, and the real-time traffic is in order; Sometimes rewrite the protocol type of the trigger rule, such as changing TCP to HTTP; Sometimes rewriting the protocol type of the trigger rule is not enough, so you can only write the rule in reverse. I don’t know if there is a problem with the writing of the rules or what is wrong?
Do you have the eve.json for runmode=single ?
What are the pcap_cnt values for the alerts ?
Maybe LDAP rule is only triggered at the end of its flow…
runmode=single
single.json (46.2 KB)
autofp-scheduler: ippair
ippair.json (46.2 KB)
Is it possible that it is related to my version of Suricata? My version is 6.0.1.
Indeed, the problem looks that signature “LDAP link detected” alerts at pcap_cnt 59 which is the end of the flow
That can be solved by adding startswith; in the rule to mention that the pattern is at the beginning of the stream
But then, the rule triggers two alerts at packet 34 and packet 59…
1 Like
So, one more thing that should be distinguished is
- alert tcp-stream : runs content detection on stream with a minimum chunk size cf
toserver-chunk-sizein suricata.yaml - alert tcp : runs content detection on both individual packets and stream
1 Like