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
------------------------------------------------------------------------------
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
