Snort: Another solution to the rule enable/disable update reset problem
-
You need to enable flowbits in the GUI to make snort remember your rules!
-
You need to enable flowbits in the GUI to make snort remember your rules!
Perfect! Thanks mate! :)
-
@/CS:
Hi guys, do you know if this bug is tracked somewhere in http://redmine.pfsense.org/ ?
I have installed Snort 2.9.4.1 pkg v.2.5.4 on pfsense 2.0.2 and this bug is still there.Your link to the bug apparently got truncated. It leads to just the top-level page at redmine.pfsense.org instead of to the bug notice.
Version 2.54 should NOT be overwriting your manually enabled/disabled SIDs. I fixed that (or thought I did) back in January. As Supermule mentioned, you also want to enable the auto-flowbits resolution option on the Categories tab. This will ensure required set-flowbits rules are enabled so other dependent rules can fire. If any flowbit-required rules give you unwanted alerts, simply add the alerts to the Suppression List on the Suppression tab.
Bill
-
Your link to the bug apparently got truncated. It leads to just the top-level page at redmine.pfsense.org instead of to the bug notice.
Hi Bill,
no actually the link was not truncated, since I just pasted the top-level page asking if somebody might know the specific page of this bug.
I upgraded to Snort 2.9.4.1 pkg v.2.5.5 , I enabled "Automatic Flowbit Resolution" but I have still the following problem:Let's say I want to enable a rule which is by default disabled. I go to the Rules tab, select the appropriate category (which is already enabled) and click on the grayed out red "X" button in front of the rule. Then the button becomes yellow which means it has been enabled by the user and then I click "Apply Changes". I restart snort or I start it if it has been stopped already but the rule is not firing when I trigger it. I also noticed that "#" is still at the beginning of the rule.
Do you know what goes wrong? Is it related to the issue you fixed or has nothing to do with that?
Many thanks,
/CS -
@/CS:
Your link to the bug apparently got truncated. It leads to just the top-level page at redmine.pfsense.org instead of to the bug notice.
Let's say I want to enable a rule which is by default disabled. I go to the Rules tab, select the appropriate category (which is already enabled) and click on the grayed out red "X" button in front of the rule. Then the button becomes yellow which means it has been enabled by the user and then I click "Apply Changes". I restart snort or I start it if it has been stopped already but the rule is not firing when I trigger it. I also noticed that "#" is still at the beginning of the rule.
Do you know what goes wrong? Is it related to the issue you fixed or has nothing to do with that?
That is supposed to be working, and I made no changes in that code. Let me go back and make sure I did not inadvertently mess something up. I will test it and see.
Bill
-
Update on this issue with manual enable/disable of rules not working –
I am able to reproduce this bug. As I suspected, that code was not changed for 2.5.5. Rather, the error has been there since an earlier update. I was not aware it was no longer working. I think that particular module was tweaked a bit by one of the main developers after I submitted it, and I never went back and tested it again.
It's not working now, and I think I know why. Hopefully I can get in a quick patch and push it along with fixing the version flag up to 2.5.5. Will post back with final solution.
Bill
-
UPDATE
Found the errant code and fixed it. The new code is posted as Snort Package version 2.5.5.
Sorry about that. It had been there since probably at least version 2.5.3, but I was unaware it wasn't working.
Bill
-
Are you sure that worked?
I updated snort package again with your fix and as a test I disabled a rule (now listed in light yellow) in VRT rules and IPS enabled "balanced", but when I go to /usr/local/etc/snort/my_snort_sensor/rules/snort.rules it is still listed there.
BTW I pressed "Apply changes" ;)
-
I reinstalled the Snort package (2.5.5), I removed all Enable/Disable changes in all Categories (Rules tab), I enabled some of them again, I applied Changes, I started Snort…but I have still the same problem.
I also confirm that the bug has been there for the previous versions too.
-
Comment1: I tried to trigger the signatures I enabled some hours later and now they are firing. :)
-
Comment2: The only prob is that the "Stop" button in "Snort Interfaces" as well as in "Services" doesn't stop snort service and gives me the following in the System Logs:
php: /status_services.php: The command '/usr/local/etc/rc.d/snort.sh stop' returned exit code '1', the output was ''
-
-
Are you sure that worked?
I updated snort package again with your fix and as a test I disabled a rule (now listed in light yellow) in VRT rules and IPS enabled "balanced", but when I go to /usr/local/etc/snort/my_snort_sensor/rules/snort.rules it is still listed there.
BTW I pressed "Apply changes" ;)
It will still be listed, but should have "#" in front of it to disable, or no "#" to enable. Using the enable/disable SID function does not remove the rule from the list, but simply comments it out, or removes the comment character, depending on the action.
I tested this using a couple of random rules in Emerging Threats, but should work the same for an IPS Policy.
Bill
-
@/CS:
The only prob is that the "Stop" button in "Snort Interfaces" as well as in "Services" doesn't stop snort service and gives me the following in the System Logs:
php: /status_services.php: The command '/usr/local/etc/rc.d/snort.sh stop' returned exit code '1', the output was ''
Hi Bill, do you have any comment on this? Any idea maybe? ???
-
@/CS:
@/CS:
The only prob is that the "Stop" button in "Snort Interfaces" as well as in "Services" doesn't stop snort service and gives me the following in the System Logs:
php: /status_services.php: The command '/usr/local/etc/rc.d/snort.sh stop' returned exit code '1', the output was ''
Hi Bill, do you have any comment on this? Any idea maybe? ???
Do you perhaps have a zombie Snort process? Have you tried a reboot, or else a manual kill from the console?
I have not seen this error before.
Bill
-
Are you sure that worked?
I updated snort package again with your fix and as a test I disabled a rule (now listed in light yellow) in VRT rules and IPS enabled "balanced", but when I go to /usr/local/etc/snort/my_snort_sensor/rules/snort.rules it is still listed there.
BTW I pressed "Apply changes" ;)
It will still be listed, but should have "#" in front of it to disable, or no "#" to enable. Using the enable/disable SID function does not remove the rule from the list, but simply comments it out, or removes the comment character, depending on the action.
I tested this using a couple of random rules in Emerging Threats, but should work the same for an IPS Policy.
This still does not work on my system. I can see commented rules in /usr/local/etc/snort/my_snort_sensor/rules/snort.rules but those are the default commented rules from Snort and ET. If I enable a default commented rule (dark yellow) nothing changes too after pressing "Apply Changes". Am I looking at the right file?
Edit: I guess I found it. The changes are made in /usr/pbi/snort-i386/etc/snort/my_snort_sensor/rules/snort.rules. But that is not the right place, is it? It should be in /usr/local/etc/snort/my_snort_sensor/rules/snort.rules. Or am I totally wrong?
Edit 2: I see now this all changed in version 2.5.5. Even the configuration file is loaded from this directory in /usr/local/etc/rc.d/snort.sh. I thought that the pbi-directory should be left untouched as it is the directory where packages are situated and configuration files should not be in there.
-
No, the idea with PBI is that all the files are in the PBI tree. Packages install themselves into an isolated environment so they do not share stuff with other packages. Only some symlinks are maintained for now by the package installer to keep some level of compatibility with non-PBI packages.
If you are using 2.1 Snort, then /usr/pbi/ is where you look for Snort now.
-
Thanks for the clarification. I still had the old directories from the previous (2.5.4) installation and I was looking there. That brought some confusion. I uninstalled snort again, removed old directories and installed it again.
You are doing a good job!
-
Thanks for the clarification. I still had the old directories from the previous (2.5.4) installation and I was looking there. That brought some confusion. I uninstalled snort again, removed old directories and installed it again.
You are doing a good job!
Yeah, one of the things I added in this latest update was to try and do a better job of "cleaning up" when uninstalling. Of course for the initial update from 2.5.4, or any earlier version, to 2.5.5, you will potentially have to do some manual clean up. After that Snort should be a little better cleaning up. It will leave some directories in the old locations, but they should be empty of files.
For 2.0.x pfSense users, the Snort files are still in /usr/local/etc/snort. But for 2.1 pfSense users, everything now will be in /usr/pbi/snort-{arch}/etc/snort where {arch} is either i386 or amd64, depending on your platform.
Bill
