@Nadrek:
That's a limitation indeed - would it be possible for the GUI to detect (parse the system log, perhaps) a failure to start SNORT, figure out which ruleset it was, and then change the snort.conf file to disable that ruleset while recording the hash of it, and when the hash changes, re-enable and then process normally (including, again, the disable on crash due to ruleset)?
No, the GUI can't do this except during manual rule updates. See, the GUI code is not even running once you leave the Snort menus. All those web page sessions in the GUI are essentially stateless. When you exit the page or browse to another menu, that former PHP GUI process shuts down. The automatic rule updates are done entirely via a cron job. Trying to figure out which rule failed is a big effort. I just don't think that is practical. After all, this problem with a corrupted rules file has only happened once in the year I have been quasi-maintaining the Snort package.
A better solution is for someone to create a service monitoring package for pfSense. You could load it with the services you want monitored, and then on some interval it could canvass the running processes (services) to see what is and is not running. It could either attempt a restart of dead services, or raise an alert or alarm if one won't restart. Maybe something like this exists and I'm just not aware of the package?
Bill
