Re: Cisco Catalyst issues

["Ryan Russell" <ryanr () sybase com>]

> Isn't CDP one of the first things to disable in a router if you are
> setting it up securely? Why not do the same in a switch?

That is, of course, what I'm suggesting.  I have some nagging
doubts that that would be sufficient.  Nothing concrete yet.

> Getting the current SNMP passwords would be much easier by just sending
> gratitous ARPs towards the Cat polluting everyone's ARP cache. Posing as a
> new device is even simpler. No Cat specific things here...

ARP won't help if you're on a different VLAN that the management interface
of the Cat, while CDP might.  It's a relatively small thing, with only
a remotely exploitable consequence (that I can think of.)  I put it
in for completeness' sake, and I thought it spoke to the general
security attitude (or lack of) that it believed itself was across
a piece of wire.

> On the other hand, if you can get access to a trunk port (which is
> hopefully not
> accesible to end users) you can do much more damage than playing with ISL
> or VTP

What I'm saying is that if one leaves the default DISL and VTP settings,
then there is a good chance the Cat can be tricked into sending
arbitrary traffic through a client machine, facilitating sniffing.

> Turning off spanning tree at the leaf connections (end-users) is usually
> one
> of the first things to do if you want to have a stable switched network.

Which you may or may not be able to do, depending if you have
other bridge devices between client machines and the Cat.

> It seems to me that these are really not Cat problems. If you take very
> elementary
> precautions like:
>
> - running ISL manually configured
> - running etherchannel manually configured
> - turning off CDP and all other unneccesary stuff
> - turning off spanning tree at leaf ports

That's the list of things I'm hinting that people need to turn off at a
minimum.
These are "Cat problems" in that ISL, CDP, ISL, DISL, VTP, and probably
others are Cisco and/or Catalyst proprietary.

I'm also not at all convinced that, even with a locked-down config,
the box won't be vulnerable in some rather serious ways.  I've got no
proof yet, but I'm working on it.  If folks want to coordinate efforts
along
those lines with me (off this list, of course) I'd be happy to work with
them.

I still say they're no good for running VLANs of differing security levels
through the same Cat.

The point of listing bad defaults is to inform people who are considering
doing such about what mught be potentially exploitable as ammunition to buy
seperate boxes... or, if they lose the budget war, what to try to configure
around, as you've pointed out.

Until such a time as I can demonstrate (if I can)a vulnerability that can't
be
configured away, no one has to take my opinions as valid reasons
to avoid such a network design.  I'm not the sort that requires concrete
proof
of holes to be suspicious.

Some folks will say that the defaults, bad as they may be, can be
configured away.  I'm saying something closer to "uberhackers will
walk right through your Cat, no matter how you configure it."  The
truth is somewhere in the middle.

                         Ryan