Bug #2338
closed
multiple drop rules triggered for same packet
Added by Dan Collins about 7 years ago.
Updated over 5 years ago.
Description
I may be wrong but I have read that once a drop rule was in effect, the packet doesn’t get processed any further down the chain.
I am using Suricata 4.0.1 with OPNsense using IPS/inline mode.
I am seeing multiple ET rules drop from the same packet in the logs quite frequently. My concern is some rules are alerts and some are drops and I have no idea which rule would be in effect. I assume the last rule, but I have no control over rule order.
Is Suricata suppose to work this way? Is there an option change I can make in suricata.yaml to stop this?
I have attached an example of two drop rules that matched the same packet.
Files
According to the suricata manual http://suricata.readthedocs.io/en/latest/configuration/suricata-yaml.html
Drop-
This only concerns the IPS/inline mode. If the program finds a signature that matches, containing drop, it stops immediately. The packet will not be sent any further. Drawback: The receiver does not receive a message of what is going on, resulting in a time-out (certainly with TCP). Suricata generates an alert for this packet.
This is not happening.
- Assignee set to Anonymous
- Target version set to Support
Did you look into how the rules were added? Most the rules are alert by default and need to be converted to drop instead. If I look into your screenshots it looks like the rules are still just alert rules.
What Action is defined under Services -> Intrusion Detection -> Rules in your OPNSense?
All of my testing was done with IPS Inline mode.
Here is an example of 2 drops from the same packet
- Priority changed from High to Normal
- Assignee set to Community Ticket
can you still reproduce that?
- Status changed from New to Closed
Also available in: Atom
PDF
