Introduction
Ce document décrit comment utiliser Umbrella DNS avec un proxy HTTP.
Conditions préalables
Exigences
Aucune exigence spécifique n'est associée à ce document.
Composants utilisés
Les informations contenues dans ce document sont basées sur le service DNS global d'Umbrella, et non sur la passerelle Web sécurisée (SWG).
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.
Informations générales
Un proxy HTTP intercepte le trafic HTTP/S sur un réseau. Ensuite, il établit la connexion HTTP/S avec le serveur distant pour le compte du client d'origine, relayant les réponses à ce client. La plupart des proxys HTTP peuvent bloquer les connexions à des sites spécifiques en fonction de la catégorisation ou du contenu de sécurité, ou bloquer les réponses de serveurs distants qui font contenir du contenu indésirable comme des programmes malveillants.
Il existe deux méthodes principales pour rediriger le trafic HTTP vers un proxy : redirection explicite et redirection transparente. Ces différentes méthodes nécessitent différentes étapes à suivre afin de fonctionner correctement en combinaison avec Umbrella.
Cet article explique comment un proxy HTTP affecte le comportement d'Umbrella et de chaque partie de la solution Umbrella, puis fournit deux ensembles d'étapes pour une redirection explicite et une redirection transparente.
Ce schéma est un résumé des solutions décrites plus en détail :
proxy-umbrella-diagramme.png
Comment un proxy HTTP affecte le service DNS global de l'infrastructure
Lors de l'interception du trafic HTTP/S, un proxy HTTP lit l'en-tête Hôte dans la requête HTTP/S et génère sa propre requête DNS pour cet hôte. Il est donc important de prendre en compte le comportement du proxy lors du déploiement des solutions Umbrella. Au niveau abstrait, cela implique de s'assurer que les connexions HTTP/S aux adresses IP Umbrella ne sont pas redirigées vers le proxy, mais sont plutôt envoyées directement à leur destination prévue.
Protection du réseau
Lorsque vous utilisez uniquement la protection Umbrella Network, il est recommandé que le proxy HTTP lui-même soit configuré pour utiliser directement Umbrella pour la résolution DNS, soit pour utiliser un serveur DNS interne qui, à son tour, transfère les requêtes DNS à Umbrella. L'adresse IP externe appropriée peut être enregistrée en tant qu'identité réseau dans le tableau de bord Umbrella. Dans ce scénario, aucune action supplémentaire n'est requise pour utiliser Umbrella.
Si cela n'est pas possible pour une raison quelconque, et que les clients eux-mêmes utilisent Umbrella, alors les actions détaillées dans cet article peuvent être prises afin de s'assurer que l'application n'est pas contournée par le proxy HTTP.
Client d'itinérance Umbrella
Lorsque vous utilisez le client d'itinérance Umbrella, les requêtes DNS de l'ordinateur client sont envoyées directement à Umbrella. Cependant, étant donné qu’un proxy HTTP effectue ses propres requêtes DNS, cela rend inefficace l’application par le client d’itinérance Umbrella. Par conséquent, lorsque vous utilisez le client d'itinérance Umbrella dans un environnement proxy, les actions détaillées dans cet article doivent être suivies.
Appareils virtuels et intégration à Active Directory
L'appliance virtuelle (VA) est conçue pour servir de serveur DNS pour les ordinateurs clients sur le réseau protégé. Ainsi, l'utilisation d'un proxy HTTP rend son application inefficace de la même manière que le client d'itinérance. Ainsi, les mesures détaillées dans cet article peuvent être suivies afin de s'assurer que l'application est efficace et que les rapports sont exacts.
En plus des actions ci-dessous, il est recommandé que le proxy HTTP soit configuré pour utiliser l'appliance virtuelle en tant que serveur DNS. Cela vous permet de définir une stratégie spécifique au proxy afin que les requêtes du proxy puissent être identifiées. Une telle stratégie vous permet également de désactiver la journalisation pour les requêtes provenant du proxy, ce qui évite d'avoir des requêtes en double dans vos rapports.
Proxies explicites
Le déploiement d'un proxy explicite implique de modifier les paramètres du proxy du navigateur afin de rediriger explicitement le trafic vers un proxy. Pour ce faire, utilisez la stratégie de groupe sous Windows ou, plus généralement, un fichier de configuration automatique de proxy (PAC). Dans les deux cas, le navigateur envoie directement tout le trafic HTTP au proxy, au lieu de l'envoyer au site distant. Comme le navigateur sait que le proxy génère sa propre requête DNS, il ne prend pas la peine de résoudre le nom d'hôte du site distant lui-même. En outre, comme mentionné précédemment, lorsque la connexion HTTP atteint le proxy, le proxy génère sa propre requête DNS, qui peut obtenir un résultat différent de celui obtenu par le client.
Ainsi, afin de fonctionner correctement avec Umbrella, deux changements sont nécessaires :
- Le client doit être forcé à effectuer une requête DNS.
- Les connexions HTTP destinées aux adresses IP Umbrella ne doivent pas aller au proxy, mais directement à Umbrella.
Ces deux modifications peuvent être apportées à l'aide d'un fichier 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";}
Dans cet exemple de fichier PAC, une requête DNS est d'abord générée, l'adresse IP résultante étant capturée dans la variable hostIP. Cette adresse IP résultante est ensuite comparée à chaque plage d'adresses IP Umbrella. S'il y a correspondance, la requête n'est pas envoyée au proxy, mais est envoyée directement. S'il n'y a pas de correspondance, la demande est envoyée aux proxys appropriés.
Notez que, pour les sites qui ne sont pas bloqués et qui ne sont donc pas redirigés vers une adresse IP Umbrella, l'utilisation du fichier PAC précédent a pour effet que le client et le proxy effectuent une requête DNS pour l'hôte distant. Si le proxy utilise également OpenDNS, cela signifie que vos rapports affichent des requêtes en double. Si vous utilisez l'appliance virtuelle, comme mentionné précédemment, cela peut être expliqué en créant une identité réseau interne pour votre proxy. Si vous le souhaitez, vous pouvez également créer une stratégie pour le proxy qui désactive complètement la journalisation afin de masquer ces demandes en double.
Remarque : Si vous bloquez les requêtes HTTP/S sortantes au niveau de votre pare-feu provenant de sources autres que votre proxy, vous devez vous assurer d'autoriser ces requêtes aux plages d'adresses IP mentionnées précédemment afin de permettre à vos machines d'accéder aux pages de blocage Umbrella.
Proxies transparents
Pour un proxy transparent, le trafic HTTP est réacheminé vers le proxy au niveau du réseau. Comme le client ne connaît pas le proxy, le navigateur génère sa propre requête DNS. Cela signifie que si le proxy utilise également Umbrella, chaque requête est dupliquée. En outre, la stratégie n'est pas correctement appliquée car le proxy utilise la réponse DNS qu'il a reçue, et non le résultat que le client a reçu.
Contrairement au cas explicite décrit précédemment dans cet article, la résolution de ce problème ne nécessite pas de forcer une requête DNS sur le client, car cela se produit déjà. Cependant, il est toujours nécessaire de contourner le proxy pour les connexions HTTP aux adresses IP Umbrella. La méthode de cette opération varie considérablement selon le mécanisme que vous utilisez pour rediriger le trafic vers le proxy. En général, cependant, cela implique d'exempter les plages d'adresses IP Umbrella d'être redirigées.
Par exemple, supposons que WCCP est utilisé sur un Cisco ASA pour rediriger le trafic vers le proxy, en utilisant cette liste de contrôle d'accès :
access-list wccp-traffic extended permit ip any any
La liste de contrôle d'accès wccp-traffic peut être modifiée pour refuser la redirection vers le proxy (contournant ainsi le proxy) pour les plages 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
Remarque : Cette liste de contrôle d'accès n'a pas été testée et varie selon la version ASA ou la version Cisco IOS® utilisée. Assurez-vous que toutes les listes de contrôle d'accès que vous créez sont appropriées pour votre solution et ont été testées minutieusement avant d'être déployées dans un environnement de production.
Remarque : Si vous bloquez les requêtes HTTP/S sortantes au niveau de votre pare-feu provenant de sources autres que votre proxy, vous devez vous assurer que vous autorisez ces requêtes aux plages d'adresses IP discutées précédemment afin de permettre à vos machines d'accéder aux pages de blocage Umbrella.