Reading the paper, I had some thoughts: Overall, most of the concerns are less about the fundamentals of IPMI and more about the general state of service processors in general.
I think RAKP is a bit mischaracterized in the paper. AFAIK it is never
about persistent key data, but about the transient privacy/integrity key
agreement. In terms of persistent key management, you have to use the set
user password and set security keys commands. Since the persistent keys
are all shared secret based, bootstrap of those credentials must be done
via some other mechanism. Commonly the presumption is some guy tediously
keying it into the 'Setup' screen one by one. In xCAT we are providing an
option where initial key agreement is only done after a node proves its
physical presence to have an x509 certificate granted and then requiring
that before we divulge or generate a shared secret for the BMC (the latter
option has unique keys per BMC, but no one ever enables it because they
care too much about the manual interactive case and know they can't
remember unique keys per BMC). I think the challenge is pretty fundamental
and ubiquitous to everything in IT security: initial establishment of trust
in highly automated environments. The reality is that most shops
auto-accept host keys rendering many security assumptions invalid unless
that problem is fixed.
"The reusable passwords used for IPMI authentication are saved in clear
text in flash memory" True, but it is a shared secret mechanism that
permits the client to never have to transmit the password on the wire
(which might be debated to be a more vulnerable place). It also provides
for implicit mutual authentication if the client is strict enough in what
it will accept from an IPMI device. One-way hashed passwords have their
own problems, notably that a spoofed server has a pretty high chance of
acquiring secrets through MITM. Ideally, you correctly have everything
private-public key based (which admittedly has no consideration in the IPMI
spec), the gap in practice is that the host public key is frequently taken
at face value. Shared secret at least makes the admin unwittingly set up
mutual authentication. The shared secret scenario is troublesome as it
limits the security for those that know and care about security, but has
some tendency to instill better practices for those that care or know less,
but do at least care enough to 'set a password'. My desire in this front
would be an additional public/private key based auth mechanism to allow
diligent users and software to implement something more unambiguously
secure. However, such diligent users can limit shared secret scope already
through unique key data everywhere (though no one seems willing).
"If you have the IPMI password for a single system, you have the password
for all the computers in that IPMI managed group" Nothing inherent about
IPMI influencing one way or another. You can have unique keys per user-bmc
combo and for Kg limiting the exposure of any single key compromise, just
as you can have unique local root passwords in /etc/shadow. Just
like /etc/shadow, the tendency is for people to reuse the credential more
than is required.
"it has to ask a potentially compromised BMC to answer truthfully." This
can be controlled vendor to vendor. E.g. an IBM IMMv2 has the entire boot
process and filesystem signed in such a way that malicious attempts to
manipulate it are thwarted. This exacerbates the 'precludes customer for
applying fixes prior to the vendor' issue, but it does mean that commands
shall work as intended by the manufacturer. The key here being to pay
attention to how the vendor protects the integrity of their implementation.
"Man-in-the-Middle attacks ... traffic going to-and-from the BMC aren't
encrypted or protected against this type of attack" So long as you avoid
IPMI 1.5 "straight" and ipmi 2.0 cipher suite 0, this isn't the case. Even
with IPMI 1.5 without encryption for privacy, you still have HMAC with MD5
for integrity assurance. The confidentiality is not protected, but the
integrity is. It's of course optimal to apply the higher security of IPMI
2.0, but 1.5 already has MITM resistant strategy in place.
In general, my recommendation would be for environments worried about
security to stop caring so much about direct human interaction and let
higher order software manage unique keys everywhere there is a desire to
use 'passwords' today. Someone recovers the BMC password off an ebay
discarded box? No big deal, the scope of that key was unique. Someone
tricks the security framework responsible for key coordination into
divulging a new key? No heightened privilege, but perhaps a way to remove
all access to a BMC which is less bad.
From: dan farmer <zenf...@gmail.com>
To: Jarrod B Johnson/Raleigh/IBM@IBMUS
Cc: "ipmitool-devel@lists.sourceforge.net"
<ipmitool-devel@lists.sourceforge.net>
Date: 02/19/2013 10:57 AM
Subject: Re: [Ipmitool-devel] ipmi configuration security best practices
Thanks for the feedback - a quick reply:
On Feb 18, 2013, at 10:24 AM, Jarrod B Johnson <jbjoh...@us.ibm.com> wrote:
Seems mostly sensible.
-Gratuitious arp: agreed, but some BMC implementations cannot manage
to get ARP requests to the BMCs. I presume this is why such a
request is in the spec at all. I'd avoid such implementations like
the plague for reasons beyond security though, just be aware that if
an implementation enables that by default it may not work at all once
disabled without static arp tables everywhere.
That's a good way of putting it, I'll put something to that effect.
-Avoid shared network: That's a pretty costly recommendation in some
environments. An adequately secured BMC is relatively low risk to
exist on the network.
-Use VLANs. I'd say that, security wise, this adds very little. If
someone has enough access on a host in the network, they can tcpdump
to discovery your management vlan id and vconfig their way onto it.
It may make sense for non-security reasons, but I'd rather not people
get a false sense of security because they enabled tagged vlan id to
BMC.
I mostly agree about VLANs, although it does stop *some* from doing things.
More complexity than it's worth in my mind, and they're almost always
misconfigured in ways that people don't understand.
The other… well, that's the basic disagreement between us, since I don't
think BMCs may be adequately secured in general (I write at length about
this in my paper, not trying to convince anyone, and there may be
exceptions.) And the cost of a compromised BMC can at lest potentially
vastly outweigh the cost of a server compromise. I would say that putting
a server between it and the attacker is at least adding a bit of friction
to the attacker's ride, but certainly not a panacea.
I've compromised BMCs with very little effort by attacking them from the
server side; my sample is very small (I've all of 3 different servers from
as many vendors, and got 2/3), but it is certainly possible. Strictly
security wise (not ops or cost) it makes sense to minimize exposure.
All that said, you know far more about IPMI+ and how it's deployed than I
do. I've talked to big vendors who also have different final conclusions
but don't disagree with my basic points; I suppose it's not a black-n-white
thing, but presumably over time we shall learn more.
dan
<<inline: graycol.gif>>
------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb
_______________________________________________ Ipmitool-devel mailing list Ipmitool-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ipmitool-devel
