My New Discovery in The Suricata pfSense Package

My New Discovery in The Suricata pfSense Package

Hello Everyone,

This week I would like to talk about something that has concerned me for quite some time now. As many of you know I have experience with Suricata and the Suricata package for pfSense. As I’ve progressed throughout my cybersecurity class I’ve noticed that they seem to suggest running an IPS on the internal network as well on on the WAN side. Now I’ve been running Suricata on my internal network for a  long time now. However, I was thinking that allowing Suricata to BLOCK addresses that generate alerts on the internal network would be asking for problems. It would just end up blocking all the endpoints wouldn’t it? WRONG!

I seem to have forgotten that Suricata has a pass file that contains the IP addresses and networks that SHOULD NOT ever be blocked. To make me look even more foolish, by default it includes the IP addresses of all the internal networks (at least when it is installed on pfSense).

In other words, I can simply enable blocking on the internal interfaces and not face any drawbacks. I can block outbound communications with servers that Suricata thinks is compromised or insecure without fear that it will block MY hosts from  communicating with the outside world.

On a larger scale, I’m sure you could only define a certain server-only subnetwork to be in the pass file (or even more stringent individual hosts). Everything else (workstations, etc) can be left to fend for themselves. After spending some time fine tuning the rules so that the workstations can get what they need to get done (and nothing more) while you have blocking disabled. You can enable blocking and remove access for any workstations that show signs of being compromised. While keeping all of the servers communicating with the other machines on the network (because they are still part of the pass list). If one workstation steps out of line, it gets picked up by Suricata and blocked for the time frame that you specify. It’s just like you would configure it on the WAN side of things: You open ports and making your rules as stringent and specific as possible. While constantly aware that you can’t trust that someone isn’t going to exploit what you DO choose to open up on the firewall. The internet is a battle field. And IPS solutions like Suricata protect you when they detect malicious patterns, blocking communication with the rogue machine(s). They extending beyond typical NPS (Network Policy Servers) and health report checks. Protecting the rest of the network from threatening network patterns that custom-made rules NPS rules might not detect.

Another thing that I recently discovered was the addition of more pre-defined Snort IPS policies. At some point, the Suricata package on pfSense had been updated to include a mode called “Maximum Detection” which is even MORE stringent then the “Security” selection. The description of this mode reads:

Maximum Detection encompasses vulnerabilities from 2005 or later with a CVSS score of at least 7.5 along with critical malware and exploit kit rules. The Maximum Detection policy favors detection over rated throughput. In some situations this policy can and will cause significant throughput reductions.” (Suricata pfSense documentation).

This description is VERY TRUE and should NOT BE TAKEN LIGHTLY. I enabled the policy for just a few moments and it knocked my bandwidth down to the point where it couldn’t even maintain a Discord connection (when it was previously not even close to being a problem) and then it disconnected me from everything completely. Believing that it was some sort of DDOS attack. Therefore, I ask that if you retain anything from this post remember to be EXTREMELY careful if you ever decide to enable Maximum Detection mode! Your best bet is to completely disable blocking, spend A LOT of time fine tuning, and above all expect your bandwidth to fall off a virtual cliff.

Leave a Reply