Bug #7259
openFlaky behaviour of rules using Threshold keyword when running with --pcap-file-continuous
Description
When we are executing Suricata: exec suricata -l "$LOGS_DIR" -r "$PCAPS_DIR" --pcap-file-continuous --pcap-file-delete --init-errors-fatal
In this way, we are running Suricata in “offline” mode and feeding it with PCAP files. We noticed a flaky behaviour of rules using Threshold keyword.
Rule example: alert tcp-pkt any any > $HOME_NET 22 (msg:"Detected SSH Brute Force"; content:"SSH"; threshold: type threshold, count 15, seconds 30, track by_both; classtype:attempted-admin; sid:920000; rev:1;)
This rule should alert only if triggered 15 times in a window frame of 30 seconds. Unfortunately, in the attached PCAP, we alert brute force on 10.126.31.254 even when this IP is not reaching the threshold. It's so flaky, that it can alert even when we change the seconds in the threshold to 1.
This behaviour does not reoccur when using tcpreplay to stream a PCAP to a virtual interface.
In addition, I verified that the problem is not in the count section by raising the value to 26, which is bigger by 1 from the number of matching packets in ssh_10.126.31.254 PCAP
I found that in the past Suricata had a bug in this realm, but it has already been fixed -
Files
Updated by Philippe Antoine about 2 months ago
- Status changed from New to Feedback
Could you supply the pcap for test ?
Updated by Ilya Knyazhansky 14 days ago
- File ssh_test_pcap.pcap ssh_test_pcap.pcap added
Philippe Antoine wrote in #note-2:
Could you supply the pcap for test ?
I updated the rule to "any", cause I obfuscated the IP and MAC
@alert tcp-pkt any any -> any 22 (msg:"Detected SSH Brute Force"; content:"SSH"; threshold: type threshold, count 15, seconds 30, track by_both; classtype:attempted-admin; sid:920000; rev:1;)
Thank you!