Telnet is the standard for remote terminal access on the Internet. It truly imitates a terminal, not a graphics workstation; it provides access to character-based applications only. Telnet allows you to provide remote access for your users from any Internet-connected site without making special arrangements.
Telnet was once considered a fairly secure service because it requires users to authenticate themselves. Unfortunately, Telnet sends all of its information unencrypted, which makes it extremely vulnerable to sniffing and hijacking attacks. For this reason, Telnet is now considered one of the most dangerous services when used to access your site from remote systems. (Accessing remote systems from your site is their security problem, not yours.) Telnet is safe only if the remote machine and all networks between it and the local machine are safe. This means that Telnet is not safe across the Internet, where you can't reliably identify the intervening networks, much less trust them. On the other hand, Telnet can be extremely useful - and extremely cost-effective - as a remote access mechanism if your users frequently travel to Internet-connected sites. In places where using a modem is expensive, difficult, and slow, using an existing Internet connection via Telnet may be the best available solution. For this practical reason, you may need to provide Telnet service, but with caution.
There are various kinds of authentication schemes for doing remote logins (in particular, see the discussion of one-time passwords in Chapter 10, Authentication and Inbound Services), but although authentication protects your password, you may still find that your session can be tapped or hijacked. Chapter 8 describes in detail the dangers of Telnet and the ways you can increase the safety of this service, particularly with a packet filtering firewall.
There are programs besides Telnet that can be used for remote terminal access and remote execution of programs - most notably rlogin, rsh, and on. These programs are used in a trusted environment to allow users remote access without having to re-authenticate themselves. The host they're connecting to trusts the host they're coming from to have correctly authenticated the user. The trusted host model is simply inappropriate for use across the Internet, because you generally cannot trust hosts outside your network. In fact, you can't even be sure the packets are coming from the host they say they are.
rlogin and rsh may be appropriate for use within a network protected by a firewall, depending on your internal security policies. on, however, places all of its security checks in the client program, and anyone can use a modified client that bypasses these checks, so on is completely insecure for use even within a local area network protected by firewall (it lets any user run any command as any other user). You disable on by disabling the rexd server, as we'll describe in Chapter 5, Bastion Hosts.