[Snort-sigs] sid:13272; rule is not so good

rmkml rmkml at ...174...
Tue Dec 6 17:25:14 EST 2011

These are good questions! (can be as complicated as to why so much bad/low as detection programs with why so many these software have security holes ...)
Maybe more information on exploits bugtraq references?:

On Tue, 6 Dec 2011, 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 at ...174...> 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:' 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

More information about the Snort-sigs mailing list