Suricata does not block/drop packages in inline mode
-
I have switched to PFSense 2.3 and turned on "inline mode".
Up to now while running "legacy mode" there had been some alerts resulting in "blocked" packages nearly every day. I had pfsense lock them out for 1 hour or - if it had been false positive and someone in the LAN needed it - put them to the suppress list.
As far as I have understood the "inline mode" there are no "blocked" IPs any more cause the suspicious packages are "dropped" directly at first sight.
But is the right behaviour of pfsense not to mark those dropped packages as "red" in the "alerts" view? Cause since switching to 2.3 and inline mode I have not seen any of those red marks.
-
Did you configure a drop sid file for the rules you want to drop on the SID Mgmt tab?
See the see the dropsid-sample.conf for examples.
-
This post should help:
https://forum.pfsense.org/index.php?topic=108365.msg603749#msg603749
-
I have switched to PFSense 2.3 and turned on "inline mode".
Up to now while running "legacy mode" there had been some alerts resulting in "blocked" packages nearly every day. I had pfsense lock them out for 1 hour or - if it had been false positive and someone in the LAN needed it - put them to the suppress list.
As far as I have understood the "inline mode" there are no "blocked" IPs any more cause the suspicious packages are "dropped" directly at first sight.
But is the right behaviour of pfsense not to mark those dropped packages as "red" in the "alerts" view? Cause since switching to 2.3 and inline mode I have not seen any of those red marks.
The other two posters are correct. Inline mode is not at all like the old legacy mode. The old legacy mode blocked on any alert action. That is not really how an IPS should work. It should just alert on many things and drop only select bad things. So the old way was not ideal, although it was easy for beginners as they could just say "block offenders" and every single rule generating an alert would also cause a block.
True inline IPS mode requires rule action keywords be changed from "alert" to "drop". The action is the very first word in the rule syntax. So to make changing rules easier, a new dropsid feature was added to the SID MGMT tab. The other posters provided links to some how-to examples. The new inline mode is better for two reasons. First, you can now have pure alerts and be more selective with actual drops. Second, the new mode does not "leak packets" like the legacy mode does due to the use of libpcap in legacy mode.
Bill
-
Ah, ok, thanks to all of you for lightning up that thing to me ;)
I´m afraid I now have to get a little deeper in which are "serious" threats and which are not.
Thanks again.
-
After following your hints, it seems to run as it should now.
Alerts which indicate blocked packages are highlighted red under "Alerts entries".
But there are no entries in the "block.log"-file (it´s still empty). Or is that the supposed behaviour not to log them there?
-
But there are no entries in the "block.log"-file (it´s still empty). Or is that the supposed behaviour not to log them there?
Unfortunately this is the default behavior of the Suricata binary when running in Netmap IPS mode. I don't know why they decided to do it that way, but the binary does not log dropped packets in the block.log file when running in IPS mode (at least it does not with Netmap). Instead, it writes the action to the alerts.log and puts the "drop" action in there.
Bill
-
Ok, thanks for your answer, although I do not really understand why blocked packages are nit logged.
Another thing again: on a second machine with pfs 2.3 blocked packages are neither marked red nor are being blocked in the same amount as it had been blocked before. While there had been about 10-20 blocked packages per day on that machine in legacy mode, now there is 0-1 blocked package per day in inline mode. And, in addition, this little alerts are not marked red.
The only difference between those two machines is that the second machine (alerting nothing) was updated to 2.3, while the first was a clean install with imported settings from the former version.
-
Ok, thanks for your answer, although I do not really see the reason why blocked packages are not logged.
Another thing again: on a second machine with pfs 2.3 blocked packages are neither marked red nor are being blocked in the same amount as it had been blocked before. While there had been about 10-20 blocked packages per day on that machine in legacy mode, now there is 0-1 blocked package per day in inline mode. And, in addition, this little alerts are not marked red.
The only difference between those two machines is that the second machine (alerting nothing) was updated to 2.3, while the first was a clean install with imported settings from the former version.
edit: I have already reinstalled the surricata package, made no difference
edit2: I did a factory reset of pfs in the morning and imported the old settings: no difference, still showing just very few alerts, not marked red, with no errors in the sys- and surricata-logs
edit3: even a clean install with imported settings did not make any change. Does the following log entry in suricata help:
<warning>– [ERRCODE: SC_ERR_EVENT_ENGINE(210)] - can't suppress sid 2200029, gid 1: unknown rule</warning>
-
Ok, thanks for your answer, although I do not really see the reason why blocked packages are not logged.
Another thing again: on a second machine with pfs 2.3 blocked packages are neither marked red nor are being blocked in the same amount as it had been blocked before. While there had been about 10-20 blocked packages per day on that machine in legacy mode, now there is 0-1 blocked package per day in inline mode. And, in addition, this little alerts are not marked red.
The only difference between those two machines is that the second machine (alerting nothing) was updated to 2.3, while the first was a clean install with imported settings from the former version.
edit: I have already reinstalled the surricata package, made no difference
edit2: I did a factory reset of pfs in the morning and imported the old settings: no difference, still showing just very few alerts, not marked red, with no errors in the sys- and surricata-logs
edit3: even a clean install with imported settings did not make any change. Does the following log entry in suricata help:
<warning>– [ERRCODE: SC_ERR_EVENT_ENGINE(210)] - can't suppress sid 2200029, gid 1: unknown rule</warning>
Have you verified that your rules packages (Emerging Threats, Snort VRT or whatever) are actually downloaded and installed on the machine? That error message means exactly what it says – there is no rule loaded with the SID. So either the rule vendor removed the rule or disabled it, or your complete rules package is not downloaded and that firewall is not running all the rules you think it is.
Go to the UPDATES tab and click the FORCE button to forcibly download all the enabled rules again. Let it say on that page downloading and updating until the pop-up modal dialog auto-closes. Do not navigate away from the page until that dialog closes. If the dialog does not auto-close after say 4 or 5 minutes, then you can close it and look in the update logs to see if any errors are being posted.
Bill
-
I did a "force" again (although I had done that several times before during the past days): no change, the error in the suricata-log shows up again and no alerts concerning dropped packages ares shown in suricata.
-
I finally got it working ;D ;D ;D
As I have read in another posting, someone succeeded in deactivating all rules, started suricata, then activated the rules and restarted suricata again. Up from that point, suricata started showing alerts at least.
Afterwards I let suricata rebuild the "Interface SID Management File Assignments", that´s when suricata started blocking packages and showing them red in the alerts view.
So maybe there had been some incompatible rules or settings in the older pfs-version-data I imported in 2.3.
Everything seems to be fine now.
Thanks for your help.