[Beowulf] KVM to a compute node - ssh

[Robert G. Brown]

On Fri, 4 Jun 2004, Dan Kidger wrote:

> On Thursday 03 June 2004 8:03 pm, Brian D. Ropers-Huilman wrote:
> > On 2004-06-03 17:15 (+0100), Guy Coates <gmpc at sanger.ac.uk> wrote:
> > ] That holy grail does just about exist.  I was plesantly surprised with
> > the ] latest intel server offering from HP.  As well as a serial port it
> > comes ] with an integrated management processor (ILO), basically just
> > another rj45 ] port which you plug into your LAN. You can talk to the ILO
> > via telnet or a ] web interface, and do remote power, hard reset etc by
> > firing carefully ] crafted bits of XML at it.
> >
> > Obviously this would be on a private LAN. The security implications of this
> > are staggering!
> 
> Not really.

Why not?  With XML the password will indeed be sent in plaintext almost
certainly, unless the port is SSL encrypted.  If it were, you'd almost
certainly know it because there would be a certificate authority and so
forth to manage.

As Brian said, on a private switched LAN it isn't a huge problem -- you
can use the sucker rod approach to security.  Reading or controlling
over any WAN segment outside of your control would be asking for
trouble.  So would the all-too-common "leave the default password
unchanged" style of management.

Remember, people crack routers, printers, phone relays, and more just to
show that they can (or for more nefarious and profit oriented purposes).
I wouldn't trust my home ISP (the one I'm typing this bidirectionally
SSH encrypted message through) to be secure -- I don't even know if I
can trust their employees, let alone somebody that might have cracked
their gateway or router hosts.

Although I'm trying to figure out if WOL in general is any better.  If
a WOL host reboots any time it receives a simply crafted packet, well,
that could be a fairly bit problem.  Five minutes of work with one of
the WOL script or binaries to encapsulate it in an nmap-like loop (or
just embed it in nmap as another security test that is somehow also an
attack) and one can scan whole networks and reboot or randomly power on
downed hosts.

All this stuff is a great idea, but it really needs to either live
inside a LAN firewall with sucker rod handy to school interior offenders
or have a serious (as in public/private key, bidirectionally encrypted,
password secured) interior layer on at least the control as opposed to
information functions.  There is no hole too small or unworthy to be
left open that the crackers will not find and exploit -- just because
they can.

> We have had these HP nodes with a Baseboard Management Controller ('ILO' in 
> HP/Compaq speak) for a long time. I can happily read temperatures, power them 
> on/off and even upgrade the firmware of all nodes in the cluster using an XML 
> script that I can fire to each node in parallel
> 
> The XML includes a username and password for the BMC. (I haven't checked if 
> this is sent in plain text or not).
> viz:
> <RIBCL VERSION="2.0">
>   <LOGIN USER_LOGIN="root" PASSWORD="secret">
>   <SERVER_INFO MODE="write">
>     <SET_HOST_POWER HOST_POWER="No"/>
>   </SERVER_INFO>
>   </LOGIN>
> </RIBCL>
> 
> I use this to power off nodes if the aircon fails. 
> If it is set up correctly - this will attempt  to shut the O/S down cleanly 
> (ACPI?) before pulling the virtual power cord.
> 
> The downer on all of this is that the host tool that sends the XML: 
> 'CPQLOCFG.EXE'  only exists as an MSDOS binary!
> Last time asked HP 6 months ago they said that they were going to do a Linux 
> version - but since then I have heard and seen nothing. :-(

If this is as simple as I think it is, you can probably query the nodes
by hand with telnet if you can figure out the IP number and port
(assuming that they are using TCP/IP as the transport layer -- nodes
monitor interfaces identified by IP number granted by dhcp rather than
MAC address).

Just use tcpdump to snoop the transaction (send it to a linux box's
regular interface instead of the monitor interface).  Observe the packet
header to see where it is going.  Then it is trivial to concoct a linux
monitor interface.

In fact, you could almost certainly hack either wulfstat or wulflogger
to do this for you.  They already have nice code for specifying whole
networks of IP numbers with simple (XML) range commands, you can specify
the port, it has a TCP connection engine to manage the connections with
the ports (retrying as required).  xmlsysd already speaks xml incoming,
so if the device returns xml as well as sends it (it really should) you
can parse it.  The only thing remaining is to create the outgoing xml
messages for the query.  Those can be generated by either writing the
raw ascii into the send buffer and sending it or by using libxml2 to "do
it properly" -- end result is the same, but the former is probably
easier if there is a library of only 5 or so distinct command patterns.

If it DOESN'T use TCP/IP, then you're not out of luck but you'll likely
have to work harder.

(The wulfstat or wulflogger code is on my personal website under beowulf
stuff, or on brahma.)

If this interface ever became standard and common, I'd write an
interface myself for the wulfstat common library so these tools could
read the temperature data at least.  As HP-only one-offs (and lacking
any of the systems) it isn't worth it to me to do so - given that I
don't get paid for it - but it really would be pretty easy for a decent
C coder to accomplish.

   rgb

> 
> 
> Yours,
> Daniel.
> 
> --------------------------------------------------------------
> Dr. Dan Kidger, Quadrics Ltd.      daniel.kidger at quadrics.com
> One Bridewell St., Bristol, BS1 2AA, UK         0117 915 5505
> ----------------------- www.quadrics.com --------------------
> 
> 
> 

-- 
Robert G. Brown	                       http://www.phy.duke.edu/~rgb/
Duke University Dept. of Physics, Box 90305
Durham, N.C. 27708-0305
Phone: 1-919-660-2567  Fax: 919-660-2525     email:rgb at phy.duke.edu