[Snort-sigs] Some notes about today's VRT Rule release for 02/09/2012

Joel Esler jesler at ...435...
Thu Feb 9 18:46:11 EST 2012


On Feb 9, 2012, at 5:45 PM, waldo kitty wrote:
> On 2/9/2012 17:35, Joel Esler wrote:
>> 
>> On Thu, Feb 9, 2012 at 5:19 PM, waldo kitty <wkitty42 at ...3507...> wrote:
>>    what policy? i've understood most things up to here... we do not use any
>>    "policy" rules in our configuration... at least nothing specifically... i don't
>>    believe that we even include the policy.rules file(s)... so one has to ask, what
>>    policy? where can one see this policy? does this change blow things up like
>>    oinkmaster's disablesid option?
>> 
>> We've had three policies in the rules for some time now in the "metadata" field.
>> "policy connectivity-ips, policy balanced-ips, and policy security-ips"
> 
> yes, i've seen those but they mean nothing to me or anything i know of that we 
> use with snort... i did actually go digging about and found a post by you back 
> in aug 2001, on the 4th or 11th i think, where you did explain a bit of this...
> 
What do they mean?
I think I did a blog post on it, let me go check.. <checks>  Yes.  I talked about them here:
http://blog.snort.org/2012/01/importance-of-pulledpork.html

So, what we've done is made the default "out of the box" experience for everyone (oinkmaster, plain download, or pulledpork without policy specification) the same.  Everyone is running rules in the "balanced-ips" policy, unless, you've made modifications yourself, or are using pulledpork to run, say, the security-ips policy.

We used to have two decisions to make when we committed rules into the system.  If it was "on" or "off" (uncommented or commented) and then what policy it was in.  In the beginning the policy was only used by the Sourcefire product.  So that our users could select a policy to "start" from, and then build their layers on that. (Those of you that are Sourcefire customers reading this know what I mean when I say "layers")

Then pulledpork came along and introduced the same concept to the open source community, meaning that the open source users could then run the policies that we ship to our customers.  This left open source users in a strange state.  You could run pulledpork, select a policy, and go with that.  Running the same policies our Sourcefire customers run.  Or... You could not specify a policy (in pulledpork) and run with what was "on" or "off".  Oinkmaster didn't give you this option, you only got "on" or "off".

Now, everyone is the same.  When we commit rules into the system, if it's in balanced or connectivity, we turn the rule on by default.  If it's only in security, or in no policies at all, it's off by default.

If you want to run a different policy besides "balanced" then you'd probably want to use pulledpork.

>> This change will not affect Oinkmaster at all.  In fact, those of you that were
>> using things other than PulledPork that didn't have flowbit auto-resolution or
>> policy enforcement are now running the exact same policies (and dependancies)
>> that those that are.  That's what we mean by "leveling the playing field".
> 
> ok... i'm still not sure what "playing field", though ;)

See above.  

> 
>> Actually, Waldo, you were one of the people specifically we had in mind when we
>> made this "fix", since you can't run PulledPork.
> 
> understood and i thank you... but i'm not sure, yet, how it is going to effect 
> my setup... i'll find out soon enough if things that were working properly are 
> suddenly getting blocked by the active response system or not blocked by it when 
> it should be...

You should be running less overall rules now. Should be fast and have good detection across the board.

--
Joel Esler
Senior Research Engineer, VRT
OpenSource Community Manager
Sourcefire





More information about the Snort-sigs mailing list