From: Anthony D'Atri (aad@beak.org)
Date: Wed Oct 10 2007 - 18:56:35 EDT
My group has historically managed hosts and network devices via
serial consoles even if an ethernet one were available, in part out
of security concerns. I recall an exploit or DDoS that certain
Baystack switches were subject to, for example.
We're now handling an increasing number of Sun's Opteron boxes --
x4100, x4200, x4600 and I'm encountering several issues:
o Ancient / inconsistent firmware from the factory: I have several
systems with 1.0 or 1.0.7 ILOM that have exhibited odd behavior. One
x4200 was actually delivered somehow with BIOS and ILOM versions that
aren't compatible, which is a neat trick given that they're in the
same firmware image. Among the issues here is that reporting of FRU
and system information is degraded, and I've seen a few documents
with the resolution of using the SP Net Mgt interface / Java console
redirection instead. Using ipmitool isn't a real alternative, as it
requires a working and accessible OS installation. I have at least
one host where it doesn't work at all, but that's another matter,
perhaps related to antebellum 1.0 ALOM.
o Updating the MPT firmware can apparently only be done by booting a
CD [image]. With remote systems it's difficult to get local hands to
burn a disc and insert it, especially if the system in question is an
x4100 with 4 disks and no optical drive . ILOM / BIOS updates have to
be done over the net mgt port via TFTP. The remote graphical console
interface via the Net Mgt connection can be used to virtualize a disc
or ISO local to a workstation for MPT firmware updates, though the
set of browsers where this works appears to be severely limited.
Clearly there's value in connecting the net mgt port in additional to
the normal serial console (though it does eat yet another switch
port). What concerns me though are the security implications of
exposing this port to the outside. Our systems (and engineers) are
spread out in a number of locations, so it's not all conveniently
located behind a single uplink to the public net, so router ACL's to
protect the SP Net Mgt ports are somewhat difficult to maintain, plus
we like to not rely on the naive "hard crunchy shell and soft chewy
center" security model. One approach that I see is to routinely
configure the Net Mgt port to have all-zeros for ip address, netmask,
and gateway, and only enable them via the serial CLI for the duration
of a specific need. I'm somewhat worried, though, that something
exotic could be done to the port even with the IP info set to all
0's. The infrequency of ILOM updates and the hassle/disruption
associated with applying them means that systems can't feasibly be
kept up-to-date all the time, plus eg. the age of the SSH on the SP
concerns me, wrt exploits. ILOM 1.1.1, for example, appears to have
the *rather* ancient OpenSSH_3.8.1p1.
So, I'd like to solicit reports on others' practices with these ports
-- leaving them disconnected, connecting them but protecting with
router ACL's, only configuring them for the duration of maintenance,
etc. I'll anonymize any quotes in my summary so as to not link
anyone's security-sensitive information with their identity.
Thanks!
_______________________________________________
sunmanagers mailing list
sunmanagers@sunmanagers.org
http://www.sunmanagers.org/mailman/listinfo/sunmanagers
This archive was generated by hypermail 2.1.7 : Wed Apr 09 2008 - 23:42:25 EDT