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.
[snip]
> 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
-----------------------------------------------------------------------------
Paul D. Robertson "My statements in this message are personal opinions
proberts @
clark .
net which may have no basis whatsoever in fact."
PSB#9280
Follow-Ups:
References:
|
|
