IDS versus inline IPS
Keep observation and enforcement separate: placement and capture mode determine whether Suricata can stop a packet.
Examples target Suricata 8.0.1 on a prepared Linux lab host. Constructed outputs are illustrative, not live sensor results. Commands are lesson examples; no sensor or enforcement is started by this page.
Passive IDS: receive a copy
A passive sensor evaluates traffic copied by a mirror or TAP. An alert can trigger an investigation or a separate response system, but Suricata cannot retract the original packet through this copy interface. Changing a rule action to drop does not turn a mirror destination into an inline enforcement point.
Inline IPS: decide before forwarding
An inline IPS is on the forwarding path. Packets selected for inspection can be forwarded or discarded according to the running policy. In ordinary IPS mode traffic is generally permitted unless a blocking rule or applicable engine policy rejects it; this is different from Suricata firewall mode with default-deny policy.
The path must include both directions. A second uninspected route can bypass the policy; a one-sided capture can also deprive stream inspection of context.
Two Linux integration models
| Model | Where the decision fits | Design constraint |
|---|---|---|
| AF_PACKET pair | Between two dedicated Layer-2 data interfaces | Matching MTUs, correct offloads and symmetric interface pairing |
| NFQUEUE | At a selected host or routed Netfilter hook | Queue the intended directions and protocol families; verify queue support |
These are deployment choices, not commands to run interchangeably. A Linux bridge alone does not prove that Suricata verdicts control its forwarding. AF_PACKET copy-mode ips honors blocking decisions; copy-mode tap forwards without that blocking behavior. A hardware network TAP and AF_PACKET tap mode are different meanings of the same word.
Prove enforcement with two observations
| Controlled test | Sensor evidence | Destination evidence |
|---|---|---|
| Benign flow | Observed without a blocking verdict | Application receives the test |
| Harmless marker with an approved drop policy | Matching blocking verdict and counter increment | Matching test traffic does not arrive |
This is an illustrative test plan, not a performed test. Compare sensor logs with a destination-side observation. A connection timeout alone could be routing, firewall, DNS or server failure. Likewise a detection alert alone is not a drop measurement.
Plan failure behavior
An inline device adds an availability dependency. Decide what should happen during process exit, interface failure, overload and maintenance. Queue bypass, hardware bypass, exception policy and redundant topology are separate mechanisms; none should be assumed to provide universal fail-open or fail-closed behavior.
Validate those cases in a lab before production enforcement. Begin with observation and tuned rules, keep a recoverable change plan, then introduce a small approved blocking policy. This page deliberately leaves deployment commands to the later platform-specific lessons.
Further reading
Key Takeaways
- IDS observes copies; inline IPS can control the inspected forwarding path.
- Rule action alone cannot make a passive mirror enforce drops.
- AF_PACKET paired interfaces and NFQUEUE are different integration models.
- Verify blocking using sensor verdicts and destination-side evidence.
- Failure behavior depends on the actual queue, interface, hardware and policy design.