Re: HOWTO on managing IDS rules?

[Phil Wood <cpw () lanl gov>]

On Tue, Sep 25, 2001 at 09:11:16PM -0500, Chris Green wrote:
> Jason Haar <Jason.Haar () trimble co nz> 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.

Yes.  Unfortunately, with this and the other mechanisms mentioned, the amount
of work at a 10,000+ system installation can be daunting.  However, it has
to be done.  I've not come up with a formal mechanism.  It's something like
attempting to write a step by step procedure of what to do when you fall off
an ocean liner in the mid Pacific at midnight, after you hit the water.

Some things I've tried.  Given multiple networks, more or less solid policys
regarding what is allowed to and from these networks, I use a hierarchy of
rules, multiple sensors, and diverse logging and alerting.

For example, on one side of the spectrum, Codered and nimda have been relegated
to a pcap log file that is summarized each evening. (I had to turn on "large
files" (>2gig), in libpcap [I manage my own pcap source] to do this).

On the other hand, I have a couple of site rules which will send me a page.
The only time this has happened is when I tested if the rule worked!  But,
that's ok, I hope I never see it.  Sorry, can't tell you what it is.  %^) 

> 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.

Good point.  I'm way guilty in not keeping up with this.

> > 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.

The classification scheme could be put to good use in controling when and
if notifications are made immediately, or just stuffed in the non-critical
bag.

> > Sounds like a plan? Any other ways people are dealing with this "information
> > overload"? 
>
>
> 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 () uab edu>
> Fame may be fleeting but obscurity is forever.
>
> _______________________________________________
> Snort-users mailing list
> Snort-users () lists sourceforge net
> Go to this URL to change user options or unsubscribe:
> https://lists.sourceforge.net/lists/listinfo/snort-users
> Snort-users list archive:
> http://www.geocrawler.com/redir-sf.php3?list=snort-users

-- 
Phil Wood, cpw () lanl gov


_______________________________________________
Snort-users mailing list
Snort-users () lists sourceforge net
Go to this URL to change user options or unsubscribe:
https://lists.sourceforge.net/lists/listinfo/snort-users
Snort-users list archive:
http://www.geocrawler.com/redir-sf.php3?list=snort-users