Block Evasive Applications
Configuration files created with — Policy Manager v11.12.2
Revised — 6/7/2017
This example demonstrates how to use policies and WatchGuard security services to effectively block evasive applications. This example focuses on how to prevent the use of one proxy application, Ultrasurf, which is a good example of an evasive application. You could use a similar strategy to block other types of evasive applications on your network.
This configuration example is provided as a basic guide. Your network environment might require additional configuration settings.
This configuration relies primarily on Application Control and WebBlocker, but also describes how to correctly configure outbound DNS, HTTP, HTTPS and TCP-UDP policies. This configuration example also includes some of the log messages that indicate the actions of the configured policies and services.
This example configuration was tested with a Windows 7 network client protected by a Firebox installed with Fireware v11.12.2. We used Ultrasurf v.16.03.
How It Works
Many proxy avoidance applications use a similar set of strategies to try to connect to their servers. Typically, the application first sends DNS queries to try to find a server. Then it tries to connect to the server on HTTP port 80 and then on HTTPS port 443. Some applications try to build an SSL tunnel on either the standard port 443, or another port, such as TCP 53 or another dynamically selected port. If all of this fails, the application could try to connect to backup servers located on popular and often allowed data centers such as Microsoft or Amazon Web Services. Another strategy includes attempts to download another executable while the application continues to repeatedly try to connect to a server.
To detect these sorts of applications, you must configure proxies and services with appropriate settings, and enable logging for reports. It is also important to regularly monitor log files and reports to keep up with the new trends in network activity as updates of those applications become available.
This example configuration uses a combination of policies and services to block the strategies used by Ultrasurf:
- Proxy Policies — Proxy policies examine all outgoing HTTP, HTTPS, and DNS connections, and deny or block connections or content that could represent a threat. The proxy policies also use configured services and other configuration settings to examine connections and content to determine whether to allow a connection.
- Application Control — Application Control drops connections for applications in the Tunneling and proxy services category and other application categories that could represent a threat. Application Control is enabled for all outgoing browsing policies.
- WebBlocker — WebBlocker blocks connections to websites in the proxy avoidance category and other categories that could represent a threat. The WebBlocker configuration is used by the HTTP-proxy and HTTPS-proxy actions.
- Gateway AntiVirus — Proxy policies are configured to scan allowed content for viruses and drop the connection if a virus is found.
- Other Security Services — Intrusion Prevention, APT Blocker, Botnet Detection, and Reputation Enabled Defense are all enabled with recommended settings to protect the network.
Example Configuration Files
For your reference, we have included an example configuration file with this document. The configuration file includes the settings described in this example.
The name of the example configuration file is block_evasive_apps.xml.
To see the configuration details of each example configuration file, open the configuration file with Policy Manager.
This configuration example has these requirements:
- WatchGuard subscription services, especially Application Control and WebBlocker
- WatchGuard firewall that filters traffic between network clients and the Internet
This example configuration uses a basic network topology, to show how the Firebox can filter all traffic between the clients on the trusted network and the public internet. All network clients must use the Firebox as their default gateway.
The Firebox interfaces in this example have these IP addresses:
- External (eth0): 203.0.113.100/24
- Trusted (eth1): 10.0.100.1/24
This section describes the configuration based on the chronological order of packets we expect to see from evasive applications such as Ultrasurf.
DNS UDP Proxy Policy
The first packets sent by the evasive application are often DNS UDP packets on port 53. For DNS requests not allowed by the DNS proxy policy, you can configure the proxy to Drop or Deny the requests, or Block the source of requests. The safest and most efficient option is to Drop requests. This causes the application to wait before it gives up and tries another strategy, and it also saves firewall resources. If you decide to Block, be aware that while this can be a very effective method to block any traffic that originates from the client when they use a Public DNS server, it can also block all Internet access from that client. In a network with an internal domain server, the Block action in the DNS proxy can block Internet access for all users on the network.
If your DNS policy for TCP-UDP traffic on port 53 allows traffic from Any-Trusted to Any-External, it could allow the application to build a tunnel to its server on port TCP 53 and may evade detection if you have not applied Application Control to that policy. That is why, in this example configuration, the outgoing DNS policy allows connections from Any-Trusted to the alias PUBLIC DNS. This alias includes a small group of trusted public DNS servers. You could use a packet filter policy instead of a proxy policy to define the destination of allowed DNS packets. This can save resources on the firewall.
For this example, this proxy policy uses the default settings from the predefined DNS-Outgoing proxy action, with these changes:
- The proxy action is configured with enabled Query Names Rules that:
- Deny connections to the domain name pattern *doubleclick.*
- Drop connections to the domain name pattern *ultrasurf.*
You could add other domain name patterns here for other evasive applications you want to block.
Application Control Configuration
The example configuration includes an Application Control profile named STRICT. To prevent connections from Ultrasurf and other similar applications, this Application Control action is configured to Drop connections for all applications in the Tunneling and proxy services category. For more complete protection, this action also restricts applications in the Media streaming services, Peer-to-peer networks, Online games, and Social networks categories. Those additional categories are not required to block Ultrasurf. Your choice of which application categories to allow depends on your company policies.
To deny unknown applications, you must be explicit about what applications are allowed, so that the default Drop action can be triggered when an application does not match.
To prevent Ultrasurf and other tunneling and proxy applications, select the Drop action for the Tunneling and proxy services category in the Application Control action. The STRICT Application Control action is applied to all policies that handle outgoing connections for web browsing.
In the example configuration, WebBlocker is enabled in the HTTP and HTTPS proxy policies. To block connections to known proxy avoidance sites, WebBlocker blocks the Proxy Avoidance category. In this configuration WebBlocker also blocks other security and productivity categories, including the Security section, the Extended Protection section, Web and Email Spam, Parked Domains, Advertisements, Unauthorized Mobile Marketplaces, Hacking, and Computer Security categories. Some proxy sites and applications can be found in any of those categories.
This configuration is set to Allow connections to a site if the URL is uncategorized. To increase protection against unknown URLs, which are often involved in ransomware, you could change this action to Deny. But the Deny setting is likely to trigger false positives if local suppliers, customers, and partners of your company have websites that are not categorized by WebBlocker. If you use the Deny action for uncategorized URLs, some sites you want to allow access to could be blocked. If this happens, you can add WebBlocker exceptions for those sites, and submit those sites for review in the WebBlocker section of the WatchGuard Security Portal.
HTTP Proxy Configuration
The HTTP Proxy is configured with strict and secure settings. The HTTP proxy action is configured with the AV Scan action for all allowed URL Paths, Content Types, and Body Content Types.
The Body Content Types settings also deny download of executable, dll, and cabinet files unless they come from an exception site such as *.windowsupdate.com. This specifically blocks attempts by the proxy application to try to download and install other executable files that can try to reach its destination when the first attempts to bypass the HTTP proxy are unsuccessful. It is also the easiest way to prevent malware downloads in general.
HTTPS Proxy Configuration
The HTTPS Proxy is configured with Content Inspection enabled, and it uses the same HTTP proxy action as the HTTP proxy policy to scan and filter content.
The HTTPS proxy is set to inspect connections to all domains by default, to block connections to the fully qualified domain ‘ultrasurf.*’, and to allow connections to *.watchguard.com and other domains required for WatchGuard products.
The most effective method to catch the application on any destination is to inspect connections to all domains.
After you check reports and log messages on your Log Server, Report Server or Dimension, you might decide to do inspection on only some categories that could represent a risk of malware download, a data breach or where productivity control is a key factor (for example Facebook Games and other Facebook Applications).
TCP-UDP Proxy Configuration
To protect your network, we recommend that you configure policies to allow outbound traffic on a list of specific outbound ports from specific sources and destinations. If possible, avoid the alias Any-External or Any as a destination in policies. If you have not yet determined all ports and destinations for traffic you want to allow, you can use the TCP-UDP Proxy to allow and inspect outbound TCP and UDP traffic to any external destination. In the TCP-UDP proxy action, you can allow HTTP and HTTPS and deny any unnecessary protocols.
Evasive applications and malware often try to use SSL encryption on a dynamic or nonstandard port as a strategy to bypass the firewall. This traffic would evade the DNS, HTTP, and HTTPS proxies described earlier, because those policies only handle traffic on ports 53, 80, and 443.
The TCP-UDP proxy policy handles TCP and UDP traffic on any port, so it applies to any connections on non-standard ports.
In the example configuration, the TCP-UDP proxy action allows HTTP and HTTPS connections and uses the same proxy actions as the HTTP and HTTPS proxy policies to inspect the traffic. This proxy action denies all protocols other than HTTP and HTTPS.
To test the effectiveness of this configuration against Ultrasurf, we launched Ultrasurf on a client on the trusted network and captured the log messages shown below. To test this configuration, we used these steps:
- Cleared the DNS cache on the Windows client with the ipconfig /flushdns command.
- Tried to browse to ultrasurf.us from the trusted network.
- Launched the Ultrasurf client on the trusted network.
This sequence of log messages was captured from Traffic Monitor.
This log message shows that the DNS proxy denied a DNS query based on the domain name:
2016-12-22 08:16:37 Deny 10.0.100.6 188.8.131.52 dns/udp 58842 53 1-Trusted 0-External ProxyDrop: DNS question match (DNS UDP Proxy-00) DNS-Outgoing.1 proc_id="dns-proxy" rc="594" msg_id="1DFF-000E" proxy_act="DNS-Outgoing.1" rule_name="ultrasurf" query_type="A" question="ultrasurf.us" geo_dst="USA" Traffic
If a user finds another way to install the Ultrasurf client, such as from a USB thumb drive or other source, we can see a similar series of attempts after it runs for the first time. Here is an example of the log message that shows that the HTTPS proxy content inspection feature detected and denied non-valid HTTP traffic:
2016-12-22 08:19:44 Deny 10.0.100.6 184.108.40.206 https/tcp 54131 443 1-Trusted 0-External ProxyDeny: HTTP request version match (HTTPS-proxy STRICT-00) HTTP-Client.Standard.1 proc_id="http-proxy" rc="595" msg_id="1AFF-0019" proxy_act="HTTP-Client.Standard.1" rule_name="Default" line="PRI * HTTP/2.0\x0d\x0a" geo_dst="USA" Traffic
A minute later, the HTTPS Proxy denied a connection because Application Control detected that Ultrasurf is in use. The log message shows the application category, the application name, and the application behavior:
2016-12-22 08:20:28 Deny 10.0.100.6 220.127.116.11 https/tcp 54168 443 1-Trusted 0-External ProxyDeny: HTTP App match (HTTPS-proxy STRICT-00) HTTP-Client.Standard.1 proc_id="http-proxy" rc="595" msg_id="1AFF-002E" proxy_act="HTTP-Client.Standard.1" app_cat_name="Tunnelling and proxy services" app_cat_id="11" app_name="Wujie/UltraSurf" app_id="9" app_beh_name="authority" app_beh_id="1" geo_dst="USA" Traffic
A moment later, the same proxy detected and allowed connections to a different valid cloud server in the Amazon Web Services (AWS) data centers.
2016-12-22 08:26:00Allow 10.0.100.6 18.104.22.168 https/tcp 54383 443 1-Trusted 0-External ProxyInspect: HTTPS domain name match (HTTPS-proxy STRICT-00) HTTPS-Client.Standard.1 proc_id="https-proxy" rc="592" msg_id="2CFF-0003" proxy_act="HTTPS-Client.Standard.1" rule_name="Default" sni="" cn="*.awsstatic.com" ipaddress="22.214.171.124" geo_dst="USA" Traffic
But the proxy detected and prevented the use of Ultrasurf to that destination. We can verify that because the same source ports and destinations are used in both log messages:
2016-12-22 08:26:00Deny 10.0.100.6 126.96.36.199 https/tcp 54383 443 1-Trusted 0-External ProxyDeny: HTTP App match (HTTPS-proxy STRICT-00) HTTP-Client.Standard.1 proc_id="http-proxy" rc="595" msg_id="1AFF-002E" proxy_act="HTTP-Client.Standard.1" app_cat_name="Tunnelling and proxy services" app_cat_id="11" app_name="Wujie/UltraSurf" app_id="9" app_beh_name="authority" app_beh_id="1" geo_dst="USA" Traffic
When the connection fails to reach Amazon’s data centers, we saw these log messages as the Ultrasurf client tried to connect to other Ultrasurf servers located in different data centers:
2016-12-22 08:26:03 Allow 10.0.100.6 188.8.131.52 https/tcp 54385 443 1-Trusted 0-External ProxyInspect: HTTPS domain name match (HTTPS-proxy STRICT-00) HTTPS-Client.Standard.1 proc_id="https-proxy" rc="592" msg_id="2CFF-0003" proxy_act="HTTPS-Client.Standard.1" rule_name="Default" sni="" cn="*.vo.msecnd.net" ipaddress="184.108.40.206" geo_dst="USA" Traffic
2016-12-22 08:26:03 Deny 10.0.100.6 220.127.116.11 https/tcp 54385 443 1-Trusted 0-External ProxyDeny: HTTP App match (HTTPS-proxy STRICT-00) HTTP-Client.Standard.1 proc_id="http-proxy" rc="595" msg_id="1AFF-002E" proxy_act="HTTP-Client.Standard.1" app_cat_name="Tunnelling and proxy services" app_cat_id="11" app_name="Wujie/UltraSurf" app_id="9" app_beh_name="authority" app_beh_id="1" geo_dst="USA" Traffic
The Ultrasurf client continues to try to connect.
These messages show Ultrasurf client connections to Azure and AWS. Application Control in the proxy action denied connections from the Ultrasurf client, even when the destination is allowed.
2016-12-22 08:26:03 Allow 10.0.100.6 18.104.22.168 https/tcp 54385 443 1-Trusted 0-External HTTP request (HTTPS-proxy STRICT-00) HTTP-Client.Standard.1 proc_id="http-proxy" rc="525" msg_id="1AFF-0024" proxy_act="HTTP-Client.Standard.1" op="POST" dstname="rs.azureedge.net" arg="/_cXTxUxhDWm7abAQTjTH3bI3MAKj8xQmmDzxxLEEySSdZUh?id=pl2L8Zw9&pid=R6cU[…]" sent_bytes="1408" rcvd_bytes="0" elapsed_time="0.001722 sec(s)" app_id="9" app_cat_id="11" reputation="-1" geo_dst="USA" Traffic
2016-12-22 08:26:05 Allow 10.0.100.6 22.214.171.124 https/tcp 54386 443 1-Trusted 0-External ProxyInspect: HTTPS domain name match (HTTPS-proxy STRICT-00) HTTPS-Client.Standard.1 proc_id="https-proxy" rc="592" msg_id="2CFF-0003" proxy_act="HTTPS-Client.Standard.1" rule_name="Default" sni="" cn="*.awsstatic.com" ipaddress="126.96.36.199" geo_dst="USA" Traffic
2016-12-22 08:26:05 Deny 10.0.100.6 188.8.131.52 https/tcp 54386 443 1-Trusted 0-External ProxyDeny: HTTP App match (HTTPS-proxy STRICT-00) HTTP-Client.Standard.1 proc_id="http-proxy" rc="595" msg_id="1AFF-002E" proxy_act="HTTP-Client.Standard.1" app_cat_name="Tunnelling and proxy services" app_cat_id="11" app_name="Wujie/UltraSurf" app_id="9" app_beh_name="authority" app_beh_id="1" geo_dst="USA" Traffic
This configuration example shows why it is important to configure a combination of policies and services to fully protect your network.
To block Ultrasurf and similar evasive applications you need:
- WebBlocker to prevent connections to the proxy site where users download the application
- Application Control to detect use of the application if it is installed on a network client
- Well-configured web proxies and policies to inspect all traffic
You can apply the same type of configuration strategies to protect against advanced malware and other evasive applications. To do this you would configure other security services such as APT Blocker, RED, and IPS. Regular monitoring of log messages and reports can help you identify new threats so you can update the configuration as threats and application behaviors evolve.