FAQ
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.

Search Discussions

  • Paul Heinlein at Jul 2, 2015 at 4:30 pm

    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/
  • Greg Lindahl at Jul 2, 2015 at 6:14 pm

    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
  • Chris Murphy at Jul 2, 2015 at 6:32 pm
    https://lwn.net/Articles/630778/


    I think you definitely want this stuff as far away from the regular
    LAN, let alone the Internet, as possible.




    Chris Murphy
  • Peter Kjellström at Jul 6, 2015 at 8:28 am

    On Thu, 2 Jul 2015 10:11:09 +0000 (UTC) Chris Olson 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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupcentos @
categoriescentos
postedJul 2, '15 at 10:11a
activeJul 6, '15 at 8:28a
posts5
users5
websitecentos.org
irc#centos

People

Translate

site design / logo © 2022 Grokbase