How to suppress a Suricata signature ID

Suricata signatures sometimes alert on traffic that is expected for one environment, such as a recurring scanner, internal application, or accepted policy exception. A suppression entry mutes alert output for a specific signature ID without removing the rule from the ruleset.

Suppressions live in Suricata's threshold file, commonly /etc/suricata/threshold.config on packaged Ubuntu systems. The alert ID format in fast.log is [gen_id:sig_id:rev], and most normal rules use gen_id 1 with the rule's sid value as the signature ID.

Use a full-SID suppression only for alerts that are already confirmed false positives or accepted noise. If the rule should stop loading entirely, disable the rule instead; if only one host or network is noisy, scope the suppression with track and ip so other sources still alert.

1. Search for the noisy alert message in fast.log.

   $ sudo grep -F 'SG SID suppress test' /var/log/suricata/fast.log
   06/25/2026-07:18:10.000000  [**] [1:1000001:1] SG SID suppress test [**] [Classification: (null)] [Priority: 3] {UDP} 192.0.2.10:49152 -> 198.51.100.20:53

   The bracketed value is [gen_id:sig_id:rev]. This alert uses gen_id 1 and sig_id 1000001. Replace the quoted message with text from the alert being suppressed.

   Related: How to view Suricata alert logs

2. Open the Suricata threshold file.

   $ sudo vi /etc/suricata/threshold.config

   The default threshold-file path in Suricata configuration is /etc/suricata/threshold.config. Edit the path named by /etc/suricata/suricata.yaml when your deployment overrides it.

3. Add a suppress entry for the signature ID.

   suppress gen_id 1, sig_id 1000001

   This form suppresses every alert from SID 1000001. Use suppress gen_id 1, sig_id 1000001, track by_src, ip 192.0.2.10 when only one source host is accepted noise.

4. Test the Suricata configuration.

   $ sudo suricata -T -c /etc/suricata/suricata.yaml
   i: suricata: This is Suricata version 8.0.3 RELEASE running in SYSTEM mode
   i: suricata: Configuration provided was successfully loaded. Exiting.

   If Suricata reports an unknown SID for the suppress entry, the rule is not loaded from the active rule files. Update the ruleset or correct the SID before restarting.

   Related: How to test Suricata configuration

5. Restart Suricata to load the suppression entry.

   $ sudo systemctl restart suricata

   Restarting a live sensor can briefly interrupt inspection. Use your site's reload method when it is already validated for Suricata rule and threshold changes.

   Related: How to manage the Suricata service

6. Replay a packet capture that previously triggered the SID.

   $ sudo suricata -r /tmp/sid-test.pcap -c /etc/suricata/suricata.yaml -l /tmp/suricata-after
   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, 1 packets, 47 bytes

   Use a capture that produced the alert before the suppress entry. On a live sensor, check the normal fast.log or eve.json output after the same traffic appears again.

7. Confirm the replay log has no alert line for the suppressed SID.

   $ sudo cat /tmp/suricata-after/fast.log
   (no output)

   No output from the replay log means the matching packet still ran through Suricata, but SID 1000001 did not create a visible alert.

8. Remove the temporary replay log directory.

   $ sudo rm -rf /tmp/suricata-after