I'll have to review the paper. The other thing I'd add is the cipher suite 0 warning probably cannot be overemphasized. If you have cipher suite 0 enabled, whether used or not, it is a huge risk. At least with STRAIGHT authentication the risk only comes about when some entity knowing the secret actually uses it, cipher suite 0 is a risk all the time. Inclusion as a valid option I think was the biggest mistake that could've been made. If there is only one thing about IPMI security someone bothers to learn, it is the cipher suite 0 thing. I know you already understand this, but I'll take any opportunity to rehash that point.
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
