PFBlocker and SNORT issues after upgrade from 22.05 to 23.01

depam

Hi Guys,

I am running SG-3100 and upgraded from 22.05 to 23.01. I am experiencing issues with PFBlocker and Snort after upgrade.
Below logs shows as below:

{code}

Filter Reload

There were error(s) loading the rules: /tmp/rules.debug:423: macro 'pfB_Asia_v4' not defined - The line in question reads [423]: block in quick on $WAN reply-to ( mvneta2 10.10.8.254 ) inet from $pfB_Asia_v4 to any ridentifier 1770009040 label "USER_RULE: pfB_Asia_v4 auto rule" label "id:1770009040"
@ 2023-02-16 13:35:03
There were error(s) loading the rules: /tmp/rules.debug:429: macro 'pfB_Asia_v4' not defined - The line in question reads [429]: block in quick on $WAN reply-to ( mvneta2 10.10.8.254 ) inet from $pfB_Asia_v4 to any ridentifier 1770009040 label "USER_RULE: pfB_Asia_v4 auto rule" label "id:1770009040"
@ 2023-02-16 13:35:15
There were error(s) loading the rules: /tmp/rules.debug:429: macro 'pfB_Asia_v4' not defined - The line in question reads [429]: block in quick on $WAN reply-to ( mvneta2 10.10.8.254 ) inet from $pfB_Asia_v4 to any ridentifier 1770009040 label "USER_RULE: pfB_Asia_v4 auto rule" label "id:1770009040"
@ 2023-02-16 13:35:26
There were error(s) loading the rules: /tmp/rules.debug:429: macro 'pfB_Asia_v4' not defined - The line in question reads [429]: block in quick on $WAN reply-to ( mvneta2 10.10.8.254 ) inet from $pfB_Asia_v4 to any ridentifier 1770009040 label "USER_RULE: pfB_Asia_v4 auto rule" label "id:1770009040"
@ 2023-02-16 13:35:41
There were error(s) loading the rules: /tmp/rules.debug:429: macro 'pfB_Asia_v4' not defined - The line in question reads [429]: block in quick on $WAN reply-to ( mvneta2 10.10.8.254 ) inet from $pfB_Asia_v4 to any ridentifier 1770009040 label "USER_RULE: pfB_Asia_v4 auto rule" label "id:1770009040"
@ 2023-02-16 13:43:22

PHP errors

PHP ERROR: Type: 1, File: /usr/local/www/pfblockerng/pfblockerng.php, Line: 1980, Message: Uncaught TypeError: sort(): Argument #1 ($array) must be of type array, null given in /usr/local/www/pfblockerng/pfblockerng.php:1980
Stack trace:
#0 /usr/local/www/pfblockerng/pfblockerng.php(1980): sort(NULL, 2)
#1 /usr/local/pkg/pfblockerng/pfblockerng_install.inc(40): pfblockerng_get_countries()
#2 /etc/inc/pkg-utils.inc(781) : eval()'d code(1): include_once('/usr/local/pkg/...')
#3 /etc/inc/pkg-utils.inc(781): eval()
#4 /etc/inc/pkg-utils.inc(899): eval_once('include_once('/...')
#5 /etc/rc.packages(76): install_package_xml('pfBlockerNG-dev...')
#6 {main}
thrown @ 2023-02-16 13:38:16

And snort isn't stable and keeps going down but not sure where to check the logs

bmeeks

A old regression has resurfaced in Snort with the move to FreeBSD-14 CURRENT and a likely update to some of the development environment tools.

A Redmine Issue has been opened for this. You can check out the ticket and details about the cause here: https://redmine.pfsense.org/issues/13958. There is nothing you can do on your firewall to make any difference. The problem is within the Snort binary itself. You will need to disable Snort until a fix is posted for the SG-3100.

depam

@bmeeks Thanks for the info. Will have to roll back i guess.

bmeeks

@depam said in PFBlocker and SNORT issues after upgrade from 22.05 to 23.01:

@bmeeks Thanks for the info. Will have to roll back i guess.

Yeah, the SG-3100 has been a Snort problem child forever. 32-bit ARM CPUs are finicky due to their difference in support of unaligned memory access. All Intel and AMD CPUs since forever have just automatically fixed up that kind of access at runtime by doing the required bit-shifting in hardware to mimic single-byte addressing. This makes the code execution slightly slower, but at least it works without aborting. The ARM 32-bit CPU does that for most of its instruction opcodes, but not for two of them. And it's those two that the llvm compiler loves to use when optimizing the executable code (for faster execution).

The ultimate root cause of these memory alignment issues is poorly written C source code, but since Intel is dominant in CPUs, and Intel CPUs do automatic runtime fix-up of any memory access alignment issues, there is no incentive for the creators of the bad C source code to change it. In the case of Snort, there are many places in the code where such unaligned access can happen.

depam

@bmeeks Do you happen to know if there is any workaround of some sort? Even manual intevention of package installation to get the IDS/IPS up and running on 23.01 SG-3100. Thanks in advance.

bmeeks

@depam said in PFBlocker and SNORT issues after upgrade from 22.05 to 23.01:

@bmeeks Do you happen to know if there is any workaround of some sort? Even manual intevention of package installation to get the IDS/IPS up and running on 23.01 SG-3100. Thanks in advance.

No, it's not possible. The root cause is the way the compiler of the ARM code for the 32-bit ARM CPU in the SG-3100 generates the Snort binary. It creates it with some CPU opcodes that do not perform automatic runtime fixup of unaligned memory access. There are many places in the Snort code where unaligned access can occur, and several of them are "data related" which means whether or not they occur is determined by the particular value of some data at the moment. Unaligned memory access is not an issue on Intel or AMD CPUs because those processors have always performed automatic fixup of such a problem at runtime. Because the bad C code in Snort always works on Intel platforms, and Intel (and AMD is the same architecture) dominates, there was never any incentive for the Snort team to address the code shortcomings.

There is absolutely nothing you as the user can do, and nothing pfSense on the machine can do, to make it work. Hopefully one of the Netgate developers can figure out why the hack put in place within the FreeBSD 12.3-STABLE compiler to avoid the problem is now failing on FreeBSD 14-CURRENT.

Just so you understand, Snort (and Suricata as well) consists of two separate pieces. You interact with a GUI part written in PHP, but all the PHP code does is create the snort.conf file that tells the Snort binary executable (which runs as a service in pfSense) what to do. The problem is in the binary executable code.

depam

@bmeeks Thanks. I hope it gets sorted out by Netgate. I know a lot of SG-3100 users are on soho and the support for Snort is one of the reason they are using it in the first place.

bmeeks

@depam said in PFBlocker and SNORT issues after upgrade from 22.05 to 23.01:

@bmeeks Thanks. I hope it gets sorted out by Netgate. I know a lot of SG-3100 users are on soho and the support for Snort is one of the reason they are using it in the first place.

My advice for the future is always buy an Intel-compatible CPU. I've seen too many little weird things with ARM and other processors. Intel is still the dominant CPU, and so code is written for it and tested on it. These other smaller market-share processors are popular in special-purpose hardware (like firewall appliances), but they bring a lot of potential baggage. This Snort issue is one such example. And Suricata on the SG-3100 can have the same issue when the stars and planets align just right.

depam

@bmeeks Got it. Thanks a lot