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

[dan farmer]

Thanks Andy - a few remarks below.

On Feb 19, 2013, at 8:07 AM, Andy Cress <address@hidden> wrote:
> RE 5. 20-character passwords
> This assumes that all deployed platforms are IPMI 2.0, since IPMI 1.5
> platforms only support 16-character passwords.  There are still some
> IPMI 1.5 platforms in use out there.

Without a doubt.  I was meaning if supported, I'll clarify (and use 16 if
that's all you can; mixing is probably ill-advised ;))

BTW - does the 'test password' operation that checks to see if 20 byte 
passwords are used mean that a password is 17-20 bytes long?  I tried
to read the spec carefully on this but it wasn't clear to me on *when*
passwords are stored as 20 bytes.

> RE 12. Disable gratuitous ARP replies
> The description here is a bit off.  There are two bits to be
> configured for gratuitous ARPs:
> Sending Gratuitous ARPs from the BMC, and enabling responses from the
> BMC to ARPs.
> The BMC firmware must support one or both mechanisms.  I think you
> mean to recommend disabling >sending< gratuitous ARPs, which is good
> as long as the firmware supports enabling replies/responses to ARPs
> instead (not all implementations support both).

Must?  I thought it was optional (13.11.3 BMC-generated ARPs says
"A BMC LAN implementation may support BMC-generated Gratuitous 
ARPs or BMC-generated ARP responses.")  Given who you are I trust 
you more than my reading of the spec, which may well have been taken
out of context of the spec or is outdated, but can you clarify?

Speaking only security-wise (not ops, spec, etc.), and talking about a 
specific host that I trust, there's no problem to *its own security* to 
send out g-ARPs.

Security-wise (only) it's not a great idea to believe or process other 
system's g-ARPs.

> RE 14 BMC to use its own dedicated physical NIC
> On some systems, this requires an additional cost for the BMC NIC
> module, and I understand that your recommendations center around
> security, so this is more secure, but it definitely costs more in
> terms of components, cabling, routing, etc.  

Since you're the 2nd in a row to mention this, I'll amplify this a bit ;)
Yes, cost can be prohibitive; as you acknowledge I was only speaking
about security.

> There are a variety of
> customer use cases for IPMI, some involve only in-band usage, without
> IPMI LAN, and some value the convenience of the shared physical NIC.
> Some have physically secured LANs, etc.   Note that the BMC IP and the
> OS IP in a shared NIC configuration could also be on separate subnets.
> So, this recommendation might say that using a dedicated physical NIC
> is more secure, but this item is not one-size-fits-all.

You phrase it well, and I'll put something in that same spirit in, thanks.

> One thing that you didn't list is to find out whether each vendor's
> IPMI LAN firmware passes a Nessus (or similar) scan.  If it does not
> pass, the firmware vendor needs to handle the issues.

I mention this in passing elsewhere, I think it's a very reasonable 
expectation, and I'll explicitly mention it in the overall doc.

The levels that the vendors give are a bit arbitrary, but FWIW, I did
a set of Nessus scans on out-of-the-box iDRAC 6, iLO3, and a Supermicro 
BMC's; no "high" security issues, but:

        Vendor          High    Med     Low     Informational
        Dell            0               3               0               30
        HP                      0               0               2               
12
        SM                      0               8               1               
45

I suppose I'd suggest killing all the medium issues if at all possible.

dan