Question about Suricate IPS mode
-
This post is deleted! -
Here are the things that are important in my view --
-
Run your Suricata instance (or instances, if multiple ones are required) on your internal interfaces. There is zero benefit in running Suricata on the WAN in most cases. It will needlessly spin CPU cycles to analyze and block something that is most likely going to be blocked by the "default-deny" firewall rules that follow Suricata in the signal processing chain. Remember that on pfSense Suricata runs "outside" of the firewall rules (meaning Suricata sees inbound traffic on an interface BEFORE the firewall rules have been applied). So, why burden Suricata with inspecting all the "noise" typically present on the WAN interface? You don't deploy Suricata to protect the firewall. You deploy it for clients behind the firewall. It can do that job perfectly fine (and in fact, better) when running on the internal interface(s).
-
Unless you run a full MITM (man-in-the-middle) scheme to proxy, terminate, and decrypt SSL and/or TLS traffic on the firewall, then enabling rules that inspect content (for example, Layer 7 stuff) is pointless. Suricata cannot analyze encrypted traffic without MITM. And 90% or more of all network traffic now is encrypted (HTTPS, SSH, SFTP, IMAPS, SMTPS, DoT, DoH, etc.).
-
Only enable rules that protect against or mitigate vulnerabilities that actually exist in your network. For example, if you don't run public-facing web servers, then you don't need to enable web server rules. If you don't run public-facing DNS servers, then you don't need DNS server rules. If you don't run public-facing email servers, then you don't need email server rules. And in the case of email and web traffic, refer to point #2 above about encrypted traffic and the futility of analyzing that without MITM. Once you work through weeding out rules using these criteria, you should quickly realize that not much is left (if anything), so why bother?
-
Related to #3 above, be sure you understand the true purpose of the ET Info and Policy rules. They generally have no place being enabled in most home networks nor in many small business networks. At the very least, if used, the ET-Info and Policy rules should be left at ALERT and not used to block traffic.
-
The SID MGMT tab has features that can make management of rules via category name or other attributes easier than clicking icons one-by-one on the RULES or ALERTS tabs. You can find example text-based conf files on that tab that are loaded with comments explaining how things work there. The SID MGMT feature works no matter if using IDS more or either of the two IPS modes (Legacy or Inline).
Last overall comment -- and I say the following from the point of view of the Suricata package creator and maintainer for pfSense:
An IDS/IPS is mostly more trouble than it's worth on home firewalls and networks.
-
First, end-to-end encryption renders it essentially powerless to inspect content unless you do MITM. Home users rarely have the skills nor patience to do MITM.
-
IDS/IPS can be a real pain to maintain as it requires constant attention and tweaking. Any given rules update can "break" stuff that's important to household users.
-
I have not run an IDS/IPS on my home network for several years now. And back even when I did run it, I did so mostly to generate logs I could use for troubleshooting/verifying the pfSense package updates I created over the years.
-
Currently I simply fire up a virtual machine, install Suricata or Snort on it, and test things there to verify things work before posting an update for the pfSense team to merge into their packages repo.
-
These days security is best handled on the network endpoints and not on the perimeter. This is due to the widespread use of end-to-end encryption. If you do full MITM and can thus inspect packet content, then yes IDS/IPS can be valuable. The "big boy" firewall vendors out there can certainly sell you a MITM solution, but it costs big bucks and requires a lot of administration (including installing custom SSL certs on every device whose network traffic you want to inspect).
-
-
This post is deleted! -
@cyb3rtr0nian said in Question about Suricate IPS mode:
Interesting answer. I didn’t know that about the order of the signal processing chain. My reasoning is what if there is a minor programming error or glitch in the normal Pfsense firewall (not too wild an idea considering the recent CrowdStrike sys file also containing a human error), then I’d like to have multiple ‘eyes’ watching and blocking unwanted traffic (e.g. pfblockerNG, Suricata, endpoint protection etc).
Here is a diagram I've shared many times here on the forum showing the network signal path when using IDS/IPS. I'll share once more just to make it easy to find:
As you see in the image above, Suricata sees traffic directly off the NIC before that traffic hits the firewall.
As for detecting minor programming errors, how do you think Suricata can do that? No IDS/IPS could have detected the CrowdStrike issue. Similarly, any kind of exploit within FreeBSD itself (and thus, pfSense) would get fixed by Netgate before IDS/IPS rules could be created to detect it.
There really is no point in running the IPS on the WAN side. One big pain is that all local IP addresses are hidden behind NAT because the IPS sits outside the firewall rules. So, any local host IPs in alerts display as the WAN public IP. That makes it very difficult to track down a potentially infected internal host. When you run the IPS on internal interfaces, the actual internal host IPs are displayed in all alerts.
@cyb3rtr0nian said in Question about Suricate IPS mode:
Do you think if I found a way to export my current ruleset and converted that into a text-based conf file for SID Mgmt (or manually typed it over) it would cause less of a temporary load spike on the CPU? Or would it come down to the same amount of rules loading as when you decide the action manually for each rule (at the thumb section (Default / Alert / Drop / Reject)).
No, the processing overhead would not be reduced by doing that. The workload is within the Suricata binary and to some extent in the PHP processing performed by the GUI portion of the Suricata package. You would simply be creating additional work for you with no benefit.
-
This post is deleted! -
@cyb3rtr0nian said in Question about Suricate IPS mode:
@bmeeks said in Question about Suricate IPS mode:
As for detecting minor programming errors, how do you think Suricata can do that? No IDS/IPS could have detected the CrowdStrike issue. Similarly, any kind of exploit within FreeBSD itself (and thus, pfSense) would get fixed by Netgate before IDS/IPS rules could be created to detect it.
Well, I don’t mean it in that way. Suricata is of course not a software made to detect programming flaws or errors in the PfSense firewall. What I meant is, what if due to some unknown error PfSense is not able to block certain incoming traffic? Similar to how the CrowdStrike issue was unknown to the CrowdStrike team at the time.
Then it might be a good idea if your security is not only dependent on 1 layer at the WAN, but you have multiple layers that could potentially stop unwanted traffic.
What is your opinion on that?
In my view, that's a pretty long stretch. If you are protecting the networks of the NSA (National Security Agency) or the secret formula for Coke, then maybe it would be worth it
. But for a home network, I would check the tightness of my tinfoil hat 
.You can certainly run Suricata wherever you desire. I was just offering my opinion and a suggestion. I've found, in the years since I started this endeavor, that running IDS/IPS on the internal interface is better than running it on the WAN for all the reasons I mentioned earlier in this thread.
In terms of detection of threats by an IDS/IPS, the main issue this day and time is the end-to-end encryption of network traffic. It makes analysis of packet content almost impossible without MITM. The best you can do for the moment is see IP address and port info along with some SNI header stuff. But once ESNI- or more likely ECH- takes over, even that limited insight will be encrypted and hidden away from the IDS/IPS.
-
@bmeeks I think you are providing wise council, but at the same time I can understand the OP's desire. We've painted ourselves into a bit of a corner with the move to run everything through the web port and then encrypt it. In days gone by we had a lot more options to inspect and mediate risks, but now the firewall's role is mostly just coarse filtering and enforcing good traffic behavior; any hope for deeper inspection is left to the endpoint scanners. Bugs me of course that for the most part we are unable to see/know much about what the endpoint scanners actually do.
--Larry
-
This post is deleted!
