Bug #1247
openUsing suppress in threshold.config does not prevent dropping
Description
I have suricata 2.0.2 running in inline/ips mode, with the following rule active:
drop ip any any -> any any (msg:"GPL ATTACK_RESPONSE id check returned root"; content:"uid=0|28|root|29|"; fast_pattern:only; classtype:bad-unknown; sid:2100498; rev:8;)
So i have create a index.html for testing:
uid=0(root) gid=0(root) groups=0(root)
With small python server
python -m SimpleHTTPServer
I can trigger the rule by:
lynx http://10.0.20.89:8000/
The rule triggers, logs into fast.log etc. and also drops the attempt.
I put "suppress gen_id 1, sig_id 2100498" into the threshold.config and did restart suricata.
What i would have expected is that i see no logs and it won't be dropped.
The logs don't appear (i have fast.log, alert-debug.log, drop.log and http.log active) but it's dropped.
The same test in snort with the same suppress rule does not log and not drop.
I guess this might be a bug introduced in some newer version, since Victor Julien got the same issue working in 2012:
http://blog.inliniac.net/2012/03/07/f-secure-av-updates-and-suricata-ips/
And i would suggest the option to also use threshold.config within the dynamic rule reload, so it's not necessary to restart the whole suricata if you just added one line into the threshold.config.
Updated by Andreas Herz over 9 years ago
Andreas Herz wrote:
I guess this might be a bug introduced in some newer version, since Victor Julien got the same issue working in 2012:
http://blog.inliniac.net/2012/03/07/f-secure-av-updates-and-suricata-ips/
It got change some months after the blogpost :)
https://github.com/inliniac/suricata/commit/80d62b59ec1b517090faf0cd52531232300aef6b
Updated by Andreas Herz over 9 years ago
I would try to improve the code to go back to the former behaviour with "suppress", but would like your opinion if it's worth it.
I would say that someone using the "suppress" option also wants to prevent the "drop" in inline/IPS mode, since a simple alert line in the logs is not the real problem, but dropping valid traffic is. So deactivating a rule by "suppress" would be a nice way to deal with it, since you can also specify it by track by_src/dst.
Another option would be to introduce another value like "nodrop" and to introduce another return value. For now we have 0,1,2 with 2 meaning silent match that does not alert but still drop. I would prefer changing 2 to no alert and no drop, although rules without track by_src/dst are not handled by this part.
There i would also suggest to change NOALERT to something else.
The workaround for deactivating for now is to comment those rule with # in the rules file, but i would prefert keeping the .rules files like they came from ET for example and use "suppress" (or alternatives) to achieve this.
Updated by Andreas Herz over 9 years ago
Although there is no real demand i would still love to include this in suricata. Can you provide me with some information where it should be included in the source code or how you want to have it done :p?
Updated by Andreas Herz over 8 years ago
- Assignee set to Andreas Herz
- Target version set to TBD
Updated by Andreas Herz almost 8 years ago
I got some requests for that (IRC and Training) and we also have other tickets for that #1002.
So I would like your opinion about that.
Updated by Andreas Herz almost 8 years ago
Two solutions so far:
1. make suppress also work on drop as well and not just hide the alert
2. add another keyword that hides the alert and will also prevent the drop
You can also exclude the rule file or change the rule itself but IMHO it's a valid use case to keep the rule as it is and just exclude a dedicated IP as it would work for alerts.
Updated by Andreas Herz over 5 years ago
- Assignee changed from Andreas Herz to Anonymous