9.3. Users Are Still Demanding TelnetTelnet is an old protocol that allows users to log in to remote systems in almost the same way as they log in to local text terminals. Security experts have been warning users about Telnet for decades and telling people to use a more modern protocol, such as the Secure Shell (SSH). The main problem with Telnet is that it sends messages in clear text. In other words, anyone with a protocol analyzer (more popularly known as a "sniffer") and a connection to your network can read all network traffic that uses the Telnet protocol. They can even capture the username and password that are sent when someone logs in and then impersonate that user. Naturally, you don't want users making their passwords so easily accessible to crackersor even the curious. But many users are familiar and comfortable with Telnet, and want to use it despite its security problems. Many administrators like the way Telnet is configured as an Internet Super Server (inetd.conf or xinetd.conf) service. Fortunately, there are secure ways to configure Telnet. These methods use the Kerberos protocol, developed at MIT, to encrypt communications. There are two stages to this process: first, you'll need to install Kerberos clients and servers, with appropriate keys; then you can install the Kerberos-enabled Telnet clients and servers. I assume you'll want to install both clients and servers on your Kerberos/Telnet server computer, so you can test the results locally.
Finally, the last section under this annoyance shows how to limit access to particular remote hosts or networks, using TCP Wrappers. 9.3.1. Preparing Kerberos for TelnetIf you want to secure Telnet, you'll need a Kerberos server, as well as Kerberos clients, for the systems where Telnet users are located. Kerberos is a well-established security system that allows identities and access rights to be shared by multiple systems. For a basic overview, see the Kerberos Infrastructure HOWTO, available from http://www.tldp.org/HOWTO/Kerberos-Infrastructure-HOWTO/. The packages you need depend on the distribution; for more information, see Table 9-1. Naturally, the components in each package vary by distribution; for example, SUSE's Kerberos server components are divided into three RPMs.
To prepare a Kerberos server, take the following steps:
Now you can configure the Kerberos version of Telnet. Users who are enabled on your Kerberos server will be able to log in from hosts, as long as the hosts are also enabled on your Kerberos server.
9.3.2. Secure TelnetKerberos versions of Telnet are available for most Linux distributions, including those covered in this book. However, the package names vary widely, as shown in Table 9-2. While many of these packages include Kerberos-enabled clients and servers for other services, the focus in this annoyance is on Telnet.
Before you continue, make sure you've installed the packages customized for your distribution. If you've properly configured your update systems, the installation command should be straightforward. If you're running Debian, the following command should install the noted packages: apt-get install krb5-telnetd krb5-clients To make sure your users don't use the insecure version of Telnet, you'll also want to uninstall the associated package with a command such as: apt-get remove telnet If you're running Red Hat Enterprise Linux, assuming your system is subscribed to the right channels, you can install (or check for upgrades to) the krb5-workstation package with the following command: up2date -u krb5-workstation Alternatively, with Fedora Linux, you can use yum commands to make sure your systems are up-to-date and can install or upgrade your systems with the following command: yum install krb5-workstation Or with SUSE Linux, you can use YaST to install the krb5-apps-servers and krb5-apps-clients packages (or you can just use the appropriate rpm command to install these packages directly from the installation source). For any RPM-based distributions, you should make sure that the regular insecure Telnet package is uninstalled with a command such as: rpm -e telnet If you're running SUSE Linux, you can keep your YaST system, and install the aforementioned packages with the following command: yast2 -i krb5-apps-servers krb5-apps-clients If you have problems, see the related annoyances on apt, yum, the Red Hat Update Agent, and YaST described in Chapter 8. 9.3.3. Secure Telnet ClientNow that you've configured the secure Kerberos Telnet server of your choice, you need Telnet clients. I'll show you what you need to do to make a Telnet client work for workstations based on the three major distributions I cover in this book. This section assumes you've already configured your Telnet users and hosts under the Kerberos server, using the instructions described earlier in this annoyance. Otherwise, even the Kerberos version of the Telnet client defaults to sending all data in clear text, including passwords. 9.3.3.1. Debian Telnet clientOn Debian, if you want to run the Kerberos-secured version of the Telnet client, you need both to install this client and to uninstall the regular Telnet package, as described earlier. When the Kerberos Telnet client is installed, it includes a series of links from the standard telnet command well known to many regular users: telnet hostname This /usr/bin/telnet command is symbolically linked indirectly to the Kerberos-secured version of this client at /usr/bin/telnet.krb5. 9.3.3.2. SUSE Telnet clientWhen you install the SUSE RPM with the Kerberos Telnet client (krb5-apps-clients), you'll need to make it easier for users to start the client. The location is not in a standard user's PATH. Therefore, you'll want to take one of the following steps to make it more accessible:
9.3.3.3. Red Hat/Fedora Telnet clientWhen you install the Red Hat RPM with the Kerberos Telnet client (krb5-workstation), you've presumably already installed the Kerberos server, which adds the Telnet client directory (/usr/kerberos/bin) to users' paths. You should also make sure to uninstall the regular Telnet package, as described earlier. When the Kerberos Telnet client is installed, it includes a series of links from the standard telnet command well known to many regular users: telnet hostname 9.3.4. Limiting Access to Particular HostsAs with any service, you can specify which hosts can log in with Telnet and which hosts cannot through the TCP Wrappers package. Thus, if your Telnet daemon is /usr/sbin/telnetd, you can limit access to the 192.168.0.0 class C network by adding the following line to /etc/hosts.allow: /usr/sbin/telnetd: 192.168.0. Naturally, you should also prohibit access to others, so deny access to Telnet with the following command in /etc/hosts.deny: /usr/sbin/telnetd: ALL TCP Wrappers reads the hosts.allow file before the hosts.deny file, so your class C network is still allowed to connect. While /usr/sbin/telnetd regulates the Kerberos Telnet service on Debian Linux, the daemon locations, and therefore what you specify in /etc/hosts.allow and /etc/hosts.deny, vary by distribution. On SUSE Linux, the Kerberos Telnet service is in a slightly different directory: /usr/lib/mit/sbin/telnetd. On Red Hat/Fedora, it's /usr/kerberos/sbin/telnetd. |