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 <[email protected]> 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 > [email protected] > https://lists.gnu.org/mailman/listinfo/freeipmi-devel -- Albert Chu [email protected] Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory _______________________________________________ Freeipmi-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/freeipmi-devel
