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.
On Thu, 2 Jul 2015, Chris Olson wrote:> 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 > than the primary serial ports. > > There is a concern about system security primarily driven by recent > information searches performed by end user admins and included > below. [...snip...] > > 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.+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. -- Paul Heinlein <> heinlein at madboa.com <> http://www.madboa.com/
On Thu, Jul 02, 2015 at 12:30:47PM -0400, Paul Heinlein wrote:> 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.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
On Thu, 2 Jul 2015 10:11:09 +0000 (UTC) Chris Olson <chris_e_olson at yahoo.com> wrote: ...> My initial recommendation was to use a totally separate network for > any service processors+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