IPMI/BMC/BIOS

Home » CentOS » IPMI/BMC/BIOS
CentOS 4 Comments

We have recently been asked to evaluate some computing machinery for a new project. This particular end user has very limited experience with the stated security requirements in a lights-out environment. Their primary work (as well as mine) in the past has been with very small, simple networks of desktop machines and a few servers with extremely limited access.  For the most part, their admins haverefused to use any maintenance connectivity to servers other thanthe primary serial ports.

There is a concern about system security primarily driven by recent information searches performed by end user admins and included below.

IPMI/BMC Security Issues
————————
https://en.wikipedia.org/wiki/Intelligent_Platform_Management_Interface http://www.google.com   Search:  IPMI “Security Holes” — Hits: 14,500
http://www.google.com   Search:  IPMI BMC “Security Holes” — Hits: 4950

BIOS Security Issues
——————–
https://en.wikipedia.org/wiki/BIOS
http://www.google.com   Search:  BIOS “Security Holes” — Hits: 342,000

My initial recommendation was to use a totally separate network for any service processors within the servers that implement IPMI/BMC capabilities. This has been standard practice in most systems I have worked on in the past, and has allowed certification with essentially no problems. The BIOS
concern seems to be another issue to be addressed separately.

Any connectivity and access to a system brings security issues.  The list from these searches is huge.  Are there specific things that must always be addressed for system security besides keeping junior admins off the server supporting the maintenance network?

Thanks in advance for any feedback and best regards.

4 thoughts on - IPMI/BMC/BIOS

  • +1 to network separation for OOB management. I assume you mean
    “non-routable LAN,” but that segment’s connectivity is an interesting question in itself. I like having access to management consoles via VPN, but others dislike any off-LAN access whatsoever.

    If your admins are comfortable with serial consoles, a concentrator like those available from Digi or WTI can offer fairly robust access controls; they can also be set to honor SSH keys rather than passwords, which may help increase security.

    WTI: https://www.wti.com/c-4-console-server.aspx Digi: http://www.digi.com/products/consoleservers/

    I’ve had an easier time working with the Digi firmware, but either will do the job.

  • I’ve used those for devices that were fairly dumb, but for servers it can be nicely cheaper to use serial-over-ipmi plus conman for that purpose. It’s necessary to log and monitor the serial consoles, there are a variety of OOPses and BUGs and whatnot that only appear there. I’ve been using ‘conman’ for this purpose.

    I totally agree with you about having a separate admin-only network. It’s not that expensive to build one up using dumb switches.

    — greg

  • …

    +1 for this. We typically put all management ports for a
    ‘system/project’ on a sep. non-routed eth. segment to which only the, for the ‘system/project’, designated management servers can connect.

    It is probably a good idea to consider random ethernet connected
    ‘things’ as soft security wise and not suitable for the big bad internet…

    As for bios/firmware on servers the best one can do is to use non-deprecated hardware from responsible vendors and keep up to date with their sec. info and update promptly when required.

    /Peter