Bug #366
closedsuppress (threshold.config) does not work with "track by_src"
Description
As pointed out by David Wharton, there is a problem with "track by_src" when using suppress rules in threshold.config
It does work when using "track by_dst".
1.1beta3 (rev 7bf1de0)
to test (generate an alert) the particular rule you should use
root# wget silverlight.dlservice.microsoft.com/download/D/C/2/DC2D5838-9138-4D25-AA92-52F61F7C51E6/runtime/Silverlight.exe
version 1.1beta3 (rev 18da4a8)
behaves the same way
thanks
Files
Updated by Victor Julien about 13 years ago
I tested with your settings and a pcap created from downloading that url and it works fine. Can you provide a real reproducible testcase with (small) pcaps?
Updated by Peter Manev about 13 years ago
- File suppresstest.pcap suppresstest.pcap added
- File supress.rule supress.rule added
- File threshold.config threshold.config added
- File suricata.yaml suricata.yaml added
Did some more testing and I think we have pinpointed the issue.
suppress gen_id 1, sig_id 5001684, track by_dst, ip 192.168.137.19suppress gen_id 1, sig_id 5001684, track by_dst, ip 192.168.137.20
#with the above 2 rules, if enabled both at the same time - it does not work as supposed (does not suppress the alert)
- 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
- 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
- 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
Updated by Victor Julien about 13 years ago
- Due date set to 11/02/2011
- Status changed from New to Assigned
- Assignee set to Eric Leblond
- Priority changed from Normal to High
- Target version set to 1.1rc1
- Estimated time set to 3.00 h
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.
Updated by Eric Leblond about 13 years ago
- File 0001-threshold-introduce-SigGetThresholdTypeIter-function.patch 0001-threshold-introduce-SigGetThresholdTypeIter-function.patch added
- File 0002-threshold-fix-thresholding-on-signature-with-multipl.patch 0002-threshold-fix-thresholding-on-signature-with-multipl.patch added
- % Done changed from 0 to 90
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.
Updated by Victor Julien about 13 years ago
- Status changed from Assigned to Closed
- % Done changed from 90 to 100
Patches applied, thanks Eric.