[Freeipmi-devel] ipmi configuration security best practices

[dan farmer]

Hey folks -

I'd been putting together a small list of things that one might

avoid in the configuration of IPMI (straight IPMI as per the spec,
not any of the vendor additions), along with some small examples
of why I think they might be problematic.  If any would care to
critique (on or off list, as appropriate) I'd be grateful.  Any
omissions, disagreements, flat-out-wrong statements, etc. would all
be great.  My plan is to put this on my site along with a little
tool to look for such things (and a bit more); we'll see how that

pans out as time goes on.

In this list I'm deliberately attempting to elide things that cannot
be checked programmatically from this particular list; for instance
I think that having appropriate process/policies/etc about the 
management of IPMI passwords is pretty crucial to effectively using 
IPMI, but it's a bit hard to write a shell script to test that.

These will be folded into a larger doc.  By all means if such a
thing already exists I'd love to see it.  I do make some small
assertions (e.g. only use ciphers 3, 8, & 12) that make sense
to me, but perhaps not to others.

Does anyone known of anyone trying to do any sort of password
cracking or anything (presumably by brute forcing SSH, telnet, or
web logins)?  I'll put together a simple tool to do some small brute
forcing, but it's not a great solution; among other things my test
subjects seem to keel over if I look at them too stridently, but
some also try to lock you out or do backoff with repeated incorrect
guesses.  (I've found that some do the last via SSH, but not when
using the web, interestingly.)

Finally, I'm extremely suspicious of the dial back stuff, but can't

figure it out yet.

dan

p.s. I sent this to both ipmitool & freeipmi lists individually.  I'll

soon move away from IPMI, don't worry ;)

---- items ----

1. Use v2.0/RMCP+ RAKP Authentication if you're able to. The KG key
should be set to something other than the default (all zeros.)

This is the hardest recommendation to follow in this document and
some of you out there may well laugh. RMCP+/RAKP authentication is
pretty daunting at the best of times (and is hence rarely used),
but it does offer one of the best defenses against IPMI's worst
problem of widely shared and reusable passwords. RAKP authentication
essentially provides a second password, and can (and should) be
different for every BMC.

2. Disable or either change or give strong passwords to default
vendor accounts.

3. While it's possible to have different usernames, IDs, passwords,
and more for each channel, that way leads to madness and confusion.
Never do this unless you really know what you're doing or someone
points a loaded gun to your head.

4. Don't allow the user to set the Session Inactivity Timeout to
too long a value (15 mins?) It defaults to 1 minute, according to
"Table 6-7, Default Session Inactivity Timeout Intervals".

5. Use 20 character passwords (or passphrases, if you ever want to
remember them) if you're going to use shared and widely disseminated
and passwords.

[Note - while you can't easily check for password length, you can
at least verify that 20 char length passwords are being used.  I can't

find if this is only used when using passwords of 17-20 chars long,

however.]

6. Don't allow or use OEM cryptography unless you're really,
really sure it's better than what the specification already provides.
Only trust published, peer-reviewed, and well-regarded cryptographic
systems.

7. Don't use MD2 or RC4 for anything (they're usable in several
places in the specification and vendors still support them.) Written
in 1989 & 1987, they've been both demonstrated to be relatively insecure.
MD5 isn't great, but at least it's better than MD2.

8. Never use Cipher zero (0). Indeed, only use ciphers 3, 8 & 12.  
There's a nice table in section 22.15.2 - Cipher Suite IDs - that
lists all the supported algorithms for authentication, integrity,
and confidentiality. The only ones that support all three goals
reasonably well are these ciphers.

9. Don't allow accounts with a null username or password. Anonymous
logins - part of the spec - should always be disabled.

   6.9.1 'Anonymous Login' Convention

   The IPMI convention for enabling an 'anonymous' login is to
   configure the entry for User ID 1 with a null username (all
   zero's) and a null password (all zero's).

10.Never disable per-message and user level authentication.

   The spec says:

   6.12.4 Per-Message and User Level Authentication Disables

   In some cases however, the connection medium is considered
   to be trusted even though multiple user sessions are allowed. Once
   a session has been activated, the computational overhead of
   authenticating each packet may not be necessary.

Suck up the "overhead" and don't disable it.

11. Don't disable Link Authentication.

One of those don't worry, be happy and be insecure things. My advice
- don't be too happy.

   6.12.5 Link Authentication

   Link Authentication is a global characteristic associated with
   the connection mode for the channel. Link Authentication is
   enabled/disabled via the serial/modem configuration parameters.
   When Link Authentication is enabled, it is necessary to identify
   one or more users that will serve as the source of the username
   (peer ID) and password information for the link. This is
   accomplished by setting an 'Enable User for Link Authentication'
   bit in the Set Channel Access command.

   For physically secure connections, these 'Link Authentication'
   protocols may be all that's considered needed to authenticate
   the user.

Don't listen to them. Who are you going to believe: me or your lying
eyes?

12. Disable gratuitous ARP replies. An ARP is a packet defined in
RFC 831 that permits computers to find a physical Ethernet (aka
MAC) address and map it to an IP address. A gratuitous ARP reply
is when a computer sends a broadcast network packet to update the
mapping between an IP address and an Ethernet, or MAC, address.
While gratuitous ARPS may be useful at times, BMCs shouldn't be
sending traffic on the local LAN anyway, and it may be used to spoof
addresses.

13. The BMC should use static IP #'s, not DHCP. You want to have
control over where your BMC shows up: monitoring, security,
maintenance, etc. all benefit.

14. The BMC should use its own dedicated Ethernet connection (e.g.
don't share the server's physical connection!)

15. If the BMC can't have or doesn't support a dedicated Ethernet
connection, use VLANs (which aren't great for security, but it's
at least a paper thin wall of added protection.)

16. Log any scrap of data that the BMC allows (not much, I know.)

[note - note sure how much I can check here.]

17. Disable all services that aren't used (this can usually be done
via the BMC's web interface, scripting interfaces, or the command
line interface. If I catch you using telnet I will beat you. Put
the services or the BMC's configuration under proper change management
and the appropriate processes for your organization. If there are
both unencrypted and encrypted versions of a service disable the
former and only allow the latter.

[again... not sure what I can do here.]

^..^