[Snort-users] HOWTO on managing IDS rules?
cmg at ...671...
Tue Sep 25 19:15:03 EDT 2001
Jason Haar <Jason.Haar at ...294...> writes:
> I've been running snort for some time now, and am trying to formalize how we
> handle signature management.
> As we all know, False Alerts are not our friends. I'm trying to generate a
> more appropriate way of dealing with signatures, and as always, would like
> to hear from others if this is a Good Idea...
> So, we have a DMZ. We get our obligatory 10,000 CodeRed/Nimda alerts per
> week from Snort. We are not interested in these alerts, as our servers are
> patched and/or Apache. OTOH, we don't want to stop detecting CodeRed/Nimda
> as one day some git (i.e. me :-) may put an unsecured M$ IIS server in the
> DMZ without thinking. So what we really want is to:
> 1> stop reporting on attack types we know ourselves to be immune to, to
> reduce the amount of logs that need checking.
The right way to do this IMO is in post processing so you still get
the alert but it can be used later. The number of times I saw a
machine "safe" from IIS patches and then they apply a Service Pack
scenarios are what gives me this opinion.
Perhaps move it into a "signs of a successful attack" alert too. I do
this with lots of odd outgoing rules.
> 2> document that this attack (from Internet to DMZ) is no longer being
> looked for.
> 3> start reporting on the same attack FROM DMZ TO INTERNET. This way we
> should catch any erroneously installed machines at a later date.
This is about what I've said above. I just move these types of alerts
out of the 'critical' bag.
> Sounds like a plan? Any other ways people are dealing with this "information
Snort Snarf's style summaries can be be good for handling this and
you'll find yourself ignoring certain types of alerts.
If you've got the pager type setup, it's definately 'take this attack
out of critical section'
Chris Green <cmg at ...671...>
Fame may be fleeting but obscurity is forever.
More information about the Snort-users