Usar DNS do Umbrella com um Proxy HTTP

Introdução

Este documento descreve como usar o DNS Umbrella com um proxy HTTP.

Pré-requisitos

Requisitos

Não existem requisitos específicos para este documento.

Componentes Utilizados

As informações neste documento são baseadas no Umbrella Global DNS Service, não para o Secure Web Gateway (SWG).

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.

Informações de Apoio

Um proxy HTTP intercepta o tráfego HTTP/S em uma rede. Em seguida, faz a conexão HTTP/S com o servidor remoto em nome do cliente original, retransmitindo as respostas de volta para esse cliente. A maioria dos proxies HTTP tem a capacidade de bloquear conexões a sites específicos com base em categorização ou conteúdo de segurança, ou de bloquear respostas de servidores remotos que fazem com que o contenha conteúdo indesejável, como malware. 

Há dois métodos principais para redirecionar o tráfego HTTP para um proxy: redirecionamento explícito e redirecionamento transparente. Esses métodos diferentes exigem que etapas diferentes sejam seguidas para que funcionem corretamente em combinação com o Umbrella.

Este artigo discute como um proxy HTTP afeta o comportamento do Umbrella e de cada parte da solução Umbrella e, em seguida, fornece dois conjuntos de etapas para redirecionamento explícito e redirecionamento transparente. 

Este diagrama é um resumo das soluções descritas em mais detalhes:

proxy-umbrella-diagrama.png

Como um proxy HTTP afeta o Umbrella Global DNS Service

Ao interceptar o tráfego HTTP/S, um proxy HTTP lê o cabeçalho Host na solicitação HTTP/S e gera sua própria consulta DNS para esse host. Portanto, é importante levar em consideração o comportamento do proxy ao implantar soluções Umbrella. Em um nível abstrato, isso envolve garantir que as conexões HTTP/S para os endereços IP do Umbrella não sejam redirecionadas para o proxy, mas, em vez disso, enviadas diretamente para o destino pretendido.

Proteção de rede

Ao usar somente a proteção de rede Umbrella, recomenda-se que o próprio proxy HTTP seja configurado para usar o Umbrella diretamente para a resolução DNS ou possa usar um servidor DNS interno que, por sua vez, encaminhe consultas DNS para o Umbrella. O endereço IP externo apropriado pode ser registrado como uma identidade de rede no Umbrella Dashboard. Neste cenário, nenhuma ação adicional é necessária para usar o Umbrella.

Se isso não for possível por algum motivo, e os próprios clientes estiverem usando o Umbrella, as ações detalhadas neste artigo poderão ser tomadas para garantir que a imposição não seja ignorada pelo proxy HTTP.

Cliente de roaming Umbrella

Ao usar o cliente de roaming Umbrella, as consultas DNS da máquina cliente são enviadas diretamente ao Umbrella. No entanto, como um proxy HTTP executa suas próprias consultas DNS, isso torna a aplicação pelo cliente de roaming Umbrella ineficaz. Assim, ao usar o cliente de roaming Umbrella em um ambiente com proxy, as ações detalhadas neste artigo devem ser seguidas.

Dispositivos virtuais e integração com o Ative Diretory

O Virtual Appliance (VA) deve atuar como servidor DNS para máquinas clientes na rede protegida. Como tal, o uso de um proxy HTTP torna sua aplicação ineficaz da mesma maneira que o cliente de roaming. Como tal, as ações detalhadas neste artigo podem ser seguidas para garantir que a aplicação seja eficaz e que a comunicação seja exata.

Além das ações abaixo, é recomendável que o proxy HTTP seja configurado para usar o VA como seu servidor DNS. Isso permite que você defina uma política específica para o proxy para que as consultas do proxy possam ser identificadas. Essa política também permite desativar o registro de consultas originadas do proxy, o que evita a duplicação de consultas em seus relatórios.

Proxies explícitos

A implantação de um proxy explícito envolve a modificação das configurações de proxy do navegador para redirecionar explicitamente o tráfego para um proxy. Isso é feito usando a Política de Grupo no Windows ou, mais comumente, usando um arquivo PAC (Configuração Automática de Proxy). Em ambos os casos, isso faz com que o navegador envie todo o tráfego HTTP diretamente para o proxy, em vez de enviá-lo para o site remoto. Como o navegador sabe que o proxy gera sua própria solicitação DNS, ele não se preocupa em resolver o nome de host do próprio site remoto. Além disso, como mencionado anteriormente, quando a conexão HTTP alcança o proxy, o proxy gera sua própria consulta DNS, que pode receber um resultado diferente do que o cliente obteria. 

Assim, para funcionar corretamente com o Umbrella, duas alterações são necessárias:

1. O cliente deve ser forçado a fazer uma consulta DNS.
2. As conexões HTTP destinadas a endereços IP do Umbrella não devem ir para o proxy, mas diretamente para o Umbrella.

Ambas as alterações podem ser feitas usando-se um arquivo 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";}

Neste exemplo de arquivo PAC, uma consulta DNS é gerada primeiro, com o IP resultante sendo capturado na variável hostIP. Esse endereço IP resultante é então comparado a cada intervalo de endereço IP de guarda-chuva. Se houver uma correspondência, a consulta não será enviada ao proxy, mas sim diretamente. Se não houver correspondência, a solicitação será enviada aos proxies apropriados.

Observe que, para sites que não são bloqueados e, portanto, não são redirecionados para um endereço IP Umbrella, o efeito do uso do arquivo PAC anterior é que o cliente e o proxy fazem uma solicitação DNS para o host remoto. Se o proxy também estiver usando o OpenDNS, isso significa que seus relatórios mostram consultas duplicadas. Se você estiver usando o Virtual Appliance, conforme mencionado anteriormente, isso pode ser explicado pela criação de uma identidade de Rede Interna para o proxy. Se desejar, você pode criar uma política para o proxy que desabilite o registro completamente para ocultar essas solicitações duplicadas.

Note: Se você estiver bloqueando solicitações de HTTP/S de saída no firewall de outras fontes que não o proxy, deverá permitir essas solicitações para os intervalos de IP discutidos anteriormente para permitir que suas máquinas acessem as páginas de bloqueio do Umbrella.

Proxies transparentes

Para um proxy transparente, o tráfego HTTP é roteado novamente para o proxy no nível de rede. Como o cliente não reconhece o proxy, o navegador gera sua própria solicitação DNS. Isso significa que se o proxy também estiver usando o Umbrella, cada solicitação será duplicada. Além disso, a política não é aplicada corretamente, pois o proxy usa a resposta DNS recebida, não o resultado recebido pelo cliente.

Ao contrário do caso explícito do anterior neste artigo, a resolução deste problema não exige que forçamos uma solicitação DNS no cliente, pois isso já está ocorrendo. No entanto, ainda é necessário ignorar o proxy para conexões HTTP para endereços IP Umbrella. O método para fazer isso varia muito dependendo do mecanismo que você está usando para redirecionar o tráfego para o proxy. Em geral, no entanto, isso envolve isentar os intervalos de endereços IP Umbrella de serem redirecionados.

Por exemplo, suponha que o WCCP esteja sendo usado em um Cisco ASA para redirecionar o tráfego para o proxy, usando esta ACL:

access-list wccp-traffic extended permit ip any any 

A ACL wccp-traffic pode ser modificada para negar o redirecionamento para o proxy (ignorando o proxy) para intervalos de IP 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

Note: Essa ACL não foi testada e varia de acordo com a versão do ASA ou do Cisco IOS® que está sendo usada. Certifique-se de que todas as ACLs que você criar sejam apropriadas para sua solução e tenham sido testadas minuciosamente antes de serem implantadas em um ambiente de produção.

Note: Se você estiver bloqueando solicitações de HTTP/S de saída no firewall de outras fontes que não o proxy, deverá permitir essas solicitações para os intervalos de IP discutidos anteriormente para permitir que suas máquinas acessem as páginas de bloqueio do Umbrella.