|
From: | dan farmer |
Subject: | [Freeipmi-devel] ipmi configuration security best practices |
Date: | Mon, 18 Feb 2013 08:52:45 -0800 |
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.] ^..^ |
[Prev in Thread] | Current Thread | [Next in Thread] |