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

Matt Olney molney at ...435...
Wed Jan 27 11:30:33 EST 2010


Completely understand the GID:3 concerns.  Remember that a lot of the
GID:3 stuff does come with source code.

Disabling GID:3 is dead easy...

Remove or comment out your references in the Snort config to the rule files:

#include /home/molney/snort/2.8.5/so_rules/web-misc.rules

Matt


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?
>
> 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
>>>
>>
>




More information about the Snort-sigs mailing list