pfSense » pfSense Packages

The rules update process will restart any running Snort processes at the end of the update. However, I guess it is possible that the currently running Snort process might try to access the shared object (*.so) rules during the instant of update and have a problem with that. Purely conjecture, though, on my part.

I have not noticed this problem on my personal system, but it is a home firewall and does not see much traffic.

This one might be hard to nail down since it is intermittent. Keep an eye on it to see if it happens again and if the crash corresponds with a fresh set of VRT rules. Those shared object rules will get updated on each Snort VRT rules package update. Those generally come out on Tuesdays and Thursdays US Eastern Time.

Bill

This happens fairly frequently for me - it crashed again on Apr. 22nd when pulling in the latest VRT rules (SIGSEGV).

If I can make snort generate a core dump file the next time it crashes, that might point to whether it is crashing when attempting to call a function in one of the .so's. I haven't figured out exactly how to make snort generate a coredump when it crashes, though. From reading online, hopefully the following will work?

sysctl kern.corefile=/tmp/%N.core
sysctl kern.capmode_coredump=1
sysctl kern.sugid_coredump=1

I also have the same problem.. nearly every night on the rule update process the snort service
dies or isn't coming up again after the updates ran.
(running pfSense community edition 2.4.3-RELEASE-p1 (amd64) with snort 3.2.9.6_1)

Jul 20 02:06:50 check_reload_status Syncing firewall
Jul 20 02:06:49 php /usr/local/pkg/snort/snort_check_for_rule_updates.php: [Snort] The Rules update has finished.
Jul 20 02:06:42 php /usr/local/pkg/snort/snort_check_for_rule_updates.php: [Snort] Building new sid-msg.map file for LAN...
Jul 20 02:06:39 php /usr/local/pkg/snort/snort_check_for_rule_updates.php: [Snort] Enabling any flowbit-required rules for: LAN...
Jul 20 02:06:15 kernel igb2: promiscuous mode disabled
Jul 20 02:06:15 kernel pid 2526 (snort), uid 0: exited on signal 4
Jul 20 02:06:09 php /usr/local/pkg/snort/snort_check_for_rule_updates.php: [Snort] Updating rules configuration for: LAN ...
Jul 20 02:05:33 php /usr/local/pkg/snort/snort_check_for_rule_updates.php: [Snort] Emerging Threats Open rules file update downloaded successfully
Jul 20 02:05:29 php /usr/local/pkg/snort/snort_check_for_rule_updates.php: [Snort] There is a new set of Emerging Threats Open rules posted. Downloading emerging.rules.tar.gz...
Jul 20 02:05:28 php /usr/local/pkg/snort/snort_check_for_rule_updates.php: [Snort] Snort OpenAppID RULES detectors file update downloaded successfully
Jul 20 02:05:27 php /usr/local/pkg/snort/snort_check_for_rule_updates.php: [Snort] There is a new set of Snort OpenAppID RULES detectors posted. Downloading appid_rules.tar.gz...
Jul 20 02:05:27 php /usr/local/pkg/snort/snort_check_for_rule_updates.php: [Snort] Snort OpenAppID detectors are up to date...
Jul 20 02:05:25 php /usr/local/pkg/snort/snort_check_for_rule_updates.php: [Snort] Snort Subscriber rules file update downloaded successfully
Jul 20 02:05:05 php /usr/local/pkg/snort/snort_check_for_rule_updates.php: [Snort] There is a new set of Snort Subscriber rules posted. Downloading snortrules-snapshot-29111.tar.gz...

Thank you for the suggested patch, but I think the rules update logic is going to need additional changes due to the inclusion of the Inline IPS option. With Inline IPS operation, any Snort stop/start operation will also result in the physical interface cycling down then back up in pfSense. This can interrupt other processes, so some Snort users want the option of Live Rules updates which, instead of stopping and restarting Snort, will send the process a signal to "live reload" the new rules.

The SO rules are special in that they are precompiled binary libraries (you probably already know this). And they are distributed pre-compiled for specific OS versions. There is a FreeBSD-12 set of SO rules, but I suspect they are compiled for RELEASE while pfSense is based on STABLE. Also not sure which 12.x version they are compiled for. So there is a bit of a potential wildcard there that might be a cause of random segfaults.

I will make the rules update process a bit more robust by incorporating your idea of saving the "entry state" for service running or not running. But I will also add logic to make sure the process accomodates Inline IPS folks who want to use the "live reload" option. Look for these changes in the near future.

The Snort GUI package now has additional logic to ensure running Snort interfaces at the start of a rules update cycle are started/restarted when the rules update cycle is completed. See this Pull Request: https://github.com/pfsense/FreeBSD-ports/pull/1075.

Once this Pull Request is merged, this issue can be closed.