[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Freeipmi-devel] ipmi configuration security best practices
From: |
Albert Chu |
Subject: |
Re: [Freeipmi-devel] ipmi configuration security best practices |
Date: |
Tue, 19 Feb 2013 10:25:33 -0800 |
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