Suricata: a stats counter is not the finding list

The number does not name a rule

Suricata writes stats records with counters for the run: packets decoded, and a detect counter of alerts. That counter is a tally. It has no signature id, no message, and no source address. You cannot file “what fired” from it.

A tally of 12 means the engine counted 12 alert records in that run, if you are reading the alert counter and you say so. It does not mean 12 distinct signatures, and it does not list them.

The list is the alert rows

The signatures are the rows whose event_type is alert. Each one has an id you can quote. If you need “which rules,” count those rows and name the ids. If the counter and the number of alert rows you can open do not match, write both numbers and do not pick the larger one.

A stats row at the end of a lab replay describes that replay. It is not a standing total for the sensor across other files. Name the capture or the time window with the counter.

What to file

File event_type stats, the counter’s name and value, and which pcap or time window the run used. If you also list signatures, file those from alert rows, with ids. Do not paste the counter into a sentence that names a rule the stats row never mentioned.

Worked case: twelve, with no ids

A lab replay’s stats row shows the detect alert counter at 12. A draft says twelve rules fired and names two the author remembers from another capture. The file’s alert rows, when counted, are 12 lines and only four signature ids, one of them repeated.

The note quotes the counter as 12 for this replay, then lists the four ids from the alert rows and the repeat. It does not use the remembered names. The counter stays a tally. The ids come from the alert rows.

event_type: stats
run: lab replay of one capture
detect alert counter: 12
alert rows opened: 12
distinct signature ids on those rows: 4
write: tally 12, four ids, not twelve rules and not names from memory