Bug #4108
openRule reloading: Rules that change the action from alert to drop, or drop to alert don't have their action updated.
Description
Testing 4.1.9, 5.0.4 and 6.0.0 and all seem to be affected. To reproduce use a simple rule like:
drop icmp any any -> any any (msg:"DROP ICMP"; sid:100000000; rev:1;)
Start Suricata with a rule file like the above. Test that ICMP is dropped. Update rule to alert, send Suricata a reload-rules signal. Suricata will continue to drop ICMP. Rule reload completion was observed in Suricata output.
Same thing happens when rule starts as alert and is changed to drop.
Updated by John Meyer about 4 years ago
To add to this:
This seems to only apply to traffic that has already matched the rule. As I test, I find that if I ping something from 10.10.10.33 to make the rule match, it still matches after a rule reload. However if I begin pinging from 10.10.10.44 after the reload, the reload has in fact worked as expected and pings are allowed or denied as per the rule.
Updated by Philippe Antoine 7 months ago
- Status changed from New to Feedback
This seems to work as expected :
The first rule
drop icmp any any -> any any (msg:"DROP ICMP"; sid:100000000; rev:1;)
trigegrs on the flow for 10.10.10.33
It makes this flow as to drop
Then when you reload rules, you still have this flow as flagged for drop... &FLOW_ACTION_DROP@ in the code I think
So, next packet with this flow will be dropped
A noter packet in another flow that triggers the rule <ill produce an alert and no drop
Maybe you would like another feature to untag all the flows that are set to drop...