[Snort-sigs] Being killed by poor IE rules...

Joel Esler jesler at ...435...
Wed Jan 27 11:38:04 EST 2010


On Wed, Jan 27, 2010 at 11:27 AM, Guise McAllaster <
guise.mcallaster at ...2420...> wrote:

> Thanks for the response Matt.  Often I wonder if there is any point in
> running GID:3 rules in high volumes, non-inline snorts.  I get many
> many false positive and when I try to investigate, I cannot not know
> what the rule is and so cannot be sure about accuracy, especially if
> details about the vulnerability are not clear.  I try to explain to my
> boss but he get mad. :(  If a snorts is inline, OK, GID:3 could be
> usefule to block.  But with such high volume and poorly written Web
> 2.0 applications out there, false positives are inevitable and with
> GID:3, it makes it very tough for the rules to be anything more than a
> waste of memory/CPUs.
>
> Is there a good way to disable GID:3 rules globally.  If not, could a
> feature request be put in to do this, maybe have a snort.conf setting?
>
> Don't load the stub rules in snort.conf

J




> Thanks again ... and sorry if my European cultural communication style
> came across as hostile.  I thought Americans were tough cowboys but I
> see a lot of crying. ;)  Just trying to give back to the community. :)
>  <----- (smiley == !hostile)
>
> Guise
>
> On 1/26/10, Matt Olney <molney at ...435...> wrote:
> > OK...
> >
> > It is unfortunate that we are required to put out some of our SO rules
> > in a compiled format.  This is particularly true in the case of
> > Microsoft rules because they are both very high profile and, in many
> > cases, very challenging detection.  However the fact is that as
> > partners with Microsoft in the MAPP program
> > (http://www.microsoft.com/security/msrc/collaboration/mapppartners.aspx
> ),
> > we are limited in the way we can distribute detection.  While this may
> > be frustrating and not the way we typically do things, the advantage
> > to our customers of getting advanced technical information from
> > Microsoft easily outweighs the drawbacks of participation.
> >
> > So what do you do?  You do exactly as Guise has done and point out
> > rules that are causing particularly performance or false positive
> > issues and we'll look at them (you might choose a delivery that is
> > less hostile, but provided you keep it relatively civil, we'll deal).
> > We get reports from several different sources, both in house and from
> > partners, but it is always valuable to get this information from the
> > open source community as well.
> >
> > On our end we'll open bugs on these three SIDs and have an analyst
> > review them.  We will make what humble efforts we can to figure out
> > what the performance issue there is and address it.
> >
> > I'll keep you posted...and on that note, I'll send another email.
> >
> > Matt
> >
> > On Tue, Jan 26, 2010 at 11:55 AM, Keith Butler <snort at ...3448...>
> wrote:
> >> The suggestions are enlightening and appreciated, the self-aggrandizing
> is
> >> getting old.
> >>
> >>
> >>
> >> ----- Original Message -----
> >> From: "Guise McAllaster" <guise.mcallaster at ...2420...>
> >> Sent: Tue, January 26, 2010 10:54
> >> Subject:[Snort-sigs] Being killed by poor IE rules...
> >>
> >>
> >> Hello.  The rules with SID 14645, 14643, 11966 are hammering my web
> >> snorts.  The first two are GID:3 so I cannot be of help in making them
> >> more good :( but the last one is this:
> >>
> >>
> >>
> >> web-client.rules:alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any
> >> (msg:"WEB-CLIENT Microsoft Internet Explorer CSS tag memory corruption
> >> attempt"; flow:to_client,established;
> >> pcre:"/\x3c[^\x3e]*style=[^\x3e]*csstext\x3a.*\x3e/i";
> >> reference:bugtraq,24423; reference:cve,2007-1750;
> >> reference:url,www.microsoft.com/technet/security/Bulletin/MS07-033.mspx
> ;
> >> classtype:attempted-user; sid:11966; rev:1;
> >>
> >>
> >>
> >> Clearly the naked pcre is big no-no.  Here are some stats from
> >> performance (notice how terrible it is):
> >>
> >>
> >>
> >> SID         GID     Checks   Matches    Alerts           Microsecs
> >>  Avg/Check
> >>  Avg/Match Avg/Nonmatch   Disabled
> >>
> >> ===         ===     ======   =======    ======               =====
> >>  =========
> >>  ========= ============   ========
> >>
> >> 14645            3     158641         0         0            11579605
> >> 73.0        0.0         73.0          0
> >>
> >> 14643           3     158641         0         0             5870863
> >> 37.0        0.0         37.0          0
> >>
> >> 11966            1    5129886         0         0             5847694
> >> 1.1        0.0          1.1          0
> >>
> >>
> >>
> >> SID         GID     Checks   Matches    Alerts           Microsecs
> >>  Avg/Check
> >>  Avg/Match Avg/Nonmatch   Disabled
> >>
> >> ===         ===     ======   =======    ======               =====
> >>  =========
> >>  ========= ============   ========
> >>
> >> 14645            3      31623         0         0             3878806
> >> 122.7        0.0        122.7          0
> >>
> >> 11966     1    1506965         0         0             1656476
> >> 1.1        0.0          1.1          0
> >>
> >> 14643     3      31623         0         0             1443499
> >> 45.6        0.0         45.6          0
> >>
> >>
> >>
> >> I am starting to wonder about the Vrt snort rules ... raw pcre with no
> >> content? ... and these GID:3 rules? ... makes me think what they are
> >> hiding ... it is tough to get good community feedback when the rules
> >> are hidden/compiled.  When I see such poor performing rules it shows
> >> me a need for a person go go thru old rules and make them more good.
> >> And I am the perfect person for this job (if I can work from France
> >> but I don't think that would be problem).  I already feel like
> >> SourceFire should be paying me, with all my good suggestion ;)
> >>
> >>
> >>
> >> Guise
> >>
> >>
> ------------------------------------------------------------------------------
> >> The Planet: dedicated and managed hosting, cloud storage, colocation
> >> Stay online with enterprise data centers and the best network in the
> >> business
> >> Choose flexible plans and management services without long-term
> contracts
> >> Personal 24x7 support from experience hosting pros just a phone call
> away.
> >> http://p.sf.net/sfu/theplanet-com
> >> _______________________________________________
> >> Snort-sigs mailing list
> >> Snort-sigs at lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/snort-sigs
> >>
> >>
> >> ----- End of original message -----
> >>
> >>
> >>
> ------------------------------------------------------------------------------
> >> The Planet: dedicated and managed hosting, cloud storage, colocation
> >> Stay online with enterprise data centers and the best network in the
> >> business
> >> Choose flexible plans and management services without long-term
> contracts
> >> Personal 24x7 support from experience hosting pros just a phone call
> away.
> >> http://p.sf.net/sfu/theplanet-com
> >> _______________________________________________
> >> Snort-sigs mailing list
> >> Snort-sigs at lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/snort-sigs
> >>
> >
>
>
> ------------------------------------------------------------------------------
> The Planet: dedicated and managed hosting, cloud storage, colocation
> Stay online with enterprise data centers and the best network in the
> business
> Choose flexible plans and management services without long-term contracts
> Personal 24x7 support from experience hosting pros just a phone call away.
> http://p.sf.net/sfu/theplanet-com
> _______________________________________________
> Snort-sigs mailing list
> Snort-sigs at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/snort-sigs
>



-- 
Joel Esler
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.snort.org/pipermail/snort-sigs/attachments/20100127/949860d2/attachment.html>


More information about the Snort-sigs mailing list