Suricata · Sensor setup

Offline PCAP analysis

Use a saved benign conversation to test detection without changing a live forwarding path.

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.

Benign lab files: Constructed HTTP PCAP · Alert rule · Drop rule · SHA-256. Save these with the suggested names. The PCAP is a synthetic 20-frame Ethernet/IPv4/TCP fixture containing complete benign marker and ordinary HTTP exchanges; it is not a recording of real users. It was constructed without transmitting traffic. A successful live Suricata replay is still to be verified.

Prepare repeatable input

Use an authorized lab PCAP containing a full TCP handshake and a cleartext HTTP GET from 10.10.10.20 to 192.0.2.80:8080 with URI /routecraft-check. A second GET /ordinary is the negative control. Keep the original capture unchanged and record its hash. The commands below assume this file already exists; no capture is started here.

Select exactly one local signature

Use the packaged 8.0.1 YAML with HOME_NET 10.10.10.0/24, EVE alert and HTTP logging enabled, and this local rule. In the replay command, uppercase -S selects only the named file; lowercase -s would add it to configured signatures.

alert 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:1000001; rev:1;)

Validate, then read the PCAP

mkdir -p lab-out
suricata -T -c /etc/suricata/suricata.yaml -S ./local.rules --init-errors-fatal
suricata -c /etc/suricata/suricata.yaml -S ./local.rules -r ./lab-http.pcap -l ./lab-out

Use a fresh empty log directory for each run. Offline -r reads packets from the file and does not send them to the network. The process exits when the input completes. Do not treat --simulate-ips output as proof of live forwarding enforcement.

Check the recorded result

Illustrative output · selected fields

jq -c 'select(.event_type=="alert") | {sid:.alert.signature_id,src:.src_ip,dst:.dest_ip}' lab-out/eve.json
{"sid":1000001,"src":"10.10.10.20","dst":"192.0.2.80"}

The selected event identifies the expected benign marker. Event counts depend on the complete fixture and engine behavior; verify the request itself using HTTP metadata or the original PCAP, not just a fixed count.

Investigate a missing match

Check	Why it matters
Exact header addresses and port	Wrong endpoints never reach the intended signature
Cleartext URI and request direction	TLS ciphertext is not an HTTP URI
Handshake and both directions	Established stream processing needs context
Checksum and capture integrity	A host capture may contain offload artifacts
Loaded rule and output selection	A stale rule or disabled alert logger hides evidence

Do not disable checksum validation by habit. If offload artifacts are established in a trusted capture, document an isolated comparison using the supported checksum option. Keep the normal validation result and the comparison distinct. Preserve both positive and negative fixture results when changing a rule.

Key Takeaways

Offline replay reads existing packets without transmitting them.
Use a complete benign positive case and a negative control.
Uppercase -S selects an exclusive rule file; lowercase -s adds rules.
Separate output directories prevent stale results from confusing a rerun.
An offline match validates detection for the fixture, not inline packet blocking.