|
10.3. Telnet Server ConfigurationAs one of the oldest and most popular remote text-mode login tools available, Telnet is an excellent choice for compatibilityjust 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. 10.3.1. Launching a Telnet ServerAll 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 serversusually 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 = }
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:
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. 10.3.2. Telnet Server Security ConcernsAs you may be tired of hearing by now, Telnet's main flaw is its lack of security featuresin 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. 10.3.2.1 EncryptionThe 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 passwordsalthough 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.
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. 10.3.2.2 Controlling access by IP addressBecause 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:
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
|
|