Console Server Design Considerations
When considering a console solution, a review of the common features available can ensure that the design meets your requirements. Although few environments need all features, it is important to understand the features available in order to measure the importance of features, rank them appropriately, and decide on the best solution for your own environment.
Rights and Authentication
Because of the escalated privileges provided on the console ports on many variants of Unix, rights and authentication features should receive careful consideration. Granularity is the key to flexibly; however, if the solution offers too much granularity, then the rights administration should support a grouping methodology to allow rights to be summarized and applied easily. Specific features to review are limiting users (or groups) to specific ports, time of day login (especially important for operators or outsource data centers), administrator access and limitation to the console, and assistance mode for viewing other sessions.
The types of authentication supported by console servers have improved drastically, with most console servers supporting multiple authentication methodologies. Popular implementations include RADIUS, TACACS, LDAP, and Microsoft Active Directory. Typically one or more of these authentication methods already exist in many environments. The following provides a brief overview of each.
Local Accounts -- Most console servers will have a method of maintaining simple user IDs and passwords. Ideally, a couple of local accounts can be provisioned to be a backup method to the preferred authentication protocol. If choosing local accounts for user and authentication, a close review of common user ID and password policies should be reviewed to ensure compliance with existing policies such as aging passwords, strong passwords, minimum password requirements, etc.
Active Directory -- With Microsoft's popularity in the desktop arena, Active Directory (AD) has become the authentication choice for many organizations.
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.
RADIUS (Remote Authentication Dial-In User Service) -- The premium authentication protocol for enterprises and service providers that was established as a standard as part of the massive PPP buildout during the 1990s to support remote access over dial-up lines. RADIUS authentication requires a RAIUS server (typically deployed with redundancy).
TACACS+ (Terminal Access Controller Access Control System+) -- This is a protocol popular in Cisco shops. Its function is similar to RADIUS.
In addition to the rights and authentication features, some environments may also have a need for access control lists. These allow the systems administrator to control from where the console server can be accessed to provide additional security.
Besides the obvious out-of-band features that console servers provide, the most important features -- and often the differentiating factors that drive the purchase decisions are those presented on top of the console access.
Logging -- Capturing all input and output to the console is a key feature to console servers. Advanced features for logging include forwarding to syslog servers and alerting based upon particular search strings on the console. If a proprietary (non-syslog) format is used for storage, the downside to having proprietary logs should be offset from the vendor with features such as statistics, alerting, indexed searches, etc. Besides forwarding to another syslog server, some implementations support picking up logs via the network file system (NFS) or file transfer protocol (ftp).
An advanced feature of the console logging is date stamps, which can be very useful in troubleshooting the timing of event within a distributed environment. Ideally, the date stamp feature is based upon support of the network time protocol (NTP) to allow even correlation to be more easily matched with logs on other devices and systems.
SNMP Translation -- One method of alerting based upon console logs is to translate particular messages to simple network management protocol (traps). This provides (additional) alerting of the hosts supported on the console. (Console servers also support SNMP management; see below.)
Solaris Key Trapping -- Sun systems provide the capability to halt a system with a break combination; however, it is important.
Shared Access -- Often multiple users need access to the console at the same time. This situation may occur when a senior admin needs to assist a junior sys admin or when the administrator needs to watch a vendor carry out particular tasks. Shared access to ports provides this feature. Advanced features include read-only viewing and individual user tracking (who typed what).
Email -- Email alerting provides simple alerting of the console and, in some cases, alerts based upon console messages. For Unix and Linux implementations, the email is typically supported natively. In some scenarios, a mail relay is required to forward the messages through.
SNMP -- Management and alerting based upon SNMP is provided in various levels of sophistication and alignment with existing management and monitoring tools, such as HP OpenView, Netview, BMC, etc.
Administration Wizards or Templates -- To speed delivery of console servers, some vendors (e.g., Cisco, Sun, and Linux) provide templates for common network and host equipment that allow console access to be quickly provided based upon standard configuration options "out of the box" for particular console support. For example, one template may set the speed to 9600 bps 8 bits, no polarity, with hardware control for a particular Sun device and have another configuration template for 2400 bps 8 bits, polarity, and software control for a PBX.
Statistics -- Usage and real-time statistics are, unfortunately, often poorly documented and in some cases poorly implemented. Large enterprises, which may be used to receiving daily operation reports that provide a 24-hour recap of activity of infrastructure items, will most likely need to document their requirements and prepare a request for information from a particular vendor. The vendor can then determine whether the requirements can be met with existing features in the console solution or whether some custom scripting will be required to provide the necessary reporting. SOX requirements should be handled in the same way, since the access will invariably be reviewed.
Restricting access to the console server and ultimately the specific port is the key to securing the connection to the console server. The following features should be considered for your particular environment.
IPSec -- IPSec has gained support in most corporations due to its almost universally accepted standard of new virtual private network deployments. Although not as popular for access to individual host systems, it has gained some popularity for access to consoles to provide a secure method of routing traffic across IP networks.
Telnet -- Telnet is a universal protocol supported by most servers and clients; unfortunately, none of the traffic traveling across this TCP protocol is encrypted, allowing very sensitive information (the most sensitive likely being user names and passwords) to pass in the open. Therefore, its uses should be avoided, especially on new deployments. There are better clients available for secure shell or the Web on all common client platforms.
Secure Shell (SSH) -- SSH is the de facto method for host connectivity. All traffic sent through SSH is encrypted ensuring passwords, and other sensitive information is not sent in the open across corporate networks.
Besides access to the console for managing the console ports, the administrator will also need an out-of-band access to the console server. Common features in this area include dial-in, and recently wireless. These methods are used for recovery whenever the local telephone exchange is overwhelmed, which can often occur with regional disasters.
Facilities management requirements are very clear in data center and carrier locations; however, remote sites may have less stringent and less well-known requirements. Most vendors offer solutions that meet power (dual, AC, and DC options), rack (19" or 21" adapters), and space (1 RU typically) requirements. Newer implementations also allow use of CAT 5 (or 6) cabling to take advantage of existing cabling infrastructure.
Some of the more advanced features available for facilities consideration include serial surge protection, serial disconnect logging, dial-back support, and power strip control.
By carefully understanding features available to current generation console servers and comparing vendor offerings, you will ensure that you have a close match with your environment's requirement. The features covered here ensure you have authentication, console features, and key management features covered.
Ronald McCarty is a freelance writer and consultant specializing in systems, network, and information security. He received his bachelor's degree in Computer and Information Systems at the University of Maryland's international campus at Schwaebisch Gmuend, Germany and his master's degree in Management with a specialization in information technology at Capella University. Ron's company, Your Net Guard (http://www.YourNetGuard.com) offers IT consulting and integration services in the Dallas/Forth Worth area. He can be reached at: firstname.lastname@example.org.