Concerns Related to Tunneling Through or Across a Firewall

Hacker tunneling that can be accomplished through or across your firewall deployments are a serious threat to your organization’s network security. Tunneling is the creation of a communication channel similar to the creation of a VPN. In some cases, it uses actual VPN solutions and protocols. Tunneling can create either a covert channel or a known channel that is unfiltered.

Tunneling uses two techniques. One method is to install a server component on an internal system, and then an external client component initiates the connection. This technique requires the firewall to allow inbound initiation connections to internal systems. A second method is to install a server component on an external system, and then use an internal client component to initiate the connection. This technique requires the firewall to allow outbound connections.

Most firewall deployments strictly limit or restrict inbound initiation of communications to specific ports and services. A tunneling setup using an inbound connection must “hijack” an existing open port or reconfigure the firewall to open another port for use by the tunnel. If the perpetrator of this security violation has the ability to reconfigure the firewall, you have much more serious security concerns to address than tunneling.

Firewalls commonly allow most outbound communications with little or no restrictions. Although it is not the best security stance, it is convenient and easy. Proper use of a deny-by-default stance should limit both inbound and outbound connections to those explicitly allowed. If the firewall allows outbound connections, then internally initiated tunnels are extremely easy to establish.

Tunnels can potentially use almost any protocol, including IP, ICMP, TCP, UDP, and most application protocols. Specialized tunneling server/client applications can replace traditional payload content with whatever content the hacker wishes. Effectively, this can convert almost any protocol at any layer of the OSI model into an encapsulation or tunneling protocol (FIGURE 13-3).

An illustrated diagram of a tunnel across a firewall.

FIGURE 13-3 A tunnel across a firewall.

Tunneling is an obvious abuse and violation of protocol rules. However, if a firewall is not investigating the payload of a frame, packet, segment, and so on, then a hacker can set up a tunnel using a protocol not designed to perform encapsulation.

The problem gets worse when the tunneling system employs encryption. This makes payload investigations more difficult, because the firewall is unable to decipher the content or purpose of the encoded payload. To combat this complexity, set the firewall to either block all encryption, allow only encryption that originates or terminates at the firewall, or allow encryption only on certain ports (potentially limiting communications to and from specific IP addresses, as well).

NOTE

Once a tunnel is open, data can move in either direction. The directionality of the connection has little to do with which end of the tunnel is the controller and which is the ultimate target or victim.

Encrypted tunnels across a firewall are not inherently or automatically malicious in nature. VPNs are encrypted tunnels that commonly create security for personal and business communications across the Internet and within private networks. However, most VPNs use well-known VPN protocols, such as IPSec and Secure Sockets Layer (SSL)/Transport Layer Security (TLS), on standardized ports, with predictable header constructions and characteristics. Unauthorized or rogue tunneling mechanisms often use odd protocols for encapsulation and can operate on any port, use invalid packet constructions, and violate communication standards.

In addition to the standard VPN protocols used for this purpose, such as IPSec, SSL, TLS, OpenVPN, PPTP, L2F, L2TP, and so on, several other legitimate and subversive services, products, and protocols can configure unauthorized tunnels. These include:

  • Loki—Loki uses ICMP as a tunneling protocol.
  • Netcat—Netcat can create TCP and UDP network connections to or from any port.
  • Cryptcat—Cryptcat is a version of Netcat that creates encrypted connections.
  • NetBus—NetBus is a malicious remote control tool.
  • Back Orifice—Back Orifice is a malicious remote control tool.
  • SubSeven—Subseven (also denoted as Sub7) is a malicious remote control tool.
  • Remote Desktop Protocol (RDP) and Remote Assistance—These are native features of the Windows OS. RDP is disabled by default, and Remote Assistance requires an invitation.
  • Tor—This is a double-blind encapsulation system that enables anonymous, but not encrypted, Internet communications.
  • JanusVM—This is Linux software powered by VMware that creates SSH encrypted tunnels used in combination with Tor. It was last updated in 2009, but it is still used in some exploits, as unpatched or legacy systems are still vulnerable.
  • PacketiX VPN—This is an encrypted web proxy service. It was last updated in 2012, but it is still used in some exploits, as unpatched or legacy systems are still vulnerable.
  • HotSpot Shield—This is an encrypted web proxy service.
  • HTTP Proxy—This is a web proxy service.
  • GoToMyPC, RescueAssist, LogMeIn, Remote Framebuffer, and similar services—These are third-party remote desktop control services.
  • TigerVNC and TightVNC—These are virtual network computing applications.

This list of products, services, solutions, and protocols used to create illicit tunnels across a firewall is not exhaustive. Several of these are legitimate services with valid uses, but when a hacker employs them without permission, especially across nonstandard ports, it represents a serious threat. Any ability to breach a firewall to allow unfiltered, full-duplex communications is cause for concern and response.

The best defense against these tunneling exploitations is to strictly enforce deny by default for both inbound and outbound communications. Clearly define in the acceptable use policy (AUP) which tools are unauthorized and which are considered security breaches. Use network and host IDS/IPS monitoring. Deploy whitelist controls to prevent the installation of unapproved software.

Another item often included in lists of tunneling issues and concerns is the danger of mobile code. Beyond the scope of this book, mobile code is dangerous because it executes on the client device. Any malware or harmful instructions included in the code are executed on your system. Limit mobile code, such as ActiveX, Java, Flash, Silverlight, and JavaScript, in browsers to minimize the possibility that a web-only form of tunneling might use an authorized web client.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.138.199.28