Re: [Freeipmi-devel] ipmi configuration security best practices

[Albert Chu]

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
> > address@hidden
> > https://lists.gnu.org/mailman/listinfo/freeipmi-devel
-- 
Albert Chu
address@hidden
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory