Snot not starting: Invalid argument to 'server_flow_depth'.
-
Thanks for the heads up.
I cleared the system log and tried a snort start:
Mar 27 10:33:48 pfsense syslogd: kernel boot file is /boot/kernel/kernel Mar 27 10:33:48 pfsense kernel: pid 11647 (syslogd), uid 0: exited on signal 11 Mar 27 10:34:17 pfsense php: /snort/snort_interfaces.php: Toggle(snort starting) for WAN(SNORT on WAN)... Mar 27 10:34:18 pfsense php: /snort/snort_interfaces.php: Checking for and disabling any rules dependent upon disabled preprocessors for WAN... Mar 27 10:34:23 pfsense php: /snort/snort_interfaces.php: Resolving and auto-enabling flowbit required rules for WAN... Mar 27 10:34:27 pfsense snort[50575]: FATAL ERROR: /usr/local/etc/snort/snort_52289_pppoe0/preproc_rules/preprocessor.rules(213) Unknown ClassType: sdf Mar 27 10:34:27 pfsense snort[50575]: FATAL ERROR: /usr/local/etc/snort/snort_52289_pppoe0/preproc_rules/preprocessor.rules(213) Unknown ClassType: sdf Mar 27 10:34:27 pfsense php: /snort/snort_interfaces.php: Interface Rule START for SNORT on WAN(pppoe0)...
EDIT: some time later… I suppose the "sdf" listed above refers to:
Enable Sensitive Data: Sensitive data searches for credit card or Social Security numbers in data
Because once I enable that preprocessor snort fails to start.
EDIT2: Bill: Thanks for the catch on the 65535 value! That helped.
-
I'm confused on one point. Can you clarify the following for me?
Does Snort run WITH the Sensitive Data preprocessor enabled, or only WITHOUT it being enabled?
This line from your logs is the problem –
Mar 27 10:34:27 pfsense snort[50575]: FATAL ERROR: /usr/local/etc/snort/snort_52289_pppoe0/preproc_rules/preprocessor.rules(213) Unknown ClassType: sdf
Are you using only the Emerging Threats rules and no Snort VRT rules? "ClassType:" refers to the classification information in the file classification.config in the snort directory. Only the file included with the Snort VRT rules contains the proper classification information for the Sensitive Data preprocessor. The file included with the ET Rules does not contain the sdf parameter.
Or stated another way, you can ONLY use and enable the Sensitive Data Preprocessor when you are using the Snort VRT rules (the ones you get as a registered free user, or a subscribing paid user, at Snort.org). If you turn on the Sensitive Data Preprocessor without using the VRT rules, then you will get the crash. I suppose I can make Snort "smarter" in this area and disable the Sensitive Data Preprocessor when only the ET rules are downloaded.
Bill
-
Since the change in format on the Snort VRT rules, I haven't run Snort rules and only run ET rules (until a month after the paid ones become free). I don't use the paid Snort VRT rules, at the moment, but am now "seeing the light".
I did not not know that I had to run the Sensitive Data Preprocessor only with the Snort VRT rules.
I hope I didn't waste much of your time tracking down a non-issue. Thank you for the education on relationship between the Sensitive Data Preprocessor and the Snort VRT rules. If I weren't such a cheapskate I could have bought the Snort rule membership and avoided this whole thread. :-[
Thanks for your time.
-
-
That would be a great addition to Snort! That you cant enable things if they are not related to what you run or how you subscribe!
I'm confused on one point. Can you clarify the following for me?
Does Snort run WITH the Sensitive Data preprocessor enabled, or only WITHOUT it being enabled?
This line from your logs is the problem –
Mar 27 10:34:27 pfsense snort[50575]: FATAL ERROR: /usr/local/etc/snort/snort_52289_pppoe0/preproc_rules/preprocessor.rules(213) Unknown ClassType: sdf
Are you using only the Emerging Threats rules and no Snort VRT rules? "ClassType:" refers to the classification information in the file classification.config in the snort directory. Only the file included with the Snort VRT rules contains the proper classification information for the Sensitive Data preprocessor. The file included with the ET Rules does not contain the sdf parameter.
Or stated another way, you can ONLY use and enable the Sensitive Data Preprocessor when you are using the Snort VRT rules (the ones you get as a registered free user, or a subscribing paid user, at Snort.org). If you turn on the Sensitive Data Preprocessor without using the VRT rules, then you will get the crash. I suppose I can make Snort "smarter" in this area and disable the Sensitive Data Preprocessor when only the ET rules are downloaded.
Bill
-
That would be a great addition to Snort! That you cant enable things if they are not related to what you run or how you subscribe!
I will incorporate this level of "smart" into the next GUI update. I'm working on some package improvements now.
1. First and foremost is trying to make the uninstall and reinstall work much cleaner.
2. Correcting the problem with viewing the Update Log on the Updates tab.
3. Adding greater intelligence to the GUI tab for Preprocessors so it will automatically disable things not related to the rule set you are running. One example is disabling the Sensitive Data Preprocessor if you are not running Snort VRT rules.
Once I finish up and get these changes tested out in my VMware environment, I will submit Pull Requests via Github for the pfSense developer team to evaluate and hopefully accept.
Bill
-
Sounds like a plan Bill!!
-
Off topic Bill, but have you seen the Community Rules feature that Snort has just implemented?
http://blog.snort.org/2013/03/the-sourcefire-vrt-community-ruleset-is.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+Snort+%28Snort%29
-
Thats a brilliant idea!!
-
Off topic Bill, but have you seen the Community Rules feature that Snort has just implemented?
http://blog.snort.org/2013/03/the-sourcefire-vrt-community-ruleset-is.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+Snort+%28Snort%29
Interesting concept, indeed! I had seen a reference to it in the recent past, but did not read up on the details. Sounds like some direct competition for the Emerging Threats rules… ;)
I see no reason this could not be incorporated into the Snort package. Need a little time to experiment with it and see how to integrate it without breaking the current VRT and Emerging Threats. I have some other updates to the GUI in the works at the moment to address known issues. Once those are released, then I can look at incorporating the Snort Community Rules.
Bill
-
When it comes time for testing I can contribute the "idiots guide" approach for ya'll. :P
-
Once those are released, then I can look at incorporating the Snort Community Rules.
Awesome, thank you.
-
Me to :D
When it comes time for testing I can contribute the "idiots guide" approach for ya'll. :P
-
Off topic Bill, but have you seen the Community Rules feature that Snort has just implemented?
http://blog.snort.org/2013/03/the-sourcefire-vrt-community-ruleset-is.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+Snort+%28Snort%29
FYI. I now have this functionality working in my latest test build of the Snort GUI. Hope to push the commit to Github soon for Ermal and the pfSense Core Team to look over. Besides adding Snort GPLv2 Community Rules support, I've made the update process quite a bit more "robust" and added logging of the updates. I also fixed that stubborn "greyed-out" button on the Updates tab for viewing the update logs.
I also found the cause of the Signal 11 exits with preprocessors enabled (specifically the http_inspect preprocessor). It is a quirk in the PBI package and the way it creates symbolic links upon Snort installation on the 2.1-BETA platform. I will try and figure out the correct lines to change in the PBI build script to correct this and submit those as well.
I've also tried my best to find all the "traps" in the code that were causing issues for users. Turns out, upon close examination, there are several paths to a given final configuration, but some of those paths could be a source of future issues if taken out of a particular order. That statement may not make perfect sense, but basically there were ways available in the GUI for an unsuspecting user to inadvertently shoot themselves in the foot. I'm in my testing phase now trying about every scenario I can envision for adding, removing and editing interfaces and rule sets to Snort. With each iteration, I'm trying to make sure you can't break it by doing stuff in the GUI. This is the whole "adding intelligence to Snort" I spoke of in an earlier post.
Finally, I've made a couple of tweaks to the package reinstall process that I hope will prevent future broken installs.
Bill
-
Thanks Bill for your continued effort.
Aaron
-
FYI. I now have this functionality working in my latest test build of the Snort GUI.
Wow, that was fast Bill. Excellent work, cant wait to try out all the new improvements. Any idea when the 2.9.4.1 rules for registered users will be released?
-
Any idea when the 2.9.4.1 rules for registered users will be released?
I would think 30 days past the first release of the 2.9.4.1 code base and its package. Snort 2.9.4.1 was released on March 4, 2013. So I expect the 2.9.4.1 rules to become available for free, registered users on April 4, 2013.
Bill
-
FYI. I now have this functionality working in my latest test build of the Snort GUI.
Wow, that was fast Bill. Excellent work, cant wait to try out all the new improvements.
Here is a link to my Github repository showing my latest changes:
https://github.com/bmeeks8/pfsense-packages/commits/master
You can look at the Commit History. Changes after March 22 have NOT yet been submitted to the pfSense team. I hope to do that in a day or two.
Bill