I’ve had this off and on problem with Suricata running on pfSense where it will block IPs that exist on the pass list. I’ve researched and posted in the Netgate forums but have had limited success in permanently resolving the error. In pfSense I restart the entire Suricata service as well as each interface. I can check and see the IP is indeed in the pass list. If I (on the most recent one with the problem) run
Then I can see the IP in the list (it’s actually the IP/32 since that’s how it’s put it in case I need to expand the IP range). What else can I check or try? Yesterday I disabled the rule entirely so when it happened this morning it wound up disabling a whitelisted IP using a disabled rule. It just feels like there is a disconnect between pfSense and Suricata. In the Alerts page on pfSense it even has the indicators that the rule is disabled and the alerts for it suppressed.
So, I’m turning here. Where can I go on the CLI to try to understand what is happening? Thanks for any help!
pfSense uses a version of Suricata that is extended with some extra functionality. I believe the passlist you mention is one of those things. So I think the best thing to do would be to go through the pfSense support channels.
Thank you for your reply. I started top and then stopped the service through the pfSense gui. It spun for a bit but then showed that it was still running. The processes still showed in top as well. I stopped it again (also through the gui) and after a minute or so it finally showed that it stopped and all the processes cleared out of top. I then started it again (through the gui) and it hasn’t blocked again, yet. I’m not exactly sure what that indicates but it could be that telling in telling it to restart at some point it wound up starting a new process without successfully stopping the old one first.
Can you post a screenshot from the pfSense GUI showing what this whitelisting looks like? I suspect it may be one of the pfSense specific extensions. Or perhaps it’s simply using a special rule file with pass rules or something.
You may be able to find what you are looking for, here: https://forum.netgate.com/topic/154984/suricata-unwanted-blocking
The pass list is an imported alias so there isn’t anything to show on the process. This is the page you select it (we are using a custom theme so it’ll look a little different than the default if you try to compare to other things)
In the filesystem it looks like a text file under the format of: /usr/local/etc/suricata/suricata_[ID]_[NIC]/passlist
Once it’s in there, though, you need to reload the interface for it to take the changes.
It must get loaded into Suricata when it is started. Is there a way to look at all of the IPs that are currently set to “pass” or “ignore” by the engine?
So, the belief is that there were multiple Suricata processes that were running at the time. The GUI locks on to the PID of the first process. If other processes also load then they have their own PIDs. When reloading or restarting the service or the interface it only does the it on the PID it is aware of. It seems the solution would be to:
Stop the service via the GUI.
Check for Suricata processes in top
If they are there, run “ps-ax | grep suricata”
Find the PID of the process and kill it with "kill -9 "
Verify all the Suricata processes are stopped
Start the service via the GUI.
Verify the processes are running on the individual interfaces.
Hopefully this helps someone who comes along after me, or helps me in the future when I forget.
Is there another option to exclude static IP’s on Suricata? I am trying to exclude Xbox devices from being scanned completely can you assist with step by step?
Guys and Girls: the Pass List feature for Suricata on pfSense is a “pfSense-only” thing. It stems from the use of a custom blocking plugin compiled into Suricata and used ONLY on pfSense. So if you have any Suricata questions when running it on the pfSense firewall distro, you should first try posting over on the pfSense (Netgate) forum for IDS/IPS here: https://forum.netgate.com/category/53/ids-ips. I am the developer and maintainer for the Suricata package on pfSense, and I frequent the forum linked.
For your issue, I suggest creating a custom PASS rule containing the IP address (or addresses) of your Xbox device(s). The default behavior for Suricata is to process PASS rules first (meaning rules with “pass” as their action), and any traffic matching a PASS rule is immediately removed from further scrutiny by Suricata.
Of course this means that NO traffic for your Xbox devices will be checked. In effect, they turn into fully trusted devices. Are you sure that’s what you want? Perhaps examining which particular rules are firing that might be false positives, and suppressing just those rules, is a better approach. You can disable those particular rules, or you can use the thresholding feature to suppress alerts from those rules when the source and/or destination IP address matches that of your Xbox device.
Thanks for your quick response. I added two pass rules, but some reason it did not work. I went under alert and block and could not find internal static IP address anywhere, but when I uninstall it it works without a hitch. I wanted to either you Suricata or at least worst case scenario snort which I haven’t tried yet, but i do have a snort subscription. I done pretty much all my modifications from YouTube, and training videos, but one of the YouTube nor training paid videos I’ve purchased covered this detail on Suricata. Will try your other suggestion and get back to you.
Thanks!