In this chapter, we examined many issues
1 Ethan Cerami . Web Services Essentials. February 2002. O'Reilly. http://proquest.safaribooksonline.com/0596002246/webservess-CHP-3-SECT-4.
2 Object Management Group. "CORBA/IIOP Specification." September 2001. http://www.omg.org/technology/documents/formal/corba_iiop.htm. December 2001.
Chapter 16. VPN Integration
In Chapter 7, "Virtual Private Networks," we addressed the basics of VPN technologies. This chapter discusses VPN integration, which refers to how these VPN technologies can be incorporated into the security perimeter. VPN integration is a complex subject because so many types of VPN solutions are available, and each one has many potential implementation issues. Without a good understanding of VPN integration, you will be ill-prepared to design or deploy VPN in your environment.
In this chapter, we look at several VPN options:
For each type of VPN, we examine the following:
We also discuss other advanced VPN integration topics. Finally, we look in depth at a case study that
The first VPN method we examine in this chapter is Secure Shell (SSH). It has become a popular replacement for Telnet, rlogin, and other
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
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
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
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.
When to Use Standard SSH Connections
Standard SSH connections have a
SSH has a powerful capability called
. In port forwarding, an arbitrary local port is
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
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
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.
When you place an SSH tunnel inside another SSH tunnel, you suffer a performance impact due to the two
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