Great Circle Associates Firewalls
(December 1997)

Indexed By Date: [Previous] [Next] Indexed By Thread: [Previous] [Next]

Subject: Re: Intrusion Detection - Switched Network
From: "Paul D. Robertson" <proberts @ clark . net>
Date: Wed, 31 Dec 1997 13:57:30 -0500 (EST)
To: Ted Doty <ted @ iss . net>
Cc: firewalls @ GreatCircle . COM
In-reply-to: <3 . 0 . 3 . 32 . 19971231111543 . 00964210 @ mail . iss . net>

On Wed, 31 Dec 1997, Ted Doty wrote:

> On Tue, 30 Dec 1997 20:48:53 (EST), "Paul D. Robertson"
> <proberts @
 clark .
 net> wrote:
> "Multi-MAC" meaning multicast?  Any particular kind (ARP, RIP, bootp,
> NetBIOS stuff, IPX Nearest Server Query, ...)?

Multi-MAC meaning monitoring port which gets packets destined for 
multiple MAC addresses instead of just the device on that port, 
broadcast, and/or multicast packets.  Sorry, left-over terminology from 
some early switch implementations.

> >          'Alarm on what we know is bad' isn't as encompassing as 'Alarm
> >because we haven't seen anything good', and I'd expect to be able to have
> >a mix of the two.
> "Alarm on what we know is bad" is *much* more accurate.  Some of the
> "haven't seen anything good" - like certain types of heartbeats - are
> probably not too hard to do, but this area should be approached with
> extreme caution.  Too many false positives result in the IDS turning into
> shelfware.

Right, but its important to note that looking for bad things follows the 
'block only what we know as bad' approach to firewalling, and not the 
'block anything not known as good' approach.  Everyone does the 'alarm on 
bad' thing, and there's an important distinction that needs to be 
addressed in that any time you have a monitor, something needs to monitor 
the monitor.  Hence the statement that a mix of both modes is 
preferable.  Heartbeats are one way to do that.  It also may be 
preferable to alarm on things outside of the norm for certain cases, in 
which case, 'alarm on not good' will help build profiles of what's good, 
and can catch new attacks, out of policy software, or what have you.  
This is one reason that I'm happy to see NFR's historical reporting 
capabilities (the only packaged IDS that I have great expience with at 
this point in time), if I can track things like that, I can do such things as 
trend virus infections, trojan horses, tunnels and the like.  The biggest 
problem is going to be justifying storing, and archiving that data on 
systems good enough to do any real-time analysis as well.  


> To be effective, the IDS needs to sort this kind of stuff pretty carefully.
>  The danger is to ask for things like, oh, "just a hunch that some
> scumbag's trying to get unauthorized access" - you might spend all day
> chasing ghosts.

The same is true of firewall alerts, I'm sure we've all been from the 
'alarm on any violation' stage to the 'alarm on what's important' stage, 
and IDS don't bring anything new to that arena.  

Personally, I think network-level IDS are a logical adjunct to firewalls,
and even though nothing beats host security, it's difficult enough getting
administrators to lock down OS' with known processes and procedures.  I 
don't think I get farther than about three months before someone puts up a 
host, router, or other gear in 'test' mode on a live network with weak or 
no passwords.  Host IDS will work for high-visibility hosts, but 
unfortunately until we can make admins carry rocks in their left hands 
and do push-ups, we're going to have a hard fight doing it correctly on a 
platform-wide basis.

> If you have some specific ideas on what to look for, please email me
> directly.  I'm only following this list sporadically.

I've only just started looking at switches, and though my collegues seem 
to be ready to buy them by the truckload, I'm still poking around on my 
test network.  I'm pretty sure that I'll have some direct feedback once I 
get into it a little deeper though.

Thanks for the references, I'll run off and read them now.

Paul D. Robertson      "My statements in this message are personal opinions
proberts @
 clark .
 net      which may have no basis whatsoever in fact."

Indexed By Date Previous: Re: tis gauntlet telnet timeout
From: Meenoo Shivdasani <meenoo @ tis . com>
Next: RE: tis gauntlet telnet timeout
From: Joseph Judge <joej @ ma . ultranet . com>
Indexed By Thread Previous: Re: Intrusion Detection - Switched Network
From: Ted Doty <ted @ iss . net>
Next: Re: Intrusion Detection - Switched Network
From: Ted Doty <ted @ iss . net>

Search Internet Search