Skip to main content
RunBook Academy

← All break/fix scenarios in OPNsense

advancedSecurity~30 min

Break/Fix: IDS false positive blocks legitimate traffic

Reported symptoms

  • ●Suricata alert fires repeatedly on traffic to a known-good application
  • ●Application users report failed connections or degraded performance
  • ●The alert signature is a generic "exploit" or "trojan" rule

Evidence

  • · Suricata alert log shows the same signature firing every minute
  • · Packet capture of the alert shows legitimate application traffic (e.g. HTTPS, REST API)
  • · The destination IP is a known-good internal service
  • · No other IDS/IPS system (SIEM, second Suricata) reports the same signature
Diagnosis and resolutionclick to reveal

Root cause

The Suricata rule is matching a legitimate traffic pattern. The rule signature is over-broad (e.g., matches a string that appears in normal application payloads), or the rule was contributed to ET/Open for a different threat and matches by accident in this environment.

Remediation

Disable the specific Suricata SID on the destination IP (per-host suppression) or on the destination port (per-port suppression). If the rule is consistently a false positive across the environment, disable it entirely. Document the suppression with the rationale (e.g., "matches legitimate API JSON format") and the date.

Verification

Suricata alerts stop firing for the suppressed signature. The application recovers normal performance. Other IDS systems continue to function normally.

Prevention

Deploy Suricata in monitor (alert-only) mode initially. Triage alerts for at least one week before enabling IPS mode. Build a per-host and per-port suppression list of known-good traffic patterns. Review the suppression list quarterly.

Scenario

You operate an OPNsense firewall with Suricata enabled in IPS mode (inline blocking) on the WAN interface. A production REST API behind the firewall starts returning 500 errors. Users report intermittent connection failures.

Available evidence:

  • Suricata alert log: the same SID fires every 30-60 seconds.
  • Packet capture from the alert: HTTPS traffic between a client IP and the API server.
  • The API server logs show no application errors.
  • The IDS rule signature is ET POLICY-S Outgoing Basic Auth Base64 HTTP Password (a generic rule for any HTTP traffic containing a Base64-encoded string).

The API uses JWT tokens, which are Base64-encoded JSON payloads. Every API request triggers the rule.

Break/Fixadvanced30 minsecurity

IDS false positive blocks legitimate traffic

Symptoms

  • Suricata alert fires repeatedly on legitimate application traffic
  • Application users see failed connections or degraded performance
  • The alert signature is a generic "exploit" or "trojan" rule

Available evidence

  • Suricata alert log: same SID firing repeatedly
  • Packet capture of alert: legitimate application traffic
  • Destination IP is a known-good internal service
  • No other IDS/IPS reports the same signature
Show diagnosis & remediation

Root cause

The Suricata rule is matching legitimate application traffic. The signature is over-broad (matches Base64 strings, which JWT tokens use) or the rule was contributed for a different threat and matches by accident.

Safe remediation

Disable the SID via Suricata suppression (per-host or per-port). Document the suppression with the rationale and date.

Verification

Suricata alerts stop firing for the suppressed signature. Application performance recovers. Other IDS systems continue functioning.

Prevention

Deploy Suricata in monitor mode initially. Triage alerts for one week before enabling IPS mode. Maintain a suppression list of known-good patterns. Review the suppression list quarterly.