Suricata Not Blocking legacy mode

everfree · Sep 2, 2019, 4:41 AM

Block Both

bmeeks · Sep 11, 2019, 5:37 PM

@everfree :
I replicated a bridge setup that I think is like yours and I still could not reproduce your issue using the previous two IP addresses I tested with (158.85.63.185 and 4.16.74.232).

On your live firewall, have you actually checked the snort2c table to verify if the IP addresses that should be blocked are in fact missing from there as well? You check this under DIAGNOSTICS > TABLES and choosing snort2c as the table to display.

I agree that in your screen capture above, the "non-highlighted" IP addresses should indeed have been blocked, but apparently they were not. Or at least the PHP code in the GUI thinks they are not and thus is not showing the red X beside them.

I really have no idea what could be happening. Your firewall has a lot of traffic if your realtime load is 2-3 Gbps. I'm beginning to wonder if it is a loading issue. I have not been able to reproduce your problem in my test setup, but I cannot simulate that level of load in my test lab. Suricata being a multithreaded application makes debugging more difficult. There is also a possibility that the internal signal flow within the Suricata binary is not working correctly under load. There are two separate modules at work. One is stock from upstream and that module does the logging (writes the alerts to a specified log file). The other module is a custom output plugin I wrote that is supposed to get a copy of every alerting packet. Maybe that is not always happening under heavy load. Maybe the logging module gets the packet but my blocking module (the custom output plugin) does not get a copy of every single packet and thus misses the opportunity to block the traffic. Just theorizing here on possibilities. I will keep looking into the binary code to see if I spot someplace a problem like you are experiencing could creep in.

everfree · Sep 19, 2019, 7:07 AM

where is the code about the custom output plugin??

I don't think it is a loading issue, because I can use it before.

bmeeks · Sep 19, 2019, 11:59 AM

@everfree said in Suricata Not Blocking legacy mode:

where is the code about the custom output plugin??

I don't think it is a loading issue, because I can use it before.

The patch *.diff file is here: https://github.com/pfsense/FreeBSD-ports/blob/devel/security/suricata/files/patch-alert-pf.difflink text.

If you want to examine the final patched source code, download a copy of the Suricata binary source tree version 4.1.4 from here. Untar that archive into an empty directory, then download the patch-alert-pf.diff file linked above and apply the patch to the source code tree. After doing all that, the source for the custom blocking plugin will be in the src/alert-pf.c and src/alert-pf.h files.

I've examined the code in the custom blocking plugin, and I have yet to find a way for the problem you describe to manifest itself. With me using your exact Pass List values, that should have reproduced the problem if it was something directly within the custom module. The fact it did not leads me to theorize it might be a load issue. Perhaps, under heavy load, my custom blocking plugin is not really seeing all the traffic. The alert log is taken directly from Suricata's alert-fast log module's output. So it would be theoretically possible for an alert to get logged but no block happen if the logging module saw the alert but my custom blocking plugin did not.

bmeeks · Sep 20, 2019, 12:26 PM

@everfree said in Suricata Not Blocking legacy mode:

where is the code about the custom output plugin??

I don't think it is a loading issue, because I can use it before.

But there have also been quite a number of changes within other parts of the Suricata binary over the last few years upstream that are not directly part of the custom blocking plugin used on pfSense. This makes it hard to nail down what might be the culprit; especially when the problem is not reproducible in a test environment.

everfree · Sep 23, 2019, 3:13 AM

This post is deleted!

nn14 · Sep 23, 2019, 4:06 AM

This post is deleted!

nn14 · Sep 23, 2019, 9:33 AM

Hi bmeeks:
Do you know how to confirm that the custom blocking plugin may lose alerts?

bmeeks · Sep 28, 2019, 1:26 AM

I have submitted a Pull Request with the custom blocking module changes that should hopefully address the "no blocks" issue identified in this thread. I've asked that the pull request be merged this Monday, September 30th. So a new Suricata package (version 4.1.5) should show up for the pfSense-2.4.4_p3 RELEASE branch sometime Monday.

everfree · Sep 30, 2019, 1:03 PM

Yes, it works, it's back back back.
thanks. bmeeks.

bmeeks · Sep 30, 2019, 1:09 PM

@everfree said in Suricata Not Blocking legacy mode:

Yes, it works, it's back back back.
thanks. bmeeks.

You're welcome. I'm still puzzled why that variable was not always getting set to NULL in the SCRadixFindKeyBestMatchIPv4() function when the IP was not in a Pass List. I need to study that function carefully to see what's going on. Might be a bug within that code that needs reporting upstream.

nn14 · Sep 30, 2019, 1:09 PM

Dear bmeeks:
We appreciate your effort to solve this issue,
Thanks for your significant contribution to this community.
Thank you!

everfree · Sep 30, 2019, 10:27 PM

still have some loss, sad >.<

everfree · Nov 24, 2019, 11:46 AM

Still waiting, hope it will be fixed.