Should you run Suricata as an IDS or an inline IPS?
Run Suricata passively as an IDS on a tap or SPAN port when your priority is detection without risking an outage, and move to inline IPS only when a specific boundary must drop traffic and you can accept what a blocking device does to availability. Passive mode sees a copy of the traffic, so a Suricata fault or overload cannot interrupt the flows it watches. Inline mode places Suricata in the forwarding path, which means the failure model changes for the whole segment: if the engine stops or drops packets, the traffic it carries stops or degrades with it. Neither mode is better in general. The right answer depends on what the boundary protects and who answers the pager when it fails.
Inline IPS is justified when a control requires prevention at a specific point, such as a segment where known-bad traffic must be blocked before it reaches a sensitive system, and when the team has tested the blocking rules against its own traffic. Suricata supports two Linux inline methods, NFQUEUE (started with the -q option) and AF_PACKET IPS mode, and they differ in how packets reach the engine and in what happens when nothing is listening. Confirm the queue bypass behavior for NFQUEUE and the fail-open or fail-closed behavior of your chosen method in the Suricata documentation before you build the design, since the default for an unattended queue is to drop packets.
Before you choose inline, confirm three things in your own environment: whether the NICs in the path have GRO, LRO or TSO offloads that the Suricata inline guide says cause drops in AF_PACKET IPS mode, how exception policies behave at the auto default (which fails closed in IPS mode), and who owns the decision to fail open during an outage. Passive IDS on a tap avoids all three risks, so it remains the safer starting point for teams that need visibility first. The Suricata IPS and inline setup guide is the natural next read for the setup steps.
How IDS on a tap and inline IPS differ on Linux
This table compares passive Suricata IDS on a tap or span port with inline IPS using NFQUEUE or AF_PACKET IPS mode. Read each row as the documented behavior that changes your risk, so the failure and exception rows matter most before you choose a mode.
| Factor | IDS on a tap or span port | Inline IPS (NFQUEUE or AF_PACKET) |
|---|---|---|
| Traffic path | Copies of traffic reach Suricata; live traffic does not pass through it | Traffic passes through the Suricata host, which sits in the forwarding path |
| Ability to drop traffic | Alerts only; no packets are dropped by the sensor | Can drop packets; in IPS mode a reject action also enables drop |
| Documented Linux setup | Capture from a tap or span interface in IDS mode | NFQUEUE started with the -q option, or AF_PACKET IPS mode with copy-mode ips, copy-iface pointing at the peer, equal MTUs and different cluster-id values |
| Failure behavior | Sensor outage removes visibility but does not affect the traffic path | Queued packets are dropped when no program listens, unless the queue bypass option is set (NFQUEUE) |
| Exception policy default (auto) | Exception policies are ignored | Most exception policies fail closed, dropping the flow or packet, for example when memcap is reached |
| Offload sensitivity | Low for detection; capture offloads affect visibility accuracy | High: GRO, LRO and TSO cause dropped packets in AF_PACKET IPS mode, so offloads must be reviewed |
| Change risk | Low; a rule mistake produces noisy alerts rather than outages | High; a faulty rule, misconfigured exception or sensor failure can block production traffic |
| Staff skills needed | Rule tuning, EVE JSON handling and capture placement | Adds Linux netfilter or AF_PACKET bridging, NIC offload tuning, change control and an on-call path for blocking decisions |
Three ways Suricata can sit on the traffic path
Suricata can watch a copy of traffic, sit in a userspace queue, or bridge two interfaces as an inline pair. Each placement changes what Suricata sees, whether it can drop packets, and how much the network team must build before go-live.
Passive capture on a tap or SPAN
Suricata receives a copy of traffic from a network tap or a switch SPAN port and runs in IDS mode. It can alert and log through EVE JSON but cannot drop or modify the live flow. The network team must provide a mirror that carries both directions of the conversations you care about, and must confirm that the monitor interface does not carry a management address. Check for dropped packets in Suricata's stats output, because a busy SPAN port can oversubscribe and silently hide traffic from detection.
NFQUEUE inline with queue bypass
With NFQUEUE, iptables or nftables rules hand packets to Suricata started with the -q option, and Suricata returns a verdict on each one. Packets queued while no program listens are dropped by default, so a crash can cut traffic. The queue bypass option makes those packets behave as ACCEPT when Suricata is not running, which trades protection for availability. The network team owns the firewall rule set, and the security team must decide which behavior is acceptable for each path.
AF_PACKET IPS mode with a peer
AF_PACKET IPS mode uses two dedicated interfaces, each set to copy-mode ips with copy-iface pointing at the other, with equal MTUs and different cluster-id values. Suricata then acts as a bridge that can drop packets. The network team must cable the pair in series, keep both NICs out of the host's routing and management plane, and match MTUs across the path. Copy-mode tap forwards without dropping, which is useful for validating the bridge before enabling drops.
Offload settings on the capture NIC
GRO, LRO and TSO can build datagrams larger than the physical layer allows, and the Suricata guide warns that these settings cause dropped packets in AF_PACKET IPS mode because the transmit path cannot handle them. Before go-live, the platform team should disable these offloads on the bridged interfaces and record the change in the host build. Confirm the exact driver behavior on your NIC model, since offload behavior varies by hardware and driver.
EVE JSON feeding Wazuh
Suricata writes alerts, HTTP, TLS, DNS and file events to EVE JSON, which is the output that most SIEMs ingest. In Wazuh's proof of concept, Suricata runs on the monitored endpoint, the Wazuh agent reads the EVE logs, and the Wazuh server analyzes them. This output works the same whether Suricata runs as IDS or IPS, so the security team can start passively and change mode later. Check that log rotation and disk sizing on the sensor match the event volume you expect.
How fail-open and fail-closed decide what happens during a failure
Whether Suricata fails open or closed is decided by configuration you set before go-live, not by the engine's defaults alone. In NFQUEUE inline mode, Suricata is started with the -q option to bind to a queue. By default, packets sent to a queue that no program is reading are dropped, so a stopped or crashed Suricata process cuts traffic. The queue bypass option changes that: when Suricata is not running, the rule behaves like ACCEPT and traffic flows uninspected. Confirm which of these applies on your build and service manager, then test it by stopping the process on a non-production sensor and watching the path between the two networks.
Exception policies govern a second class of failure, where Suricata is running but a resource limit is reached. The exception-policy setting defaults to auto. In IPS mode, most exception policies fail closed, so when a condition such as a reached memcap occurs, Suricata drops the affected flow or packet. In IDS mode, auto means the exception policies are ignored. Review each policy in the Suricata exception policies documentation and decide, per condition, whether dropping or passing traffic is the acceptable outcome for the business service behind that link.
Set and test each policy deliberately before enabling any drop or reject action. Run the sensor under representative load, push memcap and queue limits on purpose, and record what the path does in each case. Include the outcome in the change record and in your runbook, so an on-call engineer knows whether a stalled sensor means an outage or an unfiltered link. Neither fail-open nor fail-closed is safe by default. Each one trades availability for inspection, and the right balance depends on what the link carries and who you must answer to when it stops.
How to stage an inline rollout without surprises
This sequence moves Suricata from passive observation to blocking in small, reversible steps, so the team learns the alert profile, the packet path and the failure behavior before any legitimate traffic can be dropped. Each step ends with a check that tells the operator whether to continue, pause or roll back.
Run Suricata passively on a tap or span port
The network team connects Suricata to a tap or span port in IDS mode, and the security engineer loads the current rule set and enables EVE JSON output. Run it long enough to cover normal business cycles, then review which signatures fire most often. Treat the output as a list of candidates to tune, not as a list of threats. The step is done when the team has a documented baseline of alert volume per signature, and each high-volume signature has either been suppressed with a reason or confirmed as a true positive.
Verify NIC offload settings on both interfaces
The platform engineer checks the offload features on each interface in the inline pair and disables GRO, LRO and TSO where Suricata's documentation says they cause drops in AF_PACKET IPS mode. Record the before and after values, and make the change persistent so it survives a reboot. Confirm the settings with the NIC vendor's tooling or the distribution's network documentation, because command names and defaults vary by driver. The step is done when a recorded configuration shows every offload setting that matters in the documented state on both interfaces.
Confirm MTU and cluster-id values on the pair
The engineer confirms that both interfaces in the AF_PACKET IPS pair have equal MTUs and that each interface uses a distinct cluster-id, as the Suricata IPS guide requires. The check is run on the live host, not only in the configuration file, and the values are captured in the change record. A mismatch here causes the pair to behave unpredictably, so the engineer stops and corrects it before going further. The step is done when both values match on the record and the running system.
Test queue bypass and exception policy behavior
In a lab or a scheduled maintenance window, the team stops the Suricata process while traffic flows and observes what the platform does. For NFQUEUE, they check whether packets are dropped or accepted when no program is listening, and whether the queue bypass option is in effect. They then reproduce a memcap or similar condition and confirm how the exception policy behaves in IPS mode, where the default auto setting generally fails closed. The step is done when the team has a written result for each condition, showing what traffic was affected and how long recovery took, measured rather than assumed.
Write the rollback procedure before the change
The change owner writes the rollback steps before enabling any drop action. The procedure should say who can switch the sensor back to IDS mode, how the inline pair is removed or bypassed, which change ticket covers the action, and who on the application side is informed when traffic is interrupted. The engineer rehearses at least the first two steps in the lab. The step is done when the rollback has been reviewed by the service owner and a second engineer, and the approved document is attached to the change ticket.
Enable drop actions on a narrow rule set
During the approved window, the engineer switches the sensor to IPS mode and enables drop actions for a small group of signatures that the baseline showed to be high-confidence and low-volume. Other signatures stay in alert mode. Watch the EVE output, interface counters and application error rates for the agreed observation period. The step is done when the team has seen no unexplained drops against the approved traffic, and the list of enabled drop signatures is recorded with its owner.
Review drops and expand the rule set
The security team reviews every dropped flow against the business owner of the affected service, classifying each as a true block, a false positive or an unknown. False positives lead to a suppression or threshold change with a documented reason. New signatures are added to drop only after the same observation step is repeated. The step is done when the review record shows each drop classified, and the drop list is versioned in the same way as other production configuration.
Which deployment fits which team and boundary
A security operations team that needs visibility into east-west or perimeter traffic, but does not own the availability of the services behind it, usually fits passive IDS mode. Suricata sees a copy of the traffic from a tap or span port, raises alerts and writes EVE JSON for downstream analysis, so a faulty rule cannot stop a payment or patient workflow. The trade-off is that nothing is blocked, and the team must accept that an alert is only as useful as the response behind it.
- Sensor placement: Confirm the tap or span design covers the segments that matter, and that span ports are not oversubscribed, since dropped mirror traffic creates blind spots that look like clean networks.
- Approvals: Obtain written agreement from the network owner for the mirror or tap change and from the SOC for the alert handling process.
- Test evidence: Capture a known test signature, confirm the alert appears in EVE JSON and the SIEM, and record packet drop counters over a representative period.
- Ownership questions: Who triages alerts at night, and does anyone own tuning of noisy rules?
- Scope: Decide whether east-west coverage needs additional sensors, since one sensor rarely sees every segment.
Before committing, ask the network team which segments can be mirrored without affecting production forwarding, and confirm the approved path for the SOC to escalate an alert into an incident.
A team protecting one boundary, such as an internet edge or a regulated zone, where blocking is a documented requirement, usually fits inline IPS mode. Suricata sits in the forwarding path, so a drop rule or a reject action stops traffic that matches. This mode only makes sense when the security requirement is written down, the failure behavior is agreed, and the team can test the path before production. Otherwise the blocking capability becomes an outage source.
- Method choice: NFQUEUE with the
-qoption is the documented route on Linux, while AF_PACKET IPS mode needs two dedicated interfaces with copy-mode ips and copy-iface pointing at the peer. - Failure behavior: Decide between fail-open and fail-closed for each path, and document what happens when Suricata stops. The NFQUEUE queue bypass option makes traffic behave as ACCEPT when no program is listening.
- Exception policies: In IPS mode, the auto default fails closed for conditions such as a reached memcap, so set each policy explicitly and test it.
- Offload: Disable GRO, LRO and TSO where the guide warns they cause drops in AF_PACKET IPS mode.
- Approvals: Require change approval from the boundary owner, a rollback plan and a named person who can switch to passive mode quickly.
Before a blocking rule goes live, ask the application owner which legitimate flows could match, and run those flows through the inline path in a test window with drop counters watched.
A team with limited network engineering staff usually should start in passive IDS mode, and move to inline only after it has the skills to own the forwarding path. Inline deployment adds routing, bridging, NIC tuning and failure testing to the work, and each of these needs someone who can diagnose it at 2 a.m. Passive mode keeps the operational footprint closer to a logging pipeline, which is easier to staff and hand over.
- Skills gap: Identify who can troubleshoot NFQUEUE, AF_PACKET interfaces and NIC offload settings before an inline project starts.
- Hardware and tap design: Confirm the sensor has interfaces suited to the chosen mode, since AF_PACKET IPS needs two dedicated interfaces with matching MTUs.
- Approvals: Agree with the infrastructure owner who maintains the host, patches it and carries the on-call duty.
- Test evidence: Keep a runbook that shows how to return to passive operation and how to verify it, and rehearse it.
- Support model: Decide whether internal staff or an external implementation and support partner will hold the knowledge long term, and write that into the scope.
Before starting, ask the network team whether they can own the inline path for its full lifecycle, including upgrades. If the answer is no, a passive deployment with a clear review of alerts is usually the safer first step.
Who runs each mode after go-live
This table compares what an IDS on a tap or span port and an inline IPS on NFQUEUE or AF_PACKET IPS mode each ask of the team once the sensor is live. Read each row as a recurring task, and note that the inline path adds a standing on-call dependency that a passive sensor does not have.
| Operating area | Suricata IDS (passive) | Suricata IPS (inline) |
|---|---|---|
| Upgrades | Upgrade on the project's schedule. Suricata 8.0.7 is the current stable release (September 15, 2026); the 7 line is end of life after 7.0.17 (July 7, 2026), so plan moves off 7.x first. | Same version path, but each upgrade needs a maintenance window and a tested rollback, because a failed restart can stop traffic on the inline path. |
| Rule tuning | Tune for alert quality. A noisy rule creates analyst work but does not affect traffic. | Tune before any rule is set to drop. Each false positive that drops traffic is a service incident, not just an alert. |
| Drop and queue monitoring | Watch alert volume, capture drops and engine stats in EVE output. | Also watch NFQUEUE queue state or AF_PACKET peer health, dropped packets and fail-open or fail-closed events. Confirm alert thresholds with the team that owns the network path. |
| Configuration and rule backups | Back up suricata.yaml, rule sources and the rule-selection files so the sensor can be rebuilt. | Back up the same items plus the iptables or nftables rules and interface, offload and cluster-id settings that place traffic into the engine. |
| Change control for blocking rules | Changes are low risk, but still record who enabled which rule and why. | Require a documented review before any rule moves to drop or reject, with a rollback step and a named approver. Exception policy settings belong in the same change record. |
| Skills needed over time | Signature tuning, EVE JSON parsing and packet analysis. Staff can usually learn these on a standard security team. | Adds Linux networking, NIC offload behavior, firewall queue configuration and incident response on the traffic path. Confirm that staff can cover these skills across shifts. |
| Standing on-call load | Analysts respond to alerts during business hours or under the normal SOC rota. | Someone must be reachable for outages on the inline path, because a blocking sensor failure can interrupt production traffic. Confirm the escalation path with the network owner before go-live. |
What blocking adds to your availability risk
An inline Suricata sensor stops being a passive observer and becomes part of the forwarding path. A crash, a memcap event, a network card offload fault or a misconfigured drop rule can therefore interrupt live services, not just produce a missed alert. The core decision is whether the blocking value justifies that outage exposure for each segment you would place inline. Start with the segments where a false positive or a stalled sensor would hurt least, and treat every drop rule as a change that needs an owner and a rollback path.
Suricata makes this risk easy to underestimate. In IPS mode, any reject action also enables drop, so a rule written to send a TCP reset or ICMP unreachable still removes the packet from the flow. Exception policies add a second layer: under the default auto setting, most exception policies fail closed in IPS mode, so a reached memcap can drop traffic rather than let it pass. Review every rule set you import, including vendor and community rules, for reject actions before enabling it inline, and confirm the fail-open or fail-closed behavior of each exception policy in your build. Plan maintenance windows for rule and version changes, and rehearse rolling back to a passive tap or bypass path before go-live.
Ask your Suricata provider or support channel which release line and build options they will support in inline mode, and how they test offload settings on your NIC models. Ask your network team whether the design supports a hardware bypass or fail-open path, and how traffic reroutes when the sensor is down. Then measure it yourself: run a load test with realistic traffic, check for drops and memcap events, and time a forced restart to see what your services experience. Record those results before you accept any blocking rule into production.
Questions buyers ask before choosing or hiring help
Is a tap-based Suricata IDS enough to protect our network?
A tap or span port gives Suricata a copy of traffic, so it can detect and log threats but cannot stop them. For many teams that is the right first step, because detection, alerting and network security monitoring do not put production traffic at risk. Suricata produces EVE JSON logs, HTTP, TLS and DNS records and extracted files, which feed your SIEM or analysts. Move to inline mode only when your response process needs automatic blocking and you have accepted the availability risk of sitting in the traffic path. Suricata's IDS and IPS modes share one signature engine, so the detection work carries over if you switch later.
What drives the effort of running Suricata inline as an IPS?
Effort comes from the number of decisions you must make and test, not from the install itself. On Linux you choose between NFQUEUE, which needs the -q option and a queue bypass decision, and AF_PACKET IPS mode, which needs two dedicated interfaces with copy-mode set to ips, a matching copy-iface peer, equal MTUs and different cluster-id values. You must disable offloads such as GRO, LRO and TSO, which the Suricata guide says cause dropped packets in AF_PACKET IPS mode. You also need exception policy choices, because in IPS mode most exception policies fail closed. Each choice needs lab testing against your real traffic before production.
Can our own engineers run an inline Suricata deployment without outside help?
Yes, if you have Linux network engineers who can work with interface configuration, kernel offloads and packet paths, and a change process that can roll back quickly. The documentation covers the setup steps, so the gap is usually operational experience rather than knowledge of the product. Teams without that experience often underestimate testing of failure modes, such as what happens when the Suricata process stops or a memcap is reached. Outside help can be scoped to design review, lab validation, hardening and handover, or to ongoing support. DeployOpen implements, hardens, documents and supports self-hosted platforms in the client's own infrastructure, and its work is fixed-scope with agreed deliverables.
How long does a staged Suricata rollout take, and what does it depend on?
No supplied source gives a duration for a Suricata rollout, so treat any figure you hear as unverified until it is tied to a written scope. The schedule depends on the number of sensors and links, whether you use NFQUEUE or AF_PACKET, how many ruleset and exception decisions you must tune, the change windows available on production paths, and how long you run in IDS mode before enabling drop. Staging usually moves from a lab to a tap-based IDS on a single segment, then to inline on a low-risk path, then to wider rollout. Ask for the milestones, the exit criteria for each stage and the rollback plan in the proposal.
What should a quote for an inline Suricata project include?
A useful quote lists the scope in writing before work starts. Ask it to cover the architecture decision between tap and inline, the chosen inline method, the interface and offload configuration, the exception policy and fail-open or fail-closed behavior per traffic path, lab test cases including process failure and memcap conditions, the rollback procedure, documentation, and handover to your operators. Ask whether ruleset management, log forwarding to your SIEM and ongoing tuning are included or handled as a separate retainer. Fixed-scope proposals are the norm for this work, and DeployOpen does not publish a price list, so the written scope is what the quote follows from.
Is Suricata licensed for commercial use?
Suricata is licensed under GPL-2.0, according to the LICENSE file in the OISF/suricata repository, and the Open Information Security Foundation owns and supports the project as a 501(c)3 non-profit. GPL-2.0 permits use in commercial environments, but it carries copyleft obligations if you distribute modified versions. Using Suricata inside your own network without redistribution typically does not trigger distribution obligations, but your legal team should confirm this against your own use case. Rulesets have their own terms: the Emerging Threats and VRT rulesets are licensed separately from the engine, so check those terms before you deploy them.
Which Suricata inline risk should we check first?
Check what happens to traffic when Suricata stops, because that determines whether a failure is an outage or a blind spot. With NFQUEUE, packets queued when no program is listening are dropped by default, and the queue bypass option changes that behavior so traffic passes as if accepted. Confirm that choice in a lab by stopping the process while traffic flows. In IPS mode, exception policies default to auto and most fail closed, so a memcap event can drop flows. Document the behavior for each path, then agree with the business owner which paths may fail open and which must fail closed.
How DeployOpen scopes and delivers an IDS or IPS deployment
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, so a Suricata deployment is set up on your network segments, cloud accounts or air-gapped environment. Engagements are fixed-scope, with scope and deliverables agreed in writing before any work starts.
How we scope
- Map which links carry traffic, whether a tap or span port is available, and where inline placement is physically possible.
- Record in writing whether Suricata runs as IDS or IPS, and which inline method and fail behavior apply.
- Agree which exception policies, drop actions and rule sources are in scope before any blocking is enabled.
How we build
- Configure NFQUEUE or AF_PACKET IPS mode on the agreed hosts, including interface pairing, MTU and cluster-id settings.
- Test offload settings such as GRO, LRO and TSO on the actual NICs and confirm no packet drops appear in the EVE output.
- Test failure scenarios, including Suricata stopping and memcap conditions, to confirm the agreed fail-open or fail-closed behavior.
How we hand over
- Document the network placement, service configuration, exception policy decisions and the rollback steps for each inline path.
- Deliver runbooks for operators covering alert triage, rule updates and how to switch a sensor from IPS back to IDS.
- Walk your operations and security teams through the handover, with acceptance tests defined in the written scope.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, separate from the initial fixed-scope delivery.
- Review Suricata upgrades and rule changes against your documented inline configuration before they reach production sensors.
- Ask for the retainer terms, response expectations and upgrade cadence in writing so they match your own change process.
