8.3 Terminal Access (Telnet)

Telnet allows a user to remotely access a command shell on another computer. Telnet is supported by most platforms on the Internet, even some MS-DOS and Microsoft Windows systems (which provide access to a DOS shell via a Telnet server). The major exception is the Macintosh operating system, which doesn't have a command-line-oriented shell to give users access to, regardless of whether they're local or not; if MacOS did have a shell, however, somebody would probably create a Telnet server to give remote access to it. (And, having written this, we're sure someone will tell us that there is a Telnet server for Mac OS which we simply didn't know about.)

Although remote terminal access is the most common use of Telnet, most Telnet clients support the specification of arbitrary port numbers to access text-based TCP services at other ports. This is useful if you have a service for which you don't want to distribute a dedicated client, for example, it's often used to give access to MUD s (Multi-User Domains) and MOO s (Multi-user domains, Object Oriented), which are multiuser environments for games, collaborative work environments, or chat areas. Telnet clients are also used fairly often for debugging protocols that are normally accessed by dedicated clients. For example, people will check SMTP servers or verify user names by using telnet hostname 25 to connect to the SMTP server directly on port 25 and type SMTP commands at it. It's important to understand that, although you may be using the program named telnet for these purposes, all it's doing is opening a simple TCP connection to the specified port number. The telnet program doesn't use the Telnet protocol (which provides for things like option negotiation between client and server, line-at-a-time and character-at-a-time modes, and so on) unless it is talking to a server on the standard Telnet port (port 23). This section discusses only the use of Telnet clients to access Telnet servers.

Incoming and outgoing Telnet have very different security implications. Most sites want to allow their users access to outgoing Telnet service, so their users can get to command shells and information services provided via Telnet on remote systems on the Internet. ( Figure 8.8 illustrates outbound Telnet.) On the other hand, most sites don't want to allow (or want to allow but very strictly control) incoming Telnet access to their site. Chapter 10 describes reasons for, and ways of, controlling incoming access, so we won't discuss these in any detail here.

Figure 8.8: Outbound Telnet

Regardless of whether the access is incoming or outgoing, Telnet is a cleartext protocol (just like most others). Whatever information your users access or provide over a Telnet session (for example, accessing sensitive data, or providing their passwords for other systems) is going to be visible to someone snooping on the Telnet connection. Encrypting versions of Telnet are starting to become available, but none are widely used yet. As these tools become more capable and more widely supported, they should become more useful. The best place to see what's currently available would be one of the general Internet security Web pages (such as the COAST Web page) discussed in Appendix A .

Users should be warned to use different passwords on external hosts from those they use on your hosts. When they make outgoing Telnet connections, their passwords may be sniffed.