Support Support Downloads Knowledge Base Juniper Support Portal Community

Knowledge Base

Search our Knowledge Base sites to find answers to your questions.

Ask All Knowledge Base Sites All Knowledge Base Sites JunosE Defect (KA)Knowledge BaseSecurity AdvisoriesTechnical BulletinsTechnotes Sign in to display secure content and recently viewed articles

[ScreenOS] Cannot block Ultrasurf on ScreenOS firewalls



Article ID: KB21178 KB Last Updated: 21 Apr 2016Version: 3.0
This article describes the issue of being unable to block Ultrasurf at the ScreenOS firewall level.
Ultra surf is a proxy client software, which is designed to allow end-users to circumvent the security gateway in order to surf the internet without any restrictions.

The reason why Ultrasurf cannot be blocked at the firewall is because of the following reasons:
  1. Local Proxy:

    Ultrasurf sets up a local proxy on the user’s computer and then configures the Internet Explorer’s proxy settings to run all Internet requests through that local proxy. It works automatically with Internet Explorer; however, the user can also use Mozilla Firefox or any other browser that supports a proxy configuration by manually changing the browser’s proxy settings. The default port is 9666.

    The user can then normally browse any Internet site using IE. All the traffic is funneled through the local Ultrasurf proxy. Since the traffic between Ultrasurf and IE is entirely on the localhost, it never goes to the network and cannot be blocked by a network device.

    Ultrasurf then sets up an encrypted connection with a remote server in its network of proxy servers. When the user browses a blocked site (for example,, IE sends the request to Ultrasurf, which then forwards the request to its proxy server. The proxy server retrieves the content of and returns it through the encrypted tunnel to Ultrasurf, which sends it back to IE. All that you see at the gateway is the encrypted tunnel.

  2. Proxy Server Discovery:

    Ultrasurf also has a very scalable and resilient design for discovering proxy servers in this network. Once Ultrasurf discovers a proxy server in its network, it can retrieve IP addresses of other proxy servers directly from that server.

  3. Non-Standard Use of SSL:

    The connection to the remote proxy server is made over port 443, which is the standard HTTPS port (that is why the netstat output above shows a connection as https). However, in Ultrasurf versions 6.6 and 6.7, the connection travelled to port 443 but was not SSL. Beginning with version 8.8, Ultrasurf began to use what appears to be an anonymous SSL connection, where the server side does not respond with a certificate.

    It is not known whether or not the subsequent communication continues to use SSL, or whether this is merely a diversion. The use of port 443 is specifically done to trick gateway devices into ignoring the traffic. The use of non-standard SSL or non-SSL transmissions over port 443 is designed to trick gateway devices into mishandling the traffic.

  4. Cache File:

    Ultrasurf stores previously discovered nodes in a cache file that it writes to the user’s temp directory. The name of the file appears to be based on some static element of the system such as a disk ID or other hardware token, because the name of the cache file will be different across systems but always the same on the same system.

  5. DNS:

    If no cache file is found or the cache file does not contain a suitable number of proxy server nodes for fail-over, Ultrasurf attempts to locate proxy servers using a set of external DNS servers. Ultrasurf makes multiple simultaneous requests to a set of DNS servers on the Internet. The list is compiled into Ultrasurf, so it can only change the list with a new software release.

Ways to block it using the following workarounds :
  1. At the firewall, block all outbound DNS requests to unauthorized external DNS servers or request the list of known Ultrasurf DNS servers from 8e6 and block only those. Ensure that authorized DNS traffic is allowed, including the outbound traffic from your internal DNS servers to upstream DNS servers.

  2. At the web filter, block by IP address and make sure the HTTPS filtering is on. The reason for blocking is because as mentioned. If Ultrasurf still needs to find proxy servers, it will request this document from Google Docs:

    The request is made in conjunction with a group of misdirection HTTPS requests that are meant to make it difficult to see what is going on in a packet sniffer. This document is a signed, encrypted, and base64 encoded list of IP addresses of active Ultrasurf proxy servers. (This has been tested by third party vendors such as m86security).

  3. At the web filter, block the proxy category and make sure that the proxy pattern detection is enabled.

  4. Remove the Ultrasurf cache files in user temp directories and/or at the firewall, block the IP ranges of problematic home computer netblocks.

  5. ScreenOS DI and IDP at present does not block it.
  6. ScreenOS IDP Signature : WEB:ULTRASURF only detects access to the ultrasurf download site so that an admin can track who downloads the application. Please note that the IDP feature is available only in ISG 1000 and ISG 2000 platforms.
Comment on this article > Affected Products Browse the Knowledge Base for more articles related to these product categories. Select a category to begin.

Getting Up and Running with Junos

Getting Up and Running with Junos Security Alerts and Vulnerabilities Product Alerts and Software Release Notices Problem Report (PR) Search Tool EOL Notices and Bulletins JTAC User Guide Customer Care User Guide Pathfinder SRX High Availability Configurator SRX VPN Configurator Training Courses and Videos End User Licence Agreement Global Search