Runbook: Investigate an IDS Block
1 · Prerequisites
Confirm every item is in place before any state change.
- Suricata installed and running on OPNsense
- Access to the Suricata logs under Services > Intrusion Detection > Log File
- Knowledge of the legitimate traffic flows that traverse the firewall
2 · Pre-checks
Read-only diagnostic commands. If any of these don't match expected output, stop and investigate further.
- · Capture the alert SID, the source address, the destination address, and the timestamp from the alert
- · Check whether the alert is associated with a known application or protocol
- · Confirm the alert is not a duplicate of a previous alert that was already triaged
- · Cross-reference the alert with the change record to see if a recent rule change enabled the rule
3 · Procedure
Execute each step in order. Verify the expected output of a step before moving to the next.
- 1Open Services > Intrusion Detection > Log File and search for the alert SID
- 2Capture the full packet payload if the alert includes a pcap reference
- 3Identify the source and destination addresses and the timestamp of the alert
- 4Cross-reference the source and destination addresses with the known traffic flows
- 5If the alert is a true positive, escalate to the security team and capture the surrounding traffic for investigation
- 6If the alert is a false positive, suppress the rule under Services > Intrusion Detection > Administration > Rules and select the suppress option
- 7If the alert is a tuning opportunity, identify the rule and decide whether to disable it, suppress it for a specific source, or change the action from drop to alert
- 8Document the decision in the Suricata alert log so the next operator can see the resolution
- 9Repeat the investigation for any related alerts that fire in the same window
4 · Verification
Confirm the procedure actually fixed the problem.
- ✓The alert is classified as true positive, false positive, or tuning opportunity
- ✓The decision is documented in the Suricata alert log
- ✓The alert is suppressed or the rule is disabled if the decision is false positive
- ✓No new alerts of the same SID fire during the observation window
5 · Rollback
If verification fails, undo the procedure in reverse order.
- ↶If a suppression was added incorrectly, remove the suppression and re-enable the rule
- ↶If a rule was disabled, re-enable the rule and consider a more targeted suppression
- ↶If the alert is a true positive, do not roll back the security response
6 · Escalation
When the runbook isn't enough, contact:
- · Engage the security team if the alert is a true positive and the source is unknown
- · Engage the application team if the alert is associated with a legitimate application
- · Engage the platform team if the IDS performance is impacted by the volume of alerts
Purpose
Investigate a Suricata IDS alert on OPNsense, classify it as a true positive, false positive, or tuning opportunity, and take the appropriate action without disabling useful rules globally.
When to use this runbook
Use this runbook when a Suricata alert fires on the firewall, when an application owner reports that legitimate traffic is being blocked, or when the alert volume is high enough to require triage.
Pre-checks
Before starting the procedure, confirm the prerequisites and pre-checks are met. The structured lists are rendered from the frontmatter by the page layout.
Procedure
Follow the steps from the frontmatter procedure steps. The page layout renders the steps as a checklist with copy-to-clipboard affordances.
Verification
After the procedure, the structured verification items from the frontmatter are rendered as a checklist.
Rollback
If the procedure fails or makes things worse, follow the structured rollback steps from the frontmatter.
Escalation
The structured escalation path is rendered from the frontmatter. Use it if the operator cannot complete the procedure safely.