Oh yeah, one other subtlety. > 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 think you know this, but SSH, telnet, & web aren't related to IPMI. They are just additional features the vendors added to their service processors. It's perhaps a clarification that should be noted. Al On Tue, 2013-02-19 at 10:18 -0800, Albert Chu wrote: > Hi Dan, > > Some comments below (not mirroring Andy's, I'll comment on 1-2 things he > states there). > > > 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. > > As an alternate idea, you can configure different usernames w/ different > privilege limits, e.g. maximum privilege "User", "Operator", or "Admin". > That way any software using IPMI shouldn't use a username+privilege > outside of its requirements. For example, most sensor reading requires > "User" privileges (BTW, I'm going off memory, so don't quote me). No > reason to give monitoring software passwords to an Admin privileged > account that can be abused (i.e. powering on/off the server). > > Likewise, the same can be said w/ SOL. You can configure only specific > users to be able to use SOL and other ones can't. > > > 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. > > 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. > > As an alternate, I would say just disable these authentication > mechanisms so they can't be used at all period (i.e. disable MD2, > disable clear password, disable Cipher Suite 0). In bmc-config, you can > find the config of these in the sections Rmcpplus_Conf_Privilege and > Lan_Conf_Auth. > > > 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. > > Not sure if you're aware, but many of these "disable extra services" are > supported in ipmi-oem. Of course, I have to support the specific > motherboard/vendor. > > So here's 2 other security things I thought of > > A) > > In newer IPMI erratas there is support to configure how many attempts a > person has to brute force a password before the BMC just locks up that > user. I don't know how many motherboards support this, but it's not > many. Here's the description from bmc-config as an FYI. > > # Section Lan_Conf_User_Security Comments > # > # The following user security configuration options are optionally > implemented > # by the vendor. They may not be available your system and may not be visible > # below. > # > # The following configuration supports the ability for the BMC to disable a > user > # if a number of bad passwords are entered sequentially. > # "Bad_Password_Threshold" determines the number of bad passwords that must > be > # entered sequentially. "Attempt_Count_Reset_Interval" determines the range > of > # time the bad passwords must occur in. "User_Lockout_Interval" determines > the > # time a user will be locked off if the bad password threshold is reached. If > # set to "Yes", "Enable_Event_Message_When_User_Disabled" will inform the BMC > to > # log an event message when a user is disabled. > > So configuring this would be generally considered a good thing. I'll > let you determine what is the optimal configuration :-) I suppose the > logging thing also applies to your #16. > > B) > > SOL security can be tightened as well. Such as (this is a cut & paste > from bmc-config). > > ## Possible values: Yes/No > Enable_SOL Yes > ## Possible values: Yes/No > Force_SOL_Payload_Authentication Yes > ## Possible values: Yes/No > Force_SOL_Payload_Encryption Yes > > Disable if you don't want to use, force encryption, force > authentication, etc. Of course disable SOL on any user that shouldn't > be able to do SOL. > > Hope that helps, > > Al > > > On Mon, 2013-02-18 at 08:52 -0800, dan farmer wrote: > > 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.] > > > > ^..^ > > > > > > > > > > > > _______________________________________________ > > Freeipmi-devel mailing list > > [email protected] > > https://lists.gnu.org/mailman/listinfo/freeipmi-devel -- Albert Chu [email protected] Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory _______________________________________________ Freeipmi-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/freeipmi-devel
