How do you get to your critical systems if the network is down? There are a number of different technologies that are used in this case. Often, they involve some kind of terminal server that is connected to the system via a serial terminal (yes... there are still some of them around), or via an IP based KVM switch. The terminal server itself may be reachable via a backup network connection, or maybe someone even has a dial-in setup around for them. But no matter the exact technology you are using to implement this, a "backup connection", or "out of band connection" often bypasses a lot of security controls. This is done by design to ensure that the backup connection can be used even if these security devices do not respond. Often, these connections are also used to manage security devices.

The problem with this approach, from a security point of view, is that there is often little logging and auditing controls around these systems. I will look here at two specific devices and see how they can be "hardened".

SuperMicro IPMI Access

Many security professionals will grinch if I mention accessing systems via IPMI. IPMI implementations have shown to be vulnerable many times over. Patching them can be difficult (if patches are available). But in reality, IPMI is often used and indispensable when it comes to remote access in case the server can not be reached. There are a couple of meaningful steps you can take to better secure these setups. I am using Supermicro's implementation as an example, as I am familiar with it. From limited experience, I know that other implementations offer similar features.

Obscurity isn't security, but it helps:

Do not add IPMI servers to DNS. Instead, use a good old host file for them. Only a handful of people should have access anyway, so it is not too hard to use hosts files. Also, move the IPMI server to a non-standard port.

Logging and Alerting

Define an e-mail address to receive alerts. Depending on your architecture, this may be an e-mail address at a different domain/site then your primary organization's e-mail address. Remember you can't receive alerts at @company.com if Company is down. Sadly, I usually do not see any good logging for local access to the console.

SSL Security

SSL options are usually very limited. But upload a valid certificate. One signed by an internal CA should be fine, and may even be preferred unless you are planning to advertise your IPMI system via certificate transparency. With some older systems, it may also not be possible to use a certificate that matches current CA requirements (for example SHA2 signatures may not be supported)

User Configuration

Each admin with access to the system should have a personalized account. Avoid generic "Admin" accounts. You can often configure remote authentication via LDAP/Active Directory/RADIUS, but keep in mind that you need a backup in case the LDAP server is down, and any logging provided by these systems will only apply to users authenticating via them. Network authentication has, of course, its own challenges.

Network Configuration

Limit IPMI to respond only on one of your network cards, preferably one connected to a management network. In some versions, you can also setup firewall rules that will allow you to whitelist specific IP addresses for access.

Access Logging

Let me know if you find anything great in that respect. None of the systems I remember had a Syslog, or even an SNMP trap option to send alerts about log-ins. I found it best to log access on the network level (bro/snort...) . A simple snort signature that will hit whenever someone connects to an IPMI server is usually the only thing you can do.

Now another option is serial consoles. Just like IPMI, these devices tend to be not the most secure and not all that easy to maintain. I have used products from Cyclades and others. My minimum requirement is always SSH access. But even with SSH, there are often old ciphers being used. A first step should be simple "ssh hygiene":

• do not allow root logins
• move the ssh server to an odd port
• limit access via network and host-based firewalls.

On the good side, I found that these products usually are able to do remote logging via Syslog, and since they typically have some more or less "regular" Linux, configuration is a bit more flexbile. But be careful after firmware updates as they often undo a lot of the less standard configuration changes. 

---
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS Technology Institute
STI|Twitter|