Snort 2.9.4.1 pkg v. 2.5.5 Issue(s)
-
Totally uninstalled pkg v 2.5.4 and then ran "find /* | grep -i snort | xargs rm -rv" to remove any left over traces of Snort.
Reinstalled Snort to get the new pkg v. 2.5.5 but I cant get it to start, with fatal error.
Apr 10 11:08:11 php: /snort/snort_interfaces.php: Interface Rule START for HTTP Inspect(em1)... Apr 10 11:08:11 snort[49458]: FATAL ERROR: /usr/pbi/snort-amd64/etc/snort/snort_30901_em1/preproc_rules/decoder.rules(1) Unknown ClassType: protocol-command-decode Apr 10 11:08:10 php: /snort/snort_interfaces.php: Toggle(snort starting) for WAN(HTTP Inspect)... Apr 10 11:08:05 php: /snort/snort_preprocessors.php: Building new sig-msg.map file for WAN... Apr 10 11:08:01 php: /snort/snort_preprocessors.php: Resolving and auto-enabling any flowbit-required rules for WAN... Apr 10 11:08:00 php: /snort/snort_preprocessors.php: Updating rules configuration for: WAN ... Apr 10 11:08:00 check_reload_status: Syncing firewallI've unchecked every Preprocessor rule and setting on the Preprocessor Tab but I still get the same error.
-
I've unchecked every Preprocessor rule and setting on the Preprocessor Tab but I still get the same error.
You're doing that part backwards. Check (or enable the preprocessors), especially HTTP_INSPECT. If you insist on running with preprocessors disabled, then check the "Auto-Rule Disable" option now on the Preprocessors tab.
This is a change in the old default behavior, because the old way did this auto-rule disable hidden and behind your back. This left you with less than ideal protection, because of the disabled rules.
If you do not want HTTP_INSPECT alerts, then check the box on in that section on the Preprocessors tab to disable them.
The new code writes a log file to /var/log/snort with the name of the interface in the filename when the Auto-Rule-Disable feature is enabled. This shows you the rule GID:SID it disabled and which dependent disabled preprocessor caused the disabling.
This change in behavior was by design. I wanted the disabling of preprocessors and their dependent rules to be a conscious choice by the user and have them adequately warned of the consequences. Hence the new user-configurable options and logging.
Bill
-
Thank you for your reply,
I had most of them enabled including HTTP_INSPECT when it was firing off that error, I figured disabling some of them would help me find the culprit but disabling all of them still gave that same error. I enabled the Sensitive Data Preprocessor (which I never use) and it gave a different error.
FATAL ERROR: /usr/pbi/snort-amd64/etc/snort/snort_30901_em1/preproc_rules/sensitive-data.rules(1) Unknown ClassType: sdf
The only Preprocessors I dont use are the Sensitive Data, Modbus, and the DNP3. I checked the Auto-Rule-Disable and I still got the same Fatal Error from my first post.
FATAL ERROR: /usr/pbi/snort-amd64/etc/snort/snort_30901_em1/preproc_rules/decoder.rules(1) Unknown ClassType: protocol-command-decode
-
I have a 2.1-BETA VM I can try this on. Which rule sets do you have enabled? Snort VRT or Emerging Threats or GPLv2 Community or some combination?
Bill
-
Thank you for your reply,
I had most of them enabled including HTTP_INSPECT when it was firing off that error, I figured disabling some of them would help me find the culprit but disabling all of them still gave that same error. I enabled the Sensitive Data Preprocessor (which I never use) and it gave a different error.
FATAL ERROR: /usr/pbi/snort-amd64/etc/snort/snort_30901_em1/preproc_rules/sensitive-data.rules(1) Unknown ClassType: sdf
The only Preprocessors I dont use are the Sensitive Data, Modbus, and the DNP3. I checked the Auto-Rule-Disable and I still got the same Fatal Error from my first post.
FATAL ERROR: /usr/pbi/snort-amd64/etc/snort/snort_30901_em1/preproc_rules/decoder.rules(1) Unknown ClassType: protocol-command-decode
I found the source of your error, but not the "why" yet. I initially misread the error and thought it was about preprocessors. It's actually a missing CLASSIFICATION in your classification.config file. This file should exist in the Snort directory for the affected interface. The classification is in my version of the file (the "protocol-command-decode" string). Wonder if your setup has a version from only Emerging Threats or something? Mine is from the Snort VRT rules.
I find folks are really, really better off to at the very least get a "Registered User" Oinkcode so they can get the complete set of *.config and *.map files. The ones from Emerging Threats do not contain all the parameters that can be in the default Snort preprocessor text rules. You have hit one of them here. When one of the preprocessor rules that come with the Snort binary contains a Class Type that is not in the classification.config file, you get this error.
When a user does not enable the Snort VRT downloads, then the code defaults to using the *.config and *.map files that come with whatever rule sets are enabled (for now, that means Emerging Threats). As I said, that file is incomplete as it does not contain the sdf Class Type for sensitive-data, and it appears now to perhaps be missing this new Class Type.
Bill
-
I am using Emerging Threats and the regular registered Snort rules.
The classification.config file in my Snort directory for the affected interface is blank. There is a classification.config file in the /usr/pbi/snort-amd64/etc/snort/ directory. Can I just copy this over for now?
-
I am using Emerging Threats and the regular registered Snort rules.
The classification.config file in my Snort directory for the affected interface is blank. There is a classification.config file in the /usr/pbi/snort-amd64/etc/snort/ directory. Can I just copy this over for now?
Yep! That should fix it. No idea how that blank one got in there. The one in /usr/pbi/snort-amd64/etc/snort is the "master copy" used to populate the interface sub-directories. During rule updates, the newest *.config and *.map files from the rule sets are temporarily stuffed into a temp directory. Once all the rule sets are unpacked, the classification.config files from Snort VRT and ET are "merged" into a unified file containing all the unqiue lines from each. Same thing for the references.config files. These merged files are then copied up to the base Snort directory and also into the interface directories. Something appears to have gone amiss with that interface on your box, and it got an empty file.
Bill
-
Copied the file over to the affected interface directory and Snort started right up with no errors.
Going to update my other boxes and see if this same issue pops up there as well.
-
Going to update my other boxes and see if this same issue pops up there as well.
Post back if any of those have empty config files in them. That obviously should not happen, and if it repeats for you I would like to follow up.
Bill
-
Just finished up my other 2 boxes. They all required copying over the classification.config file. All of them are amd64 using 2.1 Beta snapshots so the issue must lie with just those versions if you didn't notice it on your main test VM.
Will this get overwritten on a rule update?
On a side note, any reason why the Packages list in the GUI still list Snort as 2.5.4?
-
After update, I'm getting this:
snort[36080]: FATAL ERROR: The dynamic detection library "/usr/pbi/snort-i386/lib/snort/dynamicrules/lib_sfdynamic_example_rule.so" version 1.0 compiled with dynamic engine library version 1.0 isn't compatible with the current dynamic engine library "/usr/pbi/snort-i386/lib/snort/dynamicengine/libsf_engine.so" version 1.17.So many issues from some of last updates, now I'm really afraid to update at all!
-
Just finished up my other 2 boxes. They all required copying over the classification.config file. All of them are amd64 using 2.1 Beta snapshots so the issue must lie with just those versions if you didn't notice it on your main test VM.
I tested on all versions and both platforms (32-bit and 64-bit, 2.0.x and 2.1-BETA). I did removes, reinstall, clean installs and thought I tried every possible combination. I thought I had the problems whipped. Obviously there are some differences in our environments.
Will this get overwritten on a rule update?
It should, but it should get overwritten with a good file. You can force an update and see by removing the *.md5 files in the main Snort directory, and then doing an update.
On a side note, any reason why the Packages list in the GUI still list Snort as 2.5.4?
Yeah, just realized I bumped the version in only 1 of the 2 files needed. I will submit a Pull Request for the other one this evening. That will fix it.
-
I uninstalled, and reinstalled it worked, but if I try to use (enable) SNORT GPLv2 COMMUNITY RULES it stop working:
php: /status_services.php: The command '/usr/local/etc/rc.d/snort.sh stop' returned exit code '1', the output was ''On "install packages" it still shows as (even after refresh):
Stable 2.9.4.1 pkg v. 2.5.4 platform: 2.0 -
After update, I'm getting this:
snort[36080]: FATAL ERROR: The dynamic detection library "/usr/pbi/snort-i386/lib/snort/dynamicrules/lib_sfdynamic_example_rule.so" version 1.0 compiled with dynamic engine library version 1.0 isn't compatible with the current dynamic engine library "/usr/pbi/snort-i386/lib/snort/dynamicengine/libsf_engine.so" version 1.17.So many issues from some of last updates, now I'm really afraid to update at all!
Did you do a package delete and then install fresh from the Available Packages tab? Sounds like perhaps not. Until all traces of the old version are gone via that package delete operation, you won't be able to fully kill the reinstall gremlins. Just make sure you check the "Save Settings on Package Removal" box under Global Settings (it's down at the bottom of that page), then click the X icon on the Installed Packages tab to remove Snort. Then, go to the command line directly (or via SSH) and remove the snort directory under /usr/lib (or /usr/pbi/snort-i386/lib/.
Then install again from the Available Packages tab. That should work.
Bill
-
On "install packages" it still shows as (even after refresh):
Stable 2.9.4.1 pkg v. 2.5.4 platform: 2.0That will be fixed as soon as I can submit an update to the main package config XML file. Forgot to bump the version number in it when I submitted my changes yesterday.
As for your other error, my first guess is perhaps a Preprocessor issue. For an experiment, turn on ALL the preprocessors except for the Sensitive-Data and the two SCADA ones at the bottom of the Preprocessors tab. Click Save and then go restart Snort. See if it comes up then.
If that still fails, check for a zero-length classification.config file in the Snort interface directories under /usr/pbi/snort-i386/etc/snort.
Report back.
Bill
-
After a lot persistence, I fixed it (uninstalled 2x or 3x, then updated on all those tries).
-
Good to hear it finally worked. My goal is for it to not be so painful, though. Looks like there is still room for improvement… :(
Bill
-
If that still fails, check for a zero-length classification.config file in the Snort interface directories under /usr/pbi/snort-i386/etc/snort.
Report back.
Bill
i had to copy the files over to get snort to work also… but good work on the update
-
i had to copy the files over to get snort to work also… but good work on the update
So far I have been unable to reproduce this problem. Are you guys having this issue with an empty classification.config file using JUST the new Snort GPLv2 rules by chance? They do not include any *.config nor *.map files. Just trying to get a basis for reproducing the problem.
Bill
-
Bill, I did the usual uninstall of Snort and then ran "find /* | grep -i snort | xargs rm -rv" to remove any left over traces of Snort. This time, the list of left over files and directories were a significant amount less than with the previous version, good job Bill. ;)
Reinstalled and Snort was ready to start with newly downloaded rulesets. Previous package required a manual update after installation, good job Bill. :D
Only thing missing was Snort actually starting itself, but I hit the Start toggle and it completed successfully without the errors that i got previously from the empty classification.config file.
Awesome work sir.
-
Bill, I did the usual uninstall of Snort and then ran "find /* | grep -i snort | xargs rm -rv" to remove any left over traces of Snort. This time, the list of left over files and directories were a significant amount less than with the previous version, good job Bill. ;)
Reinstalled and Snort was ready to start with newly downloaded rulesets. Previous package required a manual update after installation, good job Bill. :D
Only thing missing was Snort actually starting itself, but I hit the Start toggle and it completed successfully without the errors that i got previously from the empty classification.config file.
Awesome work sir.
Thank you. I guess the auto-start might be a good idea when reinstalling using previously saved settings. Will discuss that with Ermal for a future update.
Bill
-
i had to copy the files over to get snort to work also… but good work on the update
So far I have been unable to reproduce this problem. Are you guys having this issue with an empty classification.config file using JUST the new Snort GPLv2 rules by chance? They do not include any *.config nor *.map files. Just trying to get a basis for reproducing the problem.
Bill
I'm using Snort Basic VRT Rules, Snort GPLv2, and Emerging Threats rule sets. I've also noticed that auto blocking is removing IPs after 5 minutes instead of an hour. The cron job looks like this:
*/5 * * * * root /usr/bin/nice -n20 /usr/local/sbin/expiretable -t 3600 snort2c -
After updating snort and going through all the new settings it throws an error:
snort[32626]: FATAL ERROR: /usr/pbi/snort-amd64/etc/snort/snort_2226_em0/preproc_rules/decoder.rules(1) Unknown ClassType: protocol-command-decode
I have all but SIP and the three bottom preprocessors enabled.
I have ET and VRT (balanced) rules enabled.For update I did:
Remove with X on Installed Packages
Ran "find /* | grep -i snort | xargs rm -rv"
Installed snort from Available PackagesWhat am I missing? ???
Edit:
Also there's a minor issue with the formatting of the text box for Log Directory Size Limit under General Settings. 3 tab's (?) are added before the value.512 -
Fragged,
You're going to have to go to copy your classification.config file in /usr/pbi/snort-amd64/etc/snort/ and overwrite it to /usr/pbi/snort-amd64/etc/snort/snort_2226_em0/
You can simply go into the GUI and go to Diagnostics/Command and write
cp /usr/pbi/snort-amd64/etc/snort/classification.config /usr/pbi/snort-amd64/etc/snort/snort_2226_em0/
Now try to start Snort and it should start without error.
For anyone else with this issue, you're going to have to place the file in its respective directory for the snort interface you're using, so the directories for the command should be different.
find /* | grep -i classification.config -
I thought I checked the file being populated and not empty, but it seems it was indeed empty and copying it as you suggested let me to start Snort again. :-\
-
Thanks AhnHEL, I had that same issue as fragged and your suggestion solve my problem. I had the below error that prevented snort from starting.
snort[20991]: FATAL ERROR: /usr/pbi/snort-amd64/etc/snort/snort_29778_em3/rules/snort.rules(14640) Unknown rule option: 'ssl_state' -
I couldn't reproduce the issue with empty classification.config with either of my 2.1 VM's snapshot from Thu Apr 11 07:01:06 EDT 2013. Neither VM had Snort installed before. The minor issue with Global Settings -> General Settings -> Log Directory Size Limit - box is there on both boxes.
-
I'm using Snort Basic VRT Rules, Snort GPLv2, and Emerging Threats rule sets. I've also noticed that auto blocking is removing IPs after 5 minutes instead of an hour. The cron job looks like this
Are you still seeing this Cino? I'm not getting this at all using the same rulesets, same cron job.
-
I'm using Snort Basic VRT Rules, Snort GPLv2, and Emerging Threats rule sets. I've also noticed that auto blocking is removing IPs after 5 minutes instead of an hour. The cron job looks like this
Are you still seeing this Cino? I'm not getting this at all using the same rulesets, same cron job.
I did a full re-install of the package this morning.. deleted everything before hand… installed.... then i went each interface main settings page and clicked save... when to global settings... changed remove blocked ip to never, saved; then changed it back to 1 hour, saved.
so far so good.... i've ran the cron job from cmd and its not removing the ip... also, all my interfaces started without copying the classification.config file over
i should had done this the other night, but when snort goes thru changes and if you re-using your old settings... you need to re-save the settings for some reason (i think even a little xml change throws off the settings) Now keep in mind, my settings were first created a couple of years ago... but have gone thru many many tweaks while the pfsense snort package has been maturing.
great work btw!! keep it up....
-
i spoke too soon, its still removing IPs from the block list… I doesn't if you manually run the cron job
-
I just got update in rules and now I see this problem also..
snort[4656]: FATAL ERROR: /usr/pbi/snort-amd64/etc/snort/snort_33276_em0/preproc_rules/decoder.rules(1) Unknown ClassType: protocol-command-decode
I run 2.1-BETA1 (amd64)
built on Fri Apr 12 16:46:36 EDT 2013
FreeBSD 8.3-RELEASE-p7Answer to removing all of snort.
http://forum.pfsense.org/index.php/topic,60994.0.html on the top is a command you can remove all.. I had to do this couple days ago for another bug. -
Have you tried to replicate this on i386???
-
I have been unable to reproduce this particular problem on my test machines. The root cause of the error is an empty classification.config file getting copied into the interface sub-directory. The update process (or for some folks, the reinstall) seems to create a zero-length file. The quick fix is to copy the classification.config file from the /usr/local/etc/snort (or /usr/pbi/snort-{arch}/etc/snort if 2.1-BETA machine) to the interface's subdirectory under the main snort directory.
I will look through the code and see if I figure out what might be at fault. This has affected more than one person, so there is something amiss. Just not able to put my finger on it yet.
Bill
-
Out of curiosity I forced an update and it looks like my classification.config file got overwritten to be blank again. Looking at the update logs, ET and Snort VRT were already up to date and the only ruleset to get actually updated was the Community Rules.
It has automatically updated a couple of times in the last 2 days and I haven't had a problem with the classification.config file. Wondering if I just shot myself in the foot by just forcing the update.
Starting rules update... Time: 2013-04-11 00:03:00 Downloading Snort VRT md5 file... Starting rules update... Time: 2013-04-11 00:03:00 Starting rules update... Time: 2013-04-11 00:03:00 Downloading Snort VRT md5 file... Downloading Snort VRT md5 file... Checking Snort VRT md5 file... Snort VRT rules are up to date. Downloading Snort GPLv2 Community Rules md5 file... Checking Snort GPLv2 Community Rules md5. Snort GPLv2 Community Rules are up to date. Downloading EmergingThreats md5 file... Checking EmergingThreats md5. Emerging Threats rules are up to date. The Rules update has finished. Time: 2013-04-11 00:03:35 Checking Snort VRT md5 file... Snort VRT rules are up to date. Downloading Snort GPLv2 Community Rules md5 file... Checking Snort GPLv2 Community Rules md5. Snort GPLv2 Community Rules are up to date. Downloading EmergingThreats md5 file... Checking EmergingThreats md5. Emerging Threats rules are up to date. The Rules update has finished. Time: 2013-04-11 00:06:47 Checking Snort VRT md5 file... Snort VRT rules are up to date. Downloading Snort GPLv2 Community Rules md5 file... Checking Snort GPLv2 Community Rules md5. Snort GPLv2 Community Rules are up to date. Downloading EmergingThreats md5 file... Checking EmergingThreats md5. Emerging Threats rules are up to date. The Rules update has finished. Time: 2013-04-11 00:07:30 Starting rules update... Time: 2013-04-12 00:03:01 Downloading Snort VRT md5 file... Starting rules update... Time: 2013-04-12 00:03:01 Downloading Snort VRT md5 file... Starting rules update... Time: 2013-04-12 00:03:01 Downloading Snort VRT md5 file... Checking Snort VRT md5 file... Snort VRT rules are up to date. Downloading Snort GPLv2 Community Rules md5 file... Checking Snort GPLv2 Community Rules md5. There is a new set of Snort GPLv2 Community Rules posted. Downloading... Done downloading Snort GPLv2 Community Rules file. Extracting and installing Snort GPLv2 Community Rules... Installation of Snort GPLv2 Community Rules completed. Downloading EmergingThreats md5 file... Checking EmergingThreats md5. There is a new set of EmergingThreats rules posted. Downloading... Checking Snort VRT md5 file... Snort VRT rules are up to date. Downloading Snort GPLv2 Community Rules md5 file... Checking Snort GPLv2 Community Rules md5. Snort GPLv2 Community Rules are up to date. Downloading EmergingThreats md5 file... Done downloading EmergingThreats rules file. Extracting and installing EmergingThreats.org rules... Checking EmergingThreats md5. There is a new set of EmergingThreats rules posted. Downloading... Installation of EmergingThreats.org rules completed. Copying new config and map files... Done downloading EmergingThreats rules file. Extracting and installing EmergingThreats.org rules... Installation of EmergingThreats.org rules completed. Copying new config and map files... Checking Snort VRT md5 file... Snort VRT rules are up to date. Downloading Snort GPLv2 Community Rules md5 file... Checking Snort GPLv2 Community Rules md5. Snort GPLv2 Community Rules are up to date. Downloading EmergingThreats md5 file... Checking EmergingThreats md5. Emerging Threats rules are up to date. The Rules update has finished. Time: 2013-04-12 00:05:11 Updating rules configuration for: WAN ... Restarting Snort to activate the new set of rules... Updating rules configuration for: WAN ... Restarting Snort to activate the new set of rules... Snort has restarted with your new set of rules. The Rules update has finished. Time: 2013-04-12 00:05:18 Snort has restarted with your new set of rules. The Rules update has finished. Time: 2013-04-12 00:05:55 Starting rules update... Time: 2013-04-13 00:03:01 Starting rules update... Time: 2013-04-13 00:03:01 Downloading Snort VRT md5 file... Downloading Snort VRT md5 file... Starting rules update... Time: 2013-04-13 00:03:01 Downloading Snort VRT md5 file... Checking Snort VRT md5 file... There is a new set of Snort VRT rules posted. Downloading... Checking Snort VRT md5 file... There is a new set of Snort VRT rules posted. Downloading... Done downloading rules file. Downloading Snort GPLv2 Community Rules md5 file... Checking Snort GPLv2 Community Rules md5. There is a new set of Snort GPLv2 Community Rules posted. Downloading... Done downloading Snort GPLv2 Community Rules file. Extracting and installing Snort GPLv2 Community Rules... Installation of Snort GPLv2 Community Rules completed. Downloading EmergingThreats md5 file... Checking EmergingThreats md5. There is a new set of EmergingThreats rules posted. Downloading... Done downloading EmergingThreats rules file. Extracting and installing EmergingThreats.org rules... Installation of EmergingThreats.org rules completed. Extracting and installing Snort VRT rules... Using Snort VRT precompiled SO rules for FreeBSD-8-1 ... Installation of Snort VRT rules completed. Copying new config and map files... Checking Snort VRT md5 file... Snort VRT rules are up to date. Downloading Snort GPLv2 Community Rules md5 file... Checking Snort GPLv2 Community Rules md5. Snort GPLv2 Community Rules are up to date. Downloading EmergingThreats md5 file... Checking EmergingThreats md5. Emerging Threats rules are up to date. The Rules update has finished. Time: 2013-04-13 00:06:38 Updating rules configuration for: WAN ... Restarting Snort to activate the new set of rules... Snort has restarted with your new set of rules. The Rules update has finished. Time: 2013-04-13 00:07:22 Done downloading rules file. Snort VRT rules file download failed. Snort VRT rules will not be updated. Downloading Snort GPLv2 Community Rules md5 file... Checking Snort GPLv2 Community Rules md5. Snort GPLv2 Community Rules md5 file download failed. Community Rules will not be updated. Downloading EmergingThreats md5 file... Checking EmergingThreats md5. EmergingThreats md5 file download failed. EmergingThreats rules will not be updated. The Rules update has finished. Time: 2013-04-13 00:07:44 Starting rules update... Time: 2013-04-13 16:15:19 Downloading Snort VRT md5 file... Checking Snort VRT md5 file... Snort VRT rules are up to date. Downloading Snort GPLv2 Community Rules md5 file... Checking Snort GPLv2 Community Rules md5. There is a new set of Snort GPLv2 Community Rules posted. Downloading... Done downloading Snort GPLv2 Community Rules file. Extracting and installing Snort GPLv2 Community Rules... Installation of Snort GPLv2 Community Rules completed. Downloading EmergingThreats md5 file... Checking EmergingThreats md5. Emerging Threats rules are up to date. Copying new config and map files... Updating rules configuration for: WAN ... Restarting Snort to activate the new set of rules... Snort has restarted with your new set of rules. The Rules update has finished. Time: 2013-04-13 16:15:30 -
UPDATE – Never mind the request for info down below. I think I've found the issue. It's a logic bug triggered when just the Snort GPLv2 rules update. I'm not using those, and that's why I have not seen the bug. I have a paid VRT subscription, and with that there is no need to use the GPLv2 rules as well.
Let me be sure what I think is the logic flaw is really the only problem, and then I will submit a fix.
Bill
==================================
If you have not "fixed it already", can you give the timestamp from the empty classification.config file?
If you have already copied over a fresh file, can you get me the timestamp on the empty file the next time it happens? Also would be helpful to correlate that with the following information:
1. timestamp of classification.config file in the …/etc/snort directory.
2. time of the rule update (get from the log file as you showed above).
3. timestamp of empty classification.config file in the …/etc/snort/snort_xxxx_xx directory for the interface.Thanks,
Bill -
Bill, at midnight on the 12th and the 13th, the Community Rules got updated without issue. Another possible scenario seems to be at play in addition here as well.
-
I found the logic bug and just submitted a Pull Request to fix it. Hopefully one of the pfSense developers will see the request and Merge it this weekend. Once that is done, you can reinstall the package to pick up the fix. Here is a link to the Pull Request:
https://github.com/pfsense/pfsense-packages/pull/426
The bug required several things to come together at once in order to be triggered. It was a function of the rule downloads selected, and then depended on which particular set of enabled rule downloads actually had a new update. Also happened upon an unrelated copy-and-paste error that might have been responsible for the Barnyard2 problems some folks are seeing (me included). Fixed it as well, and hopefully it will address the Barnyard2 restart issues after rule updates.
You gave me the key clue when you said only the GPLv2 rules updated, and then it broke. Thanks for the hint! I replicated your setup with enabled rule sets, and then triggered an update of ONLY the GPLv2 rules. That gave me the zero-length classification.config and reference.config files in the interface sub-directory. It didn't take me long then to find the problem. I tested my fix against the same scenario, and it updated without issue.
Bill
-
Can you fix the minor bug with the text box in the attached picture. I'm not sure it it has any effect on functionality, but it can cause issues by making you think you had not set it up yet and you end up with odd values in the field.
-
Can you fix the minor bug with the text box in the attached picture. I'm not sure it it has any effect on functionality, but it can cause issues by making you think you had not set it up yet and you end up with odd values in the field.
I missed that one for the latest push, but will put it in the hopper for the next one.
Bill
-
UPDATE – Unknown ClassType: protocol-command-decode error fixed
I found and fixed the bug causing the following error:
FATAL ERROR: /usr/pbi/snort-amd64/etc/snort/snort_33276_em0/preproc_rules/decoder.rules(1) Unknown ClassType: protocol-command-decodeThe update was merged around 9:00 PM U.S. Eastern Saturday evening. The Snort package version was not bumped this time, but you can pick up the change by simply reinstalling the GUI code.
From the Installed Packages tab, click either the pkg or xml icons to reinstall the GUI components. Should be no need to delete the package and reinstall. The bug was triggered by just the right combination of enabled rule sets and which ones had an available update to download.
Once the GUI components reinstall completes, there is one more thing you should do to force a rules file update. From the Diagnostics menu, choose Edit File. Browse to your Snort base directory at the following location depending on pfSense version:
/usr/local/etc/snort – pfSense 2.0.x
/usr/pbi/snort-{arch}/etc/snort – pfSense 2.1-BETAwhere {arch} is either i386 or amd64
Open the MD5 files in the directory and simply change the last two digits of the md5 hash to something else and save the file. Do this for each MD5 rules hash file you see in the directory.
When finished, go to the Updates tab and perform an update. This will force new copies of all your enabled rule sets to be downloaded.
Bill
