Before deploymentSecurity

IDS / Suricata Readiness

15 items ·7 critical ·4 warn ·4 info

Suricata on OPNsense gives the firewall inline visibility into threats that a pure packet filter would let through. The cost is performance: an IPS on a busy WAN can drop packets if it cannot keep up, and a noisy ruleset can drown the operator in alerts. Readiness means choosing IDS vs IPS deliberately, keeping rules current, shipping EVE logs to a SIEM, and having a triage path.

When to use

Use this checklist before Suricata is first enabled on an OPNsense firewall, before flipping an interface from IDS to IPS, and after any rule set change or version upgrade. Re-run it quarterly as a regression check.

How to use

Walk the list while reviewing Suricata settings, the rule sets, and the SIEM ingestion. Measure CPU impact during a baseline and a peak window, decide IDS vs IPS per interface, and capture the decision in the change record.

Critical7 items

Suricata is enabled on every interface that should be inspected (typically WAN and DMZ, optionally internal zones).
```
Services > Intrusion Detection > Administration.
```
Mode is selected per interface: IDS (alert only) or IPS (alert + drop) — IPS only where false-positive risk is bounded.
Rule sets are current (Emerging Threats, ET Open, Snort VRT, or proprietary) and a rule-update schedule is in place.
```
Services > Intrusion Detection > Download Rules.
```
EVE JSON log is enabled and shipped to a SIEM or log lake for correlation.
```
Services > Intrusion Detection > Advanced; "Eve JSON Log" on.
```
Performance impact has been measured (CPU, packet drops, latency) before turning IPS on a busy interface.
A runbook exists for triaging a Suricata alert, including the path from alert to SIEM to ticket.
Promiscuous mode and the underlying NIC support is verified — IPS will not work through switches that drop SPAN traffic.

Warning4 items

Custom rules (where used) are documented, version controlled, and added via a tracked change.
```
Services > Intrusion Detection > Rules; "custom.rules" tab.
```
Suppression / whitelist lists exist for known false positives and are reviewed when alerts spike.
Rule categories are enabled selectively; broad categories (e.g. malware-cnc) are on, while low-signal categories are off by default.
HA pairs run Suricata on each node with matching rule sets; sync is configured via XMLRPC.

Info4 items

Hyperscan or Aho-Corasick pattern matchers are enabled if the CPU supports them.
Suricata drop counters and rule-match counters are monitored for sustained increase or sustained zero (silent failure).
```
Services > Intrusion Detection > Administration; Alerts tab.
```
Rule reloads are scheduled off-peak to avoid a transient rule-eval gap during compile.
Disk usage from Suricata logs (EVE) is accounted for in retention policy.