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

Nigel Houghton nhoughton at ...435...
Wed Jan 27 11:45:06 EST 2010


On Wed, Jan 27, 2010 at 11:30 AM, Matt Olney <molney at ...435...> wrote:
> 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
>>>>
>>>
>>
>
> ------------------------------------------------------------------------------
> 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
>

You can of course choose to not load the shared object libraries at
all. You can also choose to not load the .rules files, or just like
with regular rules, you can disable certain shared object rules by
commenting out the stub rule in the .rules files. Up to you which way
to go.

-- 
Nigel Houghton
Head Mentalist
SF VRT
http://vrt-sourcefire.blogspot.com && http://www.snort.org/vrt/




More information about the Snort-sigs mailing list