I defined my own signatures with priority 1 (i.e. classtype:attempted-user;) to drop packets from specific IP addresses but still other signatures with priority 2 (e.g. classtype:attempted-recon) are dropping the packets instead.
In the documentation is written that “Signatures with a higher priority will be examined first.”
I get this notification (A.B.C.D is just replacement of a real IP): [Drop] ET SCAN NMAP -sS window 1024 [Classification: Attempted Information Leak] [Priority: 2] {TCP} A.B.C.D:51730 → [myip]:61607
instead of: [Drop] MY source group 1 [Classification: Attempted User Privilege Gain] [Priority: 1] {TCP} A.B.C.D:51730 → [myip]:61607
My signature is:
drop ip [A.B.C.D] any → $HOME_NET any (msg:“MY source group 1”; reference:url,iprouter.com/block.txt; ack:0; threshold:type limit, track by_src, seconds 10, count 1; classtype:attempted-user; flowbits:set,ET.Evil; flowbits:set,MY.DropIP; sid:6001; rev:1; metadata:affected_product Any, tag iprouter, created_at 2021_01_15, updated_at 2021_01_15; )
The signature that is handling the packet first is:
drop tcp $EXTERNAL_NET any → $HOME_NET any (msg:“ET SCAN NMAP -sS window 1024”; fragbits:!D; dsize:0; flags:S,12; ack:0; window:1024; threshold: type both, track by_dst, count 1, seconds 60; reference:url,doc.emergingthreats.net/2009582; classtype:attempted-recon; sid:2009582; rev:3; metadata:created_at 2010_07_30, updated_at 2010_07_30;)
The order of detection of rules is also affected by priority and other conditions. However, I think the current problem will be smooth if there is a pcap for the above situation rather than just specifying the priority.
Ok, I have to clarify that my signature is usually firing an alert but sometimes the other signature is also firing an alert which is strange because it is kind of rules examination inconsistency.
I found that when the threshold limit of my signature is reached the other signature is firing an alert.
This is strange because in the documentation is written that the packets are still dropped even if the threshold limit for a signature is reached but according to the fast.log other signatures are examined while my signature is “silenced”.
Not exactly the same, but in my test environment (5.0.4) with a similar configuration, the priorities and conditions used in the rules were logged with the expected priority. (Single session perspective)
Looking at the additionally described situation, the problem seems to be that a number of sessions processed based on IP (track by src / dst), not in all cases, are temporarily blocked due to threshold. Is it right that you need continuous blocking?
Is it correct I understand? If continuous blocking is required, it would be better to use detection_filter or xbits rather than threshold.
Well, the “threshold limit” should not prevent the rule to continuously drop the packets according to the documentation: Rule actions drop (IPS mode) and reject are applied to each packet (not only the one that meets the limit condition).
In this case the only rule that should drop the packets is my priority 1 rule and any alerts coming from other rules are I guess malfunction of the alert/engine mechanism.
Yes. Above, both rules were understood as threshold: type both.
I thought about the scenario again. I hope the following is correct.
sig1 = MY source group 1
sig2 = ET SCAN NMAP -sS window 1024
IP is just an example.
At first start, obviously both rules will be written to fast.log as [Drop] at the same time. priority1 comes out first recorded. (Of course, there is an effect of priority, but other conditions that are also affected must be considered in situations such as actions such as reject/pass.)
Each signature is silenced according to the threshold condition. Based on a single session, the log sees that sig2 cannot be more than sig1. However, since counting is based on IP address, I think sig2’s log can be more than sig1’s.
And a new log occurs. sig1 is silent (Continuous blocking status as limit). sig2 is not silent. The log of sig2 should not occur because it is blocked by sig1 with high priority. However, log of sig2 occurs.
Actually I don’t understand the reason of logging both rules at the beginning.
The packet is dropped twice? It doesn’t seem logical to me.
I expect that packet dropped by one rule is not examined any more.
The first two logs were taken because both signatures had different types, but the count was 1.
Packets identified at the same time not only by suricata but also by other commercial IDS/IPS are logged multiple times regardless of alert/drop action.
In the example above, two [Drop] and two [Drop] are identified at the same time. Of course, it can be seen as the drop action of the highest sig1. However, following sig1, sig2 is also logged. So I think it may be related to logging in the same time.
I think it will help other people understand as well as me if more detailed situations are given through pcap.
So, as I understand the detection thread will detect all matching rules for a packet and log them and afterwards the verdict thread will drop the packet once.
It seems confusing that the log gets two drop alerts for a single packet but ok, if this is how it works.
Regardless of the behavior of suricata, there are situations where it is necessary to identify which signatures match, so I think it is necessary to show the whole rather than omit it.