[Snort-sigs] sid:13272; rule is not so good
miso.patel at ...2420...
Tue Dec 6 16:51:52 EST 2011
Thank you RMKML for pointing me to that site. I see why this could be
a problem and matching needs to be done on it. I also found these
Scary stuff! I'm glad I've only got a few years until retirements
because I don't know what threat landscapes will be like in five
years. Just mostly kidding. Say, if you buy VRT rules, do you get
support to the point that they can guarantee no bad rules or at least
fix them quick so we don't have to wait until the next release? I
would like to use a rules that are updated very often because I see
that what we are threatened with this week is not a threat to us
anymore the next week so I need something more than a, 'hey, patch MS
tuesday is here so here are a few rules to detect an wild exploit'
On 12/6/11, rmkml <rmkml at ...174...> wrote:
> 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
>> 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.
>>> 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;
>>>> pcre:"/[^\n]*?[\x25\x22]\x2E(com|bat|cmd|exe)/Ri"; metadata:policy
>>>> security-ips drop, service http; reference:bugtraq,25945;
>>>> 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
>>>> Thank you.
>>>> Miso, CISO
More information about the Snort-sigs