Telnet Server Configuration

As one of the oldest and most popular remote text-mode login tools available, Telnet is an excellent choice for compatibility—just about every OS with a TCP/IP stack comes with a Telnet client, so using a Telnet server under Linux makes your system accessible from just about everywhere. Telnet’s unencrypted nature, though, is a major drawback. Thus, you should use Telnet only when you have no other choice (say, because of limited client OS software options) or on highly protected local networks.

Telnet servers are simple and easy to configure in Linux; the worst complication is knowing whether you’re using the inetd or xinetd super server. Although Telnet’s security features are severely lacking, you may be able to improve matters using a Kerberized Telnet or by implementing limited access controls in your super server.

Launching a Telnet Server

All major Linux distributions ship with a Telnet server, although many don’t install it by default. Likely package names include telnetd, telnet-server, netkit-telnetd, telnet-bsd, and utelnetd, among others. (Kerberized or other encrypting variants are also available.) The server program itself is usually called telnetd or in.telnetd, and is usually stored in /sbin or /usr/sbin. Although Telnet servers come from several different sources, basic configuration and use is fairly consistent.

Typically, Telnet servers are launched from super servers—usually inetd or xinetd. If you’re not sure which super server your system runs, type ps ax | grep inetd and examine the output for a process called inetd or xinetd. If neither is present, you may need to install, or at least launch, your distribution’s super server package.

The inetd super server is controlled through the /etc/inetd.conf file, which devotes one line to each server it manages. A typical Telnet server configuration looks something like this:

telnet stream tcp nowait root /usr/sbin/tcpd in.telnetd

This example calls the server via the TCP Wrappers (tcpd) program, which provides added security options. An equivalent configuration for a system that uses xinetd doesn’t use TCP Wrappers because xinetd incorporates features similar to those provided by TCP Wrappers. Linux distributions that use xinetd typically place configurations for individual servers in files located in /etc/xinetd.d; the Telnet server’s file (typically called telnet or telnetd) looks like this:

service telnet
{
   disable      = no
   socket_type  = stream
   protocol     = tcp
   wait         = no
   user         = root
   group        = root
   server       = /usr/sbin/in.telnetd
   server_args  =
}

Tip

Many systems disable Telnet by default in the super server configuration files. In the case of inetd, the line defining the Telnet server is commented out by placing a hash mark (#) at the start of the line. To use Telnet, you must remove that character. In xinetd, the disable = yes option disables the server; this line must be changed to read disable = no to activate the server.

Whether you launch the server via inetd or xinetd, you can add a few options that modify the server’s behavior. In the case of inetd, you place these options at the end of the Telnet server’s configuration line; for xinetd, you place them on the server_args line, which you may need to add to the configuration file. Some of the more common and useful Telnet server options include:

-h: Telnet normally sends a banner to clients, announcing some basic information about the system, which is likely to include your distribution and kernel version number. The -h option disables the display of this banner.
-U: This option causes the server to block connections from computers whose IP addresses can’t be resolved to hostnames. This can slightly improve your security if you’re certain that all legitimate clients should have hostnames that can be obtained from their IP addresses.
-L program-file: Ordinarily, Telnet calls the standard Linux login program to authenticate users. This option enables you to substitute another program, which might be handy if you have special authentication needs or want to use Telnet for some specialized non-login purpose. For example, you can have the server launch a specialized network diagnostic tool rather than give users conventional login access.

This list of options isn’t complete, and, in fact, the options may vary from one Telnet server to another, so you may want to consult your local documentation for details on other options. Many installations work well with no Telnet server options, but to improve security slightly, you might want to use -h and, if it won’t cause problems for legitimate users, -U.

Once you’ve finished configuring your super server, you must restart the super server or force it to reload its configuration. In most cases, passing the restart or reload option to your super server’s SysV startup script will do the trick:

# /etc/init.d/xinetd reload

Thereafter, the system should be accessible via Telnet. If you have problems logging in, consult the server’s log files; chances are the super server or the Telnet server will log error messages concerning login failures or an inability to launch the Telnet server.

Telnet Server Security Concerns

As you may be tired of hearing by now, Telnet’s main flaw is its lack of security features—in particular, its lack of encryption. This limitation has implications you should understand, but there are also ways to add encryption. Another security concern with any remote-access protocol is controlling the computers that can connect to the server. Because Telnet is typically run from a super server, you can use its features, or those of tools that the super server calls, to control remote access.

Encryption

The basic Telnet provides no encryption features. This means that all data transferred between the client and the server (in both directions) is unencrypted. This flaw is most important for passwords—although you don’t see your password echoed on the screen, it can be easily retrieved should your Telnet session be intercepted. This risk is very serious for ordinary user accounts and completely unacceptable for root logins.

Tip

Because of the risks of password interception, most Linux distributions configure themselves to forbid direct root logins via Telnet.

Even if login password interception isn’t an issue, Telnet’s unencrypted nature can be a problem during login sessions. If you read a sensitive email in a Telnet session, use su to acquire root privileges, or use SSH from your Telnet session to another computer, you’ll be sending sensitive data in the clear.

Various methods of adding encryption to Telnet have been developed. Typically, the Telnet protocol is extended with an encryption layer. The Kerberized version of Telnet, described in Chapter 9, is one somewhat common example. Another approach is to encrypt Telnet traffic with the Secure Sockets Layer (SSL) library. The result is packaged with some distributions as telnet-ssl or a similar variant. A third approach is to tunnel Telnet through an encrypting protocol, such as SSH. The disadvantage to all of these approaches is that it requires extra software on both the client and the server, and this software is not as common as is Telnet. In fact, with the SSH tunneling approach, chances are you wouldn’t need to use Telnet at all, because SSH is a perfectly good text-mode login tool in its own right.

Controlling access by IP address

Because of Telnet’s poor security, if you use it you should employ your super server’s or firewall’s access control tools to limit who may access the server. For instance, you might want to restrict access to the server to computers on your own local subnet, or perhaps even to just those computers that absolutely need to use Telnet.

In xinetd, which is fast becoming the most common Linux super server, you can limit remote access by adding options to a server’s control file in /etc/xinetd.d:

only_from: This option sets a list of hostnames, IP addresses, or address/netmask pairs that are permitted to access the server. All other computers are denied access.
no_access: This option takes addresses much like only_from, but it specifies systems that should not be given access. For Telnet, only_from is likely to be the more useful tool, but you might use no_access to create exceptions to a range of addresses granted access with only_from.
bind: This option tells the server to bind to one interface only. This feature is most useful on routers and other computers with multiple network interfaces; you can bind Telnet to a secure local interface but not to the Interface that’s accessible from the Internet. You might also use it to bind exclusively to the localhost (127.0.0.1) interface or to an interface that’s used by an emulator, to enable the emulated OS to contact Linux. This parameter takes the IP address of the interface to which you want to bind as an option.
access_times: This option controls access by time rather than by IP address; you specify a time range in the form hh:mm-hh:mm, where each hh is an hour in 24-hour format (between 00 and 23) and mm is the minute.

As an example, you might use the bind and only_from parameters to restrict access to computers on the 192.168.7.0/24 network, if the computer in question has the address 192.168.7.27:

bind      = 192.168.7.27
only_from = 192.168.7.0/24

Tip

Depending on the network settings, the bind and only_from settings may seem redundant; however, they actually perform slightly different tasks. The bind option binds to a physical network card, so if a computer’s traffic is being routed in an unusual way or if it’s spoofing an address, bind won’t be fooled. In this context, only_from might be redundant, or it might not, if traffic from other networks should be arriving on that port. In any event, layered security, in which multiple checks of the same basic restriction are performed, can help improve a system’s overall security.

Previous Chapter

SSH Server Configuration

Next Chapter

Windows Remote-Login Tools