Section 9.3. Users Are Still Demanding Telnet

9.3. Users Are Still Demanding Telnet

Telnet 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.

Treat the solution in this section as a transitional measure. Prepare your users to migrate to SSH, which I cover in "My Other Computer Has No Monitor" in Chapter 11.

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 Telnet

If 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.

Table 9-1. Kerberos client/server packages
Package name	Distribution	Functionality
krb5-admin-server	Debian	Kerberos Master Server
krb5-kdc	Debian	Kerberos MIT Key Server
krb5	SUSE	Kerberos configuration files and libraries
krb5-client	SUSE	Kerberos management commands
krb5-server	SUSE/Red Hat/Fedora	Kerberos Master Server

If you're using a Microsoft Windows 2000/2003 server, it may already have a Kerberos server.

To prepare a Kerberos server, take the following steps:

Download and install the appropriate packages from those noted in Table 9-1, including dependencies. If you're using Debian and are installing the krb5-admin-server package, ignore the configuration options also available with the dpkg-reconfigure krb5-admin-server command.
Edit the default Kerberos server configuration files: /etc/krb5.conf, kdc.conf, and kadm5.acl. The locations of the last two files vary by distribution; they may be in the /etc/krb5kdc, /etc/krb5, or /var/kerberos/krb5kdc directories.
Replace each instance of EXAMPLE.COM with the name of your realm and domain. They may be the same. In fact, for the purpose of this annoyance, I use EXAMPLE.COM as the name of my domain and my Kerberos realm.

The IETF has decreed that example.com can't be assigned, and should be used for documentation; while I use example.com in this book, you should not do so on your networks.
Start the Kerberos Key Distribution Center (KDC) database with the following command:
```
 /usr/sbin/kdb5_util create 
```
You're prompted for a Kerberos database master password. Don't store it online, but put it on paper or a removable disk and store it somewhere safe. If you forget this password, you may have to reinstall and reconfigure your Kerberos server.
Start the KDC, and confirm the master password you've just created:
```
 /usr/sbin/krb5kdc -m 
```
Now you can use the /usr/sbin/kadmin.local administrative database to start adding users and hosts. The kadmin.local command opens a subshell with the name of the command as a prompt. At the prompt, a ? displays a list of available Kerberos administrative commands.
Kerberos works with policies. You'll want to add policies for hosts, users, and an administrator with the following commands:
```
 kadmin.local: addpol hosts kadmin.local: addpol users kadmin.local: addpol admin 
```

Now create the users you need, including those who will log in to the local Kerberos Telnet server. Repeat as needed.

 kadmin.local: add_principal -policy users michael Enter password for principal "michael@EXAMPLE.COM": Re-enter password for principal "michael@EXAMPLE.COM": principal "michael@EXAMPLE.COM" created.

Create an administrator; as you can see from the command list, you can substitute ank or addprinc for add_principal:
```
 kadmin.local: ank -policy admin michael/admin 
```
Enter the same Kerberos database master password for this user when prompted.
Create host computer accounts. The -randkey option creates a random encrypted key for communication. In the following example, debian.example.com is one of the hosts on my network.
```
 kadmin.local: ank -randkey -policy hosts host/debian.example.com 
```
Repeat this command for the other hosts that will be using Kerberos Telnet to connect to this system.
Create a KDC keytab file, with the generic administrator account (kadmin) for your Kerberos server. The keytab file is as defined in the kdc.conf filenormally kadm5.keytab, in the same directory as the kdc.conf file:
```
 kadmin.local: ktadd -k /etc/krb5kdc/kadm5.keytab kadmin/admin \kadmin/changepw 
```
Exit from the kadmin.local interface with the quit command.
Start the Kerberos Administration service:
```
 /usr/sbin/kadmind -m 
```
Test and then list your Kerberos user credentials. I've tested mine as user michael:
```
 kinit michael klist 
```
Now make sure the Kerberos Administrative system works in regular (nonlocal) mode with the /usr/sbin/kadmin command. If you see the kadmin: prompt, it worked.
Start the Kerberos key server. If it works, you'll see messages indicating the server is listening on certain IP addresses, commencing operation in the /var/log/krb5kdc.log file, and so on.
```
 /usr/sbin/krb5kdc 
```
Make sure the Kerberos administrative (kadmind) and key servers (krb5kdc) are active the next time you start Linux. Depending on your distribution, that may require specific chkconfig or update-rc.d commands.

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.

If you don't configure a Kerberos server, you can still use the Kerberos Telnet packages. However, without a Kerberos server, passwords will still be transmitted in clear text.

9.3.2. Secure Telnet

Kerberos 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.

Kerberos is itself a rich and complex topic. This annoyance covers only those skills required to start Kerberos sufficiently to configure a secure Telnet system. For more information on Kerberos on Linux, read the associated HOWTO at http://www.tldp.org/HOWTO/Kerberos-Infrastructure-HOWTO.

Table 9-2. Kerberos Telnet packages
Package name	Distribution	Functionality
krb5-telnetd	Debian	Kerberos-enabled Telnet server
krb5-clients	Debian	Kerberos-enabled clients for Telnet, FTP, and the remote shell
krb5-workstation	Fedora/Red Hat	Kerberos-enabled clients and servers for Telnet, FTP, and the remote shell
krb5-apps-servers	SUSE	Kerberos-enabled servers for Telnet, FTP, and the remote shell
krb5-apps-clients	SUSE	Kerberos-enabled clients for Telnet, FTP, and the remote shell

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 Client

Now 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 client

On 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 client

When 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:

Add /usr/lib/mit/bin to each user's PATH. The easiest way to do so for all SUSE users is by editing /etc/profile. SUSE suggests that changes by local administrators should be incorporated into /etc/profile.local.
Open /etc/profile.local in a text editor, and add the following line to add the noted directory to each user's PATH:
```
 PATH=$PATH:/usr/lib/mit/bin 
```
Create a link from a standard directory already in every user's path. For example, the following command creates a link from /usr/bin/telnet to the Kerberos Telnet client:
```
 ln -s /usr/lib/mit/bin/telnet /usr/bin/telnet 
```
Create a menu item in the GUI. For more information on how to do so on the GNOME or KDE desktop, see Chapter 1.

9.3.3.3. Red Hat/Fedora Telnet client

When 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 Hosts

As 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.