[Snort-sigs] sid:13272; rule is not so good
william.metcalf at ...2420...
Tue Dec 6 17:26:55 EST 2011
Regarding performance. Your network is a snow flake, unique,
impossible to recreate in a lab. If you on-staff engineers are not
doing rule perf evaluation/tuning in your environment your IDS engine
is probably performing like a Yugo when it could be performing like a
Ferrari. Your rule vendors can only do so much people, the rest is up
On Tue, Dec 6, 2011 at 3:51 PM, Miso Patel <miso.patel at ...2420...> wrote:
> 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
> "bugtraq" links:
> 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'
> type thing.
> Miso, CISO
> 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
> Cloud Services Checklist: Pricing and Packaging Optimization
> This white paper is intended to serve as a reference, checklist and point of
> discussion for anyone considering optimizing the pricing and packaging model
> of a cloud services business. Read Now!
> Snort-sigs mailing list
> Snort-sigs at lists.sourceforge.net
> Please visit http://blog.snort.org for the latest news about Snort!
More information about the Snort-sigs