Suricata tuning and false positives — disabling rules, suppressing alerts, and the operational discipline

A Suricata deployment that has not been tuned produces alerts. A tuned deployment produces the alerts the operator should respond to. The difference is discipline: the operator triages every alert, classifies it as true positive or false positive, and acts — either disabling the rule, suppressing the alert on the specific source, or accepting the alert and writing a runbook for the response. A deployment that runs without tuning for months accumulates noise that buries real threats. This lesson covers the triaging process, the three tuning mechanisms (disable, suppress, threshold), and the operational discipline of periodic rule review.

The triaging process

The first tuning step is triaging the alerts. The EVE log is the source of truth. Each alert includes:

• timestamp — when the alert fired
• src_ip, src_port, dest_ip, dest_port — who was involved
• signature_id, signature, category — what rule fired
• flow_id, pcap_filename — the captured packet (if pcap logging is enabled)

The triaging process for each unique signature_id:

1. What does the signature mean? Read the ET documentation for the signature_id (search the ET ruleset documentation or visit the Emerging Threats site). Understand what the signature is designed to detect.
2. What was the actual traffic? If pcap logging is enabled, open the pcap and look at the packet. If pcap logging is not enabled, the EVE log includes enough metadata to reason.
3. Is this a true positive? A true positive is a real attack or compromise attempt that the operator should respond to.
4. Is this a false positive? A false positive is legitimate traffic that matches the signature. The signature is too broad for the operator’s network.
5. Is this unknown? An alert the operator cannot classify. May need research or consultation.

$ jq -r 'select(.event_type=="alert") | .alert.signature_id + " " + .alert.signature' /var/log/suricata/eve.json | sort | uniq -c | sort -rn | head -10

 4827 2014828 ET POLICY Outgoing Basic Auth Base64 HTTP Password
3124 2024001 ET MALWARE Cobalt Strike beacon
892 2002027 ET SCAN Behavioral Unusual Port 137 Traffic
234 2024123 ET EXPLOIT Possible CVE-2024-1234 Attempt
187 2014819 ET POLICY GNU/Linux OS User-Agent Detected
156 2024124 ET EXPLOIT Possible CVE-2024-1235 Attempt
 98 2021567 ET TROJAN Possible Backdoor Connection

Tuning mechanism 1 — disabling rules

The bluntest tuning mechanism: disable the rule entirely. The rule no longer fires; the alert disappears from the log.

When to disable:

• The rule produces false positives the operator cannot accept (a signature that fires on every legitimate customer login).
• The signature is irrelevant to the operator’s network (a Windows-specific malware signature on a Linux-only network).
• The signature is a duplicate of another rule that fires first.

When not to disable:

• The rule produces mostly true positives with a few false positives (use a suppression instead).
• The operator has not triaged the alerts and is disabling on a hunch.

The OPNsense GUI per-rule toggle is at Services → Intrusion Detection → Rules → click on the rule → set “enabled” to off. The plugin writes the change to a modified rules file and reloads Suricata.

Tuning mechanism 2 — suppressions

A suppression silences a specific rule on a specific host or network without disabling the rule globally. Suppressions are useful when:

• A rule fires on a specific server (a monitoring system that legitimately uses a suspicious user-agent) but is correct on the rest of the network.
• A rule fires on a specific destination (a test environment that generates traffic matching the signature) but is correct elsewhere.

The Suricata suppression syntax:

suppress gen_id 1, sig_id 2014828, track by_src, ip 192.0.2.50

This silences signature 2014828 (Basic Auth password) for source IP 192.0.2.50 — the monitoring server that legitimately uses basic auth. The rule still fires for every other source.

OPNsense exposes suppressions through the GUI at Services → Intrusion Detection → Rules → Suppress. The operator adds a suppression per (signature, host) pair.

Tuning mechanism 3 — thresholding

A threshold rate-limits the alerts from a rule. The rule still fires, but the engine limits how often the alert is logged:

• threshold — fire the alert once per N events from the same source.
• limit — fire the alert no more than N times per period from the same source.
• both — fire the alert at most N times per period from the same source.

The thresholding syntax:

alert http any any -> $HOME_NET any (msg:"ET MALWARE Cobalt Strike beacon"; ... sid:2024001; rev:2; threshold: type both, track by_src, count 1, seconds 60;)

This signature fires at most once per 60 seconds per source. A host that triggers the signature every second will produce one alert per minute, not thousands per hour.

Thresholding is useful for:

• Noisy rules that are mostly true positives but fire too often to triage.
• Rules that fire as part of a scan (the same source triggers many rules in a burst).

The OPNsense GUI exposes per-rule thresholding in the rule detail view. The operator sets the threshold type and values per rule.

The tuning workflow

The recommended workflow:

1. Collect baseline alerts. Run in IDS mode for one to two weeks with the intended rule set.
2. Identify the top alert producers. The jq command above shows the signatures with the highest counts.
3. Triage each top producer. Classify as true positive or false positive.
4. For false positives:
   • If the rule is broadly wrong for the network: disable.
   • If the rule is correct but a specific host triggers it: suppress.
   • If the rule fires too often even for true positives: threshold.
5. For true positives:
   • Document the alert in the runbook. The operator should know what to do when the alert fires.
   • If the alert volume is overwhelming: threshold to rate-limit; do not disable.
6. Re-tune. After a week of operation with the new tuning, run the top-producers analysis again. New top producers may have emerged.

$ jq -r 'select(.event_type=="alert") | .alert.signature_id + " " + .src_ip' /var/log/suricata/eve.json | sort | uniq -c | sort -rn | awk '$1 > 100 {print}' | head -10

 3124 2024001 198.51.100.45
892 2002027 203.0.113.10
623 2014828 192.0.2.50
412 2014828 192.0.2.51
234 2024123 203.0.113.99
187 2014819 198.51.100.12
156 2024124 203.0.113.99

The discipline of periodic rule review

The rule set changes. The ET Open ruleset updates daily; the network changes (new hosts, new services, new applications). A deployment tuned once becomes untuned within months.

The discipline: schedule a quarterly rule review. The review covers:

• New top producers — signatures that have emerged since the last review.
• Suppressions that are no longer needed — hosts that have been decommissioned.
• Disabled rules that can be re-enabled — signatures that may have been disabled for hosts that no longer exist.
• New categories — Emerging Threats categories that did not exist at the last review.
• Thresholding changes — rules whose threshold values are too tight or too loose.

A quarterly review is one hour of work for a typical deployment. The investment is small; the benefit (a tuned deployment that produces actionable alerts) is significant.

Summary

• Triaging alerts is the first step: classify as true positive, false positive, or unknown.
• Three tuning mechanisms: disable (rule off globally), suppress (rule off for specific hosts), threshold (rate-limit alerts).
• Identify top alert producers with the jq command on the EVE log.
• Document every tuning change; disable one rule at a time; revisit quarterly.
• A tuned deployment produces alerts the operator should respond to. An untuned deployment produces noise.