Project

General

Profile

Actions

Bug #7259

open

Flaky behaviour of rules using Threshold keyword when running with --pcap-file-continuous

Added by Ilya Knyazhansky about 1 month ago. Updated about 1 month ago.

Status:
New
Priority:
Normal
Assignee:
Target version:
Affected Versions:
Effort:
Difficulty:
Label:

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 -

Actions #1

Updated by Ilya Knyazhansky about 1 month ago

  • File deleted (ssh_10.126.31.254.pcap)
Actions

Also available in: Atom PDF