Snort: Another solution to the rule enable/disable update reset problem
-
I started using the Snort package for pfSense 2.0.1 (amd64) some days ago but as many others I noticed the problem with the enable/disabled rules resetting after updating the rules.
So last night I started working on a quick fix for, and came up with a nice and working solution. My solution involves enabling and disabling specific rules in a oinkmaster.conf file, so it's not a GUI solution. But at least now it's possible to have your own set of enabled/disabled rules.
Anyway, here we go. I'll take it step by step here.First of all, you'll need to install wget (so that oinkmaster.pl will work). For pfSense 2.0.1 amd64 use the following command (change URL according your platform and version).
fetch http://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-8.2-release/ftp/wget-1.12_2.tbz pkg_add wget-1.12_2.tbzNext step is to create a /etc/oinkmaster.conf file. Mine looks like this (change the Snort URL to include your oinkcode and change the snapshot version if you're a basic user or subscriber, look at the list on snort.org, for example use snapshot-2905 if you don't have a paid subscription).
Note: Change your enabled/disabled rule at the bottom, this is just my own example, tweak to your needs.############################# # Location of rules archive # ############################# url = http://www.snort.org/pub-bin/oinkmaster.cgi/YOURCODEHERE/snortrules-snapshot-2922.tar.gz ######################### # System configurationi # ######################### path = /sbin:/usr/sbin:/bin:/usr/bin:/usr/local/bin:/usr/local/sbin use_external_bins = 1 tmpdir = /tmp umask = 0027 ######################## # Extra configurationi # ######################## update_files = \.rules$|\.config$|\.conf$|\.txt$|\.map$ # Sanity check use_path_checks = 1 ################## # Rules handling # ################## # Files to skip skipfile local.rules skipfile deleted.rules skipfile snort.conf # skipfile threshold.conf # SIDs to enable enablesid 19559, 20120 # SIDs to disable disablesid 19110, 19139, 19140, 19138, 19155, 19137, 19157, 19168, 19209, 19826Last step is to create a small shell script which will handle the update and coping of rules etc. Every time the script is being run it will download a new set of rules, enable/disable the rules you've chosen in oinkmaster.conf, copy the files to /usr/local/etc/snort/rules and /usr/local/etc/snort/snort_YOURNIC/rules.
Note: You need to change the NIC variable!#!/bin/sh ################################################# # Solution to pfSense/Snort rule disable/enable # # Written by Jack-Benny # ################################################# # Define your Snort interface SNORT_NIC="47399_em0" # Check if tmp dir exists, and if not, create it if [ ! -d "/tmp/snort_rules" ]; then /bin/mkdir /tmp/snort_rules fi # Time do download our new snort rules /usr/local/bin/oinkmaster.pl -o /tmp/snort_rules # Lets begin with adding the snort_ prefix to our rules cd /tmp/snort_rules for f in * do /bin/mv "$f" "snort_$f" done # We must add a whitespace after every "#" to make it compatible /usr/bin/sed -i -e 's/^\#alert/\# alert/g' snort_* # Remove sed backups files /bin/rm *-e # Now move them all to the correct locations /bin/mv /tmp/snort_rules/snort_* /usr/local/etc/snort/rules/ /bin/cp /usr/local/etc/snort/rules/snort_* \ /usr/local/etc/snort/snort_${SNORT_NIC}/rules/ # And finally, restart Snort /usr/local/etc/rc.d/snort.sh start echo "Your new rules have been downloaded and Snort has been restarted"If you'd like automatic updates, just put the shell script in your crontab and let it run every 12 hour or so. Here is an example of my crontab.
Don't forget to turn of automatic updates in the WebGUI0 */12 * * * /root/update_rules.sh > /root/last_rule_update.log 2>&1I hope this could be useful to someone out there! :)
Cheers and have a nice day!
And thanks to all the pfSense developer and to the Snort package maintainer! I really like the Snort package, so keep up the good work!//Jack-Benny
-
Nice writeup. Will try this if I ever have this issue. Thanks
-
Anybody get this to work or is there a better way?
-
The Snort package has changed since the original post was written, so there may be additional changes now needed to do it this way…
-
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. -
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!
