It restricts cipher suite zero to callback privilege.  That's probably safe
enough.  It certainly protects against people being able to change anything
about your system or BMC (i.e. no power actions, no BMC reconfig, without a
password).  I think it even prevents query of power state and sensor
readings, but I generally 'X' out the protocol so I don't have to worry
about it.

That second BMC, I'm not sure.  It's not IPMI 2.0 compliant in the
strictest sense (0-3 are mandatory, and it omits the more secure ones).
You might be able to disable IPMI 2.0 entirely if IPMI 1.5 works and just
use 1.5 (make sure 'NONE' is disallowed and use MD5 and your authentication
is protected, but your data is not private, so a sniffer would see thot you
powered down your system.  The authentication is generally what you want to
make sure is airtight anyway.  Those are some ideas to play with, but that
second BMC may have some fundamentally grave security issues.


                                                                       
  From:       Fred Tyler <fred...@gmail.com>                           
                                                                       
  To:         Jarrod B Johnson/Raleigh/i...@ibmus                       
                                                                       
  Cc:         ipmitool-devel@lists.sourceforge.net                     
                                                                       
  Date:       04/15/2009 10:55 AM                                      
                                                                       
  Subject:    Re: [Ipmitool-devel] IPMI lanplus connection using -C0 does not   
require password
                                                                       





On Wed, Apr 15, 2009 at 10:28 AM, Jarrod B Johnson <jbjoh...@us.ibm.com>
wrote:
> You have to change your BMCs to reject cipher suite 0. FYI, IBM servers
ship
> with it disabled for this very reason.
>
> ipmitool lan set 1 cipher_privs XaaaXXXXXXXXXXX

Ok, my lan channel is 2 on one machine and 6 on another, so I changed
this command, but then I get the following errors:

===============
Machine 1 (lan channel 2)
===============

$ ipmitool lan set 2 cipher_privs XaaaXXXXXXXXXXX
LAN Parameter Data does not match!  Write may have failed.


===============
Machine 2 (lan channel 6)
===============

$ ipmitool lan set 6 cipher_privs XaaaXXXXXXXXXXX
Mismatched data lengths: 2 != 9

~~~~~~~~~~~~~~~~~~~~~~~~~~~

However, I found that if I changed the command on Machine 1 to the
following, it "worked":

$ ipmitool lan set 2 cipher_privs caaaXXXXXXXXXXX

This does seem to block the blank passwords, though I'm not sure how
or why or if it's actually secure.

~~~~~~~~~~~~~~~~~~~~~~~~~

As for Machine #2, I can't get any cipher_privs command to work on it,
which apparently only has 2 cipher suites and reports "Not available"
for priv max:

RMCP+ Cipher Suites     : 0,1
Cipher Suite Priv Max   : Not Available

~~~~~~~~~~~~~~~~~~~~~~~

And just in case there is a simple solution: All I want to do is have
a secure way for a single user (me) to remotely reboot a machine, log
in to a console, etc. I don't need multiple users or anything complex.

If I'm making this more difficult than need be, please let me know :-)

Thanks.

<<inline: graycol.gif>>

<<inline: ecblank.gif>>

------------------------------------------------------------------------------
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
_______________________________________________
Ipmitool-devel mailing list
Ipmitool-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ipmitool-devel

Reply via email to