Test Inline Prevention¶

Move from passive detection to blocking only after documenting the traffic path, management path and rollback procedure.

Inline mode can disconnect the lab

Use console access and a disposable snapshot. Never introduce NFQUEUE or an inline bridge on the only management path. Schedule production changes through the organisation's normal review and rollback process.

Plain-language refresher

A passive IDS watches a copy of traffic and normally cannot block it. An inline IPS handles the real traffic and can allow or drop it. NFQUEUE asks Snort for a verdict on packets selected by the Linux firewall; AFPacket inline passes traffic across a paired set of sensor interfaces. See Understand sensor placement for diagrams and explanations of TAP, SPAN, NSM, host IDS, and inline IPS.

Select the architecture¶

Mode	Traffic path	Key requirement
Passive IDS	Mirrored/TAP traffic to one sensor interface	`alert` actions observe but do not block
AFPacket inline	Traffic crosses a paired two-interface path	A verified interface pair and bridge topology
NFQUEUE inline	Linux firewall deliberately queues selected packets	Matching queue number, tested bypass and explicit cleanup

Confirm the selected module exists before changing traffic flow:

sudo /usr/local/bin/snort --daq-list
sudo /usr/local/bin/snort -c /usr/local/etc/snort/overview.lua -T

Understand the verdict path¶

In passive mode, a drop rule can be logged without enforcing a drop because Snort is not controlling packet forwarding. In inline mode the DAQ presents a packet to Snort, Snort returns a verdict, and the DAQ or firewall enforces it. Prove all three stages before concluding that prevention works.

AFPacket inline requires two interfaces and a paired DAQ instance; specifying one interface does not create an inline bridge. NFQUEUE requires Linux firewall rules that send a deliberately selected flow to the same queue Snort opens.

Prepare a scoped drop rule¶

Copy the known-good alert rule and narrow it to disposable lab endpoints:

drop icmp 10.0.0.29 any -> 10.0.0.22 any (
    msg:"LOCAL LAB inline ICMP drop";
    itype:8;
    sid:1000010;
    rev:1;
)

Validate the complete ruleset before introducing any queue or interface pair:

sudo /usr/local/bin/snort -c /usr/local/etc/snort/overview.lua -T

Stage a safe blocking test¶

Prove the traffic path with an alert rule.
Record a working management connection and open a console.
Limit the rule to one disposable source, destination and protocol.
Change the action to drop only after the alert test is correct.
Start Snort in the selected inline mode using the syntax supported by the installed LibDAQ version.
Run the positive test and confirm the intended packet is dropped and logged.
Run a negative test and confirm unrelated traffic still passes.

For NFQUEUE, queue only the lab flow instead of inserting broad INPUT, OUTPUT and FORWARD rules. Save the firewall state and record every inserted rule with a unique comment so cleanup does not depend on changing line numbers.

NFQUEUE host test¶

This example queues only ICMP echo requests from the authorised test host to the sensor. Run it from a local console, not through the flow being tested.

First record the baseline and start Snort on queue 1:

sudo iptables-save > "$HOME/iptables-before-snort-lab.rules"
sudo /usr/local/bin/snort -Q \
  --daq nfq \
  --daq-var queue=1 \
  -c /usr/local/etc/snort/overview.lua \
  -A alert_fast -l /var/log/snort

In a second console, confirm Snort has opened NFQUEUE and then insert the narrow rule. The exact DAQ variables are version-specific; use --daq-list and the matching LibDAQ documentation if the command rejects queue=1.

sudo iptables -I INPUT 1 \
  -p icmp --icmp-type echo-request \
  -s 10.0.0.29 -d 10.0.0.22 \
  -m comment --comment SNORT-LAB-NFQ \
  -j NFQUEUE --queue-num 1
sudo iptables -vnL INPUT --line-numbers

Generate one ping from 10.0.0.29. Confirm:

the NFQUEUE rule packet counter increases;
the ping receives no echo reply;
SID 1000010 appears in the configured alert output; and
a ping from a different authorised host still succeeds.

If the counter remains zero, troubleshoot firewall matching before Snort. If the counter increases but the packet passes, verify Snort is in inline mode and loaded the drop rule. If traffic stops without an alert, check the queue, logger, permissions and Snort process separately.

Remove the test rule by its complete specification:

sudo iptables -D INPUT \
  -p icmp --icmp-type echo-request \
  -s 10.0.0.29 -d 10.0.0.22 \
  -m comment --comment SNORT-LAB-NFQ \
  -j NFQUEUE --queue-num 1

Do not rely on a changing line number for cleanup. Do not add --queue-bypass without documenting that it changes sensor failure into fail-open behaviour.

NFQUEUE gateway test¶

On a gateway, use FORWARD rather than broad INPUT and OUTPUT rules. Scope the test to one client, destination and protocol, verify IP forwarding and existing firewall policy, and ensure the management connection does not cross the queued flow. Apply the same counter, positive-test and negative-test checks.

AFPacket inline test¶

Use two dedicated, unnumbered sensor interfaces placed between the two lab segments. Record their MAC addresses and link state. The DAQ interface syntax depends on the LibDAQ release; obtain it from snort --daq-list/module help and record the exact paired-interface command. Confirm first with alert, then with the scoped drop rule. Test both directions and verify that stopping Snort has the documented fail-open or fail-closed result for the chosen topology.

Rollback¶

Before testing, prepare and verify these actions from the console:

Stop the Snort process or service.
Delete only the firewall rules carrying the recorded lab comment.
Restore the known-good local rules and snort.lua.
Restore the original interface/offload state if it was changed.
Validate the passive configuration and confirm management connectivity.

Do not describe missing alert_fast output as normal NFQUEUE behaviour. Check the configured logger, log directory permissions, rule action, process user and DAQ verdict path separately.

Evidence to retain¶

topology and management path;
Snort, LibDAQ and ruleset versions;
complete inline command and DAQ module;
firewall rules before, during and after the test;
queue counters;
positive drop alert and packet loss;
benign comparison result; and
proof that rollback restored the baseline.

Completion criteriaThe intended flow is blocked and logged, the benign comparison passes, management remains available, and rollback returns the sensor and firewall to their recorded baseline.

↑ Back to Snort journey map