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

[Ales Ledvinka]

Hello,

Seeing how this mail thread is interleaved on freeipmi and ipmitool
list. I am wondering a little bit why the openipmi-developer was left out.

Correct that the rest delivered with BMC is not IPMI related.
Head right to the DMTF.org for the rest of the management stack standards.
SMASH CLP through either ssh or telnet. WS-MAN through CIMMOM like sfcbd.
And to OEMs for particular implementation details.

Then there is just the web gui left.
None of that is IPMI but still BMC provided.

----- Original Message -----
From: "Albert Chu" <address@hidden>
To: "dan farmer" <address@hidden>
Cc: address@hidden
Sent: Tuesday, February 19, 2013 8:01:56 PM
Subject: Re: [Freeipmi-devel] ipmi configuration security best practices

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



_______________________________________________
Freeipmi-devel mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/freeipmi-devel