Snort failing to start on pfSense 2.2.4
-
A previous implementation I configured via the guide went without issue. This pfSense box, I'm having an error when I attempt to start Snort on the WAN interface. Getting a fatal error in the logs:
php-fpm[67130]: /snort/snort_rulesets.php: [Snort] Updating rules configuration for: WAN …
Mar 9 14:08:51 php-fpm[67130]: /snort/snort_rulesets.php: [Snort] Enabling any flowbit-required rules for: WAN…
Mar 9 14:08:51 php-fpm[67130]: /snort/snort_rulesets.php: [Snort] Building new sid-msg.map file for WAN…
Mar 9 14:09:14 php-fpm[32990]: /snort/snort_interfaces.php: Toggle (snort starting) for WAN(re2)…
Mar 9 14:09:14 php-fpm[32990]: /snort/snort_interfaces.php: [Snort] Updating rules configuration for: WAN …
Mar 9 14:09:17 php-fpm[32990]: /snort/snort_interfaces.php: [Snort] Enabling any flowbit-required rules for: WAN…
Mar 9 14:09:18 php-fpm[32990]: /snort/snort_interfaces.php: [Snort] Building new sid-msg.map file for WAN…
Mar 9 14:09:28 php-fpm[32990]: /snort/snort_interfaces.php: [Snort] Snort START for WAN(re2)…
Mar 9 14:09:29 snort[60910]: FATAL ERROR: Failed to load /usr/pbi/snort-i386/lib/snort_dynamicrules/os-linux.so: /usr/pbi/snort-i386/local/lib/snort_dynamicrules/os-linux.so: Shared object has no run-time symbol table
Mar 9 14:09:29 php-fpm[32990]: /snort/snort_interfaces.php: The command '/usr/pbi/snort-i386/bin/snort -R 15380 -D -q –suppress-config-log -l /var/log/snort/snort_re215380 --pid-path /var/run --nolock-pidfile -G 15380 -c /usr/pbi/snort-i386/etc/snort/snort_15380_re2/snort.conf -i re2' returned exit code '1', the output was ''Thanks,
-
Did you disable any of the "Pre-processors" in the WAN Interface? Looks like its failing due to a missing pre-processor… Best to keep the pre-processor settings as default...
-
Is this a full install on a conventional hard disk (or SSD) or is it a NanoBSD installation? If NanoBSD, you might have RAM disk space issues that are causing the rules extraction and installation to get fouled up.
Another possibility is the rules are not the correct version for the binary, but this is unlikely. You can do a FORCE UPDATE on the UPDATES tab to forcibly download and install a fresh vendor rules package to see if that help.
@BBcan177 is also correct that it might be due to a disabled preprocessor, but usually that results in an error message about "unsupported option" or something similar.
Bill
-
It is a nanoBSD implementation. I do not believe it to be a rule missing a preprocessor error as I enabled the Auto-Disable rules missing preprocessor option and am getting the same issue. I'll try adjusting the RAM usage of Snort. It's odd though - I double checked the old desktop I previously used for SNORT and it has less memory (2Gb).
Thanks!
-
It is a nanoBSD implementation. I do not believe it to be a rule missing a preprocessor error as I enabled the Auto-Disable rules missing preprocessor option and am getting the same issue. I'll try adjusting the RAM usage of Snort. It's odd though - I double checked the old desktop I previously used for SNORT and it has less memory (2Gb).
Thanks!
Don't confuse RAM for Snort operation with RAM used for RAM disks. On NanoBSD, part of RAM is used to provide the "hard drive". Snort needs at least 150 MB of free space on /tmp and perhaps as much as 250 MB for multiple rule set in order to download, unpack and then install the rules. It blindly assumes there is enough disk space, but if there is not, unpredictable results will occur. That may be happening to you. I do not recommend using Snort (or Suricata) on NanoBSD installs. There are just too many reported issues with running out of RAM disk space on some critical partitions. If you search the forums, you can find some suggestions from other users on how to customize and increase the defaults for RAM disk sizes.
Bill
-
The problem was the /tmp and /var space. Due to NanoBSD implementation, defaults were in place 40Mb and 60Mb. However, the box I'm running it on is running AMD G-T40E dual core w/ 4G RAM. I increased the size of the /var and /tmp to 500 MB each and reinstalled SNORT packages. Took SNORT a bit over 5 minutes to start up, but it's been running with out issues with Balanced IPS policy and Emerging Threat rules enabled.
