Snort 4.1.6_7 crash report / Problems force-disabling rules
-
So without plus, I was able to successfully block rules.
I upgraded to plus. Now I have the same issue as before - I can't force-disable rules. It does all of the statusing as if it's doing something, but the rule doesn't stay blocked.
All rules that were blocked before the plus upgrade are still blocked (statused yellow) and don't revert.
How can I troubleshoot this further?
-
@jsnl said in Snort 4.1.6_7 crash report / Problems force-disabling rules:
So without plus, I was able to successfully block rules.
I upgraded to plus. Now I have the same issue as before - I can't force-disable rules. It does all of the statusing as if it's doing something, but the rule doesn't stay blocked.
All rules that were blocked before the plus upgrade are still blocked (statused yellow) and don't revert.
How can I troubleshoot this further?
Have you tried simply refreshing the page? Click on the tab at the top to reload/refresh the page. So ALERTS, RULES, etc., depending on where you are in the Snort tabs menu.
-
@bmeeks Yes I have. The state resets.
I went looking for the rule (119:2 in this case) which I found out was a preprocessor rule. I went into WAN Rules and into preprocessor, and I can manually disable 119:2 and hit apply and it sticks. So it's something about the way the link is working from the "alerts" page. It triggers the green message and orange X, but the rule doesn't block (or stay blocked longer than 15 seconds).
-
@jsnl Did anything ever come of this? I've had the snort force-disable problem since 23.01. Checked that there weren't two processes and even killing the active one with no resolve, there doesn't seem to be a lot of conversation about it either https://www.reddit.com/r/PFSENSE/comments/11w6c51/snort_forcedisable_no_longer_working/.
The problem exists separate from the crash report mentioned above and seems to be isolated to pfsense+.
Version: 23.05-RELEASE
System: Netgate 5100 -
@booshwa Unfortunately no. I still have the issue on certain boxes, and haven't been able to find a way around it.
Fortunately manually disabling the rule in "rules" works. But it's just a terrible way to go about it when there's an infinitely easier way that's supposed to be available to us. I often find myself completely turned around looking through all of the subsets to find the rule I want to disable, and I can't display all rules and search for it because it takes too much memory and crashes. (Which should be another reported bug...)
-
I've verified the issue with saving "user force-disabled" rule states on the ALERTS tab in Snort. In fact, a couple of things on this page seem to be broken with the move to PHP 8.1 back early in 2023. Don't really know how I missed it during my testing back then as I migrated the package code over to PHP 8.1.
I did not find a Redmine ticket for the problem. No Redmine issue is likely how it has continued to slip by for so long. I will submit a Redmine ticket for the problems and work on getting them corrected.
FYI, I do not have a Reddit account and do not normally check in there to read any posts. If you have issues with Snort's operation and suspect a bug, please open a pfSense Redmine ticket here; https://redmine.pfsense.org/projects/pfsense. This is the official bug tracking system for pfSense and its associated packages.
Edit: I've created the following Redmine Issue to track the resolution of this bug: https://redmine.pfsense.org/issues/14832.
-
The pull request containing the fix for the user force-disabling rules issue on the ALERTS tab has been posted and is awaiting review and merging by the Netgate developer team. You can follow the progress here: https://github.com/pfsense/FreeBSD-ports/pull/1300.
-
@bmeeks Awesome, thanks for taking time to look into this!
-
@bmeeks Yes, thank you! Much appreciated.
-
@bmeeks Verified that it's working perfectly on 4.1.6_11.
Thanks again!
