Snort v3.2.9.9 Package Update - Release Notes (for pfSense-2.4.4 RELEASE)



  • pfSense-pkg-snort-3.2.9.9
    This update for the Snort package on pfSense-2.4.4 adds support for the latest v2.9.14.1 snort binary. It also adds one new feature and corrects two issues.

    NOTE: this Snort GUI package version (v3.2.9.9) is released for pfSense-2.4.4-RELEASE users only.

    New Features:

    1. The physical real interface is now shown in parentheses along with the friendly interface name when displaying interfaces on the INTERFACES tab and within drop-down selectors on the INTERFACE SETTINGS and ALERTS tabs.

    2. Add support for the latest snort-2.9.14.1 binary from upstream.

    Bug Fixes:

    1. Remove an unnecessary write_config() call when performing the scheduled cron task to update rules to prevent spamming the ACB (Auto Config Backup) service.

    2. Release the config array reference pointer used to iterate the Snort config.xml entries during saved settings migration steps when finished using the reference pointer.



  • I'm on 2.4.4-p3 and package manager is still showing v3.2.9.8_6 as the latest.
    snort.jpg



  • @gfeiner said in Snort v3.2.9.9 Package Update - Release Notes (for pfSense-2.4.4 RELEASE):

    I'm on 2.4.4-p3 and package manager is still showing v3.2.9.8_6 as the latest.
    snort.jpg

    Do you have a Netgate appliance? If so, that's why. For some reason package updates to the firmware repository for the Netgate appliances are usually delayed for sometimes days. I verified the new package is showing on the CE (Community Edition) repository, but the Netgate firmware repository is not yet updated. I myself have an SG-5100, so I don't see the update either yet.

    There is a different package repository URL for Netgate appliances with factory firmware (pfSense installed) as compared to the CE version of pfSense.

    Here is the URL for pfSense CE packages: https://files00.netgate.com/pfSense_v2_4_4_amd64-pfSense_v2_4_4/All/.

    Here is the URL for Netgate Appliance Packages: https://firmware.netgate.com/pkg/pfSense_factory-v2_4_4_amd64-pfSense_factory-v2_4_4/All/.

    Scroll down and find the file pfSense-pkg-snort-3.2.9.x and you will see the different versions. Same thing for the snort-2.9.xx.x binary file.


  • Galactic Empire

    Now available for Netgate devices.



  • @NogBadTheBad said in Snort v3.2.9.9 Package Update - Release Notes (for pfSense-2.4.4 RELEASE):

    Now available for Netgate devices.

    Great. I traded an email yesterday with the pfSense team asking how long it usually takes for the Netgate repository to get updated.



  • @bmeeks
    Yes I do have a Netgate appliance. I didn't realize the repos were different.



  • @gfeiner said in Snort v3.2.9.9 Package Update - Release Notes (for pfSense-2.4.4 RELEASE):

    @bmeeks
    Yes I do have a Netgate appliance. I didn't realize the repos were different.

    Yeah, the main reason for the difference is because the pfSense for the Netgate appliances is slightly customized for the appliance hardware, plus it includes a special package for AWS or something like that. That separation flows over into the other packages as well. The pfSense developer who merged my Snort update forgot to also merge it to the Netgate repository. He did that around 8:00 AM EDT on Thursday, August 15th.



  • Hello,
    since the last update, after about 20 minutes when the Snort service on LAN started, the following error occurred to me: kernel: igb1: promiscuous mode disabled. I have no problems on the other three network cards.

    What is the problem? how can i fix it?

    I also tried the Snort removal and fresh installation and configuration.

    Thanks for any help



  • @Simbad said in Snort v3.2.9.9 Package Update - Release Notes (for pfSense-2.4.4 RELEASE):

    Hello,
    since the last update, after about 20 minutes when the Snort service on LAN started, the following error occurred to me: kernel: igb1: promiscuous mode disabled. I have no problems on the other three network cards.

    What is the problem? how can i fix it?

    I also tried the Snort removal and fresh installation and configuration.

    Thanks for any help

    Need more information for troubleshooting.

    1. What type of hardware (CPU type) and how much RAM?

    2. What other messages are displayed in the system log? The message you posted is simply the last message the kernel will print when Snort shuts down as the libpcap library is returning the interface to normal non-promiscuous mode operation. List the system log messages that preceed (in time) the message you posted.



  • I have i9900 and 32GB ram.

    last log, after LAN snort die:
    Aug 18 19:28:35 kernel: igb1: promiscuous mode disabled
    Aug 18 19:28:09 barnyard2[43267]: OpSyslog_Alert(): Invoked with Packet[0x45fa000] Event[0x0] Event Type [0] Context pointer[0x460d700]



  • @Simbad said in Snort v3.2.9.9 Package Update - Release Notes (for pfSense-2.4.4 RELEASE):

    I have i9900 and 32GB ram.

    last log, after LAN snort die:
    Aug 18 19:28:35 kernel: igb1: promiscuous mode disabled
    Aug 18 19:28:09 barnyard2[43267]: OpSyslog_Alert(): Invoked with Packet[0x45fa000] Event[0x0] Event Type [0] Context pointer[0x460d700]

    That's all? There are no other Snort messages? And that Barnyard2 message was in the pfSense system log? I would expect to see other Snort messages in your pfSense system log (at least something like "snort exited with Signal 11" or similar). Nothing in your log like that?

    You say you have no problems on the other three network cards. What is different about those setups? Are they all running Snort? Are their configurations the same, or if not, what are some of the differences?



  • I have quad intel 350i network card (igb0, igb1, igb2, igb3).

    This is log from system logs (with snort log).

    All four configuration settings are exactly the same (clone) WAN settings.

    7d987c22-6d72-4adb-b869-bb1a200cb490-image.png



  • @Simbad said in Snort v3.2.9.9 Package Update - Release Notes (for pfSense-2.4.4 RELEASE):

    I have quad intel 350i network card (igb0, igb1, igb2, igb3).

    This is log from system logs (with snort log).

    All four configuration settings are exactly the same (clone) WAN settings.

    So you have four identical configurations of Snort running on four different interfaces? Why? That really makes no sense unless you actually have four WAN interfaces in some kind of failover/load balancer setup.

    If you do in fact have four identical setups and three work fine but the fourth does not, then something is wrong with that fourth setup. It would not be the Snort software if the exact same setup works in three other instances.

    You have Snort outputting alerts to syslog and thus that is creating a lot of extra noise in the log and is likely masking the other messages relative to the Snort daemon that I was looking for.



  • I have 4 different ones to help identify the internal source.



  • @Simbad said in Snort v3.2.9.9 Package Update - Release Notes (for pfSense-2.4.4 RELEASE):

    I have 4 different ones to help identify the internal source.

    Then why on the WAN, too? The WAN is going to drop all unsolicited inbound anyway unless you have configured port forwards. And even if you have port forwards, if you have Snort on every LAN interface then those installations will catch bad stuff.

    Suit yourself if you want four identical Snort setups, but my original comment still stands. If three of the four identical setups work and only one of them does not, then you will need to search thoroughly and find out how that fourth one is different. Something must be if it stops and others do not. The Snort binary and PHP code is identical for all four instances.



  • Thank you, I'll bury my head in logs like an ostrich in the ground,...

    7566b68f-a11d-4f84-9fca-df8455d0a495-image.png



  • @Simbad said in Snort v3.2.9.9 Package Update - Release Notes (for pfSense-2.4.4 RELEASE):

    Thank you, I'll bury my head in logs like an ostrich in the ground,...

    7566b68f-a11d-4f84-9fca-df8455d0a495-image.png

    I would recommend first temporarily turning off the option for sending alerts to syslog. Do that for all interfaces and then restart Snort on all interfaces. That will make for a quieter log where other messages will more easily stand out. Once you track down the problem with the troublesome interface, you can re-enable the syslog alert output.


Log in to reply