Skip to main content

LevelBlue Named Official Cybersecurity Advisor of the PGA of America. Learn more

LevelBlue Named Official Cybersecurity Advisor of the PGA of America. Learn more

Services
Cyber Advisory
Managed Cloud Security
Data Security
Managed Detection & Response
Email Security
Managed Network Infrastructure Security
Exposure Management
Security Operations Platforms
Incident Readiness & Response
SpiderLabs Threat Intelligence
Solutions
BY TOPIC
Offensive Security
Solutions to maximize your security ROI
Operational Technology
End-to-end OT security
Microsoft
Unlock the full power of Microsoft Security
Securing the IoT Landscape
Test, monitor and secure network objects
Why LevelBlue
About Us
Awards and Accolades
LevelBlue SpiderLabs
PGA of America Partnership
Secure What's Next
LevelBlue Security Operations Platforms
Security Colony
Partners
Microsoft
Unlock the full power of Microsoft Security
Technology Alliance Partners
Key alliances who align and support our ecosystem of security offerings
Loading...
Loading...

HOWTO: Blocking SSL Tunneling Applications with WebMarshal

Expand / Collapse


This article applies to:

  • WebMarshal 6.1 and above

Question:

  • How can I block UltraSurf with WebMarshal?
  • How can I block FreeGate with WebMarshal?
  • How can I block SSL tunneling or anonymous browsing applications with WebMarshal?

Background:

A number of SSL Tunneling applications are available that allow users to browse without inspection or filtering. Well known examples are UltraSurf and FreeGate.

These applications establish a secure connection (SSL tunnel) between the user's browser and a remote server that then redirects the traffic. 

These applications can be used to bypass local web filtering. The user can freely access any content, including content that is not allowed by corporate policy or local laws. A company or school could be legally liable for problems arising from the content being received by the user, and could also suffer damage from malware downloads.

How It Works:

The tunneling application is usually downloaded. It could be brought in on personal flash drive, and run by the user. The application redirects the browser settings to a localhost port where the application is listening. The application creates a connection to a pre-configured remote server and then all traffic from the browser is passed through the tunnel, without filtering.

Normal Traffic Route
User > Content Filtering Proxy > Firewall > Internet > Web Server

SSL Tunnel Route
User > Local SSL Proxy > SSL Tunnel > Remote SSL Proxy > Web server

The IP addresses or names of the remote servers are changed frequently, so most URL-based content filters will not be able to block these connections.

Procedure:

There are two different methods for managing these applications:

Global Policies

One line of defense in a Windows network is to use Global Policies. This can be to prevent unknown executables from being run, and/or to prevent the browser settings from being changed by the application.

These policies may not be fully effective, considering the range of operating systems and browser applications that are available. Also, they will not be effective for users who require greater permissions.

It is possible to block many of these applications by requiring authentication, as they may be proxy aware, but do not supply authentication. However the drawback of this option is that many legitimate applications (such as Java and Silverlight) require access outbound without authentication in order to function. Normally these are provided for in WebMarshal via port 8081 by IP Authentication, and this can also be abused by the application to bypass authentication.

WebMarshal Configuration

By enabling HTTPS Content Inspection in WebMarshal, you can block any SSL requests made by tunneling applications. These applications expect to communicate directly with the remote server when negotiating the SSL tunnel.

To implement this solution, you can create two HTTPS rules:

  • The first rule blocks any SSL/TLS connection that does not attempt to negotiate with WebMarshal by using the condition "And where SSL/TLS could not be negotiated". Since the application expects to negotiate directly with the remote server, it will be blocked by WebMarshal.
  • The second rule uses the "Permit access and do not inspect content" action to allow other SSL traffic to flow normally
    • You can also choose to inspect HTTPS content for some or all sites. However, inspection of the content is not required to block the unwanted connections.

Since WebMarshal supports SSL, it attempts to negotiate with the tunneling application. This is not the behavior the application is expecting and therefore the connection fails.


To contact LevelBlue about this article or to request support:


Rate this Article:
     

Add Your Comments


Comment submission is disabled for anonymous users.
Please send feedback to Trustwave Technical Support or the Webmaster
.