[c-nsp] Vulnerabilities in HTTP server on Catalyst Switches

[John Neiberger]

I'm having a disagreement with a security admin and I wanted to get
some opinions.

Can any of you think of a good reason to leave the http server on a
Catalyst switch turned off? I understand that it's best to leave
services turned off if you don't need them, but what if you want to
use Cisco Network Assistant, for example, and that requires you to
turn on the http server?

The security admin just says "it's best practice to leave it off" and
doesn't back it up with any useful information.

What do you all think? Is there any real security risk by giving
someone read-only access through CNA? I don't see a downside to it.

Thanks,
John

_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[Curtis Doty]

Post by John Neiberger
I'm having a disagreement with a security admin and I wanted to get
some opinions.
Can any of you think of a good reason to leave the http server on a
Catalyst switch turned off? I understand that it's best to leave
services turned off if you don't need them, but what if you want to
use Cisco Network Assistant, for example, and that requires you to
turn on the http server?
The security admin just says "it's best practice to leave it off" and
doesn't back it up with any useful information.
What do you all think? Is there any real security risk by giving
someone read-only access through CNA? I don't see a downside to it.

You might have a better chance of winning him over if you show him how
you've carefully designed separate data and control planes. With
carefull attention to aaa and policing the control plane. Then, of
course, allow him to audit your design. And finally, convice him that it
was all his idea.

../C

[Rodney Dunn]

Yep....protect the device from all angles.

He could argue the same thing about *any* port
being open.


Rodney

Post by Curtis Doty

Post by John Neiberger
I'm having a disagreement with a security admin and I wanted to get
some opinions.
Can any of you think of a good reason to leave the http server on a
Catalyst switch turned off? I understand that it's best to leave
services turned off if you don't need them, but what if you want to
use Cisco Network Assistant, for example, and that requires you to
turn on the http server?
The security admin just says "it's best practice to leave it off" and
doesn't back it up with any useful information.
What do you all think? Is there any real security risk by giving
someone read-only access through CNA? I don't see a downside to it.

You might have a better chance of winning him over if you show him how
you've carefully designed separate data and control planes. With
carefull attention to aaa and policing the control plane. Then, of
course, allow him to audit your design. And finally, convice him that it
was all his idea.
../C
--
These are not the droids you're looking for. - Obi-Wan Kenobi
_______________________________________________
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[Lars Erik Gullerud]

Post by John Neiberger
Can any of you think of a good reason to leave the http server on a
Catalyst switch turned off? I understand that it's best to leave
services turned off if you don't need them, but what if you want to
use Cisco Network Assistant, for example, and that requires you to
turn on the http server?

Based on the track-record of the IOS http server when it comes to
vulnerabilities, I'd be inclined to agree with your security admin unless
the switch is sitting in a very protected network environment. In
fact, we don't have a single Cisco device with the http server enabled
anywhere, and I believe most of the network engineers would riot if
someone suggested turning it on. :)

/leg
_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[Gert Doering]

Hi,

Post by John Neiberger
Can any of you think of a good reason to leave the http server on a
Catalyst switch turned off?

Oh yes. Web UIs are slow and annoying (and the java stuff is especially
bad). Command line rules.

But that's personal user preferences.

Post by John Neiberger
From a security point of view, the best practice for switch management

is to put the management VLAN behind a HUGE firewall (preferably the
air-gap type) and stop worrying about L3 exploits against your nice
L2 devices.

gert

[John Neiberger]

I'm only interested in the security aspects of the http server on the
switches, not the usability of the GUI. I also prefer the CLI but I'm
considering offering CNA to some of the other people in our department
so they can do some basic troubleshooting on their own without
involving me.

Thanks,
John

Post by Gert Doering
Hi,

Post by John Neiberger
Can any of you think of a good reason to leave the http server on a
Catalyst switch turned off?

Oh yes. Web UIs are slow and annoying (and the java stuff is especially
bad). Command line rules.
But that's personal user preferences.
From a security point of view, the best practice for switch management
is to put the management VLAN behind a HUGE firewall (preferably the
air-gap type) and stop worrying about L3 exploits against your nice
L2 devices.
gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/

_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[joshua sahala]

Post by John Neiberger
I'm only interested in the security aspects of the http server on the
switches, not the usability of the GUI. I also prefer the CLI but I'm
considering offering CNA to some of the other people in our department
so they can do some basic troubleshooting on their own without
involving me.

John,

You might consider a looking glass-type application for that. It wouldn't
require the old java or the new ie, and would be a lot faster than CNA,
but it would probably be able to give the same info :) There is some
looking glass code included with rancid, or there are a plethora of others
(version6.net's version is pretty cool)

http://www.traceroute.org/#source%20code

With just a bit of modification, you could specify the commands you want
them to be able to use, and you don't have to worry about Cisco's
historically insecure webui

/joshua
--
A common mistake that people make when trying to design something
completely foolproof is to underestimate the ingenuity of complete
fools.
- Douglas Adams -

_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[Church, Chuck]

The http server has been found to have security vulnerabilies in the
past, but if you're locking it down to only certain address ranges being
able to attach, it should be secure enough. Keeping the management
interface in a separate VLAN is certainly a good idea as well.


Chuck Church
Lead Design Engineer
CCIE #8776, MCNE, MCSE
Netco Government Services - Design & Implementation
1210 N. Parker Rd.
Greenville, SC 29609
Home office: 864-335-9473
Cell: 703-819-3495
***@netcogov.com
PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x4371A48D


-----Original Message-----
From: cisco-nsp-***@puck.nether.net
[mailto:cisco-nsp-***@puck.nether.net] On Behalf Of John Neiberger
Sent: Thursday, June 09, 2005 3:20 PM
To: Gert Doering
Cc: cisco-***@puck.nether.net
Subject: Re: [c-nsp] Vulnerabilities in HTTP server on Catalyst Switches

I'm only interested in the security aspects of the http server on the
switches, not the usability of the GUI. I also prefer the CLI but I'm
considering offering CNA to some of the other people in our department
so they can do some basic troubleshooting on their own without
involving me.

Thanks,
John

Post by Gert Doering
Hi,

Post by John Neiberger
Can any of you think of a good reason to leave the http server on a
Catalyst switch turned off?

Oh yes. Web UIs are slow and annoying (and the java stuff is

especially

Post by Gert Doering
bad). Command line rules.
But that's personal user preferences.
From a security point of view, the best practice for switch management
is to put the management VLAN behind a HUGE firewall (preferably the
air-gap type) and stop worrying about L3 exploits against your nice
L2 devices.
gert
--
USENET is *not* the non-clickable part of WWW!

//www.muc.de/~gert/

Post by Gert Doering
Gert Doering - Munich, Germany
fax: [phone]

***@net.informatik.tu-muenchen.de
_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[Chris Cappuccio]

Post by John Neiberger
What do you all think? Is there any real security risk by giving
someone read-only access through CNA? I don't see a downside to it.

Your security guy is right. Turn off the http server.

Anything you do with separating out access via "planes" is a POLICY decision,
NOT a SECURITY decision. People like to use their POLICY to enforce SECURITY
but the fact of the matter is that any vulnerability in the http server
completely bypasses your hours of POLICY configration.

This is not a subtle point. I'm not talking about some "far out chance" that
someone might someday write an IOS vulnerability exploit. Although it's
not a prerequisite, the various Cisco IOS source code leaks over the
years make exploits slightly easier to craft. The day has come and past where
a buffer overflow has been exploited in Cisco's code to elevate privileges
from 'outside observer' to 'able to control the router'.

The discussion this list really should be having is why hasn't Cisco
(or anyone else for that matter) started using relatively simple
prevention measures (if they were, wouldn't it be press release material?),
like OpenBSD has done with W^X, guard pages, randomized memory allocation,
privilege separation, propolice, and many more pieces, integrated into the
kernel and userland. (Oh, right, everything on IOS runs with the same
privilege level. I wonder if anyone 0wns route-views.oregon-ix.net ?)

These are not abstract concepts. IT HAS BEEN DONE AND IT WILL BE DONE AGAIN.
TURN OFF SERVICES YOU DON'T USE TO LOWER YOUR EXPOSURE. That's the only
'policy' that might actually stop or at least slow an attack to the point
where it might catch your attention. Well, only if you're looking.
And, if you're looking, it's actually pretty hard to really look in all
the right places. Don't be suprised if someday, some well funded, anonymous
group can run code on your router via an exploit in the BGP listener,
executed via a worm in one of your peer's routers. By thsi time, perhaps they
already 0wn most of the Juniper and Cisco internet through this. The lack of
modern security models and measures on such critical infrastructure hardware
such as this is more than a little scary when you consider the implications!

(You know, OpenBSD's bgpd can handle today's full views in 64MB of RAM, can
load them up in less than a minute, and on halfway decent hardware, can rival
any 7200 NPE. The limited interface selection is, well, limiting. T1, T3,
802.11 or 10/100/1000 Ethernet are the only real options. For several people
on this list, that won't cut it. For 7200 users, it probably does.)

-c
_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/