ProxySG TechBrief – Controlling Tunneling Applications

What are Tunneling Applications?

Many network applications are blocked by corporations and cannot be used outside network
boundaries. Applications such as telnet, SSh, FTP, etc. are viewed as unnecessary for most
employees. However, access is granted through a firewall to allow the use of these applications
for a specific set of users. Some Internet applications have been cleverly designed to work
across port 80 and can operate virtually undetected across a corporate network.

Today, applications such as gotomypc.com pose a different type of issue. These types of
applications can initiate a connection from the inside of a corporation out to a user’s home
computer across a DSL connection, for example. These applications go out over port 80 (across
the firewall) and initiate a connection with a remote PC. Therefore, data coming back into the
corporate network is viewed as acceptable by the firewall because of the existing connection.
This can be a serious breach in security and administrators need the ability to stop this activity
when necessary or prohibited by company policy.

Another type of tunnel is created using applications designed to tunnel any TCP or UDP
application over HTTP. The two styles of these applications behave quite differently. One
approach uses a client application only, utilizing a Proxy ‘service’ on the Internet. The other style
has two pieces of software running, commonly known as a client and a server.

The first approach uses a client application only and connects to proxy-like servers on the
Internet. Rules are created in the client application and the user points the application to be
tunneled going over port 80, or through the corporate proxy, with credentials if required. The port
80 traffic, which is really another application such as SSh or Telnet ‘encapsulated’ in port 80,
arrives at these proxy servers out on the Internet. The server accepts the request, strips off the
port 80, and initiates the real connection to the ultimate destination Telnet or SSh server.

The second approach consists of client and server software. A server is installed at home, for
example, and the client component runs on a machine at the corporate office. The server
behaves just like the ‘Proxy’ server on the Internet in the other example. The server is configured
to listen on any port, and when a connection arrives on this port, it then reinitiates a connection to
the ultimate destination on behalf of the client application.

A Good discussion of these techniques can be found at the following URL:

http://www.tldp.org/HOWTO/mini/Firewall-Piercing/

Controlling Tunneling Applications on the ProxySG

The Blue Coat ProxySG can be configured to block these types of applications with ease. These
two previously discussed sets of applications are designed to circumvent a company’s security
policies and can be used by a relatively naïve technical user.

GNU
For example, successfully blocking the GNU operating system that is using ‘htc’ and ‘hts’
applications can be accomplished by configuring the ProxySG with the default proxy policy of

1 Technical Brief
‘Deny.’ The GNU applications are easily identified as not legitimate HTTP by the Blue Coat
Policy Engine and are denied.

As an example the ProxySG can be set to allow all traffic through. The following information
appears in the Blue Coat access log:

1050543229.404 29227 192.168.1.101 TCP_NC_MISS/200 3103 GET

http://192.168.1.11:8888/index.html - DIRECT/192.168.1.11 text/html
1050543229.897 29723 192.168.1.101 TCP_NC_MISS/0 0 POST
http://192.168.1.11:8888/index.html - DIRECT/192.168.1.11 -
1050543389.125 6 192.168.1.101 TCP_MISS/301 104 GET http://192.168.1.20:8081/
- DIRECT/192.168.1.20 -

The URL looks legitimate, but the headers are not standard HTTP. Telnet over HTTP may work
perfectly to a public telnet site on the Internet. Additionally, this example will fool any stateful
inspection firewall and application level firewalls as well. The Blue Coat ProxySG is able to block
this traffic by simply setting the proxy policy to Deny. Here is an example of the access log when
the ProxySG policy is set to Deny:

1050543229.560 154 192.168.1.101 TCP_DENIED/403 2780 GET

http://192.168.1.11:8888/index.html - DIRECT/- -
1050543235.520 0 192.168.1.101 TCP_DENIED/403 2780 POST
http://192.168.1.11:8888/index.html - DIRECT/- -
1050543235.547 25 192.168.1.101 TCP_DENIED/403 2780 GET
http://192.168.1.11:8888/index.html - DIRECT/- -
1050543244.023 0 192.168.1.101 TCP_DENIED/403 2780 POST
http://192.168.1.11:8888/index.html - DIRECT/- -
1050543245.126 100 192.168.1.101 TCP_DENIED/403 2780 GET
http://192.168.1.11:8888/index.html - DIRECT/- -

If a default proxy policy of Deny is not feasible for your environment, you can also create a
customized rule using the Blue Coat Content Policy Language (CPL) to block this application:

<proxy>

request_header.User-Agent=!”” DENY

A Blue Coat policy trace looks will appear like this:

start transaction ------------------------------

CPL Evaluation Trace:
<Proxy>
MATCH: DENY request_header.User-Agent=!""
connection: client_address=192.168.1.101 proxy_port=8080
time: 2003-04-17 02:21:28 UTC
request: POST http://192.168.1.11:8888/index.html
user: unauthenticated
DENIED: policy
end transaction --------------------------------

start transaction ------------------------------

CPL Evaluation Trace:
<Proxy>
MATCH: DENY request_header.User-Agent=!""
connection: client_address=192.168.1.101 proxy_port=8080
time: 2003-04-17 02:21:28 UTC
request: GET http://192.168.1.11:8888/index.html
user: unauthenticated

2 Technical Brief
 DENIED: policy
end transaction --------------------------------

Fpipe
FPipe is a TCP source port forwarder/redirector application. FPipe can create a TCP stream with
a source port of your choice. This type of application is useful for getting past firewalls that allow
traffic with source ports of say 23, to connect with internal servers.

The ‘fpipe’ application does not work through a proxy server such as a ProxySG. Restricting
outbound access from user machines is the security practice that prevents this application from
circumventing policy. Though, this TechBrief assumes that outbound access directly from
desktop is restricted.

TCPTunnel
Yet another tunneling application, TCPTunnel downloaded from ‘Sureshot Software’ requires the
HTTP CONNECT method for the operation to work. The client issues the CONNECT method to
the port that the server piece is listening on. It then sends the real connection information in
munged data format. Out of the box, the Blue Coat ProxySG blocks all CONNECT requests to
ports other than 443; the CONNECT method should only be used for explicitly proxied browsers
requesting a connection to an SSL site.

The user may discover this and use port 443 to communicate with the server piece. At this point,
Blue Coat engineers have observed the packet trace and noticed the application does nothing to
appear like a browser. The earlier rule used to block the GNU application, will also block this
application as it sends no User-Agent string. The following CPL code can be applied to the
ProxySG:

<proxy>

request_header.User-Agent=!”” DENY

HTTP-Tunnel.com
The HTTP-Tunnel Client application works differently than the GNU application. It utilizes servers
on the Internet to provide this service. Applications such as a browser, telnet, or SSh, utilize a
local port that the client is listening on. The client then tunnels the application through the
corporate proxy, across the firewall, and to the servers. These servers “de-encapsulate” the port
80 traffic and utilize the true application to the destination server. Blue Coat Systems has
inspected the behavior of this application and has used Content Policy Language (CPL)
constructs to block this traffic.

The policy that can block this application through the ProxySG is the following

<Proxy>
DENY request_header.Host="http-tunnel.com"
DENY method=POST url_host_is_numeric=yes url_path=/update.htm

3 Technical Brief
 Keep in mind if the corporate firewall has ports 80 or 443 open to a user' s desktop, there is no
way to stop tunneling without the use of additional products. For example, using the ProxySG
with the appropriate tools and capabilities you can prevent this application from working by
following these recommendations:

Start by only allowing connect on 443 (this is the Blue Coat default)

• Create a rule on the Blue Coat ProxySG that allows HTTPS only to approved sites
(HTTPS white list). You can define a custom (error) page to first send a request to open
a new site and have the administrator check and approve it prior to allowing access.
• If HTTPS white lists are not feasible, at a minimum deny HTTPS to most of the content
filtering categories such as Webmail, anonymizers, shopping, portals, etc. In addition,
block HTTPS to IP addresses that will not resolve under reverse DNS. This is why an
integrated filtering list is so important. You can use it in combination with methods, user
agents, protocols, and other features found on the ProxySG.
• Use positive rules to determine which User Agents are allowed. (E.g. only certain
versions of IE and Netscape). This will help reduce interesting applications such as the
use of stunnel, a program that allows encryptions of arbitrary TCP connections inside
SSL (as long as they do not spoof the user agent).
• Use positive rules to allow certain HTTP methods (get, put, etc.)
• Last rule should be a “deny all”

Conclusion
Authentication and reporting are also very important to assist in controlling these occurrences of
tunneling. Using authentication can trace these various tricks back to a specific user. Reporting
shows who did it and when. By using the Blue Coat ProxySG, an enterprise can control the types
of applications that are run across open ports on their firewall. The ProxySG allows flexible and
complex rules to be created that allow only approved Web sites to be accessed. In conjunction
with a corporate firewall, the Blue Coat ProxySG can provide the solution needed to control
tunnelling applications.

Copyright ©2003 Blue Coat Systems, Inc. All rights reserved worldwide. No part of this document may be reproduced by any means nor translated to
any electronic medium without the written consent of Blue Coat Systems, Inc. Specifications are subject to change without notice. Information
contained in this document is believed to be accurate and reliable, however, Blue Coat Systems, Inc. assumes no responsibility for its use. Blue Coat is
a registered trademark of Blue Coat Systems, Inc. in the U.S. and worldwide. All other trademarks mentioned in this document are the property of their
respective owners.

Contact Blue Coat Systems • 1.866.30BCOAT • 408.220.2200 Direct • 408.220.2250 Fax • www.bluecoat.com
4 Technical Brief