SNORT - Unknown clastype sdf
-
Hi,
I keep on getting this error periodically. The fix is simple, browse to
/usr/local/etc/snort/snort<interface>/</interface>
edit the file
classification.config
and add
"config classification: sdf,Sensitive Data,2"
So that fixes the problem and that works for a seemingly random time. Then all of a sudden I'll wake up like I did this morning and find that snort has failed to re-start. My guess is at some point somewhere it's either updating this file as part of the standard updates process or it copying a backup of a file from somewhere and overwriting the one I'm editing. So why is this happening and how can I stop it doing this on a more permanent basis?
Thanks
G
-
I've discovered an issue with Snort on pfSense when you run both the Emerging Threats and VRT rules. The automatic rules update routine is not smart enough to merge and build some important files with both rule sets enabled. These files are sid-msg.map, classification.config and reference.config. The current code just unzips the tarball from the rules download, and overwrites the existing files with the new ones.
The problem occurs when both ET and VRT rules are enabled. Say you have an update available for both rule sets. The code does them one at the time, so the last rule set unpacked and copied is the one who's *.config and *.map files get copied and used. This causes the problem you are seeing. It also causes barnyard2 to not have all of the correct descriptions to go along with the rule SIDs. This shows up when barnyard2 logs to a database, for example.
There are perl scripts out there that handle this dual rule set problem, but integrating them into pfSense is tricky. The two most popular scripts are Pulledpork and Oinkmaster.
I am currently working on a code revision to the Snort auotmatic rules update on my pfSense box that will mimic what Pulledpork and Oinkmaster do in terms of building the correct sid-msg.map and *.config files. I have a prototype working and am currently refining it. I will be happy to post my files when I'm done. Also, if someone will enlighten me on the process for doing so, I will submit my changes to the pfSense team for consideration to be incorporated into the Snort package. I've also discovered a few missing configuation elements in the snort.conf file for the various pre-processors. I have a fix for them as well that I will include.
Bill
-
Excellent. Huge thanks for your response. I'd actually decided a couple of days ago to disable the sdf setting so the problem went away permanently. I'd prefer to lose those rules (which are 99% only useful in the US anyway) than suffer Snort being down until I happened to notice it.
Perhaps an obvious question but as Pulledpork is the officially condoned/sanctioned method for pulling updates for Sonrt and dealing with all this, why isn't that integrated into the pfSense Snort package? Seems a little daft to be doing something bespoke for pfSense when I would have assumed it would be a LOT easier to just shoehorn PP into PF.
Thanks again and I'll look forward to your patch files.
Thanks
G
-
Perhaps an obvious question but as Pulledpork is the officially condoned/sanctioned method for pulling updates for Sonrt and dealing with all this, why isn't that integrated into the pfSense Snort package? Seems a little daft to be doing something bespoke for pfSense when I would have assumed it would be a LOT easier to just shoehorn PP into PF.
Pulledpork is a PERL script, and I think there can be some difficulty getting it working on pfSense (but not impossible). Some other difficulties arise with the way Pulledpork handles updates as essentially a command-line script versus the built-in PHP pages that are called from a cron job on pfSense when Snort is installed. At least one user on the forums here did get Pulledpork installed and working, but he had to disable completely the updates in the web GUI. You also should not use the GUI update tab if Pulledpork is installed.
I'm hoping my solution will preserve the web GUI interface while still allowing proper generation of the map and config files when using more than one rule set in Snort.
-
That makes an assumption that you are putting both on.
I was talking more generally about the way it's done in pfSense in the Snort package. Why not just rip out all the proprietary code pf uses in the Snort package and replace it wholesale with one based and built on Pulledpork? It just seems to be duplicating code to do something thats already done (if not better at least officially) elsewhere. Done right it would mean the whole updating script maintenance would likely go away (as long as you kept PP pure and update from official mirrors I assume it hugely unlikely to break)
As you say, at least one person has it working, so it's not a technical issue (at least not directly). The PHP could just be changed to instantiate PP instead of it's own code.
Appreciate I'm GROSSLY trivialising the work involved and it's probably just not worth the effort as it works perfectly fine for most people so why bother. That kind of situation never stops me from asking the questions though ;)
Thanks again for your response.
G
-
I agree with you on scrapping the current built-in Snort rule update process and turning it into a pure PulledPork process. However, I'm not skilled enough in programming the web GUI in pfSense to pull this off yet. I'm just trying for now to work within the boundaries of what's there already.
The best process for the future is to strip out the GUI update code and just run PulledPork. Perhaps a little bit of web GUI code can be put in to "manage" the PulledPork configuration. Its configuration is really just a single text-based file called pulledpork.conf.