Pfsense has 40 percent free ram and 10 percent swap usage
-
The most immediate benefit I noticed right away in terms of differences between inline and legacy is that inline doesn't totally kill a machines ability to work just because it did one thing wrong, where as with legacy you would be offline for 15 minutes for every alarm triggered. Less PITA.
-
So, when I built my private hardware pfsense years ago I insisted on using Intel Server nics. So, After playing for a few days with my VM network (which is an actual every day used set of small servers), I felt confident to turn it on in the remote hardware pfsense I use pretty much 24/7 for VPN and file storage etc. Works perfectly. I'm very glad I installed those "overkill" network cards now. Other than sucking down half the ram on the box, and finally pushing the cpu above idle, I've noticed nothing odd. Its watching 3 LAN NICs and has no problem maxing out the ISPs bandwidth.
I've heard lots of chatter here and there about how pfsense doesn't work with suricata well. At this point, I can say for sure it works. I think its just a matter of having compatible hardware. Its not even breaking on my pitiful little VM I starved for resources. Working like a champ.
-
I get it. I'm just trying to keep the language simple. For my purposes, dropped is same as discarded, although I like your explanation.
So, the answer then is that setting only impacts legacy mode. OK. I know you are going to note things in the GUI eventually.
Specifically I was initially worried to see the same IPs showing up in alerts again in less than 15 minutes, but now I understand.
So, inline is actually a bit less severe and less of a blunt instrument since it doesn't kill an IP for a while but rather evaluates every new packet against the rules?
Very cool. Thanks again.
Since I've never had this working properly on hardware I am still getting used to what to expect. So far so good.
You have it now. Inline is like a surgeon's scapel evaluating each packet and either passing that one packet or discarding it (a drop). Legacy is more blunt, it simply puts the offending IP address in a pre-configured pf firewall table and that's it. From that point on, all traffic from that IP is blocked until the IP is removed from the pf firewall table.
The key benefit of Inline IPS Mode is that no packet leakage occurs. Suricata will queue up and buffer the session until it has enough packets to analyze against the rule, and if the rule triggers and the action is drop, the whole queued up session is just dropped from Suricata's memory like it never happened. The firewall and the rest of pfSense never see it. Legacy Mode, on the other hand, is getting only copies of those packets as they exit the NIC on the way to the kernel. So the original packets continue on to the firewall and the target host. Only later, after Suricata evaulatues enough traffic, will the firewall block be added and the existing states cleared (if you enable that option when turning on Legacy Mode blocking).
Bill
-
I get it. I'm just trying to keep the language simple. For my purposes, dropped is same as discarded, although I like your explanation.
So, the answer then is that setting only impacts legacy mode. OK. I know you are going to note things in the GUI eventually.
I have some of the controls within the Blocking Configuration section on the INTERFACE SETTINGS tab hide themselves depending on what is selected in the blocking mode drop down. I probably do need to put something on the GLOBAL SETTINGS tab in the help hint text for the Clear Blocked Hosts control. I can't hide that setting, though, because folks may have different blocking configurations on different interfaces (like WAN using Inline IPS but LAN using Legacy, or some other variation).
Bill
-
I find it to be much more forgiving to use than legacy mode so far. It causes so little trouble I wasn't sure it was working!
However, I've checked it by doing things I shouldn't and its working. Pinging tor exit nodes, for instance, is a very simple way for me to be sure that not only does it seem to be working, but it is in fact working. I was very happy to see it play nice with intel NICs that were not even very expensive on real hardware vs virtual.
I think this is going to become "standard" for any decent firewall.
I think you are on the right track with the "hints". Just something for us not-experts so that we know what to expect.
-
The most immediate benefit I noticed right away in terms of differences between inline and legacy is that inline doesn't totally kill a machines ability to work just because it did one thing wrong, where as with legacy you would be offline for 15 minutes for every alarm triggered. Less PITA.
The time before blocks are cleared in Legacy Mode is configurable to one of several intervals all the way up to NEVER. I recommend something between 15 minutes and 1 hour, but there some users here who think NEVER is good. I don't agree with that for the very reason you described. One mistake in configuration by enabling a "too sensitive rule" and you are locked out of the firewall perhaps until you reboot it! Shorter blocks clearing intervals help you recover painlessly from shooting yourself in the foot.
Bill
-
When using legacy mode, my thinking was that 15 minutes is enough to make doing something bad to my servers so inconvenient and slow that the person would just give up and move on to easier targets. Now, with inline mode I've had to rethink that. The way its working now is much less "all or nothing". Much less of me DDOSing myself. A major improvement.
-
It is still running great, but as I run this I realize there is a small feature that would be nice to have.
Right now you can suppress rules, which gets the noise off your alerts page, but also causes the rule to not drop anything.
For things that really do need to be dropped, but at the same time are so constant that you don't want to look at them all the time in your log, it would be nice to be able to supress the alert, but not supress the "drop".
That way, I could see if something new was chewing on the firewall without it being lost in a zillion alerts you know to expect already.
An example of this is my son has a Chinese phone, and it is forever trying to contact Chinese servers and Chinese servers are forever trying to ping it.
Its locked down. I want it to keep doing its thing and dropping those packets, but I want that alert out of my face.
Maybe a bridge too far? Not sure.
However, it is working great.
-
It is still running great, but as I run this I realize there is a small feature that would be nice to have.
Right now you can suppress rules, which gets the noise off your alerts page, but also causes the rule to not drop anything.
For things that really do need to be dropped, but at the same time are so constant that you don't want to look at them all the time in your log, it would be nice to be able to supress the alert, but not supress the "drop".
That way, I could see if something new was chewing on the firewall without it being lost in a zillion alerts you know to expect already.
An example of this is my son has a Chinese phone, and it is forever trying to contact Chinese servers and Chinese servers are forever trying to ping it.
Its locked down. I want it to keep doing its thing and dropping those packets, but I want that alert out of my face.
Maybe a bridge too far? Not sure.
However, it is working great.
Unfortunately that's not a feature supported by the underlying binary source code of Suricata (dropping but not alerting). To most folks that would be counter-intuitive any way. You would have traffic being blocked but have no idea why it was blocked or by what if it was not logged.
If you want to do detailed log analysis and have a high traffic network, you should consider one of the third-party open source tools out there that can accept EVE JSON logs from Suricata. The alerts/drops get stored in a MySQL or equivalent database on a separate server and then analytics packages are run against the data to produce nice charts and reports with all sorts of filtering options available.
Bill
-
I could probably filter out a list of known offenders to see what is new with a simple script. Thanks.