Console Design Considerations

Ron McCarty

This article will cover some of the more common design criteria and best practices you should consider when designing and acquiring a console infrastructure. Console servers, although little known outside the datacenter, provide key services to quick recovery, better systems administration practices, and better datacenter security.

When choosing a console server, you should carefully consider your requirements, because console servers vary in the features supported. An understanding of these features will ensure you can define the appropriate requirements and not miss your requirements in a list of features that might seem overwhelming at first glance.

Out-of-Band Management

There are times when an out-of-band management method of accessing Unix systems is needed. This out-of-band connection could be a modem that allows a dial-in into the terminal server or an "uplink" to another terminal server. Although terminal servers do not provide "production" service, out-of-band access can prove useful in site disaster recovery where there is limited access to the datacenter or computer room, such as in the case of a water or chemical spill. Out-of-band management to the console server also might prove useful for short-term vendor access to the system in the case of a system failure.

User Interfaces

Console servers have come a long way from the simple TCP to serial mapping that makes them so useful. Interface changes have been driven mostly by security requirements within the enterprise, but ease of management has also impacted the interface design that the systems administrator experiences. Because the console mode on most Unix versions gives various levels of privileges normally associated only with the superuser account, an additional level of security is normally integrated with the interface. Before covering the security features, though, let's examine the general interfaces available:

Telnet -- This traditional remote access method has become less popular because of its lack of encryption -- mostly passing the password in the clear text across the wire. However, telnet may be important to you if you have older versions of Unix servers or network devices that do not support secure shell (or some other secure method). If you need telnet support, you should also have a middle tier authorization between the telnet session and the serial port -- not a clear pass through, even if the device supports a direct access to the device.

Secure Shell (SSH) -- SSH has become the de facto method for securely connecting to Unix servers and many network devices. Although most sys admins' access to Unix systems is not sensitive unless the administrator also has application responsibilities, such as HR or financial systems support, the account information must still be protected. The easiest way to protect the account is through strong passwords and encrypted communications.

IPSec -- IPSec is supported on some devices and has become very popular for corporate virtual private networks. Although not as popular for Unix administrators, it is an industry-supported standard and might be a very viable option for environments where network administrators will also be using the console server.

Web -- A Web interface with SSL (secure socket layer) support provides the same advantages as SSH, but also provides a pretty universal method of getting to the terminal server. The universal access is practical when the administrator does not have SSH access. Web interface often relies on Java, JavaScript, or a plug-in to provide a terminal emulation that is sent through the SSL connection to the terminal server.

Management Features

The features available for system management include:

Port buffering -- Port buffering provides the administrator with a historical look at what has shown up on the console. Port buffering is often quoted in lines or kilobytes. This feature can be very useful during a system crash and restore, therefore several hundred lines at a minimum should be available for this purpose.

Logging -- Logging works on the same principal as buffering, but typically an extra step must be carried out to get to the log. The logs may be stored in proprietary format if the vendor provides added value, such as alerting or statistics, or in plain text if the logs are purely for later, reactive, access.

Log forwarding -- Log forwarding allows the console server to forward the logs to another facility, such as syslog, or to another file system via ftp or NFS. This can be very useful for security incidents and alerting.

Alerting email -- Email alerting based upon what the console server receives from the console can be a simple alerting mechanism, especially in shops without enterprise management tools.

SNMP translation -- Some terminal servers allow console messages to be converted to simple network management protocol (SNMP) traps.

Real-time monitoring -- Real-time monitoring allows the administrator to see what is happening on a particular serial port. This is useful when vendors must be given access for a particular reason or to allow a senior sys admin to advise a less experienced person.

Authentication

Access to the console server should be granted only to authorized users. The following features should be considered when designing your solution:

RADIUS (Remote Authentication Dial-In User Service) -- This protocol is the protocol of choice for ISPs and many enterprises that provide point-to-point protocol (PPP) dial-in capability. If the console server will be providing dial-in services as well as console access, then RADIUS is likely a requirement in most environments. Keep in mind that a RADIUS server will also be needed for the actual user name, password, and rights management.

TACACS+ (Terminal Access Controller Access Control System+) -- This is a protocol popular in Cisco shops. Its function is similar to RADIUS.

LDAP -- The Lightweight Directory Access Protocol is gaining strength in Unix shops as Sun moves away from NIS. If you are considering LDAP in other parts of the environment, then LDAP for the console server would also be a good idea. Like RADIUS, LDAP will require an LDAP server to provide the user management capability.

Active Directory -- With Microsoft's popularity in the desktop arena, Active Directory (AD) has become the authentication choice for many organizations.

Proprietary accounts -- Most console servers will have a method of maintaining simple user IDs and passwords. This feature may also be configurable to be used as a backup to another authentication protocols.

Rights Management

Because of the management nature of console access, being able to provide additional security in addition to the Unix login is desired in many environments. Features to look for in rights management include limiting specific users to specific ports, time of day access (so admins can look at messages during a particular time of day), configuration management, and assistance mode (allows users to look in on other sessions and assist).

Cabling Requirements

Console cabling specifications are well documented, so there is little to consider in design; however, specifications should be followed, and gender of adapters followed closely to avoid the use of "gender benders". One option that is available from some vendors is direct support of category 5 (CAT5) cable or adapters that allow the cable and connectors to be used.

Hardware Considerations and Support

Console servers come in many flavors with pros and cons of each type. Appliance solutions are often easier to integrate into a datacenter, because backups, monitoring, and acceptance are easier than on open operating systems that have been customized with a wrapper. These open system solutions are often based upon a Linux kernel. In these scenarios, the vendor should be very specific on what management activities will be carried out by the staff and what will be provided by the vendor. For example, who will apply security patches? Should the sys admin download the patches, or will the vendor provide them? Are the patches deployed using standard OS tools, or does the vendor have a wrapper?

Non-Unix Systems

Most console servers will support network devices such as switches, routers, and CSU/DSUs. Additionally, PDUs and power supplies have intelligence built in to allow power to be controlled from a serial interface (and IP). Often an enterprise approach can be taken and the same console server can serve all of the devices.

These design criteria along with the vendor information provided in this issue should get you started putting together a console server solution that meets your needs. Good luck!

Ronald McCarty is a systems/network professional and freelance author. Ron completed his undergraduate in CIS with University of Maryland and is currently seeking a graduate degree from Capella University. He is Director of Product Operations at Net Watch Solutions, Inc., a company providing IT management solutions in the asset and change management arenas. His free time is spent with his best friend and wife, Claudia, and their two children. Ron can be reached at: mccarty@mcwrite.net.