Secure Shell

The first VPN method we examine in this chapter is Secure Shell (SSH). It has become a popular replacement for Telnet, rlogin, and other inherently insecure remote utilities. SSH can be used to provide strong encryption for remote shell access, file transfers, and other application usage. Another nice feature of SSH is that it offers multiple authentication methods, including username/password and public key based. In this section, we look at the two main types of SSH usage: standard SSH connections and SSH tunneling.

Standard SSH Connections

The most popular use of SSH is to provide a strongly encrypted connection to a remote server in order to gain shell or command-line access on that server, to transfer files between the client and server, or to remotely execute commands. We refer to these types of usage as standard connections.

SSH Client Integration

Installing SSH client software is simple. Actually, in nearly every UNIX operating system, installing SSH is not necessary because it's already included in the default OS install. If it's not, then downloading, building, and installing freely available SSH client code, such as OpenSSH (http://www.openssh.org/), is easy. However, Windows boxes do not include SSH client software, so you need to download SSH client software and install it. One of the most popular free Windows SSH clients is PuTTY, available at http://www.chiark.greenend.org.uk/~sgtatham/putty/. OpenSSH has also been ported to Windows (http://sshwindows.sourceforge.net/). There are also Java-based SSH clients, such as MindTerm (http://www.appgate.com/products/80_MindTerm/index.php), that are platform independent and can run within a web browser. Installing just about any SSH client should be easy because it is typically a simple software package that does not make changes to a machine's network configuration. The process is as simple as installing the SSH client and running it.

SSH Server Integration

SSH server software installations are also straightforward. Many UNIX systems have an SSH server daemon (sshd) installed by default. If not, it's usually simple to install sshd by compiling it from the source code. The only special note is that you may need to set sshd to start automatically so that it's available after a server reboot. Of course, it's important to keep all sshd installations and their servers' operating systems current with patches and upgrades.

Each SSH server implementation has its own default configuration. Many different SSH server configuration options are available, and it's highly likely that you will want to change some of the options to fit the needs of your environment. These settings not only affect the security of your installation, but may also impact the functionality of your SSH solution. The exact options you set are based on several factors, including the capabilities of your sshd implementation, the characteristics of your environment, your security needs, and the capabilities and characteristics of the SSH clients. Examples of options you should carefully consider include the following:

• How many failed logins should be allowed in a single session

• Which SSH protocols to allow: SSH1 or SSH2

• Which types of authentication to permit

The Dangers of SSH

You should be aware that, like any other program, SSH can be dangerous if it is not deployed, maintained, and upgraded properly. Multiple serious vulnerabilities exist in various implementations of SSH servers and clients; for example, a vulnerability in PuTTY in late 2004 allowed malicious SSH servers to execute arbitrary code on clients (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1008) in a man-in-the-middle attack. Also, weaknesses have been identified in the SSH1 protocol. If you are going to use SSH in your environment, be sure to use the latest software versions and to keep it current with all patches. Also, configure your SSH servers to only permit the use of the SSH2 protocol, instead of SSH1, unless a specific need exists for backward compatibility. SSH servers have become popular targets for attackers, so you must take great care to protect and harden such servers as much as possible.

SSH Perimeter Defense Adjustments

Minimal changes need to be made to most perimeter defenses in order to accommodate standard SSH connections. SSH servers typically listen on TCP port 22 only; this means that perimeter defenses only need to be adjusted to permit traffic to the SSH server's TCP port 22. Where in your environment should SSH servers be deployed? You may have many servers to which you want to enable external users to SSH, and it's both logical and easy to set up SSH server daemons on each of those servers. From a perimeter defense perspective, however, it's unwise to allow external users to directly SSH to each of those servers. You are opening too many holes in your perimeter and allowing unauthorized external users to have access to too many internal hosts.

From a security perspective, it would be much better to have an SSH server deployed on a screened subnet at the edge of your perimeter and to permit external users to initiate an SSH connection to only that server. After external users have successfully authenticated to that server, they can then SSH from that box to other SSH-enabled hosts on your internal network. This does require external users to perform an extra step in order to access the internal hosts, but it provides much greater control over your perimeter defenses and provides a much more secure solution.

The Hidden Value of Using SSH for File Transfers

As mentioned earlier, SSH has file-transfer capabilities. One major advantage of using SSH instead of FTP is that whereas FTP establishes one connection as a control channel and an additional connection for each data transfer, SSH only needs a single connection for all control functions and data transfers. SSH not only provides encryption for file transfers, but it also has much less of an effect on perimeter defenses than FTP.

When to Use Standard SSH Connections

Standard SSH connections have a well-defined usage: to facilitate remote shell access, remote command execution, and file transfers. Each connection provides access to a single host; therefore, if a user needs to access several hosts at a time, he needs to establish several separate connections. Standard SSH connections are handy for external users who simply need SSH access to particular internal hosts. However, for more sophisticated or complex needs, other VPN methods should be considered because a standard SSH connection has limited capabilities. One alternative that may provide a good solution is SSH tunnels.

SSH Tunnels

SSH has a powerful capability called port forwarding. In port forwarding, an arbitrary local port is chosen and linked by an SSH connection to a particular remote host and remote port. After the connection is established, the SSH client listens for traffic on the specified local port. Any traffic that is sent to that port is then sent through the tunnel to the remote SSH server. This technique is known as SSH tunneling.

Tunneling can be used for many services and applications; however, it's important to realize that because tunnels are remote-port specific, you need a separate tunnel for each remote host/port combination to which you want to tunnel traffic. For example, if you want to tunnel HTTP and IMAP traffic to and from host X, you need to establish a tunnel to host X's port 80 and another tunnel to its port 143. If you need to use six different protocols, you need to establish at least six tunnelsor possibly more than that if a particular protocol uses more than one port number. Another limitation of SSH tunnels is that they can only transfer TCP packets; therefore, packets for other protocols such as UDP cannot be carried by SSH tunnels.

SSH Tunnel Client Integration

The same SSH client software that is used for standard SSH connections can often be used for tunneling as well, although not all SSH clients support tunneling. If you want to do SSH tunneling, verify that your client supports it. The installation and configuration procedures for preparing for SSH tunneling are nearly identical to those for standard SSH connections, with one important exception: If you are configuring tunneling, you usually want to tell the SSH client to accept local connections only. This means that other hosts cannot connect to your local port that is being used for port forwarding and then pass traffic through your tunnel. If your SSH client accepts connections, attackers can contact your local port and gain access to the remote network.

Figure 16.1 shows an example of configuring an SSH client, SecureCRT, to perform local port forwarding for POP3 traffic. After you have configured your SSH client, you must reconfigure all the software packages on your local host that need to utilize the tunnel. For example, you would set your system's POP3 client to contact the local port you have configured to perform SSH port forwarding to the remote server's TCP port 110, instead of trying to directly contact the remote server's TCP port 110. When you ask your POP3 client to retrieve your mail, it contacts your local port, which then forwards the request through the tunnel to the remote mail server. The mail would then be returned through the tunnel to the local port and given to the POP3 client.

Figure 16.1. SSH clients can be configured to provide a tunnel for POP3 traffic.

SSH Tunnel Server Integration

Setting up an SSH server for tunneling is nearly identical to setting it up for standard connections. The only difference is that most SSH servers have some sort of configuration setting that allows tunneling to be enabled or disabled. Of course, you would need to set this to enable tunneling. The exact details of the setting are server-dependent, so consult your SSH server's documentation for information on how to configure tunneling.

SSH Tunnel Perimeter Defense Adjustments

Unlike standard SSH connections, which require minimal perimeter defense changes, SSH tunneling can require many perimeter changes to be made. Remember that each connection within the tunnel may have a different ultimate destination port; therefore, if external users are using tunnels for traffic destined to a variety of ports on many internal hosts, perimeter security can become a nightmare. Depending on the placement of the SSH server and the internal hosts, such a scenario can open far too many holes, allowing external users to attack many different internal hosts and their services. However, it's easy to eliminate this problem.

One nice feature of SSH tunnels is that you can put a tunnel within another tunnel. To implement this securely, you place an SSH server on a screened subnet on your perimeter, just as is recommended for standard SSH connections. After a user establishes a tunnel from her local host to this SSH server, she could then establish additional tunnels that pass through this tunnel to connect to other hosts on the remote network. In this scenario, the perimeter configuration needs to be modified to permit tunnels to be established to this single server and then to pass additional tunnels between that server and other hosts. Although this still weakens the perimeter somewhat, it is more secure than permitting dozens or hundreds of different tunneling connections to be made directly between external hosts and various internal hosts.

Note

When you place an SSH tunnel inside another SSH tunnel, you suffer a performance impact due to the two layers of SSH processing required and keying. Depending on the bandwidth available to users, the overhead involved in running a tunnel inside another tunnel may be significant.

When to Use SSH Tunnels

SSH tunneling can provide an inexpensive solution for remote users who need to run one or more insecure protocols over public networks in a secure manner. A major advantage of tunneling over most other VPN methods is that it can generally be deployed extremely quickly and at minimal cost. However, configuring and using tunneling requires a certain level of technical knowledge that many end users might not have. Also, because a separate tunnel needs to be established for each port, it can become cumbersome to establish several different tunnels, one or more for each protocol. Another factor is that some SSH clients do not support tunneling; therefore, users might have to find a client that does. For these reasons, SSH tunneling is recommended for technically proficient users who want to use a limited number of protocols.