Snot not starting: Invalid argument to 'server_flow_depth'.

awsiemieniec

pfSense 2.0.2-RELEASE (amd64)
Snort 2.9.4.1 pkg v. 2.5.4

Thanks for your help.

/usr/local/etc/snort/snort_23789_pppoe0/snort.conf is up on pastebin here: http://pastebin.com/ML96hwBL

bmeeks

pfSense 2.0.2-RELEASE (amd64)
Snort 2.9.4.1 pkg v. 2.5.4

Thanks for your help.

/usr/local/etc/snort/snort_23789_pppoe0/snort.conf is up on pastebin here: http://pastebin.com/ML96hwBL

Per your posted snort.conf file, your flow depth is set for 65536. That is one byte too high. The max is 65535. Manually edit the server flow depth value to 65535 and Save. Then restart Snort.

awsiemieniec

It's working again.

I just uninstalled via the GUI package manager, then went into /usr/local/etc/ and removed everything that had "snort" in it (directories), and then went back in the GUI and installed via the Available Packages.

Thx for taking the time…

bmeeks

@awsiemieniec:

It's working again.

I just uninstalled via the GUI package manager, then went into /usr/local/etc/ and removed everything that had "snort" in it (directories), and then went back in the GUI and installed via the Available Packages.

Thx for taking the time…

You are welcome. I'm working on improving the de-install and re-install routines a bit to try and prevent the issues folks are having with package updates. As Ermal mentioned on another thread, the Snort package is in need of some tender loving care to make it more resilient. As you probably know, development work on the package has been sporadic. As far as I can tell, the original developer of the package has not worked on it for more than a year. Ermal made some updates in the middle of last summer. I came along and added the VRT IPS Policy selection code, auto-flowbit resolution code, and automatic disabling of preprocessor-dependent rules when the associated preprocessor is not enabled. These updates were added in late January of this year.

Bill

awsiemieniec

Bill and Ermal -
Thanks for the assistance on the Snort package.

I spoke too soon about all working fine. I did reinstall and run Snort and it worked, then I went back and added the preprocessors and more of the Emerging Threats rules and then it failed to start again - same issue. I'm working on which setting withing the GUI kills the process form starting up again. I'm going one by one… I'll post back when I've narrowed down the culprit.

Thanks again.

Aaron

bmeeks

Look in the logs. It should tell you which thing killed Snort on startup. Post back with the error message from the system log.

awsiemieniec

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.

bmeeks

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

awsiemieniec

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.

bmeeks

@awsiemieniec:

Thanks for your time.

No problem. You are most welcome.

Bill

Supermule

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!

@bmeeks:

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

bmeeks

@Supermule:

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

Supermule

Sounds like a plan Bill!!

AhnHEL

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

Supermule

Thats a brilliant idea!!

bmeeks

@AhnHEL:

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

awsiemieniec

When it comes time for testing I can contribute the "idiots guide" approach for ya'll. :P

AhnHEL

@bmeeks:

Once those are released, then I can look at incorporating the Snort Community Rules.

Awesome, thank you.

Supermule

Me to :D

@awsiemieniec:

When it comes time for testing I can contribute the "idiots guide" approach for ya'll. :P

bmeeks

@AhnHEL:

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