Most enterprise security controls include strong firewalls, intrusion
detection systems (IDSs), and user policies, such as proxies and time-of-day rules that limit the amount and type of traffic generated onuser networks. Tunneling data through other protocols often by passes these controls and may allow sensitive data to exit the network and
unwanted data to enter. It is even possible to extend all networks
through these means without ever triggering an alert or log entry.

Most researchers cannot help but think of secure shell (SSH) when
hearing the word tunneling. The authors of SSH, the encrypted ver-
sion of Telnet “on steroids,” designed it to be able to tunnel data over
the connections it makes so that other applications and protocols could potentially be more secure. Data, after all,is no different when it is composed of keystrokes and terminal printouts than when it is simply files sent over FTP, Web requests sent over HTTP, or entire IP packets. That is all tunneling really is—a way to transfer arbitrary
data in the payload of a protocol and then potentially interpret them
differently or in some other extended way than originally intended.

A common, simple form of traffic tunneling in SSH is the tunneling of a Transmission Control Protocol (TCP) port. When a user configures such tunneling over an SSH session, the protocol simply proxies a TCP connection over the SSH connection, and the content of the TCP connection does not flow directly from source to destination, but rather through the SSH connection. One side of the SSH
connection (either server or client) listens on a specified TCP port as
the source of the data and transfers all the data to the other side of the
SSH connection. This other side then forwards the data to the specified TCP destination. An SSH tunneling configuration can become more complicated, because users can configure it to provide a reverse tunnel or arbitrary application proxying through protocols such as SOCKS, but the underlying concept remains the same. Picture shows how an SSH connection can tunnel a Telnet connection securely between trusted environments. The example tunnels traffic between two unrelated hosts that have no SSH capability to illustrate the flexibility of the solution.

Researchers designed SSH to provide this capability,but it is simple to block. The Internet Engineering Task Force Request for Comments (IETF RFC), which has published documents describing protocol standards, defines SSH’s port cleanly so administrators can filter it. The traffic signature, especially the initial handshake, is obvious, and some deep packet inspection tools may block it regardless of what port a user choose. Still, tunneling is not limited to SSH. A
deft attacker can coax any protocol into tunneling traffic; however, for
the tunnel to be valuable for hoarding data in and out of a network,protocols with substantial areas of payload work best. Many types of open source software already exist, all of which allow tunneling through well-known protocols, which attackers can use out of the box or with some simple tweaking to defeat most firewalls’ rules,proxies,nd other administrative access controls quickly. By writing custom applications that act as the client and server for other protocols in a given environment, malicious code can hide its activities and gain
unfettered access to and from any network. To illustrate this point,
this section examines some of the most common unrestricted protocols in the enterprise—HTTP, the domain name system (DNS), and Internet Control Message Protocol (ICMP)—to show how open and flexible they are.