Please include the following information with your help request:
Suricata version - 7.0.10
Operating system and/or Linux distribution - Ubuntu 22.04.5 LTS
We’re observing an issue in Suricata where the
rate_filterconfiguration does not suppress repeated alerts for specific rules, even though the setup appears correct and aligns with documentation.
This affects both:
STUN-based rules:
ET INFO STUN Binding Request (SID: 2016149)
ET INFO STUN Binding Response (SID: 2016150)
Stream-related Suricata rules:
- SURICATA STREAM 3way handshake wrong seq wrong ack (SID: 2210010)
Confirmedthreshold-file: /etc/suricata/threshold.configis included insuricata.yaml- threshold.config entries are as follows:
STUN Binding Request
rate_filter gen_id 1, sig_id 2016149, track by_src, count 1, seconds 900, new_action alert, timeout 900
STUN Binding Response
rate_filter gen_id 1, sig_id 2016150, track by_dst, count 1, seconds 900, new_action alert, timeout 900
TCP 3-way handshake wrong seq wrong ack
rate_filter gen_id 1, sig_id 2210010, track by_rule, count 1, seconds 900, new_action alert, timeout 900
Observed Behavior: Even with the above configuration in place, Suricata continues to generate multiple identical alerts for the same
(src_ip, dst_ip)pair.We’ve verified:
Rule SIDs match
Rules exist and are loaded from
/var/lib/suricata/rules/suricata.rules
threshold.configis correctly included in the YAMLSuricata was restarted after changes
Despite this, the suppression doesn’t seem to take effect. The alerts continue to flood.
Is there a known issue where
rate_filterdoes not apply to certain event types like STUN or stream alerts?
Should a differenttracktype be used for UDP-based events?
Would usingthresholdinstead ofrate_filterhelp in these specific cases?