Snort 2.9.4.1 pkg v. 2.5.5 Issue(s)
-
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