[Snort-sigs] Snort.org Blog: The importance of PulledPork
jesler at ...435...
Mon Jan 23 14:47:51 EST 2012
The importance of PulledPork
Bottom line up front: If you aren't using PulledPork, you are going to have a gigantic depreciation in functionality.
You've heard it said on the Snort lists, you've heard it on this blog, you've heard it on Twitter, you've heard it from CNN... okay, well, not CNN..
The importance of PulledPork.
The reason that we are very heavily insist that you are using pulledpork is primarily for two very big reasons:
• Flowbit auto-resolution
• Default Policy usage
• The first reason: Flowbit auto-resolution
I've written in great length about the need for flowbits, you can find a couple of my blog posts here
The reason that I'm writing about it again, is that to refresh your memory back when we created the file-identify rule category:
We outlined that part of this conversion was to move all flowbit names from their old names (such as http.gif) to a new format (now file.gif). This project has now been completed and all flowbits across all files have been moved to the new format, and all the rules that "set" flowbits have been commented to be "off" by default and in no policies.
What we are relying on here is either if you are using PulledPork or the Sourcefire product, you either select your base policy (which I'll talk about in section two), or, even if you don't, PulledPork will auto-resolve the flowbit "set" names that you'll need and go through and turn those on for you. That way you are only running rules that you need to have on based upon either the policy you are running, or the state of the rules. We really insist that you use the disablesid and enablesid functionality in PulledPork to be able to turn the rules that you WANT for your environment on and let PulledPork auto-resolve all the dependancies you need for you.
• The second reason: Policy usage
There are four states that we place rules in when we create them, three of the states are assigned to policies.
The last state is "in no policies".
The last state is "in no policies". This means that we insist that you look through these by product name or CVE in order to turn them on. These may not have a fast content match, could be false positive prone, or the vulnerability it is covering is not in a very prevalent piece of software.
The way we make the decision about what is "on" or "off" by default when you aren't using the policies, is, if it's in balanced, it's on by default, it's it not in balanced, it's off by default. There are a ton of exceptions to this rule, but this is the general rule of thumb.
More information about the Snort-sigs