As discussed in Chapter 10, "Protecting Data in Transit," I recommend replacing telnet with Secure Shell (ssh) whenever possible. However, you may have reasons for not using Secure Shell. This chapter provides several alternatives.
Unlike many other services, telnet (or a reasonable facsimile) is an absolute must (especially if you're using Linux on Internet or intranet servers). There are just too many tasks easily performed with telnet that would otherwise prove difficult.
So, the question isn't whether you'll be using telnet (or telnet-like) services. The question is whether you should provide such services to others. The answer is generally no. Unless you have a very good reason to, do not allow public telnet or shell access.
Note
If you want to learn how to deny public telnet access (but still allow private access), please see Chapter 18, "Linux and Firewalls."
Garden-variety telnet has had many security issues in the past. One worth noting (because it affected Linux) is the environment variable passing attack. This emerged in November 1995 and affected even many "secure" versions of telnet that used Kerberos-based authentication. The technique involved passing local environment variables to the remote target using the ENVIRON option in all telnet versions conforming to RFC 1408 or RFC 1572.
As described in CIAC Information Bulletin G-01:
Some telnet daemons support RFC 1408 or RFC 1572, both titled "Telnet Environment Option." This extension to telnet provides the ability to transfer environment variables from one system to another. If the remote or targeted system, the one to which the telnet is connecting, is running an RFC 1408/RFC 1572-compliant telnet daemon *and* the targeted system also supports shared object libraries, then it may be possible to transfer environment variables that influence the login program called by the telnet daemon. By influencing that targeted system, a user may be able to bypass the normal login and authentication scheme and may become root on that system.
The ENVIRON option supports several variables, including the following:
ACCTTheACCTvariable is used to transmit the account ID that the client wants to use on the remote host.DISPLAYTheDISPLAYvariable is used to transmit the X display location of the client.JOBTheJOBvariable is used to transmit the job ID that the client wants to use on the remote host.USERTheUSERvariable is used to transmit the user or account name that the client wants to log in to on the remote system.
Researchers discovered, however, that attackers could pass other environment variables to remote hosts, including the following:
This allowed attackers to load a custom libc, which, under certain circumstances, could buy them root access.
Note
If you have an older Linux distribution lying around and you'd like to see the ENVIRON attack in action, get the exploit source code at http://www.insecure.org/sploits/telnetd.LD_PRELOAD.enviropassing.html.
You might wonder why environment variable-passing is supported at all. One reason is that it enables you to test custom libraries on existing binaries without removing the existing libraries. You simply specify another path. Another reason is that your server (or a remote server) may house libraries in non-traditional locations. In these instances, you can use environment variables to specify additional search paths.
Over the years, security folks have recognized this to be a problem. Hence, developers explicitly instruct setuid and setgid programs to ignore sensitive environment variables, such as LD_LIBRARY_PATH.
Note
For interesting environment variable attacks, visit David Barr's presentation "Why LD_LIBRARY_PATH is bad," located at http://www.visi.com/~barr/ldpath.html.
Other memorable attacks included the following:
On some early Linux distributions, attackers could force a core dump using telnet. The dump revealed shadowed passwords. An explanation is found at http://www.hoobie.net/security/exploits/hacking/telnet_core.txt.
On Red Hat Linux 4.0, attackers could determine valid usernames by brute-forcing login. The telnet package on Red Hat 4.0 distributions would cut the connection if an invalid username was given. However, if the username was valid (but the password was incorrect), the server reissued a login prompt for retry.
Such attacks are rare, though, and most telnet implementations have been hardened against them. But that doesn't mean that you should use standard telnet services without hardening them, because telnet has several serious shortcomings:
Passwords are not encrypted, and third parties can capture them with sniffers.
Telnet does not employ strong user authentication.
Telnet does not perform session integrity checking.
Telnet sessions are not encrypted.
For these reasons, if you can't or won't use Secure Shell, you'll need some other secure telnet system.
Above and beyond Secure Shell, several "secure" telnet (or telnet-like) implementations exist, including the following:
desloginSRA Telnet from Texas A&M University
SRP from Stanford University
SSLTelnet
STELfrom the University of Milan
David A. Barrett's deslogin provides a network login service with secure authentication (as opposed to telnet or rlogin). Transiting data is encrypted using DES and is therefore shielded against electronic eavesdropping. (If you're merely looking for quick-and-dirty session encryption, deslogin is a suitable choice.)
To install deslogin, you'll need two files:
The
deslogincore, available at ftp://ftp.uu.net/pub/security/des/deslogin-1.3.tar.gzThe encryption cipher, located at ftp.uu.net:/pub/security/des/cipher-3.0.tar.Z
After downloading the deslogin and cipher packages, unzip and tar them:
[root@linux6 /]# gunzip cipher-3_0_tar.Z [root@linux6 /]# tar -xvf cipher-3_0_tar.Z [root@linux6 /]# gunzip deslogin-1_3_tar.gz [root@linux6 /]# tar -xvf deslogin-1_3_tar
The cipher package will unpack to cipher-3.0/, and deslogin will unpack to deslogin-1.3/.
Next, change to cipher-3.0/ and build the cipher package:
make
After you verify that the make was successful (no errors other than warnings about 16 bit keys), install the package:
[root@linux6 /cipher-3.0]# make install cp cipher /usr/local/bin ln /usr/local/bin/cipher /usr/local/bin/decipher cp cipher.1 /usr/local/man/man1 cp btoa atob /usr/local/bin cp btoa.1 /usr/local/man/man1 ln /usr/local/man/man1/btoa.1 /usr/local/man/man1/atob.1
Change to deslogin-1.3/ and open Makefile for editing. Here, you'll need to configure Makefile for your own system. For example, change line 50 to reflect your shell. By default, line 50 is
SHELL=/bin/sh
Next, you may want to change lines 92, 93, and 94 to specify alternate log files and directories. The default settings are
USER_FILE= "/usr/local/etc/deslogind.users" LOG_FILE= "/usr/adm/deslogind.log" GW_LOG_FILE= "/usr/adm/deslogingw.log"
Next, go to line 268. There, you'll need to uncomment lines 271–274 so deslogin will build using Linux gcc. The lines to uncomment look like the following:
#CC = gcc -ansi #CFLAGS = $(DEBUG) -Dlinux -D_LINUX_SOURCE #LDFLAGS = $(DEBUG) #NSTCFLAGS= $(DEBUG) -Dlinux
Now, you're ready to make the deslogin package. To do so, run a make:
make
The make will initially die with the following error:
make:***No rule to make target `desblock.o', needed by `deslogin'. Stop.
Pay no attention to it, and run a make again:
make
deslogin will now build and prompt you for an encryption passphrase:
You must select a default encryption key for the userFile. This allows you to place "deslogind -c" in /etc/inetd.config. Pick a secure passphrase, longer than 8 characters, that you can remember. You will need it every time you must edit the userFile (to add users, or to change pass phrases). The most secure way to run deslogind is with no arguments and type the userFile passphrase in response to its query. You need never use the -c option, and when you do, it never exposes the contents of the userFile. If you use a different key to encrypt the userfile, the -c option will not work, but otherwise the deslogind will work fine. The compiled-in key is not stored as a text string, nor is it a simple 8-byte DES key. ***Do not run deslogind where its virtual-memory data segment ***can be examined by sufficiently determined hostile users. ***Do not use the -c option if the executable file can be ***can be examined by sufficiently determined hostile users. Input Default UserFile PassPhrase:
After you enter your passphrase, the make will finish. At that point, you can install the package:
make install
Note that, on some systems, you may get an error here and be forced to install manually. If so, follow these directions:
You must install by hand. Running automatic installation scripts (especially as root) is extremely dangerous. It's more secure if $(BINS) are stripped, linked statically, and not readable or writeable by users other than owner. They should *NOT* be setuid but they can and should be executable by anyone. The following two commands should work: strip $(BINS) chmod 111 $(BINS)′ --- For system-wide installations --- Deslogind should be owned by root. Add to /etc/services: deslogin 3005/tcp deslogingw 3006/tcp Add to /etc/inetd.conf: deslogin stream tcp nowait root $(BINDIR)/deslogind deslogind -c deslogingw stream tcp nowait root $(BINDIR)/deslogingw deslogingw -c Make sure $(USER_FILE) exists. If you use deslogind with -c, make sure the file is encrypted with cipher using the same passphrase you specified when building deslogind. See the deslogind man page for details. Install the executables with the following commands: cp $(BINS) $$(BINDIR) cp $(MANSRC) $(MANDIR)
Before using deslogin, you'll need to establish several configuration options. First, copy the sample netlogind.users file to /usr/local/etc/ (if it isn't already there).
The sample file looks like the following:
# # Netlogind user database # # Whitespace separated list of username/passphrase pairs. # Note that whitespace may appear in the passphrase so it's last. # The empty passphrase is allowed # Ascii values greater than 127 are illegal. # # For added security, this file may be encrypted with the cipher # program # and the same key given to netlogind when it's invoked # interactively. # In any case, make sure that it's not readable by other than root # and the # netlogind program's owner (group). # martha martha's passphrase john simple, but secure
The file format is simple: Each line must be an 8-character (or less) username, a tab, and a passphrase consisting of any number of 7-bit characters. (Lines beginning with # are commented out).
deslogind (the deslogin server) takes several command line options, which are summarized in Table 13.1.
Table 13.1. deslogind Command Line Options
deslogind does not allow users to pass environment variables to the server end. (Unlike telnet, deslogin prohibits environment attacks). However, deslogind does set the following environment variables at log in:
HOMELOGNAMEMAILPATHRHOSTNAME(name of remote host)SHELLTERMTZUSER
Authentication takes place during log in:
Deslogind uses a "challenge-response" protocol to authenticate users. Upon connection, the remote host sends a line containing the remote user name, then another giving the login name for the local user. Deslogind looks up local user name in the userFile and retrieves the corresponding passphrase, which is hashed to produce the user's DES authentication key. An "unpredictable" 64-bit nonce is generated by using the user's authentication key with DES in ECB mode to encrypt the (LSB zero-padded) output of time(2) and getpid(2). Deslogind then encrypts this nonce with the user DES key and sends it as the challenge to the remote machine. The remote deslogin prompts the user for a passphrase, which is hashed into a DES key used to decipher the challenge and send back the 64-bit "response". Deslogind compares the response with the nonce; if they're equal, authentication succeeds and a unique session key is generated by encrypting the challenge with the user's DES key. The authentication keys are destroyed by both hosts, and the session key is then used to encrypt all other data transferred.
User sessions are logged to wtmp and can be tracked much like telnet sessions.
The deslogin client is easy to use. Issue the deslogin command plus your username, the remote hostname, and the port, as shown in the following:
$ deslogin [email protected]:2010
In response, the system will prompt you for a passphrase:
Pass Phrase:
And finally, if you enter the correct passphrase, deslogind will log you in:
linux6 $
There are three command line options:
STEL hails from David Vincenzetti, Stefano Taino, and Fabio Bolognesi, from CERT-IT, the Computer Emergency Response Team, Italy, Department of Computer Science, University of Milan.
In their announcement paper, Vincenzetti, Taino, and Bolognesi set forth STEL's purpose:
Eavesdropping is becoming rampant on the Internet. We, as CERT-IT, have recorded a great number of sniffing attacks in the Italian community. In fact, sniffing is the most popular hacker's attack technique all over the Internet. This paper presents a secure telnet implementation, which has been designed by the Italian CERT, to make eavesdropping ineffective to remote terminal sessions. It is not to be considered as a definitive solution but rather as a "Band-Aid" solution, to deal with one of the most serious security threats of the moment.
It's simple to install and use.
It encrypts sessions with a random key using
DES,TripleDES, orIDEA(your call).It uses Diffie-Hellman for session key exchange, and it hardens against man-in-the- middle attacks known to work against such systems. Note that Diffie-Hellman is free from patent restrictions, which is a definite plus.
It supports various authentication schemes, including garden-variety UNIX passwords,
SecureID, andS/Key.The package is exceptionally well documented.
It comes with open source and a
S/Keyserver.
Get STEL at ftp://idea.sec.dsi.unimi.it/pub/security/cert-it/.
SSL MZ-Telnet incorporates SSL into telnet using SSLeay and is a suitable telnet replacement with encryption support. SSL Telnet replaces normal telnet using SSL authentication and encryption. It works with normal telnet, as well, just in case incoming clients aren't SSL-enabled.
Get SSL MZ-Telnet at ftp://ftp.replay.com/pub/replay/pub/redhat/i386/SSL-MZtelnet-0.11.2-1.i386.rpm.
Note
Though the previously referenced rpm contains a binary distribution, you must still install SSLeay to use it. This is a bit of a job in itself. To learn how, please refer to Chapter 15, "Secure Protocols."
SRA Telnet's authentication is based on Request for Comments 1416, "The Telnet Authentication Option." The SRA system
…provides drop in replacements for telnet and ftp client and server programs, which use Secure RPC code to provide encrypted authentication across the network, so that plain text passwords are not used. The clients and servers negotiate the availability of SRA so that they work with unmodified versions. These programs require no external keyserver or ticket server, and work equally well for local or Internet wide connections.
Get SRA at http://www.net.tamu.edu/ftp/security/TAMU/srasrc-1.3.1.tar.gz.
Note
Before installing SRA, check out the release document "Secure RPC Authentication (SRA) for TELNET and FTP," David R. Safford, David K. Hess, and Douglas Lee Schales, Supercomputer Center, Texas A&M University, located at ftp://ftp.funet.fi/pub/unix/security/login/telnet/doc/sra/sra.ps.gz.
The SRP system is an attempt to answer many problems with secure telnet distributions. As explained in the documentation, SRP is
…a new password authentication and key-exchange protocol suitable for authenticating users and exchanging keys over an untrusted network. The new protocol resists dictionary attacks mounted by either passive or active network intruders, allowing, in principle, even weak passphrases to be used safely. It also offers perfect forward secrecy, which protects past sessions and passwords against future compromises. Finally, user passwords are stored in a form that is not plaintext-equivalent to the password itself, so an attacker who captures the password database cannot use it directly to compromise security and gain immediate access to the host.
To install SRP, you'll need two files:
The Exponential Password Suite (EPS).—. The EPS is a suite of utilities that manage a password file in the format used by the SRP tools. Get it at ftp://srp.stanford.edu/pub/srp/binaries/1.4/eps-i386-linux.tar.gz.
SRP Utilities (the core binaries).—. Get them at ftp://srp.stanford.edu/pub/srp/binaries/1.4/srp-i386-linux.tar.gz.
Caution
Be sure to carefully read the SRP documentation before installing the distribution, because it replaces some standard services.
The following documents will give you an overview of the various methods devised to shore up telnet's authentication (and add session verification and encryption).
"The S/KEY One-Time Password System," Neil M. Haller, Bellcore, Morristown, New Jersey (ftp://ftp.bellcore.com/pub/nmh/docs/ISOC.symp.ps).
"Description of The S/KEY One-Time Password System," Neil M. Haller and Philip R. Karn (ftp://ftp.bellcore.com/pub/nmh/docs/skey.txt).
"The Telnet Authentication Option," D. Borman, Editor, Cray Research, Request for Comments 1409).
"DASS: Distributed Authentication Security Service," Charles Kaufman, Digital Equipment Corporation).
"Kerberos FAQ," Barry Jaspan, OpenVision Technologies (ftp://athena-dist.mit.edu/pub/kerberos/doc/KERBEROS.FAQ).
"SDSC's Installation and Development of Kerberos," Wayne Schroeder, San Diego Supercomputer Center San Diego, California, U.S.A. (http://www.sdsc.edu/~schroede/kerberos_cug.html).