Suricata IPS mode and blocking — inline detection, drop rules, and the cost of false positives

Suricata IPS mode is the difference between seeing an attack and stopping one. In IDS mode, Suricata produces an alert and the packet continues; in IPS mode, the engine can drop or reject the packet before it reaches the destination. The trade-off is consequential: a false positive in IDS is an alert the operator dismisses; a false positive in IPS is a broken connection the customer sees. This lesson covers how IPS mode works in OPNsense, the action keywords and their effects, the discipline of promoting rules from IDS alerts to IPS drops, and the verification that proves blocking is actually working.

How IPS mode works

In IDS mode, Suricata captures a copy of the traffic — the original traffic continues regardless of what the engine decides. In IPS mode, Suricata sits in the forwarding path and decides whether each packet is forwarded or dropped.

The capture mechanism is the difference:

• IDS mode uses netmap or AF_PACKET in passive mode — the kernel copies packets to Suricata while continuing to forward the originals.
• IPS mode uses netmap in inline mode — the kernel forwards packets to Suricata first; Suricata inspects them and returns them to the kernel; the kernel then forwards them to the destination. If Suricata drops a packet, it does not return it to the kernel.

        IDS mode                          IPS mode

   +--------+        +--------+      +--------+        +--------+
   | kernel |------->| Suricata|     | kernel |<------>|Suricata|
   |        |  copy  |  (passive)|    |        | inline | (inline)|
   +--------+        +--------+      +--------+        +--------+
        |                                  |
        v                                  v
   forwarded                          forwarded or dropped

The inline path adds latency — every packet makes a round trip through Suricata — and adds CPU cost. The trade-off is the ability to block.

The action keywords

Suricata rules have four action keywords:

The effect on traffic:

• alert is the IDS default. The packet is logged and continues. The customer sees no impact.
• drop is the IPS default. The packet is silently discarded. The TCP sender retransmits; after a timeout the connection fails. UDP has no recovery; the application sees a missing response.
• reject is more aggressive than drop. The firewall sends a TCP RST or ICMP unreachable so the sender knows immediately. Some attacks exploit RST injection (TCP RSTs can be spoofed); reject makes the rejection explicit.
• pass is used in rules that say “this traffic is known-good, do not evaluate other rules against it”. Often used as a performance optimisation.

The operator who enables IPS mode with rules that have only alert actions is running IDS through an inline path — adding latency without the ability to block. To block, the operator must convert alert rules to drop (or write new rules with drop).

The discipline of promoting rules

The standard deployment pattern for IPS mode:

1. Run in IDS mode for at least two weeks with the rule set the operator intends to use in IPS mode. Collect the alerts.
2. Triage the alerts into true positives, false positives, and unknown.
3. Disable rules that produce false positives the operator cannot accept. The OPNsense GUI per-rule toggle is the mechanism.
4. Verify the false-positive rate is acceptable for the remaining rules. A rule with one false positive per 10,000 true positives may be acceptable; a rule with one false positive per 100 true positives is not.
5. Promote rules from alert to drop for the rules that pass the false-positive test. In the OPNsense GUI, the per-rule action can be changed from alert to drop.
6. Switch the interface from IDS to IPS mode. Verify blocking is working.
7. Monitor the alert volume and the customer impact for at least one week. Adjust as needed.

A deployment that switches to IPS mode on day one without the IDS-observation discipline is a deployment that blocks legitimate traffic from the first alert.

$ configctl suricata status; echo '---'; tail -20 /var/log/suricata/eve.json | grep -E '"event_type":"alert"' | head -5

suricata 1234 1 0 12:34 ? 00:00:42 /usr/local/bin/suricata
status: running
mode: ips
rules loaded: 28473
drop rules: 127
alert rules: 28346
---
{"timestamp":"2026-08-14T12:34:56","flow_id":123456789,"event_type":"alert","src_ip":"203.0.113.45","src_port":54321,"dest_ip":"10.0.0.50","dest_port":80,"proto":"TCP","alert":{"action":"blocked","gid":1,"signature_id":2024001,"rev":2,"signature":"ET MALWARE Cobalt Strike beacon","category":"A Network Trojan was detected","severity":1},"http":{"hostname":"malicious.example.com","url":"/aaa","http_user_agent":"curl/7.68.0","http_method":"GET","protocol":"HTTP/1.1","status":0,"length":0}}

Converting alert to drop in OPNsense

The OPNsense GUI exposes per-rule action toggles. The operator navigates to Services → Intrusion Detection → Rules, clicks on a rule, and changes the action from alert to drop (or reject).

The plugin writes the modified ruleset to a custom rules file (typically /usr/local/etc/suricata/rules/modified.rules) and reloads Suricata. The original ET Open rules are preserved; the modified rules override them.

The discipline:

• Document every rule modification in the change log. A rule converted to drop is a rule that blocks production traffic; the operator should be able to revert it.
• Test the modification in IDS mode first (if the rule was originally alert, observe it firing in IDS mode before converting).
• Convert in small batches. A single conversion per change window, not a batch of 50 conversions that the operator cannot isolate if it produces a problem.

The failure modes of IPS mode

Four production failure modes:

1. False-positive blocking. The most common. A drop rule fires on legitimate traffic; customers see broken connections. The fix is the discipline above (observe in IDS first, tune, then promote).
2. CPU saturation. IPS mode adds inspection cost per packet. A rule set that ran fine in IDS mode may saturate the CPU in IPS mode. The fix is fewer rules, faster hardware, or both.
3. Capture failure. Suricata in inline mode depends on the netmap or AF_PACKET mechanism. If the capture fails (kernel panic, driver issue), Suricata cannot inspect — and may not forward packets. The fix is monitoring (configctl suricata status, the capture thread stats in the log) and a tested failover to IDS mode if IPS is broken.
4. Asymmetric traffic. A deployment where inbound traffic goes through the firewall but outbound traffic does not (a routing misconfiguration) means IPS inspects only one direction. An attack that originates from inside the LAN and goes out the WAN will not be blocked. The fix is symmetric routing.

The verification

After enabling IPS mode, the operator verifies blocking is working:

1. Send a known-triggering packet. The EICAR test string (a standard anti-malware test) over HTTP to a destination the operator controls. Verify Suricata logs the alert with action: "blocked" and the destination does not see the request.
2. Check the EVE log for the action: "blocked" field. IDS-only alerts have action: "alerted" (or no action field, depending on version); IPS blocks have action: "blocked".
3. Check the customer’s experience — the connection should fail or reset, not hang.
4. Check the destination server’s logs — no record of the blocked request.

A deployment that passes all four checks is working. A deployment that has alerts but no action: "blocked" field has a configuration error.

Summary

• IPS mode uses inline capture (netmap on OPNsense); every packet is inspected before forwarding.
• The action keywords: alert (log only), drop (silently discard), reject (RST or ICMP unreachable), pass (stop evaluating).
• The discipline: observe in IDS mode first, tune false positives, then promote to drop. No exceptions.
• Verify blocking with a known-triggering packet and the EVE log action: "blocked" field.
• The failure modes: false positives, CPU saturation, capture failure, asymmetric traffic.