Remote Access (Building Internet Firewalls, 2nd Edition)

2.5. Remote Access

There are many situations in which you would like to run a program on a computer other than the one that you're in front of. For instance, you may be in front of a slow computer because you're travelling with a laptop, or your other computer is a supercomputer, or you're using "thin clients" -- purposefully stupid computers -- in order to lower maintenance costs and get economies of scale. Originally, remote access meant some form of remote terminal access, which allows you to use character-based applications. These days, character-only access is rarely sufficient. Instead, you may need some form of remote graphics.

The general questions about remote access are the same for all methods:

Are there appropriate controls on who can access the machine remotely? How are remote users authenticated?
Can anybody take over a connection that's in progress?
Can eavesdroppers pick up important information (particularly, authentication information)?

2.5.1. Remote Terminal Access and Command Execution

Originally, programs that provided remote terminal access allowed you to use a remote system as if your computer were a directly attached terminal -- an old-fashioned terminal, capable of displaying and generating text. These days, there are computers that support remote terminal access without supporting genuine physical terminals, and there are many computers that can't do much with a text-only interface no matter how it's attached to them.

Telnet is the standard for remote terminal access on the Internet. Telnet allows you to provide remote text 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.

There are various kinds of authentication schemes for doing remote logins, which will automatically work with Telnet (in particular, see the discussion of one-time passwords in Chapter 21, "Authentication and Auditing Services"). Unfortunately, even if you protect your password, you may still find that your session can be tapped or hijacked; preventing it requires using an encrypted protocol.

There are two popular ways of doing this. First, you can simply replace Telnet with an encrypted remote terminal access program; the widely accepted Internet standard is the secure shell (SSH), which provides a variety of encrypted remote access services, but a number of other solutions are available. Second, you can create an encrypted network connection (a virtual private network, or VPN) and run normal Telnet across that. See Chapter 5, "Firewall Technologies", for a discussion of VPN techniques.

Other programs besides Telnet and SSH 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 reauthenticate 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 a 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 18, "Remote Access to Hosts". Fortunately, on is relatively rare these days; Windows NT, which provides rlogin and rsh clients, does not provide an on client.