snort-sigs February 2011 archive
Main Archive Page > Month Archives  > snort-sigs archives
snort-sigs: Re: [Snort-sigs] oinkmaster vs pulled port, round tw

Re: [Snort-sigs] oinkmaster vs pulled port, round two:

From: Jason Wallace <jason.r.wallace_at_nospam>
Date: Thu Feb 10 2011 - 17:52:17 GMT
To: Joel Esler <jesler@sourcefire.com>

Regarding round 1:

I don't think it has been mentioned, but you can turn off/on all the
rules in an original rule file using the "categories" method in the PP
config files (ie. web-iis,shellcode,smtp)

<Skipping round 2>

Round 3:

The biggest problem I run into with PP is that there is only one
enable and one disable pass. You can pick what order they happen in
but you only get one shot at each state process. I think there needs
to be 3 state change steps.

Ether:
disable, enable, disable
or
enable, disable, enable

The original rule files ship with some rules on and some rules off so,

Situation 1 - order: disable,enable

Using categories, you disable all rules except the "blacklist" and "botnet-cnc".
Using categories, you enable all the "blacklist" and "botnet-cnc" rules.
At this point you are stuck. There is no easy way to disable an
individual rule in either the "blacklist" or "botnet-cnc" rulesets.

Situation 2 - order: enable,disable
Using categories, you enable all the "blacklist" and "botnet-cnc" rules.
Using categories, you disable all rules except the "blacklist" and "botnet-cnc".
At this point you are stuck. There is no easy way to enable a handful
of rules from any of the other rulesets.

Fix: command line option to set the initial state of all rules

Fix 1 - order: --all-on, disable,enable

Turn everything on.
Using categories, you disable all rules except the "blacklist" and "botnet-cnc".
At this point, you are at the end state of both Situation 1&2, but you
have another enable step at your disposal. You can now enable a
handful of rules in other files if you want. This solves the problem
in Situation 2.

Fix 2 - order: --all-off, enable, disable

Turn everything off.
Using categories, you enable all the "blacklist" and "botnet-cnc".
At this point, you are at the end state of both Situation 1&2, but you
have another disable step at your disposal. You can now disable rules
in the "blacklist" and "botnet-cnc" sets if you want. Solves Situation
1. You could also enable a few rules in the other files with the
single enable step too. Solves Situation 2.

Looks like just adding an --all-off option is what is really needed.

Wally

On Thu, Feb 10, 2011 at 11:33 AM, Joel Esler <jesler@sourcefire.com> wrote:
> Not a bad idea.  Can you submit that as a feature request on the pulledpork
> site?
> Joel
> On Feb 10, 2011, at 10:20 AM, Michael Scheidell wrote:
>
> I think round one was a draw.
> some people want the rules in their original files, some would like them in
> easier managed 'single file'
>
> I can see with PP, how being able to disable a RULE in, say snort_lan.conf
> vs disabling a whole rule set would have its advantages.
> I can see how you might want to manage your main distribution point with
> oinkmaster.
>
> round 2: licensing, copyrights:
> our situation:
> we pull down VRT rules (licensed), run oinkmaster on them to set up 'our
> tweaks' to the rules, then create a tarball (./rules/*.rules)
> each individual snort sensor BOX runs a local copy of oinkmaster, to pull
> down our tarball and add local oinkmaster.conf tweaks to it.
>
> I assume that even if I go with PP on the individual sensors (which seems to
> give me more flexibility, see round 1), that I still would need oinkmaster
> for the first step.
>
> Also, how would PP preserve the copyright and license agreements that are in
> each rule file?
> I believe that, even though we are licensed to redistribute VRT rules (and
> pay for each sensor...), we are required to leave the license and copyright
> notices there.
>
> this would apply to VRT rules, GPL(2,3,) lesser, apache, anything, right?
>
>
> this still makes PP vs oinkmaster, round two a draw.  PP can't preserve the
> copyright/license, oinkmaster can. so, on main distribution point, we still
> would need oinkmaster.
>
>
> --
> Michael Scheidell, CTO
> o: 561-999-5000
> d: 561-948-2259
> ISN: 1259*1300
>> | SECNAP Network Security Corporation
>
> Certified SNORT Integrator
> 2008-9 Hot Company Award Winner, World Executive Alliance
> Five-Star Partner Program 2009, VARBusiness
> Best in Email Security,2010: Network Products Guide
> King of Spam Filters, SC Magazine 2008
>
> ________________________________
>
> This email has been scanned and certified safe by SpammerTrap®.
> For Information please see http://www.secnap.com/products/spammertrap/
>
> ________________________________
> ------------------------------------------------------------------------------
> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> Pinpoint memory and threading errors before they happen.
> Find and fix more than 250 security defects in the development cycle.
> Locate bottlenecks in serial and parallel code that limit performance.
> http://p.sf.net/sfu/intel-dev2devfeb_______________________________________________
> Snort-sigs mailing list
> Snort-sigs@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/snort-sigs
> http://www.snort.org
>
> --
> Joel Esler
> jesler () sourcefire.com
> http://blog.snort.org && http://blog.clamav.net
>
> ------------------------------------------------------------------------------
> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> Pinpoint memory and threading errors before they happen.
> Find and fix more than 250 security defects in the development cycle.
> Locate bottlenecks in serial and parallel code that limit performance.
> http://p.sf.net/sfu/intel-dev2devfeb
> _______________________________________________
> Snort-sigs mailing list
> Snort-sigs@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/snort-sigs
> http://www.snort.org
>
>

------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
_______________________________________________
Snort-sigs mailing list
Snort-sigs@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/snort-sigs
http://www.snort.org