Drop verification and failure policies

Use a narrow benign enforcement marker

Use either the AF_PACKET pair or the scoped NFQUEUE lab, not both simultaneously. Confirm that GET /ordinary and GET /routecraft-check initially reach the prepared server with the alert-only local policy. Then replace only that marker with the following drop signature and validate the selected rules.

drop http 10.10.10.20 any -> 192.0.2.80 8080 (msg:"LAB PacketLab marker"; flow:established,to_server; http.uri; content:"/routecraft-check"; startswith; sid:1000002; rev:1;)

Correlate three pieces of evidence

This matrix describes expected controlled results, not a performed test. Loss of all traffic indicates a broader path or availability problem, not a precise success. An application may retry, so exact packet and alert counts are not fixed.

Read final verdict carefully

jq -c 'select(.event_type=="alert") | {sid:.alert.signature_id,action:.alert.action,verdict}' /var/log/suricata/eve.json
{"sid":1000002,"action":"blocked","verdict":{"action":"drop"}}

The verdict field requires the corresponding EVE option and is optional. Another individual alert may be allowed while the final engine decision is drop. Match endpoints, time, sensor and flow rather than relying on a text signature name.

Separate engine exceptions from rule matches

A parser error, resource limit or missing stream context can invoke an exception policy. For Suricata 8 IPS, documented defaults commonly favor blocking for relevant exceptions, but individual policy support and settings differ. Inspect the complete installed configuration and exception counters before changing them. An exception drop is not proof that the marker signature matched.

Test and restore deliberately

In an isolated lab with separate management, test one failure at a time: remove the consumer, interrupt a data link and exercise the approved rollback. Record both traffic continuity and inspection continuity. No-listener bypass is not a universal answer to a hung consumer or full queue.

Restore the alert-only rule and known-good topology when done; remove the dedicated NFQUEUE table if it was used. Verify ordinary traffic and expected logging again. Prevention validation is complete only when both intended blocking and intended continued service are demonstrated.