Suricata

Did some more testing and I think we have pinpointed the issue.

1. if we enable only one (or change the sig_id of one of the rules and enable both), it does work (alerts are suppressed) - the same situation below with "trck by_src"

#if you enable both of the rules below - an alert would be generated with suppresstest.pcap (although it should not)
#if it is only one suppress rule enabled (82.96.58.41) - it works as expected - suppresses the alert
#suppress gen_id 1, sig_id 5001684, track by_src, ip 82.96.58.41
#suppress gen_id 1, sig_id 5001684, track by_src, ip 5.5.5.5

1. with both below rules enabled - suricata works as expected (notice the difference between the sid_id)
   #suppress gen_id 1, sig_id 1234567, track by_src, ip 5.5.5.5
   #suppress gen_id 1, sig_id 5001684, track by_src, ip 82.96.58.41

1. so it actually (judging by the tests) comes down to the same sig_id value, if you have it more than once, it seems it is not working

please find a 7 packet pcap attached along with a yaml conf file
The pcap has source ip - 82.96.58.41 and destination ip - 192.168.137.19

You can use repeatedly:
suricata -c /etc/suricata/suricata.yaml -s supress.rule -r suppresstest.pcap
to verify the issue.

thanks

Thanks Peter, I was able to reproduce it today.

The issue is quite simple: per sid suppressions are stored in the signature itself. When checking a sig, only the last of the suppression settings of a signature is checked.

- SigGetThresholdType gets the last suppression.
- PacketAlertHandle uses that to check the suppression.

What needs to be done is that PacketAlertHandle loops all suppression settings in a signature.

Pull request send to Victor who will review the fixes. Thanks a lot for such a precise bug report and diagnostic! Patches attached to the ticket for reference or supplementary tests.

Patches applied, thanks Eric.