Snort Unknown rule option: 'ssl_version'.

peffyes

I found that snort had died, and wouldn't restart. Checking the log showed:

snort[91913]: FATAL ERROR: /usr/pbi/snort-i386/etc/snort/snort_23121_em0/rules/snort.rules(2602) Unknown rule option: 'ssl_version'.

So I ssh'ed in, and looked at the snort.rules file. There were two entries from the emerging-current_events.rules that referenced ssl_version.

SID 2019417 ET CURRENT_EVENTS excessive fatal alerts (possible POODLE attack against client)
SID 2019418 ET CURRENT_EVENTS SSL excessive fatal alerts (possible POODLE attack against server)

I disabled them from the WAN rules config on my system, and all is now running.

pfsense ver 2.1.5-RELEASE (i386)
Snort 2.9.6.2 pkg v3.1.5

The ssh preprocessor is enabled.

I posted here as I wasn't able to find anything helpful on this, only a couple year old thread ( https://forum.pfsense.org/index.php?topic=51493.180 )

Don't know if this helps anyone, but those two rules really break things for me!

bmeeks

Check the SSL preprocessor, not SSH. The SSL preprocessor is enabled by default. Make sure it has not gotten inadvertently turned off in your setup. It's on the PREPROCESSORS tab down near the bottom of the page in the section header "General Preprocessors".

Bill

fsansfil

And I would not disable those rules if I were you…

http://arstechnica.com/security/2014/12/meaner-poodle-bug-that-bypasses-tls-crypto-bites-10-percent-of-websites/

F.

peffyes

I went back and checked, and sure enough, the SSL preprocessor option had gotten turned off somehow. Of course, enabling it allows the rules to run again.

Not sure how that happened, or how I missed it, but TYVM bmeeks!

@fsansfil:

And I would not disable those rules if I were you…

http://arstechnica.com/security/2014/12/meaner-poodle-bug-that-bypasses-tls-crypto-bites-10-percent-of-websites/

F.

I would disable them, since:
1)POODLE 2.0 only affects load balancers from specific vendors and not the protocols in general
2)SSL went away already (major browser/email client vendors already dropped it)

peffyes

I just had snort on another pfsense firewall die with the same error. Checked the preprocessor options, and SSL was set to on. Restarting snort failed with the same error. So I unchecked the SSL preprocessor, saved the config, checked it back on, saved the config again and restarted snort. The service started right up no issues. Just wonder whats happening with that…

bmeeks

@smarc:

I just had snort on another pfsense firewall die with the same error. Checked the preprocessor options, and SSL was set to on. Restarting snort failed with the same error. So I unchecked the SSL preprocessor, saved the config, checked it back on, saved the config again and restarted snort. The service started right up no issues. Just wonder whats happening with that…

Thanks for the more detailed troubleshooting info. I will look into this some more. So it sounds like you essentially had to toggle it "off", save it, then toggle it back "on" and save it in order for it to really stick. That should not be necessary, so I check into that section of code.

Bill

Supermule

Did the same and the SSL Preproc came back online no issues.

peffyes

Yes, that's exactly right. You stated it more clearly then I did! And thanks!

@bmeeks:

@smarc:

I just had snort on another pfsense firewall die with the same error. Checked the preprocessor options, and SSL was set to on. Restarting snort failed with the same error. So I unchecked the SSL preprocessor, saved the config, checked it back on, saved the config again and restarted snort. The service started right up no issues. Just wonder whats happening with that…

Thanks for the more detailed troubleshooting info. I will look into this some more. So it sounds like you essentially had to toggle it "off", save it, then toggle it back "on" and save it in order for it to really stick. That should not be necessary, so I check into that section of code.

Bill

bmeeks

@Supermule:

Did the same and the SSL Preproc came back online no issues.

Glad it fixed yours as well. Might be an issue of looking for "on" versus "enabled" in the code when checking if the preprocessor should be on or off. I will investigate it further.

Bill