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.

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.)

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