Snort Won't Start, Failed to load file-other.so



  • After a recent rule set update Snort will no longer start. The error code in the log is:

    FATAL ERROR: Failed to load /usr/local/lib/snort_dynamicrules/file-other.so: /usr/local/lib/snort_dynamicrules/file-other.so: invalid file format
    

    I submitted a bug report to Snort. Their response was "This may be a problem with how pfsense parses the ruleset directory. Please contact pfsense." #superhelpful

    PfSense version is 2.4.4-RELEASE-p3. Snort package is 3.2.9.8_6. I have reinstalled the package, tried rebooting, tried to force update the rules. This has occurred on two different systems, both of which have otherwise hummed along fine for years.

    Any one have any ideas?



  • I don't currently use that particular rule category, so I will have to load up a VM and test it there. At first glance, based on the error message, it looks like a potentially corrupt file in the tarball your update downloaded.

    Where are you located in the world? That might help me determine if perhaps your update tarball was fetched from a different geographical server. My last rules update is showing for this past Saturday, June 22nd. What does your Update Log show as the most recent update of the Snort Subscriber Rules?



  • Both servers are located in Oklahoma City, Oklahoma, USA and have a WAN IP to match.

    The IPS Policy is "Balanced". ET Open Rules enabled are "current_events", "mobile_malware", and "web_server". Snort Test Rules, Snort SO Rules, and OpenAPPID are not enabled.

    I did a force update just now on box sites. MD5 Signature date is Monday, 24-Jun-19 16:06:16 CDT.



  • UPDATE:
    Just tested in a Snort VM that I happened to have running for another purpose. Enabled the File-Other shared-object rules and started Snort without issue. Verified those rules were actually loaded.

    My suggestion would be to force another update to overwrite that earlier download. Perhaps the file got corrupted either during download or during the install process. Also need to mention that if you are running with a RAMDISK (highly NOT recommended for Snort or Suricata!), then make sure you have at least 256 MB of free space on the RAMDISK to hold the rules tarball and its extracted contents.

    To force an update, click the Force button on the UPDATES tab.



  • @jasonsansone said in Snort Won't Start, Failed to load file-other.so:

    Both servers are located in Oklahoma City, Oklahoma, USA and have a WAN IP to match.

    The IPS Policy is "Balanced". ET Open Rules enabled are "current_events", "mobile_malware", and "web_server". Snort Test Rules, Snort SO Rules, and OpenAPPID are not enabled.

    I did a force update just now on box sites. MD5 Signature date is Monday, 24-Jun-19 16:06:16 CDT.

    Our posts may have passed each other in the ether ...

    I am located in the Southern US, so likely we get our updates from the same server farm. Snort rules are hosted on AWS intrastructure.

    I can force an update of my rules in the VM and try it again. I just installed Snort on that VM this morning and it installed a fresh set of rules.

    BTW, you are likely picking up the SO rules via that IPS Policy (which is fine). The policy will load up a number of rules for you from the Snort Subscriber selection.

    Update:
    Still working in my test VM with a new forced rules update.



  • I am using ram disks. Each (both /tmp and /var) have been set to 256mb on each machine and a reboot was performed. Tmp utilization is 0% and /var is below 10% on each server. I just performed a reinstall of the Snort package on both. Snort will now start. Not sure where the problem was, but it automagically works again. Thank you!



  • @jasonsansone said in Snort Won't Start, Failed to load file-other.so:

    I am using ram disks. Each (both /tmp and /var) have been set to 256mb on each machine and a reboot was performed. Tmp utilization is 0% and /var is below 10% on each server. I just performed a reinstall of the Snort package on both. Snort will now start. Not sure where the problem was, but it automagically works again. Thank you!

    The RAMDISK ran out of free space for /tmp. I guarantee you. Have seen it happen here many times. You won't see the out-of-space condition after the fact because the Snort cron job cleans up behind itself by deleting the temp files it created (thus your RAMDISK space magically reappears). Look through the pfSense system log and I suspect you will find an out-of-space error message.

    I really DO NOT recommend running a RAMDISK with either Snort or Suricata for exactly the reason you just experienced. It will eventually run out of space and then cause very weird issues. With the reliability of today's SSDs, there is really no valid reason for a RAMDISK in my humble opinion.



  • Thank you. I will disable the RAM disks going forward.


Log in to reply