Skip to main content
RunBook Academy

← All break/fix scenarios in OPNsense

intermediateSecurity~25 min

Break/Fix: Suricata IDS Blocks Legitimate Traffic

Reported symptoms

  • ●A specific application or service stops working after Suricata IPS is enabled
  • ●Alerts.log shows the same signature firing repeatedly against an internal host
  • ●Disabling Suricata immediately restores the affected traffic

Evidence

  • · Suricata alerts: ET POLICY or ET TROJAN signature SID 2024897 firing on a legitimate endpoint
  • · Affected connection is to/from an internal service the rule was never designed to police
  • · Ruleset source includes emergingthreats or ETPRO with overly broad keywords
Diagnosis and resolutionclick to reveal

Root cause

A signature in the ruleset matches a benign pattern — for example, ET TROJAN signatures that fire on default user-agent strings, or ET POLICY rules that flag normal traffic on non-standard ports.

Remediation

1. Identify the SID from the alert and look it up (e.g. on docs.emergingthreats.net or via the rule's metadata reference). 2. Decide: suppress with a SID management rule for that signature on that network, or tune the rule's threshold. 3. Apply the suppression in Services → Intrusion Detection → Administration → SID Management. 4. Reload Suricata and verify.

Verification

Alerts for that SID stop firing on the suppressed scope; the previously blocked application works with Suricata enabled; legitimate traffic is not dropped.

Prevention

Treat IDS ruleset changes as production changes: enable in alert-only mode first, monitor for false positives over a window, then promote to IPS for vetted signatures only. Use SID management to document every suppression, and review suppressions quarterly.

Scenario

You are operating an OPNsense edge with Suricata in IPS mode. The following symptoms appear:

  • A specific application or service stops working after Suricata IPS is enabled
  • alerts.log shows the same signature firing repeatedly against an internal host
  • Disabling Suricata immediately restores the affected traffic

Available evidence:

  • Suricata alerts: ET POLICY or ET TROJAN signature SID 2024897 firing on a legitimate endpoint
  • Affected connection is to/from an internal service the rule was never designed to police
  • Ruleset source includes emergingthreats or ETPRO with overly broad keywords

Your task

Determine the cause, recover, document, and validate.

Investigation

The investigation follows the discipline taught in Part XXXI:

  1. Form hypothesis, find evidence, test, validate.
  2. Use the available evidence above to bound the search.
  3. Reach one of the likely root causes.

Recovery procedure

(Do not reveal until you have reasoned through the problem.)

  1. Identify the failing component.
  2. Apply the remediation pathway.
  3. Validate with the verification step.
  4. Document the incident.

Remediation

  1. Identify the SID from the alert and look it up (e.g. on docs.emergingthreats.net or via the rule’s metadata reference). 2. Decide: suppress with a SID management rule for that signature on that network, or tune the rule’s threshold. 3. Apply the suppression in Services → Intrusion Detection → Administration → SID Management. 4. Reload Suricata and verify.

Verification

Alerts for that SID stop firing on the suppressed scope; the previously blocked application works with Suricata enabled; legitimate traffic is not dropped.

Rollback

Re-enable the SID in alert-only mode; revisit the suppression scope.

Prevention

Treat IDS ruleset changes as production changes: enable in alert-only mode first, monitor for false positives over a window, then promote to IPS for vetted signatures only. Use SID management to document every suppression, and review suppressions quarterly.