Configuring Telnet

Telnet may be the most common login protocol on the Internet. Most OSs, including Linux, ship with Telnet client programs (usually called telnet ). There are Telnet clients available for those few OSs that don't ship with them. Telnet servers are also quite common, although they're most common on OSs that support multiple simultaneous users, such as Linux, UNIX, and VMS. In many ways, Telnet is a more complex protocol than is that used by rlogind , but it's still fairly simple as TCP/IP protocols go. Configuring Telnet on Linux usually involves installing a package and ensuring that the protocol is enabled in your super server, although in some cases you'll want to investigate startup options. You can also configure a few other elements of Telnet's operation, such as the login message it returns to clients.

Telnet's security is weak by modern standards, but it's not quite as bad as is rlogind 's. Understanding precisely how Telnet's security is weak can help you know where it is and is not appropriate to use this protocol, and how to minimize risks if you must use it in situations where it's less than ideal to do so. As with rlogind , you can improve Telnet's security by using a Kerberized version of the client and server, if your network supports Kerberos.

Setting Telnet Startup Options

The Telnet server may or may not be installed in your Linux distribution by default. There's little standardization in terms of the package names under which this server is distributed. For instance, it's included in Caldera's netkit-telnet , Debian's telnetd , Mandrake's telnet-server , Red Hat's telnet-server , Slackware's tcpip1 , SuSE's nkitserv , and TurboLinux's telnet . Some of these, like Debian's telnetd , contain the Telnet server only; others, like TurboLinux's telnet , include the client and server together in one package. Most distributions install the relevant packages by default with most installation options, but the server may or may not be configured to run by default. Consult Chapter 4 for information on how to launch the Telnet server (which is usually called telnetd or in.telnetd ) via your distribution's super server.

The Telnet server accepts a number of arguments that can modify the way it operates. Some of these, however, relate to optional security features that aren't available on most standard Telnet servers. The more useful options include the following:

• -D debugmode ” This option is intended for debugging Telnet or its connections. To use it, you launch telnetd from the console, rather than via a super server. Depending on what you enter as debugmode , the server displays information on the connection or the data it receives. Possible debugmode values include options and report (both of which show information about the negotiation of connections), and netdata and ptydata (which display the incoming and outgoing data streams, respectively).

• -h ” Normally, telnetd sends a login banner to clients, identifying the computer for the user 's benefit. This banner sometimes contains information you'd prefer that random outsiders not have, such as the version of the OS you're running. Using -h suppresses the display of this banner, thus giving a would-be intruder less information on your system.

• -L loginprog ” By default, telnetd uses /bin/login to handle login interactions. You can specify some other program if you like, though.

• -n ” Like rlogind , telnetd uses keepalive messages to check that a client is still active, and to close a link if a client becomes inaccessible. This option disables the use of keepalive messages.

The server supports several additional options, mostly related to data encryption and security, but most of these options aren't useful except on comparatively rare Telnet servers that include these features. Although encrypted versions of Telnet exist, and in theory can be a good solution for secure text-mode logins, these Telnet variants haven't become very popular; that role has been filled largely by SSH. If your network uses Kerberos, though, the Kerberized version of Telnet that ships with Kerberos is well worth investigating, as described in Chapter 6.

Adjusting the Telnet Login Display

The telnetd server reads the contents of the /etc/issue.net file and displays it to clients when they first connect. This file is displayed before the user has a chance to log into the system, and it's what is suppressed by inclusion of the -h startup option to telnetd . The intent is that this message announce something about the computer to let users know that they've connected to the correct system. The default message, though, usually announces the Linux distribution name , and often additional information such as the kernel version. Most users don't need or want this information, but it can be very helpful to those who would break into your computer because it may give them clues about what other software may be running on your system, some of which may have security-related bugs .

NOTE

A similar file, /etc/issue , displays a login message for console logins ”those done at the keyboard and display connected directly to the computer. (X-based logins don't use either file, though; they're handled through a display manager program such as those discussed in Chapter 14.)

On many systems, you can edit /etc/issue.net directly. Change the text to whatever you'd like. You can include several variables in your text, which telnetd replaces with system-specific information. These are summarized in Table 13.1. For instance, you might change /etc/issue.net to read as follows :

 Welcome to %h. Current time is %d. Notice: For authorized users only! 

If your computer were called maple .threeroomco.com , this might result the following login banner:

 $  telnet maple.threeroomco.com  Trying 172.21.32.43... Connected to maple.threeroomco.com. Escape character is '^]'. Welcome to maple.threeroomco.com. Current time is 10:57 on Monday, 12 August 2002. Notice: For authorized users only! 

Table 13.1. Variables Usable in /etc/issue.net

Variable	Meaning
%t	The current tty (a number corresponding to a text input/output device)
%h	The computer's FQDN
%D	The name of the NIS domain, if the computer uses NIS
%d	The current date and time
%s	The name of the operating system ( Linux )
%m	The hardware (CPU) type
%r	The kernel version number
%v	The OS version ( generally not a useful value)
%%	Displays a single percent symbol ( % )

Unfortunately, there's a potentially major wrinkle in this picture. Some distributions (notably Caldera, Mandrake, and some versions of Red Hat) recreate /etc/issue and /etc/issue.net on every boot. They do this via the /etc/rc.d/rc.local script, which includes lines resembling the following (in Mandrake 8.1):

 # This will overwrite /etc/issue at every boot.  So, make any \ changes you # want to make to /etc/issue here or you will lose them when you \ reboot. if [ -x /usr/bin/linux_logo ];then     /usr/bin/linux_logo -c -n -f > /etc/issue     echo "" >> /etc/issue else     > /etc/issue fi echo "$R" >> /etc/issue echo "Kernel $(uname -r) on $a $SMP$(uname -m) / \l" >> /etc/issue if [ "$SECURITY" -le 3 ];then     echo "Welcome to %h" > /etc/issue.net     echo "$R" >> /etc/issue.net     echo "Kernel $(uname -r) on $a $SMP$(uname -m)" >> /etc/issue.net else     echo "Welcome to Mandrake Linux" > /etc/issue.net     echo "-------------------------" >> /etc/issue.net fi 

NOTE

Red Hat has shifted to static issue and issue.net files with version 7.2, but Caldera 3.1 and Mandrake 8.1 continue to create these files from the /etc/rc.d/rc.local files.

Some of these lines reference variables that are defined earlier in the script. This procedure allows the system to create a login banner that's slightly more dynamic than might otherwise be possible, such as specifying the number of CPUs in the computer. On the other hand, it means that if you want to change your login banner, you must modify the /etc/rc.d/ rc.local script. You can either comment out or delete the lines that modify /etc/issue and /etc/issue.net and adjust those files directly, as just described, or you can modify the lines in /etc/rc.d/rc.local to better reflect your intended message.

Understanding Telnet Security

After telnetd sends the contents of /etc/issue.net (with any applicable variable substitutions) back to the client, it passes control of the connection to /bin/login , or whatever program was specified by the -L loginprog parameter to telnetd . The /bin/login program is used for local text- mode logins, as well as remote logins. It presents two prompts, login: and Password: , at which users should enter their usernames and passwords, respectively. Assuming these are entered correctly, /bin/login notes when the last login occurred and passes control to the user's default shell.

One very important consequence of this sequence, in conjunction with the fact that most Telnet servers are not configured to encrypt data transfers, is that both the username and the password are sent unencrypted over the network. This is true even though the user won't see the password echo to the screen. Unless you use -L loginprog to change the login program that telnetd uses, this unencrypted username/password pair is the only authentication method used by telnetd ; it does not use a trusted hosts model like rlogind , and it doesn't even rely upon the client to automatically transmit the username (although this information does ultimately come from the client computer, and some Telnet client programs can be configured to send the username and even the password automatically).

The unencrypted nature of Telnet logins is a potential threat because the data stream might be intercepted between the client and the server. In most Internet transfers, packets pass between a dozen or more routers. If any of these routers has been compromised, the cracker who's done so might note the password that's passed over the Telnet session and use it to gain access to your computer. A threat that's at least as great is the potential for packet sniffing on the network that's local to either the client or the server. In this approach, a computer (which may not be directly involved in the data transfer) "sniffs" the network wires for data such as passwords. Again, the result is a compromised password.

In addition to risking login passwords, Telnet's unencrypted nature means that all the data passing over the connection after it's established may be compromised. This includes private e-mail that's read, confidential files that are edited, and any additional passwords that might be typed (for instance, if the user connects to another computer or uses su to acquire superuser privileges). The same comments apply to rlogind and other unencrypted protocols (which includes most protocols in common use today). The unencrypted nature of Telnet and rlogind is potentially more serious than, say, unencrypted e-mail transmission because Telnet and rlogind are general-purpose protocols ”in one connection, you can give away your login password, the contents of private e-mail, the contents of sensitive files, and more.

Short of switching to an encrypted protocol, what can you do to minimize your risks with Telnet? The basic rule of thumb is to transfer as little sensitive data as possible. Don't read confidential or otherwise sensitive files or e-mail using Telnet. Don't log directly into another computer, even if you use Telnet to reach the first computer but then use SSH or some other secure channel. Don't use su to acquire root privileges. Don't use the password for any computer you access via Telnet on any other computer. Telnet is best used on small private networks that you're confident haven't been compromised, like a private LAN with no Internet connectivity. If you must use Telnet, change your password frequently (preferably not over a Telnet link) to give any would-be attackers a limited window of opportunity for doing more damage should they abscond with your password.