Suricata Still adds IP's to snort2c table and blocks for disabled rules?
-
As the title states, I've disabled an entire rule set. I stopped suricata on the interface in questions, I cleared the snort2c table, and i reset the states and the alerts for the interface then i restarted suricata on the interface.
As soon as i start it back up it shows traffic that matches the rules, it shows that the rule is disabled, but it also shows that the IP has been added to snort2c!
When i go to the snort2c table, it is indeed on the list.
Why?
How do i get rid of rules I don't want?
-
As the title states, I've disabled an entire rule set. I stopped suricata on the interface in questions, I cleared the snort2c table, and i reset the states and the alerts for the interface then i restarted suricata on the interface.
As soon as i start it back up it shows traffic that matches the rules, it shows that the rule is disabled, but it also shows that the IP has been added to snort2c!
When i go to the snort2c table, it is indeed on the list.
Why?
How do i get rid of rules I don't want?
Do you have the Auto-flowbits option enabled? If so, that could be where the rules are getting turned back on. Which particular rules are firing that you have disabled? Second question is are the alerts coming from Snort VRT rules or Emerging Threats rules?
You can grep the suricata.rules and flowbit-required.rules files in the interface's subdirectory to see if the rules in question reside in either file. You will find them in /usr/local/etc/suricata/suricata__xxxx_/rules (where the "xxxx" will be a string containing the physical interface name and a UUID number). If in the flowbit-required.rules file, then that's how the rules are getting "re-enabled". Before you disable them, though, you need to read up on flowbits and learn their importance.
Final possibility, assuming none of the above is true, you may have two instances of Suricata running on the same interface. That can sometimes happen. Examine the output of this CLI command –```
ps -ax | grep suricataBill -
Thank you, it ended up working after a system reboot when i updated to the latest 2.4.0.
If I run into it again, I'll definitely run through those steps!
-
Thank you, it ended up working after a system reboot when i updated to the latest 2.4.0.
If I run into it again, I'll definitely run through those steps!
If a reboot cured the problem, then it was most likely two instances running on the same interface. When that happens, one is essentially a sort of zombie process that will be using the config file that was in place when that binary instance started. The GUI will have no influence over a zombie instance, so any changes you make won't affect the zombie process that has become "detached" from the GUI.
All the GUI does on pfSense is create the suricata.yaml configuration file for the binary to use and then sets up a few necessary sub-directories for logging and such. The GUI then launches the binary. After that, anything you do is signalled to the running binary via the PID file. However, there is also a shell script that the firewall will use during boot and when executing a package resync command. That shell script will start Suricata using the last saved suricata.yaml file. The shell script will normally shutdown any running Suricata processes and then restart them when it is invoked. However, there are some edge instances where the shell script gets called multiple times in quick succession. When that happens, it winds up launching two (any maybe more) instances for each configured interface. That's how you can get the zombie processes created that are using an old version of the config file and the rules, and changes you make in the GUI get sent to one of the running instances but not the others.
Bill
-
Thank you that's very good to know for the future!
