Utilizar Umbrella DNS con un proxy HTTP

Introducción

Este documento describe cómo utilizar Umbrella DNS con un proxy HTTP.

Prerequisites

Requirements

No hay requisitos específicos para este documento.

Componentes Utilizados

La información de este documento se basa en el servicio DNS global de Umbrella, no en el gateway web seguro (SWG).

La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.

Antecedentes

Un proxy HTTP intercepta el tráfico HTTP/S en una red. A continuación, realiza la conexión HTTP/S al servidor remoto en nombre del cliente original y retransmite las respuestas a ese cliente. La mayoría de los proxies HTTP tienen la capacidad de bloquear conexiones a sitios específicos en función de la categorización o el contenido de seguridad, o de bloquear respuestas de servidores remotos que contengan contenido no deseado, como el malware. 

Existen dos métodos principales para redirigir el tráfico HTTP a un proxy: redirección explícita y redirección transparente. Estos diferentes métodos requieren diferentes pasos a seguir para funcionar correctamente en combinación con Umbrella.

Este artículo trata sobre cómo un proxy HTTP afecta al comportamiento de Umbrella y a cada parte de la solución Umbrella y, a continuación, proporciona dos conjuntos de pasos para la redirección explícita y la redirección transparente. 

Este diagrama es un resumen de las soluciones descritas con más detalle:

proxy-umbrella-diagram.png

Cómo Afecta un Proxy HTTP al Servicio Umbrella Global DNS

Al interceptar tráfico HTTP/S, un proxy HTTP lee el encabezado Host en la solicitud HTTP/S y genera su propia consulta DNS para ese host. Por lo tanto, es importante tener en cuenta el comportamiento del proxy al implementar las soluciones de Umbrella. En un nivel abstracto, esto implica asegurarse de que las conexiones HTTP/S a las direcciones IP de Umbrella no se redirijan al proxy, sino que se envíen directamente a su destino previsto.

Protección de red

Cuando se utiliza únicamente la protección de Umbrella Network, se recomienda que el proxy HTTP en sí esté configurado para utilizar Umbrella directamente para la resolución de DNS o puede utilizar un servidor DNS interno que, a su vez, reenvía las consultas DNS a Umbrella. La dirección IP externa adecuada se puede registrar como identidad de red en el panel de Umbrella. En este escenario, no se requiere ninguna acción adicional para utilizar Umbrella.

Si esto no es posible por alguna razón, y los propios clientes utilizan Umbrella, se pueden realizar las acciones detalladas en este artículo para garantizar que el proxy HTTP no omita la aplicación.

Cliente de roaming de Umbrella

Cuando se utiliza el cliente de itinerancia de Umbrella, las consultas DNS del equipo cliente se envían directamente a Umbrella. Sin embargo, dado que un proxy HTTP realiza sus propias consultas DNS, esto hace que la aplicación por parte del cliente de roaming de Umbrella sea ineficaz. Por lo tanto, al utilizar el cliente de roaming de Umbrella en un entorno con proxy, se deben seguir las acciones detalladas en este artículo.

Dispositivos virtuales e integración de Active Directory

El dispositivo virtual (VA) está diseñado para actuar como servidor DNS para las máquinas cliente de la red protegida. Como tal, el uso de un proxy HTTP hace que su aplicación sea ineficaz de la misma manera que el Cliente de roaming. Por lo tanto, se pueden seguir las medidas detalladas en este artículo para garantizar que la aplicación sea eficaz y la presentación de informes sea exacta.

Además de las siguientes acciones, se recomienda que el proxy HTTP se configure para utilizar el VA como su servidor DNS. Esto le permite definir una política específica para el proxy para que las consultas del proxy puedan ser identificadas. Esta directiva también permite deshabilitar el registro de consultas originadas en el proxy, lo que evita que haya consultas duplicadas en los informes.

Proxies explícitos

La implementación de un proxy explícito implica la modificación de la configuración del proxy del navegador para redirigir explícitamente el tráfico a un proxy. Esto se realiza mediante la directiva de grupo de Windows o, más comúnmente, mediante un archivo de configuración automática de proxy (PAC). En cualquier caso, esto hace que el explorador envíe todo el tráfico HTTP directamente al proxy, en lugar de enviarlo al sitio remoto. Dado que el explorador sabe que el proxy genera su propia solicitud DNS, no se molesta en resolver el nombre de host del sitio remoto en sí. Además, como se ha mencionado anteriormente, cuando la conexión HTTP llega al proxy, éste genera su propia consulta DNS, a la que se le puede dar un resultado diferente del que obtendría el cliente. 

Por lo tanto, para funcionar correctamente con Umbrella, se necesitan dos cambios:

1. Se debe forzar al cliente a realizar una consulta DNS.
2. Las conexiones HTTP destinadas a las direcciones IP de Umbrella no deben dirigirse al proxy, sino directamente a Umbrella.

Ambos cambios se pueden realizar mediante un archivo PAC:

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";}

En este archivo PAC de ejemplo, primero se genera una consulta DNS, y la IP resultante se captura en la variable hostIP. Esta dirección IP resultante se compara con cada intervalo de direcciones IP de Umbrella. Si hay una coincidencia, la consulta no se envía al proxy, sino que se envía directamente. Si no hay ninguna coincidencia, la solicitud se envía a los proxies apropiados.

Tenga en cuenta que, para los sitios que no están bloqueados y que, por lo tanto, no se redirigen a una dirección IP de Umbrella, el efecto de utilizar el archivo PAC anterior es que tanto el cliente como el proxy realizan una solicitud DNS para el host remoto. Si el proxy también está utilizando OpenDNS, esto significa que sus informes muestran consultas duplicadas. Si utiliza el dispositivo virtual, como se ha mencionado anteriormente, esto se puede tener en cuenta creando una identidad de red interna para el proxy. Si lo desea, puede crear además una política para el proxy que inhabilite completamente el registro para ocultar estas solicitudes duplicadas.

Nota: Si está bloqueando las solicitudes HTTP/S salientes en su firewall de orígenes que no sean su proxy, debe asegurarse de permitir estas solicitudes a los rangos de IP descritos anteriormente para permitir que sus equipos accedan a las páginas de bloqueo de Umbrella.

Proxies transparentes

Para un proxy transparente, el tráfico HTTP se redirige al proxy en el nivel de red. Dado que el cliente desconoce el proxy, el explorador genera su propia solicitud DNS. Esto significa que si el proxy también utiliza Umbrella, cada solicitud se duplica. Además, la política no se aplica correctamente, ya que el proxy utiliza la respuesta DNS que ha recibido, no el resultado que ha recibido el cliente.

A diferencia del caso explícito anterior en este artículo, para resolver este problema no es necesario forzar una solicitud DNS en el cliente, ya que esto ya está ocurriendo. Sin embargo, sigue siendo necesario omitir el proxy para las conexiones HTTP a las direcciones IP de Umbrella. El método para hacer esto varía ampliamente dependiendo del mecanismo que esté utilizando para redirigir el tráfico al proxy. En general, sin embargo, implica eximir los rangos de direcciones IP de Umbrella de ser redirigidos.

Por ejemplo, suponga que se está utilizando WCCP en un Cisco ASA para redirigir el tráfico al proxy, utilizando esta ACL:

access-list wccp-traffic extended permit ip any any 

La ACL de tráfico wccp se puede modificar para denegar la redirección al proxy (omitiendo así el proxy) para los rangos de IP de Umbrella:

access-list wccp-traffic extended deny ip any 67.215.64.0 255.255.224.0access-list wccp-traffic extended deny ip any 204.194.232.0 255.255.248.0access-list wccp-traffic extended deny ip any 208.67.216.0 255.255.248.0access-list wccp-traffic extended deny ip any 208.69.32.0 255.255.248.0access-list wccp-traffic extended deny ip any 185.60.84.0 255.255.252.0access-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

Nota: Esta ACL no se ha probado y varía según la versión de ASA o la versión de Cisco IOS® que se utilice. Asegúrese de que todas las ACL que cree sean adecuadas para su solución y de que se hayan probado exhaustivamente antes de implementarlas en un entorno de producción.

Nota: Si está bloqueando las solicitudes HTTP/S salientes en su firewall de fuentes que no sean su proxy, debe asegurarse de permitir estas solicitudes a los rangos de IP anteriormente mencionados para permitir que sus equipos accedan a las páginas de bloqueo de Umbrella.