Upcoming Snort Package Updates for pfSense-2.4.5 and pfSense-2.5.0
-
Look for some changes in the Snort package in the near future. I've posted updates for the pfSense team to review and merge.
The updates include the latest Snort-2.9.16.1 binary from upstream. However, the biggest change will be to users of Snort on pfSense-2.4.5 RELEASE. The new update will finally bring Inline IPS Mode using netmap to Snort on pfSense-2.4.5 systems! This is the same type of IPS operation currently available with Snort when using pfSense-2.5.0 DEVEL, and it's the same IPS mode available in the Suricata package. The new Inline IPS Mode will be especially useful to security admins using the OpenAppID rules where you would like to drop selected traffic to a host, but not block all traffic from that host. Inline IPS Mode lets you do that by selectively modifying the Action of rules you select from ALERT to DROP. This is most efficiently done using the SID MGMT tab options.
For users on pfSense-2.5.0 DEVEL, the new Snort package includes support for multiple host rings when the physical NIC in the netmap connection pair exposes multiple rings. Not all NIC drivers currently do this, but a few do. The multiple host rings feature is limited to FreeBSD-12.x and higher, so unfortunately the multiple host rings capability is just not available on pfSense-2.4.5 because it uses FreeBSD-11.x.
-
Hi,
thx, for the new version.
One Interface is failing to start. I get this error message in the system logs:
Sep 18 20:23:55 php: /tmp/snort_vtnet2.400_startcmd.php: The command '/usr/local/bin/snort -R _vtnet2.400 -D -q --suppress-config-log --daq pcap --daq-mode passive --treat-drop-as-alert -l /var/log/snort/snort_vtnet2.40049222 --pid-path /var/run --nolock-pidfile --no-interface-pidfile -G 49222 -c /usr/local/etc/snort/snort_49222_vtnet2.400/snort.conf -i vtnet2.400' returned exit code '1', the output was ''
Sep 18 20:23:55 snort[63989]: FATAL ERROR: Invalid pidfile suffix: _vtnet2.400. Suffix must less than 11 characters and not have ".." or "/" in the name.What can I do?
pfSense: 2.4.5-RELEASE-p1
Snort pkg: 4.1.2Thx! :)
-
@Beerman said in Upcoming Snort Package Updates for pfSense-2.4.5 and pfSense-2.5.0:
Hi,
thx, for the new version.
One Interface is failing to start. I get this error message in the system logs:
Sep 18 20:23:55 php: /tmp/snort_vtnet2.400_startcmd.php: The command '/usr/local/bin/snort -R _vtnet2.400 -D -q --suppress-config-log --daq pcap --daq-mode passive --treat-drop-as-alert -l /var/log/snort/snort_vtnet2.40049222 --pid-path /var/run --nolock-pidfile --no-interface-pidfile -G 49222 -c /usr/local/etc/snort/snort_49222_vtnet2.400/snort.conf -i vtnet2.400' returned exit code '1', the output was ''
Sep 18 20:23:55 snort[63989]: FATAL ERROR: Invalid pidfile suffix: _vtnet2.400. Suffix must less than 11 characters and not have ".." or "/" in the name.What can I do?
pfSense: 2.4.5-RELEASE-p1
Snort pkg: 4.1.2Thx! :)
First question is was this a working install on the previous Snort version, or is this a new installation, or have you added this new VLAN interface recently?
That particular error is being thrown by the Snort binary itself, I believe. It means literally what it says -- when your VLAN ID of 400 is tacked on to the package generated string for the interface PID filename, it results in a string longer than the 11-character limit.
-
Thank you for the quick answer.
It was an update. I did not change anything in the configuration, before and after the update.
In the previous version I did not have this error, there I had no problems of this kind.
-
@Beerman said in Upcoming Snort Package Updates for pfSense-2.4.5 and pfSense-2.5.0:
Thank you for the quick answer.
It was an update. I did not change anything in the configuration, before and after the update.
In the previous version I did not have this error, there I had no problems of this kind.
Okay, let me carefully compare the PHP code between this version and previous one. I did copy over the sections from the pfSense-2.5 DEVEL branch that supported Inline IPS Mode operation. Perhaps something happened there. If so, I can submit a fix in the near future.
-
Thx, for your support! :)
-
Hi @bmeeks -
Just went through the upgrade here and everything went fine. I wish, however, I could say the same for using inline mode instead of legacy mode:
- My system has 4 port Chelsio T540 10Gbit SFP+ network expansion card (for the LAN interfaces) and an Intel i210 based 1Gbit WAN interface. I was able to enable inline mode on all these interfaces (including those with VLAN's) without issues.
- Unfortunately with inline mode enabled performance really nose-dived. I used to be able to push 4Gbit/s+ between two different (LAN) network segments (both with Snort's Balanced policy enabled), using iperf3 in legacy mode. However, with inline mode enabled instead (and still using the Balanced policy) that throughput number reduced sharply to around 200Mbit/s.
- I also saw a large number of netmap transmit errors during the upload portion of WAN speed test (I have a symmetric 1Gbit fiber connection), as described here: https://forum.netgate.com/topic/138613/configuring-pfsense-netmap-for-suricata-inline-ips-mode-on-em-igb-interfaces Perhaps my system needs to have a faster CPU - it is Xeon D-1518 based which has worked quite well up now.
Ultimately, I decided to go back to legacy mode for now while I investigate these netmap performance issues further. Do you have any ideas why performance might be so bad? I do have all the offloading and flow control options disabled, but it didn't really seem to help.
I also have one quick question for you: While Snort is in legacy mode, does it matter what the IPS Policy Mode is set to under interface categories (i.e. either Alert or Policy)? Am I correct in thinking that it actually does not matter in legacy mode as long as Block Offenders is checked?
Thanks in advance for your help, I really appreciate it.
-
@tman222 said in Upcoming Snort Package Updates for pfSense-2.4.5 and pfSense-2.5.0:
Hi @bmeeks -
Just went through the upgrade here and everything went fine. I wish, however, I could say the same for using inline mode instead of legacy mode:
- My system has 4 port Chelsio T540 10Gbit SFP+ network expansion card (for the LAN interfaces) and an Intel i210 based 1Gbit WAN interface. I was able to enable inline mode on all these interfaces (including those with VLAN's) without issues.
- Unfortunately with inline mode enabled performance really nose-dived. I used to be able to push 4Gbit/s+ between two different (LAN) network segments (both with Snort's Balanced policy enabled), using iperf3 in legacy mode. However, with inline mode enabled instead (and still using the Balanced policy) that throughput number reduced sharply to around 200Mbit/s.
- I also saw a large number of netmap transmit errors during the upload portion of WAN speed test (I have a symmetric 1Gbit fiber connection), as described here: https://forum.netgate.com/topic/138613/configuring-pfsense-netmap-for-suricata-inline-ips-mode-on-em-igb-interfaces Perhaps my system needs to have a faster CPU - it is Xeon D-1518 based which has worked quite well up now.
Ultimately, I decided to go back to legacy mode for now while I investigate these netmap performance issues further. Do you have any ideas why performance might be so bad? I do have all the offloading and flow control options disabled, but it didn't really seem to help.
I also have one quick question for you: While Snort is in legacy mode, does it matter what the IPS Policy Mode is set to under interface categories (i.e. either Alert or Policy)? Am I correct in thinking that it actually does not matter in legacy mode as long as Block Offenders is checked?
Thanks in advance for your help, I really appreciate it.
The netmap device is a complicated beast and has gone through several generations of tweaks on FreeBSD. There has also just been a big change in the overall NIC hardware driver interface introduced in FreeBSD-12. That new interface is called iflib. So in FreeBSD-12, netmap functionality is handled within iflib, and NIC manufacturers create their drivers for FreeBSD-12 to use iflib. So netmap interfacing comes without any extra work by the NIC hardware drive author. None of that is the case on FreeBSD-11. There, each hardware NIC driver vendor is responsible for their own netmap intefacing. Some do it better than others.
Another complicating issue is that netmap is not designed to work well with VLANs. So when you have VLANs, netmap is not going to be a good idea for you in terms of performance. You also will need to disable any and all hardware-level VLAN options on the NIC.
Lastly, there is a different netmap interface API version in FreeBSD-11 versus FreeBSD-12. Only FreeBSD-12 supports multiple host rings in netmap. FreeBSD-11 exposes only a single pair of Tx/Rx host rings.
Netmap is really designed to rapidly move data from one physical NIC to another physical NIC, but it does not work as well when exchanging data between a physical NIC and the host stack (or the kernel itself). The implementation on pfSense needs netmap to exchange data between a NIC and the host stack.
There have been some recent commits (software updates) made to the netmap portion of the iflib code in FreeBSD-12. Some of those changes explicitly addressed netmap transmit errors. Apparently there is a bug in the iflib code related to them. However, since pfSense-2.4.5 is based on FreeBSD-11, those iflib updates will not get into pfSense-2.4.5.
So short answer to the long story above is netmap is going to be selective feature that works well for some, but not for others. And on FreeBSD-11 it is also going to be hardware dependent. And on both pfSense-2.4.5 and pfSense-2.5, if you are using VLANs, then netmap is not an ideal choice for you with the IDS/IPS.
-
@tman222 said in Upcoming Snort Package Updates for pfSense-2.4.5 and pfSense-2.5.0:
I also have one quick question for you: While Snort is in legacy mode, does it matter what the IPS Policy Mode is set to under interface categories (i.e. either Alert or Policy)? Am I correct in thinking that it actually does not matter in legacy mode as long as Block Offenders is checked?
Thanks in advance for your help, I really appreciate it.
No, that setting has no influence when the operational mode is Legacy Blocking. In fact, I really meant for that option to be hidden when an interface is running in Legacy Mode. I will need to fix that so it does not even display when using Legacy Mode on an interface.
-
@tman222
I found the change that is causing your problem. However, that code has been running over in pfSense-2.5 DEVEL for over a year, so it's weird that nobody running Snort 4.x on the DEVELOPMENT snapshots has encountered this. It's caused by the extra long name of your real interfaces with the VLAN ID tacked on the end.A typical NIC real interface name is three or four characters such as em0, bce1, etc. An interface with that name length won't hit the suffix name limit defined by the Snort binary, even when a VLAN ID is tacked on (unless the VLAN ID is really long). Your NIC real interface shows up as vtnet2, so that is a bit longer than normal. That, plus your three digit VLAN ID, is what puts you over the limit when the underscore character is included.
The code change was made in the 4.x branch of Snort to address some other issues with the older technique used in the 3.x Snort branch of passing a randomly-generated GUID as part of the PID file name. I can possibly revert back to that method, but I need to carefully review all of the 4.x PHP code to be sure I find and fix all the places that reference the PID filename.
The only thing you can do in the interim is shorten that real interface name. The only method I think you have is to shorten the VLAN ID, but that of course likely requires other changes in your system that you may not wish to undertake.
-
Hi there,
I just upgraded from 2.4.4.3 to newest build, prior to the upgrade I upgraded snort and pfblocker.
After the upgrade snort would not start and I received a similar error, Ialso noticed that the snort rules failed to download at first, but i managed to download them manually.
Sep 19 03:20:10 php /tmp/snort_bge0_startcmd.php: The command '/usr/local/bin/snort -R _bge0 -D -q --suppress-config-log --daq pcap --daq-mode passive --treat-drop-as-alert -l /var/log/snort/snort_bge022424 --pid-path /var/run --nolock-pidfile --no-interface-pidfile -G 22424 -c /usr/local/etc/snort/snort_22424_bge0/snort.conf -i bge0' returned exit code '1', the output was 'ERROR size 1464 != 1448'
my WAN adapter is named bge0 so nothing unusual and I do not have VLAN tagging enabled in pfsense as that is handled on the switch.
The only other thing i have changed apart from the upgrade was that I disabled PXE boot rom from the NIC at server boot.
This the first integrated adapter out of two on a HP dl385 G4 server dual Xeon CPU with 6gb Mem, it has run for years and never failed an upgrade.
Please let me know if you want any other info from the system.Kind Regards
Sebastian
-
@mikrosec said in Upcoming Snort Package Updates for pfSense-2.4.5 and pfSense-2.5.0:
Hi there,
I just upgraded from 2.4.4.3 to newest build, prior to the upgrade I upgraded snort and pfblocker.
After the upgrade snort would not start and I received a similar error, Ialso noticed that the snort rules failed to download at first, but i managed to download them manually.
Sep 19 03:20:10 php /tmp/snort_bge0_startcmd.php: The command '/usr/local/bin/snort -R _bge0 -D -q --suppress-config-log --daq pcap --daq-mode passive --treat-drop-as-alert -l /var/log/snort/snort_bge022424 --pid-path /var/run --nolock-pidfile --no-interface-pidfile -G 22424 -c /usr/local/etc/snort/snort_22424_bge0/snort.conf -i bge0' returned exit code '1', the output was 'ERROR size 1464 != 1448'
my WAN adapter is named bge0 so nothing unusual and I do not have VLAN tagging enabled in pfsense as that is handled on the switch.
The only other thing i have changed apart from the upgrade was that I disabled PXE boot rom from the NIC at server boot.
This the first integrated adapter out of two on a HP dl385 G4 server dual Xeon CPU with 6gb Mem, it has run for years and never failed an upgrade.
Please let me know if you want any other info from the system.Kind Regards
Sebastian
That error is not related the other poster's error in this thread. His error message clearly stated the PID suffix was too long.
While it does not say so, your error seems like it might be an MTU or snaplen thing. Is this interface by chance a PPPoE interface?
LATER FOLLOW-UP:
Okay, did some Google research and found this error can be caused by having incorrect versions of some shared libraries. If you upgraded from pfSense-2.4.4_p3, that is clearly possible.
Go to the GLOBAL SETTINGS tab and verify that the "Keep Settings After Deinstall" setting is enabled (box checked). That is the default, but check to be sure. Then go to the SYSTEM > PACKAGE MANAGER tab and then Installed Packages and delete the Snort package. Let the package removal complete. Then go to the Available Packages tab and install it again. Report back on how that works.
-
It's a normal Ethernet Link nothing special, but you are absolutely right it is not related I just found this error:
98858 FATAL ERROR: Failed to initialize dynamic preprocessor: SF_MODBUS version 1.1.1 (-2)
I will investigate and open another thread if necessary, sorry for barging in.
KInd Regards
-
@mikrosec said in Upcoming Snort Package Updates for pfSense-2.4.5 and pfSense-2.5.0:
It's a normal Ethernet Link nothing special, but you are absolutely right it is not related I just found this error:
98858 FATAL ERROR: Failed to initialize dynamic preprocessor: SF_MODBUS version 1.1.1 (-2)
I will investigate and open another thread if necessary, sorry for barging in.
KInd Regards
Follow my instructions in the "LATER FOLLOW-UP" edit I made to my previous post above. That should correct your problem.
-
@bmeeks Thank you for that!
I checked that "Click to retain Snort settings after package removal." was enabled and deinstalled and reinstalled smoothly without any errors. And it started up smoothly, like it has for 8 years now :-)
Saved my night
Cheers.
-
@mikrosec said in Upcoming Snort Package Updates for pfSense-2.4.5 and pfSense-2.5.0:
@bmeeks Thank you for that!
I checked that "Click to retain Snort settings after package removal." was enabled and deinstalled and reinstalled smoothly without any errors. And it started up smoothly, like it has for 8 years now :-)
Saved my night
Cheers.
The
pkg
utilty that FreeBSD uses to install and update packages sometimes misses updating certain shared libraries, particularly when changing base OS versions such as when updating from pfSense-2.4.4 to 2.4.5 (that was a FreeBSD operating system update). In this case, some of the Snort preprocessor libs did not get deleted and the new versions installed. -
@bmeeks said in Upcoming Snort Package Updates for pfSense-2.4.5 and pfSense-2.5.0:
I found the change that is causing your problem. However, that code has been running over in pfSense-2.5 DEVEL for over a year, so it's weird that nobody running Snort 4.x on the DEVELOPMENT snapshots has encountered this. It's caused by the extra long name of your real interfaces with the VLAN ID tacked on the end.
A typical NIC real interface name is three or four characters such as em0, bce1, etc. An interface with that name length won't hit the suffix name limit defined by the Snort binary, even when a VLAN ID is tacked on (unless the VLAN ID is really long). Your NIC real interface shows up as vtnet2, so that is a bit longer than normal. That, plus your three digit VLAN ID, is what puts you over the limit when the underscore character is included.
The code change was made in the 4.x branch of Snort to address some other issues with the older technique used in the 3.x Snort branch of passing a randomly-generated GUID as part of the PID file name. I can possibly revert back to that method, but I need to carefully review all of the 4.x PHP code to be sure I find and fix all the places that reference the PID filename.
The only thing you can do in the interim is shorten that real interface name. The only method I think you have is to shorten the VLAN ID, but that of course likely requires other changes in your system that you may not wish to undertake.
Thanks for the quick check! :)
Can you estimate how long you will need for the fixing this?
-
After upgrade to the new version, I am unsable to perform a "rule action" to modify rules within the Snort alerts. Happens with Firefox and Safari.
Edit: Happens also directly within the rules editor of the interfaces.
Is there any way to roll back to the old package version?
-
@dotsch said in Upcoming Snort Package Updates for pfSense-2.4.5 and pfSense-2.5.0:
After upgrade to the new version, I am unsable to perform a "rule action" to modify rules within the Snort alerts. Happens with Firefox and Safari.
Edit: Happens also directly within the rules editor of the interfaces.
I am unable to reproduce your problem. I changed a rule from DROP to ALERT and it showed up as "user-forced Alert" on the RULES tab.
You do understand that when making a change on the ALERTS tab that the icon for the past alert will not change. If the rule was DROP when the rule was triggered, that is the action written to the log file and thus will be the action displayed. However, it will be different on the RULES tab if you force an action change on the ALERTS tab and then go check the same rule on the RULES tab.
Lastly, the action change dialog pops up as what Bootstrap calls a Modal Dialog. It's possible that some security settings in your browser might be preventing that from displaying. Are you saying you never see the Modal Dialog box, or you see the box and make a change but it does not "stick"?
Is there any way to roll back to the old package version?
No, there is no way to roll back. The old package is removed from the repository.
-
@Beerman said in Upcoming Snort Package Updates for pfSense-2.4.5 and pfSense-2.5.0:
Can you estimate how long you will need for the fixing this?
It will be several days. Perhaps as long as a week. Once I make the change, the update has to be reviewed and approved by the pfSense team before it gets posted in the package repositories.