Bug #8953
opendetect: signature ordering prefers the previous criteria
Description
Currently Suricata internally sorts the rules by these criteria in this specific order:
- Action
- Flowbits
- Flowint
- Flowvar
- Pktvar
- Hostbits
- IPPairbits
- Priority
For two rules such as:
alert tcp any any -> any any (flowbits:set,x; sid:1;) pass tcp any any -> any any (flowbits:isset,x; flowbits:set,y; sid:2;)
even though the flowbits comparator would keep sid: 1 before sid:2, the action comparator would force sid:2 before sid: 1 thus making the latter the winner of the final ordering.
Note : These code paths are getting discovered with the flowbits ordering work. I'm sifting through them as not all issues that we see there are introduced by or are limitation of the flowbits ordering work in itself.
Action?
I don't know if we can or should change how Suricata behaves in this state. An ideal solution would be a state machine that makes sure that every state of each rule in the ruleset is satisfied but we've seen it's already turning out to be complicated while only taking flowbits into the picture. So, maybe a note in the docs about the criteria of internal ordering? If needed, allow it to be configurable but idk if anybody would need it that way.
SB Updated by Shivani Bhardwaj about 24 hours ago
- Status changed from New to Triaged