How to test a Suricata rule

Testing a Suricata rule proves that the signature loads and matches the traffic it was written to detect. A small offline replay keeps the check repeatable, so the same rule and packet capture can be used during review, tuning, or a sensor build.

The -S option loads only the supplied test rule for the replay run, while -r reads a saved pcap file and -l writes output into a separate log directory. Keeping the test rule and replay logs outside the service directories avoids mixing lab evidence with the sensor's normal rules and alerts.

Use a capture that contains the exact traffic the rule should match. The sample rule below alerts on an HTTP request for /sample.txt and uses local sid 9000002, so the matching fast.log and eve.json entries should show that signature ID.

1. Create a lab directory for the rule test.

   $ mkdir suricata-rule-test

2. Enter the lab directory.

   $ cd suricata-rule-test

3. Copy the known test capture into the lab directory.

   $ cp ~/captures/rule-test.pcap ./rule-test.pcap

   The capture must contain the packet or request your rule is meant to match. For the sample rule, use a capture with an HTTP request for /sample.txt.

4. Create the rule file to test.

   $ vi rule-test.rules

   rule-test.rules

   alert http any any -> any any (msg:"SG Suricata rule test HTTP request"; http.uri; content:"/sample.txt"; sid:9000002; rev:1;)

   Use a local sid range reserved for your environment. Reusing a managed rule sid can make suppression, thresholding, and alert triage point at the wrong signature.

5. Test that Suricata can load the rule.

   $ suricata -T -c /etc/suricata/suricata.yaml -S rule-test.rules -v
   Notice: suricata: This is Suricata version 8.0.3 RELEASE running in SYSTEM mode
   Info: suricata: Running suricata under test mode
   Info: detect: 1 rule files processed. 1 rules successfully loaded, 0 rules failed, 0 rules skipped
   Notice: suricata: Configuration provided was successfully loaded. Exiting.

   -S loads this rule file exclusively for the test, so the rule count should match the test file instead of the full production ruleset.
   Related: How to test Suricata configuration

6. Create a fresh log directory for the replay.

   $ mkdir rule-test-logs

7. Replay the capture with the test rule.

   $ suricata -r rule-test.pcap -l rule-test-logs -S rule-test.rules -k none
   i: suricata: This is Suricata version 8.0.3 RELEASE running in USER mode
   i: threads: Threads created -> RX: 1 W: 8 FM: 1 FR: 1   Engine started.
   i: suricata: Signal Received.  Stopping engine.
   i: pcap: read 1 file, 9 packets, 688 bytes

   -k none disables checksum validation for the replay, which avoids false misses when the capture came from a host using checksum offload. Leave checksum validation enabled when checksum correctness is part of the rule test.

8. Confirm that the replay wrote Suricata log files.

   $ ls rule-test-logs
   eve.json
   fast.log
   stats.log
   suricata.log

9. Check fast.log for the expected rule alert.

   $ cat rule-test-logs/fast.log
   06/25/2026-08:10:00.000000  [**] [1:9000002:1] SG Suricata rule test HTTP request [**] [Classification: (null)] [Priority: 3] {TCP} 192.0.2.10:49152 -> 192.0.2.20:80

   The bracketed alert ID should show the local sid and revision from rule-test.rules.
   Related: How to view Suricata alert logs

10. Confirm the same rule match in eve.json.

    $ jq -r 'select(.event_type=="alert") | [.alert.signature_id, .alert.signature, .src_ip, .dest_ip, .proto] | @tsv' rule-test-logs/eve.json
    9000002	SG Suricata rule test HTTP request	192.0.2.10	192.0.2.20	TCP

    Matching fast.log and eve.json output confirms that the replay reached detection and both alert outputs.
    Related: How to read Suricata eve.json logs

11. Remove the temporary rule test files after saving any needed evidence.

    $ rm -rf rule-test-logs rule-test.rules rule-test.pcap

    Run the cleanup from the lab directory only. The command removes the copied pcap, the one-rule test file, and the replay logs in the current directory.