Put the engine in the packet path#

You will end up with Suricata deciding on packets rather than watching a copy of them: a firewall rule hands the traffic it matches to the engine, the engine decides on each packet, and a packet it refuses never reaches the other side.

The IDS is detection: it watches and cannot block. Inline prevention needs the engine in the path. All of it is configuration — an engine and a firewall rule — reviewed in the pending changes and applied like anything else.

Before you start#

The operator role and a licence.
An existing Accept rule in the Forward chain covering the traffic you want inspected. This matters — see the next section.
The engine installed from Apps: it runs as a container, and its image has to be on the router before the change can be applied.
An honest answer to "what happens if this blocks something it should not". Read the section on what keeps traffic flowing before you apply anything.

The safe way: inspect traffic an accept rule allows#

Send traffic an accept rule already admits through the engine. Same connections, now inspected. Nothing new is allowed, because a rule that sends traffic to an engine that then passes it is exactly the accept it replaced.

The IDS page also offers a new rule that sends everything arriving on an interface to the engine, and says what that does: until rules are loaded the engine passes everything, so that rule admits all the interface's traffic until then.

Step 1 — Build the change#

Protect → IDS, at the bottom of the page, Turn on inline prevention. Choose Traffic an accept rule allows and the rule. The panel shows what the change will do under Before you apply, and says when the engine is not installed yet.

Step 2 — Add it and apply#

Turn on inline prevention adds the engine and the rule's new action to the pending changes. Apply with auto-revert: this touches the path every connection through that rule takes.

What keeps traffic flowing if the engine stops#

Check it worked#

The Inline prevention panel says Blocking when the engine is in place, running, and a rule sends it traffic, and lists the rules that do.

Traffic still flows. Before anything else, from a client behind the rule:

bash

curl -sS -o /dev/null -w '%{http_code}\n' https://example.com
ping -c 20 192.0.2.1

The rule is matching. Its counters on the Firewall page rise. A rule with flat counters is not matching, and the traffic is going through some other rule uninspected.

Undoing it#

Turn off inline prevention asks twice, then removes the engine and turns each rule that sent it traffic back into a plain Accept rule — which is why inspecting an accept rule was the safe way in: the rule goes back to being what it was.