| oct2006.tar |
Security Best Practices for Console Servers: An Interface ApproachRon McCarty Console servers have become key components of managing large centralized data centers as well as remote sites and shops that require quick administrative access to systems during outages. Because of the critical nature of console servers and the escalated privileges they can grant to the systems being managed, systems administrators must have a strong understanding of the security implications involved and take the necessary steps to mitigate any risk associated with providing console access. The risks associated with console servers are well worth the return benefits assuming good security practices are used to minimize the effect of those risks. This article gives an overview of those risks as well as some best practices that can mitigate them. The approach used for this article is an interface approach -- each interface and the logical interfaces "above" the interfaces will be covered from a security standpoint. Network: Ethernet The Ethernet interfaces used by the console server provide the physical access to the IP network for the console server. Within some console servers, a redundant network interface is provided. Ideally, this interface should be provisioned as a redundant interface to provide additional availability. However, if the redundant Ethernet interface is not used, then the interface should be removed if possible or configured into an administrator down state. The interface should not be connected to any networks other than the network it is providing redundancy on, since this can be used to effectively bridge or route between two networks. Shops with strong intrusion detection postures will want to track both the MAC and IP addresses of their console server equipment. Network: IP The Ethernet address will need an IP address to make the console server reachable on the network; however, there may be a tendency to simply turn up the console server, place it in a convenient network, and start plugging in servers, especially in networks where console servers have not been deployed. There are several steps the sys admin can take to ease management and provide a more robust security posture for the console. In environments that have the most stringent network security, the console server should be placed in a DMZ dedicated to network and systems management. This will allow traffic to be filtered and only allowed to specific IT networks that are identified for sys admin workstations. This security posture will also lends itself to mitigating risk of most employee attempts to access the console servers. Even environments that do not require the toughest security should also consider a DMZ placement, since a firewall can provide protection to services that may not be able to be disabled on the terminal server. If the environment does not support such a stringent security policy, then the console server should be placed on an IP network designed for network management. This will position the console server to ease administration for future intrusion detection investigations, where sensors need to be placed around devices to try to identify an intruder by separating the console traffic away from normal production traffic. Network: Telnet Don't. With secure shell (SSH) being proven over the last several years, there is no reason to provide a method such as telnet that sends passwords in clear text. Many less flexible sys admin will try to rationalize the access because telnet (client) comes installed on workstation and PC operating systems. What needs to be very clearly understood, however, is that a sniffer placed on a port mirrored to the console server can grab passwords quickly, especially if the sniffer is placed there during a patch weekend where numerous boxes are accessed and rebooted. Network: Secure Shell Secure Shell has become the de facto standard for direct login in Unix shops that prefer to keep their servers secure. Use it. Network: SNMP The Simple Network Management Protocol (SNMP) is very popular for network management and monitoring. Due to the wide variances in versions, vendor interpretations and implementations, and the vulnerabilities associated with a poor posture when using SNMP, the following approach can be used to ensure the most secure posture of SNMP:
Network: HTTP Don't. The Hypertext Transfer Protocol (HTTP), like telnet, is an open protocol. Therefore, authentication credentials are sent in clear text. Generally, there is no need to provide HTTP access since SSL is provided for most modern console servers. If possible, HTTP access should be administratively shut down. If HTTP is configurable on a per-user basis, then HTTP should not be granted to any users. Network: HTTP with SSL Because of the proliferation of e-commerce, secure socket layer (SSL) has become a common Web interface for providing encryption. By encrypting the traffic, passwords and sensitive data will be not be passed in the clear where they could easily be intercepted. Network: Authentication Protocols Authentication protocols are numerous; however, not all authentication protocols are created equal. Luckily, due to the concern for security created by recent legislation at both the federal and state levels, there has been quite a bit of interest in supporting encryption. Protocols without encryption should be avoided, and research and due diligence are the key to selecting a secure method to authenticate without assuming unnecessary risk. Also keep in mind that although many older and proven technologies are not encrypted, they have been improved upon with secure versions. For example, the lightweight directory access protocol (LDAP), is available as secure LDAP. Network: FTP/TFTP/scp File transfer may be needed on the console server to perform system upgrades, system backups, and log rotation; however, the file transfer protocol (FTP) and trivial file transfer protocol (TFTP) should be avoided since passwords are passed in clear text. Most vendors have provided secure methods, such as secure copy (scp), to replace this functionality. If TFTP is necessary for booting the system, then the TFTP server needs to ensure adequate security is provided by the TFTP daemon and directory permissions. This is because TFTP does not provide any authentication method, and all traffic is sent in clear text. (Booting from local storage is preferred for this reason, but larger environments may choose to take on the risk associated with TFTP to support large numbers of console servers centrally.) FTP and TFTP should be shut off if the console server supports the functionality and they are not required. Network: NTP The network time protocol (NTP) is supported on most console servers. NTP can support a broadcast and a query method of keeping systems in sync. The query method is preferred since rogue NTP services can be activated on the network. In addition to using the query method, there should also be at least two NTP servers for redundancy within the network. For the most secure method of using NTP, configure the console server to query NTP and provide the IP address of the NTP servers. If NTP is unavailable, ensure the time is set correctly on the console server, because any intrusion or unauthorized use investigations will depend on accurate time reporting. Network: ACLs Some console servers support access control lists (ACLs) that allow only specific traffic to be passed on to the applications layer. ACLs should be considered to limit access only from appropriate workstation and remote networks. If feasible, only specified protocols should be allowed. (The feasibility often depends on the ease of use of the interface.) Wireless Wireless connectivity to console servers has become popular due to the almost universal deployment of wireless into laptops. Wireless provides easy access to the console server, but it must be deployed securely. Under the right conditions, it can provide access to intruders who would not normally have access to the network. Wireless access should be considered carefully. If wireless access is needed (in most environments it is a convenience, not a requirement), ensure it is deployed used the latest most secure protocols based upon the WiFi Protected Access Protocol (WAP) that is part of the 802.11 security specification. Additional security can also be implemented using MAC filtering (but MAC addresses can be spoofed). Console Ports Console security is provided mostly through limiting the physical access to the system; however, there is best practice to further mitigate risk. Ports that are not used on the console server should be administratively shut down to mitigate the likelihood of someone gaining unauthorized access to a new system. On console servers that provide user assignments to ports, users should be provided access only to the console ports for which they are authorized. Even though the server connected to the port will authenticate the user as well, this provides tiered security and ensures someone does not tie up a port inadvertently. Port logging and buffering should be activated for all ports. In addition to the additional security information this provides, it also supplies valuable operational data during a system crash that may not get written to disk before the crash. Modems Modems can provide an additional method to gain access to the console server and can be very useful in a site impacting outage. However, modems also provide an additional method into the network that requires careful consideration. If a modem is provided but not needed, it should be removed or administratively disabled and no connections to the telephone network should be made. If a modem is needed, then the vendor's recommendation on securing it and assigning user rights followed closely. Any logging should be turned on. Call detail records from the PBX or telephone company should also be reviewed as part of a regular security review. Portable Computer Cards Some console servers use portable computer cards (PC cards, also sometimes still called Personal Computer Memory Card International Association [PCMCIA] cards) to provide additional functionality such as Ethernet, wireless, and modems. The PC Card should be treated like the functionality it is providing, such as following best practice for modems. Summary By taking an interface approach, many of the security risks that come with console servers can be removed or mitigated. To assist in the interface approach a checklist is provided in the sidebar. By combining this interface approach with a good systems approach that covers patching, user identification and password management, and sound management, your console servers can stay secure. Ronald McCarty is a systems/network professional, freelance author, and founder of Your Net Guard, a company specializing in systems, networking, and security services. Ron completed his undergraduate in CIS with University of Maryland and is currently seeking his graduate degree from Capella University. His free time is spent with his best friend and wife, Claudia, and their two children. Ron can be reached at mccarty@mcwrite.net.
|