browse
Overview
This article only applicable for Umbrella Global DNS Service not for Secure Web Gateway (SWG)
An HTTP proxy intercepts HTTP/S traffic on a network, and then makes the HTTP/S connection to the remote server on behalf of the original client, relaying the responses back to that client. Most HTTP proxies have the ability to block connections to specific sites based on categorization or security content, or to block responses from remote servers that make contain undesirable content (e.g. malware).
There are two primary methods for redirecting HTTP traffic to a proxy: explicit redirection and transparent redirection. These different methods require different steps to be taken in order to function properly in combination with Umbrella.
This article will first cover how an HTTP proxy affects the behavior of Umbrella and each portion of the Umbrella solution and then provide two sets of steps for explicit redirection and transparent redirection.
This diagram is a summary of the solutions outlined in more detail:
How an HTTP proxy affects Umbrella's Global DNS Service
When intercepting HTTP/S traffic, an HTTP proxy will read the "Host" header in the HTTP/S request, and generate its own DNS query for that host. Thus, it is important to take the proxy's behaviour into consideration when deploying Umbrella solutions. At an abstract level, this involves ensuring that HTTP/S connections to Umbrella IP addresses are not redirected to the proxy, but are instead sent directly to their intended destination.
Network protection
When using only Umbrella Network protection, it is recommended that the HTTP proxy itself is configured to either use Umbrella directly for DNS resolution, or it should use an internal DNS server which in turn forwards DNS queries to Umbrella. The appropriate external IP address should be registered as a Network identity in the Umbrella Dashboard. In this scenario, no additional action should be required in order to use Umbrella.
If this is not possible for some reason, and clients themselves are using Umbrella, then the actions detailed in this article should be taken in order to ensure that enforcement is not bypassed by the HTTP proxy.
Umbrella Roaming Client
When using the Umbrella roaming client, DNS queries from the client machine are sent directly to Umbrella. However, since an HTTP proxy will perform its own DNS queries, this renders enforcement by the Umbrella roaming client ineffective. Thus, when using the Umbrella roaming client in a proxied environment, the actions detailed in this article should be followed.
Virtual Appliances and Active Directory Integration
The Virtual Appliance (VA) is intended to act as the DNS server for client machines on the protected network. As such, the use of an HTTP proxy will render its enforcement ineffective in the same manner as the Roaming Client. As such, the actions detailed in this article should be followed in order to ensure that enforcement is effective and reporting is accurate.
In addition to the actions below, it is recommended that the HTTP proxy be configured to use the VA as its DNS server. This allows you to define a policy specific to the proxy so that queries from the proxy can be identified. Such a policy also allows you to disable logging for queries originating from the proxy, which will avoid have duplicate queries in your reports.
Explicit Proxies
Deploying an explicit proxy entails modifying the browser proxy settings in order to explicitly redirect traffic to a proxy. This is done either by using Group Policy in Windows, or more commonly, by using a Proxy Auto-Configuration (PAC) file (http://en.wikipedia.org/wiki/Proxy_auto-config). In either case, this causes the browser to send all HTTP traffic directly to the proxy, instead of sending it to the remote site. Because the browser knows that the proxy will generate its own DNS request, it does not bother to resolve the hostname of the remote site itself. Additionally, as mentioned above, when the HTTP connection reaches the proxy, the proxy will generate its own DNS query, which may be given a different result than the client would get.
Thus, in order to function properly with Umbrella, two changes are needed:
- The client must be forced to make a DNS query.
- HTTP connections destined to Umbrella IP addresses must not go to the proxy, but rather go directly to Umbrella.
Both of these changes can be accomplished using a PAC file:
function FindProxyForURL(url, host) {
// Generate DNS request on the client
hostIP = dnsResolve(host);
// If the requested website is using an Umbrella IP address, return DIRECT
if (isInNet(hostIP, "67.215.64.0", "255.255.224.0") ||
isInNet(hostIP, "204.194.232.0", "255.255.248.0") ||
isInNet(hostIP, "208.67.216.0", "255.255.248.0") ||
isInNet(hostIP, "208.69.32.0", "255.255.248.0") ||
isInNet(hostIP, "185.60.84.0", "255.255.252.0") ||
isInNet(hostIP, "155.190.0.0", "255.255.0.0") ||
isInNet(hostIP, "146.112.0.0", "255.255.0.0")) ||
isInNet(hostIP, "151.186.0.0", "255.255.0.0"))
{
return "DIRECT";
}
// DEFAULT RULE: All other traffic, use below proxies, in fail-over order.
return "PROXY 192.0.2.5:8080; PROXY 192.0.2.6:8080";
}
In the sample PAC file above, a DNS query is first generated, with the resulting IP being captured in the "hostIP" variable. This resulting IP address is then compared to eachUmbrella IP address range. If there is a match, then the query is NOT sent to the proxy, but instead is sent directly out. If there is not a match, then the request is sent to the appropriate proxies.
Note that, for sites that are not blocked and thus do not get redirected to an Umbrella IP address, the effect of using the above PAC file is that both the client AND the proxy will make a DNS request for the remote host. If the proxy is also using OpenDNS, this means that your reports will show duplicate queries. If you are using the Virtual Appliance, as mentioned above, this can be accounted for by creating an Internal Network identity for your proxy. If so desired, you can additionally create a policy for the proxy which disables logging completely in order to hide these duplicate requests.
NOTE: If you are blocking outbound HTTP/S requests at your firewall from sources other than your proxy, you will need to ensure that you allow these requests to the above IP ranges in order to allow your machines to access the Umbrella block pages.
Transparent Proxies
For a transparent proxy, HTTP traffic is rerouted to the proxy at the network level. Because the client is unaware of the proxy, the browser will generate its own DNS request. This means that, if the proxy is also using Umbrella,then each request will be duplicated. Additionally, policy may not be properly applied as the proxy will use the DNS response that it received, not the result the client received.
Unlike the explicit case above, resolving this issue does not require us to force a DNS request on the client, as that is already occurring. However, bypassing the proxy for HTTP connections to Umbrella IP addresses is still required. The method for doing this varies widely depending on what mechanism you are using to redirect traffic to the proxy. In general, however, it involves exempting the Umbrella IP address ranges from being redirected.
For example, suppose WCCP is being used on a Cisco ASA to redirect traffic to the proxy, using the following ACL:
access-list wccp-traffic extended permit ip any any
The "wccp-traffic" ACL could be modified to deny redirection to the proxy (thus bypassing the proxy) for UmbrellaIP ranges:
access-list wccp-traffic extended deny ip any 67.215.64.0 255.255.224.0 access-list wccp-traffic extended deny ip any 204.194.232.0 255.255.248.0 access-list wccp-traffic extended deny ip any 208.67.216.0 255.255.248.0 access-list wccp-traffic extended deny ip any 208.69.32.0 255.255.248.0 access-list wccp-traffic extended deny ip any 185.60.84.0 255.255.252.0 access-list wccp-traffic extended deny ip any 146.112.0.0 255.255.0.0
access-list wccp-traffic extended deny ip any 155.190.0.0 255.255.0.0
access-list wccp-traffic extended deny ip any 151.186.0.0 255.255.0.0
access-list wccp-traffic extended permit ip any any
NOTE: The above ACL has not been tested and may vary depending on the ASA version or IOS version being used. Please ensure that any ACLs you create are appropriate for your solution, and have been thoroughly tested prior to being deployed in a production environment.
NOTE: If you are blocking outbound HTTP/S requests at your firewall from sources other than your proxy, you will need to ensure that you allow these requests to the above IP ranges in order to allow your machines to access the Umbrella block pages.