Re: sid:13272; rule is not so good

[Joel Esler <jesler () sourcefire com>]

SEU is our internal Sourcefire product name for rule releases.  That rule was also written 4 years ago, while that's no 
excuse, the knowledge continually evolves, (as do the detection features in Snort) for how to make things faster.  We 
consistently review the performance of rules and upgrade them as necessary.  We also welcome and review all submissions 
to us to make things faster and improve detection.  We can replicate tons of different types of networks, but our 
customers have much more coverage of different types of traffic than we do.

As far as UAT, we test our rules in many different types of environments before release.  Both test environments and 
live environments.  We are also increasing this coverage with the VRT Rule test group that is in the process of being 
rolled out.

As far as responding to false positives and bad performance, we field requests from customers through our support 
department, via email at fp[at]sourcefire.com, and our submission interface http://snort.org/uploads.  We respond with 
improvements to our rule, false positive analysis, and other comments about the vulnerability when we receive this 
information, and generally update the rule (if possible) to handle the FP case in the very next rule release.  We 
generally provide the updated to rule the customer that requested it right away.  I don't know if your engineers 
provide feedback on rules, but we'd be glad to welcome it at the above link, if they are indeed submitting feedback to 
you that much, we'd welcome the feedback as well.

We release detection for MS Tuesday vulnerabilities the very same day that Microsoft releases their protection.  We are 
always one of the first IPS vendors to do so and have a bigger depth of coverage.  If new ways of exploiting a 
vulnerability is released, we cover this right away.  

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



On Dec 6, 2011, at 3:59 PM, Miso Patel wrote:

> Thanks you.  I am not sure what SEU is but this (along with year end
> projects and future planning for 2012/goals) has got me thinking ...
> why then did this rule make it into the release to begin with?  What
> UAT does the rules go thru?
>
> For a while now I have been thinking about and have not yet pulled the
> trigger on the Emerging Threats Pro rules?  Does anyone have
> experience with these or recommend them?  I am getting tired of my
> engineers coming to me and showing such bad snort performance
> profiling from VRT rules.  There has to be a better way and I don't
> have the staff/budget to hire my own IDS QA special engineer right
> now.
>
> Thanks.
>
> Miso, CISO
>
> On 12/6/11, rmkml <rmkml () yahoo fr> wrote:
> > Hi Miso,
> > Can you upgrade this rule to last revision (5) please?
> > Appear on SEU 501 at 22 sep 2011.
> > Regards
> > Rmkml
> >
> >
> > On Tue, 6 Dec 2011, Miso Patel wrote:
> >
> > > My engineers say rule sid:13272; is not performing good.  Here is it:
> > >
> > > misc.rules:alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any
> > > (msg:"MISC Microsoft Windows ShellExecute and IE7 mailto url handling
> > > code execution attempt"; flow:to_client,established;
> > > content:"mailto|3A|";
> > > pcre:"/[^\n]*?[\x25\x22]\x2E(com|bat|cmd|exe)/Ri"; metadata:policy
> > > security-ips drop, service http; reference:bugtraq,25945;
> > > reference:cve,2007-3896;
> > > reference:url,www.microsoft.com/technet/security/advisory/943521.mspx;
> > > reference:url,www.microsoft.com/technet/security/bulletin/ms07-057.mspx;
> > > classtype:attempted-user; sid:13272; rev:3;)
> > >
> > > They say it is just a 'mailto:&apos; match (which seems common with the web
> > > pages these days) and then a "Regular Expression" which is causing our
> > > sensors to not like it and CPU is consumed.
> > >
> > > I know we run a slightly older rules (due to antiquated hardware,
> > > corporate bureaucratic red tape, etc.) but are all these rules so bad?
> > > My engineers say this is not good and I wonder if we are detecting on
> > > what we need to or if there are dropped packets due to so much bad
> > > rules using CPU and RAM?  Is there a better rule list I can use for my
> > > sensors?
> > >
> > > Thank you.
> > >
> > > Miso, CISO
>
> ------------------------------------------------------------------------------
> Cloud Services Checklist: Pricing and Packaging Optimization
> This white paper is intended to serve as a reference, checklist and point of 
> discussion for anyone considering optimizing the pricing and packaging model 
> of a cloud services business. Read Now!
> http://www.accelacomm.com/jaw/sfnl/114/51491232/
> _______________________________________________
> Snort-sigs mailing list
> Snort-sigs () lists sourceforge net
> https://lists.sourceforge.net/lists/listinfo/snort-sigs
> http://www.snort.org
>
>
> Please visit http://blog.snort.org for the latest news about Snort!


------------------------------------------------------------------------------
Cloud Services Checklist: Pricing and Packaging Optimization
This white paper is intended to serve as a reference, checklist and point of 
discussion for anyone considering optimizing the pricing and packaging model 
of a cloud services business. Read Now!
http://www.accelacomm.com/jaw/sfnl/114/51491232/
_______________________________________________
Snort-sigs mailing list
Snort-sigs () lists sourceforge net
https://lists.sourceforge.net/lists/listinfo/snort-sigs
http://www.snort.org


Please visit http://blog.snort.org for the latest news about Snort!