Suricata Missing Rule Signatures
-
I installed a fresh version of pfSense 2.4.5-RELEASE (amd64). I installed Suricata, at the time I believe was 5.0.x.; I'm now on 5.0.2_2. I noticed I was being pinged by the following rule signatures:
ET COMPROMISED Known Compromised or Hostile Host Traffic group 30
ET COMPROMISED Known Compromised or Hostile Host Traffic group 31I went to Services > Suricata > Interfaces tab and opened the interface. I went to the Available Rules Categories section > Category > Active Rules and found the offending rule signatures. I then dropped them. Some time later, I checked the Active Rules again and noticed that the two rule signatures are no longer there. Is this normal? Any ideas why they went missing? Thank you.
-
IF you disabled them, then they will not show up in Active Rules. That's the whole point of disabling them.
Another question would be why did you disable them? Those rules are composed of lists of IP addresses of known compromised hosts (in other words, usually bad guys up to no good). You would usually want to see those alerts, especially if a LAN host is talking to an IP on one of those lists.
If you want to see those rules, you should go to the CATEGORIES tab for the interface, find the correct category (probably ET-CIARMY or ET-DSHIELD) and you should find the SIDs and the rule text in one of those.
The "Active Rules" category is actually on the INTERFACES > RULES tab and represents the entire list of currently loading Suricata rules (meaning those that are active in RAM and being used to scan traffic).
-
I'm not sure if we are using the same terminology or not but I chose to "DROP" the rule from here -
It was my understanding that if I chose drop as the rule action, the packets on that interface would be dropped [the Alerts tab] -
I have an example of this that actually works. Every signature that I chose to drop is highlighted in red except for a sporadic signature from a Category that pops up now and again.I thought maybe when Suricata updated itself, it removed those two rule signatures. Just a guess though.
-
@newUser2pfSense said in Suricata Missing Rule Signatures:
I'm not sure if we are using the same terminology or not but I chose to "DROP" the rule from here -
It was my understanding that if I chose drop as the rule action, the packets on that interface would be dropped [the Alerts tab] -
I have an example of this that actually works. Every signature that I chose to drop is highlighted in red except for a sporadic signature from a Category that pops up now and again.I thought maybe when Suricata updated itself, it removed those two rule signatures. Just a guess though.
Suricata itself will not remove rules, but the rules vendors (Snort Subscriber Rules team or the Emerging Threats team) can and do frequently update individual rules in their packages. They may remove rules, edit their content, or add new rules. They may also decide to leave a given rule in their package but comment it out so that it is not "enabled". Perhaps that happened with the rules you are asking about. You can get the SID from previous alerts (if you still have access to them in the log) and look up the SID on the vendor's site. The rules you mentioned would have come from Emerging Threats.
Reading your post again leads me to think maybe you are asking me another question. Did you, in the recent past, make a change to the action for these rules? From your description I could also theorize that you may have a second "zombie" Suricata process running on that interface. If so, that instance would not be controllable from the GUI and thus any changes made to rules would not impact that zombie process. But the zombie process can still generate alerts. If this is your issue, then you will need to stop Suricata using the GUI icons on the INTERFACES tab. Then open a shell prompt on the firewall and issue the following command to see if any running Suricata process still shows up --
ps -ax | grep suricataIf you still see a running process, note its process ID <pid> and kill it using this command --
kill -9 <pid>Then go to the GUI and restart your Suricata process from there.
-
I can see the rules vendors updating their rules which I would guess is why those two signatures were removed.
As far as a zombie Suricata process running, I'm running Suricata on three interfaces and I get the following from the command:
Ss 0:18.26 /usr/local/bin/suricata --netmap -D -c /usr/local/etc/s
Ss 0:18.60 /usr/local/bin/suricata --netmap -D -c /usr/local/etc/s
S 0:00.00 sh -c ps -ax | grep suricata 2>&1
S 0:00.00 grep suricata
Ss 0:17.41 /usr/local/bin/suricata --netmap -D -c /usr/local/etc/sIt looks like Suricata is running on three interfaces; no zombie Suricata processes.
-
@newUser2pfSense said in Suricata Missing Rule Signatures:
I can see the rules vendors updating their rules which I would guess is why those two signatures were removed.
As far as a zombie Suricata process running, I'm running Suricata on three interfaces and I get the following from the command:
Ss 0:18.26 /usr/local/bin/suricata --netmap -D -c /usr/local/etc/s
Ss 0:18.60 /usr/local/bin/suricata --netmap -D -c /usr/local/etc/s
S 0:00.00 sh -c ps -ax | grep suricata 2>&1
S 0:00.00 grep suricata
Ss 0:17.41 /usr/local/bin/suricata --netmap -D -c /usr/local/etc/sIt looks like Suricata is running on three interfaces; no zombie Suricata processes.
Correct. If you are running Suricata on three interfaces you can expect to find three running Suricata instances. A "zombie" would have shown up as a complete duplicate line of one of those, so for example two identical lines. In that case you would know you have a "zombie". Those can happen in some rare situations due to the way some events can cause pfSense to issue several "restart all packages" commands in quick succession.
-
Thanks for the great explanations Bill. I appreciate your time.
