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

[Albert Chu]

On Tue, 2013-02-19 at 08:36 -0800, dan farmer wrote:
> 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.

My recollection is hazy, but I don't think it does what you want.  What
it does is check if you stored the password in a 16 or 20 byte buffer,
b/c you can store a password <=16 bytes into a 20 byte buffer (w/ padded
0s).  So if I store the password "FOOBAR" in a 16 byte buffer, it fails
a check if I say "is FOOBAR the password stored in a 20 byte buffer."

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

I think what Andy means is that pretty much all vendors support 1 or the
other.  I do think that it's possible a vendor can support neither
(which means users would have to manually set the BMC MAC in their ARP
cache). I've never heard of a vendor supporting neither though.

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