Suricata IDS: prove the sensor can see the traffic you care about
Start with capture visibility and a harmless detection fixture before counting alerts.
Archive date is an editorial placement, not the original publication date. Published 9 September 2026; documentation reviewed 9 September 2026. Examples describe proposed checks, not customer incidents or measured product results.
A Suricata service can be running with a current ruleset and still inspect the wrong traffic. The first acceptance test is visibility: the intended packets reach the sensor, the expected rule fires, and the event reaches the analyst.
Define the observation point
Draw the path from a representative client to the protected service. Mark switches, virtual switches, firewalls, and encryption boundaries. A SPAN port observing an internet uplink may miss traffic between two servers on the same VLAN. A mirror that carries only one direction can impair stream interpretation.
Record the capture interface, expected networks, link capacity, and whether traffic can bypass the observation point. This is the sensor’s coverage statement. Avoid describing it as coverage of the entire enterprise.
Validate configuration and a known capture
On a lab host with Suricata 7.x and its matching configuration, use the documented test and offline modes:
suricata -T -c /etc/suricata/suricata.yaml
mkdir -p ./suricata-lab-output
suricata -r ./approved-test.pcap -c /etc/suricata/suricata.yaml \
-l ./suricata-lab-output
The PCAP is an approved fixture you supply; it is not downloaded or generated by these commands. It should contain synthetic traffic matching a known enabled test signature. Consult the command-line reference for your package’s options and permissions.
A configuration test establishes syntax and loading, not detection correctness. The offline run establishes behavior on a fixture, not live capture visibility.
Inspect the event, then the live path
With EVE alerts enabled in the configuration:
jq -c 'select(.event_type == "alert") |
{timestamp,src_ip,dest_ip,signature:.alert.signature}' \
./suricata-lab-output/eve.json
Suricata’s EVE documentation describes the event output. Confirm the expected signature identifier and endpoints rather than accepting any alert as success.
Next generate the approved benign test on the actual monitored path. Find its event locally and in the SIEM. Record the delay and the rule revision. If it appears offline but not live, investigate placement, capture filtering, and packet delivery before changing the detection rule.
Measure loss under ordinary load
Watch capture and decoder statistics during representative busy periods. Compare the switch mirror’s capacity with the traffic it aggregates. A mirror receiving two directions from several links can be oversubscribed even when the sensor’s nominal interface speed looks adequate.
Do not publish a throughput guarantee from a small fixture. Keep the configuration, rule count, traffic mix, CPU allocation, and observed drop statistics together.
Acceptance evidence
Retain configuration-test output, fixture identity, expected alert, live-path alert, SIEM arrival, and coverage limitations. That establishes a functioning IDS path. Blocking requires a separate IPS rollout.