by Ronnie Angello

While the growing popularity of broadband Internet services and elevated concerns with securing Wireless LANs (WLANs) have become major concerns for network administrators today, Secure Shell (SSH) Protocol tunneling has proven to be a secure and effective solution for addressing various needs and concerns of both network users and administrators. Making the transition from traditional dialup remote access to a broadband solution can bring along with it some roadblocks when trying to preserve functions and security. WLANs can be difficult to secure in the enterprise, mainly because of the various client types that must connect to the network. SSH tunneling can help alleviate both of these issues.

SSH tunneling, also known as SSH port forwarding, is the process of forwarding selected TCP ports through an authenticated and encrypted tunnel. These tunnels can be constrained to within two points of the company's enterprise network, or it can originate on a small office or home office (SOHO) computer on a given provider's network, and transit the Internet to a server on the enterprise network. Some practical uses for SSH tunneling are outlined in this article.

A Look Back at Traditional Remote Access
Remote access is the method of connecting from a SOHO computer that resides on a remote foreign network, or has no permanent network connection, to the enterprise network or central office. Usually this involves traversing the Internet. This can be for the purpose of telecommuting, providing on-call support from home, checking e-mail while away from the office, or for the old-fashioned workaholic who must work from home. Remote access used to involve simply accessing a network through an analog phone line or possibly ISDN. In either case, the user was authenticated by an access server that resides on the enterprise network and given authorization to certain resources.

When connected to the access server, users had the feel of being connected to their company's enterprise network. They were free to browse internal Web pages and access various Windows domain resources. They could connect to the network neighborhood and transfer files to and from the work computer. They could connect directly to internal UNIX servers with SSH and use a local X-server application to access UNIX applications from the SOHO.

PC remote-control applications such as VNC, etc. could be used to access files and applications that reside on a host computer on the enterprise network without extensive configuration on the home PC. In addition to the ease of configuration for the administrator or user, fewer applications need to be installed on the home computer to accomplish work tasks from home. This approach saves software licenses in addition to valuable company resources.

Most network administrators cannot let PC configuration consume a great deal of their time because they are busy enough as it is. From a function standpoint, users felt like they were working from their office at work. It was too slow though, so it did not really matter. Then broadband services were introduced, and they offer high bandwidth, but getting the same functions is a bit more challenging. Users benefit from the extra added bandwidth, but of course the administrator has to make sure that everything works as if nothing ever changed.

Broadband Services Emerge
Many users are now migrating from their traditional dialup connections for Internet access to a technology that offers more bandwidth such as cable or DSL. Broadband wireless services are now emerging in some areas as well. These services may even be cheaper than what the company or individual was previously paying for ISDN service, and it is "always on." Most users are no longer dialing a company access server to access the resources that are vital to their job. They are now permanently connected to a foreign provider's network, and often the only choice for secure remote access to the enterprise is through a VPN. Strict policies, however, may need to be enforced on the remote SOHO computer for it to be a comfortable solution for security administrators to implement.

For those organizations without the time, money, or manpower to implement and support VPN, Linux login servers can be opened up to the Internet to authenticate users that employ SSH to access the enterprise network from these remote networks. These servers are no more than relay points to access internal systems. They should be placed in the DMZ or on a "screened" network protected by a firewall. The other internal systems are not directly accessible from the remote networks. In cases where remote access is considered a valuable resource to the organization, more than one of these servers should be implemented for load sharing and redundancy.

However, certain functions are lost. Initiating an application from a UNIX computer and displaying it to your SOHO computer with a local X server has been proven to be slow and inadequate from some remote networks. In addition, internal domain PCs and network shares are no longer accessible through the network neighborhood, and file transfer is not available without an additional secure, standalone application. The remote-control applications that access the internal PC will no longer work without opening holes in the firewall. There is a simple solution to all this that is free, secure, and effective: SSH tunneling.

Securing Broadband Remote Access
The functions described in this section can be achieved with any SSH client capable of tunneling, any Web browser that supports HTTP and Secure Sockets Layer (SSL) proxies, and any PC remote-control application. The first step is always to connect to the remote login server that has been made accessible to the SOHO user. When connected to this login server, the user can use SSH to access any other internal machine, or take advantage of SSH port forwarding to accomplish their other tasks.

A proxy server may already be configured on your enterprise network. This server is configured to accept connection requests for Web pages and allow the clients to view them with little network overhead. The SSH client on the SOHO computer is configured to forward the specified local source HTTP port (such as 8080) to port 80 on the remote destination HTTP proxy server. It can also be configured to forward the specified local source SSL port (such as 4433) to port 443 on the remote destination SSL proxy server.

The browser on the client machine is configured to use the HTTP or SSL proxy server localhost on the specified local port(s). When the browser attempts to download a page, the SSH client forwards the request to the specified remote proxy server on your enterprise network through the established tunnel. Internal Web pages that would normally be available only on the enterprise local intranet are available without latency and without compromising security.

The same concept can be followed for tunneling PC remote-control application data through SSH. The remote-control host service is not changed, and it is waiting for a connection attempt from a remote computer as it normally would. A new remote-control connection is configured on the SOHO computer pointing to localhost. Using any additional encryption offered by the remote-control application is possible, but not necessary. Additional encryption will add latency, and SSH provides strong encryption itself with Triple Digital Encryption Standard (3DES), Blowfish, etc. The SSH client is configured to forward the local source ports used for the remote-control data (that is, port 3389 for RDP) to destination ports on the host computer on the enterprise network.

Once again, all the functions that the user had when dialing up the enterprise network directly are now available. With SSH, an additional layer of security is provided. Because the desktop of the internal computer is available on the SOHO computer's desktop, users have access to all applications, files, and network resources that they would if they were physically working from their office at work. No additional software applications need to be installed on the office computer to satisfy requirements of working from home, and minimal software needs to be installed on the users' personal home computers. Some of these remotecontrol applications also provide a file transfer tool that can be used to transfer or synchronize files between the two PCs.

SSH Tunneling for WLAN Security
Securing WLANs has become a monumental problem today for most network administrators. Many organizations are resorting to proprietary solutions or are simply avoiding the implementation of WLANs entirely. An entire article could be dedicated to the importance of securing wireless and the details of accomplishing such a feat.

In addition to the uses described in the previous sections, SSH tunneling can also be used to supplement or replace weaker, more vulnerable encryption found in other network applications. Consider Wired Equivalent Privacy (WEP) encryption, for example.

Although other alternatives such as Wi-Fi Protected Access (WPA) are available, most WLANs have been implemented with either no encryption or with static WEP only. Static WEP has been highly criticized because of vulnerabilities in the protocol that have been discovered and widely documented. Even when implemented at the 128-bit level, there are tools circulating the Internet that exploit a well-known vulnerability that allows a hacker to crack WEP keys. Even with a WPA solution in place, there will be clients that support only static WEP. These traditional clients can be secured in the meantime by restricting network access with an Access Control List (ACL) and tunneling insecure protocols through SSH. Once again, the same functions can be achieved with a VPN solution, but some organizations have neither the money nor resources to implement it.

Summary
In conclusion, SSH tunneling can be used well beyond the scope of the methods explained this article. The particular uses outlined in the previous sections have been practical in my experience and have been very successful implementations. When users decide to change to a provider that offers broadband, I have found that simply providing a procedure for configuring tunneling has been successful for getting them operational from home.

SSH tunneling should be of interest to any organization that wishes to allow its users secure access to all the resources that they may need to accomplish their job functions—especially from a remote location. While exploring possibilities to make a particular application or protocol secure, always consider SSH tunneling an option. SSH provides authentication and encryption that has been proven to be effective for any application.

Securing Remote Access to Internal PCs, Web Pages, etc.
The following is a short example procedure for configuring tunneling for this specific function. It does not include detailed instructions for configuring specific applications, but it outlines the important steps that must be followed in order for it to work properly.

	Any SSH client that supports tunneling can be used. You can download the PuTTY SSH client (putty.exe) from: http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html
	Make sure that you select port 22 (SSH). (See Figure 1.)

Figure 1: PuTTY Configuration Screen — Sessions

Choose your preferred encryption cipher; enable compression and X forwarding if desirable. Click "tunnels" in the tree menu. Add the local source port(s) and the remote destination port(s) for the ports that you would like to forward through the tunnel. (See Figure 2.)

Figure 2: PuTTY Configuration Screen —Tunnels

	Make sure that the LAN settings in your Web browser are configured to use the HTTP/SSL proxy server localhost on the local port that you specified.
	Make sure that your remote-control connection is pointing to the computer "LOCALHOST." If you have trouble connecting, make sure that the host service is running on the host PC.

For Further Reading
[1] The SSH (Secure Shell) Remote Login Protocol, SSH-1 Specification, T. Ylonen, November 1995.

[2] SSH-2 Specifications IETF Secure Shell working group, June 2003.

[3] O'Reilly Network Using SSH Tunneling: http://www.oreillynet.com/pub/a/wireless/2001/02/23/wep.html

[4] Secure Email Through SSH Tunneling: http://www.slac.com/~mpilone/projects/kde/kmailssh/

[5] PuTTY Links: http://cdot.senecac.on.ca/software/putty/links.html

[6] William Stallings, "SSL: Foundation for Web Security," The Internet Protocol Journal, Volume 1, No. 1, June 1998.

RONNIE ANGELLO, CCNP, CQS-CWLANSS, CCNA, holds an A.A.S. Degree in Information Systems Technology (Specialization in Operating Systems and Network Operations) and is currently completing degree requirements for the Bachelor of Science Degree in Information Science (Concentration in Networking and Communications) at Christopher Newport University in Newport News, Va. He recently passed the CCIE Routing and Switching Qualification Exam and is preparing for the CCIE Lab Exam. Email: angello@jlab.org