Re: same question about snort rules

[rmkml <rmkml () yahoo fr>]

contacted vrt privately at May 14 22:53:09 2010...
Patrick answered my question.
Rmkml


On Thu, 4 Aug 2011, rmkml wrote:

> Hi,
> Excuse me but I have previously writed privately to VRT for this subject, 
> because extraneous pcre are exclusively on netbios.rules:
> grep -h -P "pcre:\"\/\^\.\{\d+\}\/R\";" seu481/*|grep -P "^alert" |wc -l
> 46
> grep -h -P "pcre:\"\/\^\.\{\d+\}\/R\";" seu481/netbios.rules|grep -P 
> "^alert" |wc -l
> 46
> VRT clearly have not fixed this...
> Regards
> Rmkml
>
>
> On Thu, 4 Aug 2011, Joel Esler wrote:
>
> > That's not specifically part of the three projects that I have, but I'll 
> > take a look at what you are saying and see if it makes sense.
> > Thanks.
> > Joel
> >
> > On Aug 4, 2011, at 1:47 PM, Will Metcalf wrote:
> >
> > > While your reorganizing the entire rule-set, mind doing a bit of house
> > > cleaning?  I can't think of any reason why the inspection pointer
> > > should be moved with pcre /^.{number of bytes}/R you can accomplish
> > > the same thing with distance/within for content matches or
> > > byte_test/byte_jump with offset,relative modifiers etc. I'm sure that
> > > you are aware unnecessarily invoking PCRE is the devil when it comes
> > > to perf.
> > >
> > > grep -h -P "pcre:\"\/\^\.\{\d+\}\/R\";" /opt/snort2905/etc/vrt/* |
> > > grep -P "^alert" |wc -l
> > > 47
> > >
> > > On Thu, Aug 4, 2011 at 12:27 PM, Joel Esler <jesler () sourcefire com> wrote:
> > > > On Aug 3, 2011, at 11:53 PM, Zhuxian wrote:
> > > >
> > > > > 1. Does snort provide the test tools and test model to test these rules?
> > > >
> > > > Snort is the way to make sure the rules are correct and Snort starts, if 
> > > > you are looking at how to test the rules themselves.
> > > >
> > > > > Or is there any suggested tools to test these rules?
> > > >
> > > > If you are looking to test the detection the rules provide, you can look 
> > > > at tools like metasploit and other pen-testing tools.  We use the same 
> > > > tools to test Snort and our rulesets (and a few more) that a lot of you 
> > > > use, so the results should be the same.
> > > >
> > > > > <snip>
> > > >
> > > > > 2. Some rules are commented in rules file released by snort. Does this 
> > > > > means these are the default rules setting for snort?
> > > >
> > > > So, there are the connectivity over security (connectivity-ips), balanced 
> > > > (balanced-ips), and Security over connectivity (security-ips) policies. 
> > > > We have criteria (performance, detection, in the wild, etc) for what 
> > > > rules go into what policies.  We are currently examining ways to expose 
> > > > that criteria to the end user.  We have a method for how to do it, I just 
> > > > haven't had a chance to finish the project plan yet.  :)  The VRT makes 
> > > > this determination when we write the rule and then the determination is 
> > > > double checked when the rule is committed into the set.
> > > >
> > > > Then we have if the rule is "on" or "off" (not-commented out vs. 
> > > > commented out), this is also for performance, detection, in the wild, 
> > > > etc.  And as I said, we are working on ways to expose this to the user. 
> > > > The policies override the default on/off. But the default on/off is there 
> > > > for people who do not use the pulledpork (and Sourcefire) features of 
> > > > those products to use one of the three policies.
> > > >
> > > > The three policies are a basis start point, then you tune from there.
> > > >
> > > > > Is their any references or guides for the customer to tune the rule set?
> > > >
> > > > We don't have a formal written guide for people to tune the rule set for 
> > > > Snort.  Might be a good idea.
> > > >
> > > > However, we are currently working on a project within the VRT to 
> > > > reorganize the entire ruleset into something that makes more sense for 
> > > > the end user and makes the ruleset easier to tune, both from a starting 
> > > > point, and from a continuation point (as rule updates are downloaded). 
> > > > This project plan I am currently working on, and we are going to be 
> > > > working on it through 2011 (it's a large change).  I will keep the Snort 
> > > > community updated through blog posts on http://blog.snort.org as the 
> > > > project progresses.
> > > >
> > > > Joel

------------------------------------------------------------------------------
BlackBerry&reg; DevCon Americas, Oct. 18-20, San Francisco, CA
The must-attend event for mobile developers. Connect with experts. 
Get tools for creating Super Apps. See the latest technologies.
Sessions, hands-on labs, demos & much more. Register early & save!
http://p.sf.net/sfu/rim-blackberry-1
_______________________________________________
Snort-sigs mailing list
Snort-sigs () lists sourceforge net
https://lists.sourceforge.net/lists/listinfo/snort-sigs
http://www.snort.org