Partager via

Microsoft Forefront

  • Article

Utilisation de Microsoft Forefront TMG 2010 comme passerelle Web sécurisée

Yuri Diogenes, Jim Harrison et Mohit Saxena

Lorsqu'une entreprise établit une stratégie de sécurité, l'un des principaux objectifs consiste à permettre aux employés de pouvoir naviguer sur Internet en toute sécurité. Bien entendu, cela couvre de nombreux aspects et exigences, tels que :

  • s'assurer que les utilisateurs respectent la stratégie de l'entreprise relative à l'accès à Internet ;
  • inspecter le trafic et bloquer les activités suspectes et logiciels potentiellement malveillants ;
  • faire prendre conscience aux utilisateurs finaux que leur trafic Web est inspecté.

Fort heureusement, les fonctionnalités de passerelle Web sécurisée offertes par Microsoft Forefront Threat Management Gateway (TMG) 2010 peuvent aider à atteindre ces objectifs. La figure 1 illustre les principales fonctionnalités de Forefront TMG 2010 auxquelles vous pouvez faire appel pour implémenter une passerelle d'accès Web sécurisée :

 

 

Figure 1 Principales fonctionnalités de Forefront TMG 2010 pour un scénario de passerelle Web sécurisée

Comme vous pouvez le voir, Forefront TMG utilise trois principaux composants du nuage : Microsoft Update, le service de télémétrie et Microsoft Reputation Service (MRS). Microsoft Update permet de maintenir les signatures anti-logiciel malveillant et NIS (Network Inspection System) à jour. L'équipe Microsoft de réponse aux logiciels malveillants utilise les rapports de télémétrie fournis par TMG pour en savoir plus sur les attaques détectées et ainsi améliorer la qualité des signatures. MRS maintient une énorme base de données d'URL classées qui peut être interrogée par TMG 2010.

Dans cet article, nous allons étudier le filtrage d'URL et l'inspection HTTPS. Nous avons traité en détail l'inspection des logiciels malveillants dans notre précédent  article de TechNet Magazine en février 2009, et cette fonctionnalité n'a pas changé dans Forefront TMG 2010.

Utilisation du filtrage d'URL pour une navigation plus sécurisée

Le filtrage d'URL peut être considéré comme la première ligne de défense de Forefront TMG pour ce qui est de la sécurisation de l'accès Web au sein de votre organisation. Grâce à l'utilisation du filtrage URL pour bloquer les demandes de sites Web indésirables, Forefront TMG consacre moins de temps à rechercher et analyser les logiciels malveillants et davantage de temps à délivrer du contenu utile.

Le filtrage d'URL fait appel à deux composants principaux : le filtre de proxy Web, qui évalue les demandes Web, et MRS, qui fournit les définitions de catégories à partir desquelles le filtre détermine la façon dont une demande doit être classée. Voici une forme simplifiée du processus qui a lieu pour une demande Web :

  1. L'application Web envoie une demande pour « http://malware.contoso.com/nefarious » par le biais de TMG.

  2. Le filtre de proxy Web passe la demande à travers le filtrage d'URL.

  3. Le filtrage d'URL fractionne la demande entière en différents segments. Dans notre exemple, il pourrait s'agir des segments suivants :

    • Com
    • Contoso.com
    • Malware.contoso.com
    • Malware.contoso.com/nefarious

  4. Le filtrage d'URL recherche chaque segment dans le cache de catégories d'URL local.

    Remarque : si aucune correspondance ne peut être établie entre la demande et une catégorie d'URL dans le cache local, le filtrage d'URL interroge MRS. Si ce dernier retourne « inconnu » ou si MRS est injoignable, le filtrage d'URL retourne une réponse « inconnu » au filtre de proxy Web.

  5. Une fois que le filtrage d'URL connaît la catégorie associée à chaque segment d'URL, il détermine la catégorie applicable à l'URL entière. Pour cela, TMG utilise une liste de précédence prédéfinie fournie par MRS, qui lui permet de savoir quelles catégories prévalent sur d'autres. Par exemple :

    • Com = Inconnu
    • Contoso.com = Activité commerciale générale
    • Malware.contoso.com = Malveillant
    • Malware.contoso.com/nefarious = Inconnu Dans cet exemple, deux catégories sont identifiées : Activité commerciale générale et Malveillant. Selon la liste de précédence prédéfinie, Malveillant est prioritaire par rapport à Activité commerciale générale ; en conséquence, l'URL entière sera désignée comme Malveillant.

  6. Si la catégorie d'URL résultante correspond à une règle de refus, la demande est rejetée et une réponse d'erreur est retournée à l'application Web.

  7. Si la catégorie d'URL ne correspond à aucune règle de refus et correspond à une règle d'autorisation, la demande est remplie conformément aux critères restants de la règle correspondante.

  8. Si la demande ne correspond à aucune règle de refus ou d'autorisation créée par l'utilisateur, le traitement de règle TMG se rabat sur la règle de refus par défaut et retourne une réponse de refus à l'application Web.

Les utilisateurs présentant, statistiquement, des habitudes dans leur utilisation du Web, le cache de catégories d'URL assumera davantage de pertinence au fil du temps, à mesure que TMG traitera les demandes des utilisateurs. De cette façon, le rapport requêtes MRS/demandes utilisateur finira par diminuer. Les catégories d'URL étant susceptibles de changer, MRS assigne une durée de vie à chaque entrée. Ainsi, le nombre de demandes MRS n'atteindra jamais zéro, même si vos utilisateurs accèdent toujours aux mêmes sites.

Pour bien comprendre le fonctionnement du filtrage d'URL, il faut également comprendre la façon dont les applications créent des connexions et émettent des demandes. On peut généralement répartir les applications en deux catégories : celles qui sont configurées pour agir comme clients de proxy Web, et celles qui ne le sont pas.

  • Proxy Web (CERN) : Ce type d'application Web est configuré de sorte qu'il connaisse un proxy Web et soit en mesure de se comporter en conséquence. L'application Web se connecte à un écouteur de proxy Web et émet des demandes d'une forme spécifique :
  • HTTP :
METHOD http://website.contoso.com/path/page.aspx?querystring HTTP/1.x
METHOD http://1.2.3.4/path/page.aspx?querystring HTTP/1.x

Dans ce cas, Forefront TMG, et par conséquent le filtrage d'URL, dispose de l'URL complète afin de la comparer à celles figurant dans la base de données de filtrage d'URL.

Remarque : METHOD peut être toute méthode HTTP valide, telles que GET, POST et ainsi de suite.

  • HTTPS :
CONNECT website.contoso.com:443 HTTP/1.x
CONNECT 1.2.3.4:666 HTTP/1.x

Pour ces demandes, Forefront TMG et le filtrage d'URL ne disposent que du nom d'hôte ou de l'adresse IP (selon la façon dont le client émet la demande) et du port à des fins de comparaison avec les URL de la base de données de filtrage.

  • Proxy non-Web : Lorsque l'application Web n'est pas configurée pour agir comme client proxy CERN, elle tente de résoudre le nom du site Web en une adresse IP et, en cas de succès, tente de se connecter à cette adresse IP à l'aide du port qui faisait partie de l'URL d'origine, quel qu'il soit. Que le client soit un client TMG (anciennement appelé client de pare-feu) ou un client SecureNET (également appelé client SecureNAT), la demande sera envoyée au format suivant :
METHOD /path/page.aspx?querystring HTTP/1.x

Dans ce cas, la capacité du filtrage d'URL à évaluer la demande dépend de deux critères :

  • La connexion est-elle dirigée vers le port HTTP par défaut ? Si c'est le cas, le proxy Web peut être en mesure d'intercepter cette demande et de la passer au filtrage d'URL à des fins de comparaison. Dans le cas contraire, la demande ne sera pas détectée par le filtrage d'URL et ne pourra donc pas être comparée à celles de la base de données.
  • Si la connexion est dirigée vers le port HTTPS par défaut, l'inspection HTTPS est-elle activée ? Si c'est le cas, l'inspection HTTPS peut jouer le rôle de pont pour la connexion, et le filtrage d'URL aura une opportunité de comparer la demande aux URL de la base de données.

Ce qui peut ne pas sembler évident de prime abord est le fait que le filtrage d'URL, en lui-même, ne procure aucune forme de mécanisme de blocage ; il répond simplement au proxy Web avec les catégories associées à l'URL demandée tel que le proxy Web (et donc le filtrage d'URL) la comprend. Dans tous les cas, lorsque le filtrage d'URL reçoit une demande d'un client, il procède comme illustré à la figure 2.

 

Figure 2 Flux de base du filtrage d'URL

Si Forefront TMG doit interroger MRS, une demande est effectuée à l'aide d'un appel de Services Web unique au portail de services Web MRS. MRS traite les données présentées par Forefront TMG et répond avec les catégories d'URL actuelles applicables aux données reçues par MRS. Forefront TMG 2010 a un ensemble de domaines prédéfini qui inclut les destinations de portail en vigueur lors de la publication de Forefront TMG (voir figure 3).

 

Figure 3 Ensemble de domaines MRS

Si les catégories d'URL retournées par le filtrage d'URL figurent dans une règle de refus, Forefront TMG envoie une réponse de refus (code de résultat HTTP 502) au client. Selon que le client est un navigateur ou une autre application Web, l'utilisateur peut recevoir la page de réponse Forefront TMG ; dans le cas d'une application non-navigateur (telle que le Lecteur Windows Media ou une application FTP de proxy CERN), il se peut que l'utilisateur reçoive uniquement un message d'erreur de la part de l'application proprement dite.

La tâche la plus coûteuse que doit effectuer Forefront TMG afin de déterminer la catégorie d'URL étant d'interroger MRS, ce processus est beaucoup moins onéreux en termes de ressources de processeur, de mémoire et de réseau que de laisser l'utilisateur joindre le site Web et d'avoir ensuite à effectuer une analyse anti-logiciel malveillant sur tout le contenu qu'il demande.

Contrôle du canal chiffré à l'aide de l'inspection HTTPS

On conseille depuis de nombreuses années aux utilisateurs d'utiliser le protocole HTTP avec SSL (HTTPS) pour effectuer une transaction en ligne sécurisée. Néanmoins, ce canal sécurisé est également employé à des fins malveillantes. Lorsque des utilisateurs commencent une transaction à l'aide du protocole HTTPS, ce trafic est normalement chiffré de bout en bout (de l'utilisateur au serveur de destination), ce qui rend le contenu échangé entre les deux parties illisible pour tout périphérique situé entre les deux. Bien que ce comportement soit souhaitable, puisqu'il ne faut pas que quelqu'un puisse consulter votre transaction de carte bleue en ligne, l'inconvénient est qu'aucune opération malveillante sur ce canal ne peut être évaluée. La figure 4 illustre les principales phases de cette opération à l'aide d'ISA Server 2006 comme pare-feu.

 

Figure 4 Scénario HTTPS traditionnel

La figure 4 illustre un scénario de proxy dans lequel le client accède à un site HTTPS. Les étapes résumées sont divisées en deux phases principales, comme décrit ci-dessous :

Phase 1 – Tunnel SSL

  1. Le client se connecte au proxy Web.
  2. Le client émet une demande de tunnel SSL : CONNECT malicious.contoso.com:443 HTTP/1.1.
  3. Le proxy Web résout malicious.contoso.com en adresse IP 1.2.3.4.
  4. Le proxy Web se connecte à 1.2.3.4 sur le port TCP 443.
  5. Le proxy Web envoie « 200 OK » au client.

Phase 2 – Conversation chiffrée

  1. Le client et le serveur Web échangent des messages de négociation SSL, des clés de chiffrement et des certificats.
  2. Le client dispose maintenant d'un tunnel chiffré de bout en bout jusqu'au serveur de destination, et il peut initier le trafic envoi-réception à travers ce tunnel.
  3. ISA Server conserve ce tunnel ouvert entre le client et le serveur mais il n'inspecte pas le trafic car il n'en a pas la capacité.

Le risque potentiel présenté par ce scénario est qu'à la phase 2, le pare-feu de périphérie n'a aucune connaissance de ce qui est réellement transmis sur ce canal. Dans un scénario où le serveur de destination est piraté et où du code malveillant est inséré, il existe un risque que le serveur de destination envoie un logiciel malveillant par le biais de ce canal chiffré, que le client recevra sans hésitation car il proviendra d'une connexion supposément approuvée.

La fonctionnalité d'inspection HTTPS de Forefront TMG réduit cette menace en inspectant le trafic et en maintenant des canaux chiffrés distincts avec l'utilisateur et le serveur. La figure 5 illustre comment Forefront TMG procède.

 

Figure 5 L'inspection HTTPS en action

Les étapes résumées sont encore divisées en deux phases principales ; en revanche, le processus inclut maintenant l'inspection :

Phase 1 – Demande du client

  1. Le client se connecte à l'écouteur de proxy Web TMG.
  2. Le client émet une demande de tunnel SSL : CONNECT malicious.contoso.com:443 HTTP/1.1.
  3. TMG résout malicious.contoso.com en adresse IP 1.2.3.4.
  4. TMG se connecte à 1.2.3.4 sur le port TCP 443.
  5. TMG négocie une connexion SSL avec le serveur et évalue le certificat.
  6. Si le certificat est valide et approuvé, TMG répond « 200 OK » au client.

Phase 2 – Conversation chiffrée avec inspection

  1. Le client et TMG échangent des messages de négociation SSL, des clés de chiffrement et des certificats. Notez que du fait que TMG crée un certificat de serveur à l'aide d'informations dérivées du certificat de serveur Web, le client croit qu'il communique avec le serveur Web.

  2. Le client dispose maintenant d'un tunnel chiffré avec Forefront TMG et Forefront TMG dispose d'un tunnel chiffré avec le serveur de destination. Forefront TMG sera en mesure d'inspecter tout le trafic envoyé entre le client et le serveur en suivant cette séquence :

    a)     TMG reçoit et déchiffre le trafic chiffré en provenance du serveur de destination.

    b)     TMG applique l'inspection de logiciel malveillant et les filtres NIS au trafic.

    c)      Si l'inspection de logiciel malveillant et les filtres NIS le permettent, TMG chiffre les résultats et les envoie à la station de travail cliente.

    d)     Le client reçoit, déchiffre et traite le trafic.

Pour établir la négociation SSL avec le client, Forefront TMG a besoin d'un certificat de serveur. Pour le créer, Forefront TMG crée un faux certificat basé sur les données de certificat de serveur d'origine et le signe avec le certificat d'Autorité de certification d'inspection HTTPS. Pour garantir des performances maximales, Forefront TMG conserve un cache de certificats de serveur dupliqués. TMG recherche un certificat de serveur dupliqué dans le cache local et, s'il n'en trouve aucun, il duplique le certificat de serveur en amont et le place dans le cache. Le cache est stocké uniquement en mémoire. Ainsi, le cache de faux certificats est vide après le redémarrage du service Pare-feu.

Remarque : la taille du cache (le nombre de certificats) est contrôlée par la propriété COM LowLevelSettings.ClonedCertificatesCacheSize COM.

Options d'inspection HTTPS

Avant de configurer l'inspection HTTPS, il est important de bien comprendre l'ensemble des fonctionnalités et options qui la composent. La figure 6 indique les domaines dans lesquels l'inspection HTTPS peut être configurée.

 

Figure 6 Ensemble de fonctionnalités de l'inspection HTTPS

Lors de la planification de votre implémentation d'inspection HTTPS, vous devez tout d'abord prendre en considération les paramètres de certificats, afin de décider si vous utiliserez un certificat auto-signé ou un certificat émis par une Autorité de certification interne. Lors de l'importation d'une Autorité de certification de confiance, il vous faut un fichier PFX qui contient le certificat de l'autorité et sa clé privée. Cette clé privée est nécessaire pour signer le faux certificat émis par TMG. Vous devez également vous assurer que l'utilisation de la clé du certificat est configurée pour la signature de certificat. Ce certificat d'Autorité de certification doit ensuite être déployé sur les ordinateurs clients (sous « Autorités de certification racines de confiance » dans le magasin de certificats de l'ordinateur local), sinon le client n'approuvera pas le certificat de serveur envoyé par TMG.

Sur Forefront TMG, l'inspection HTTPS peut être activée par le biais de la stratégie d'accès au Web. Pour activer cette fonctionnalité, procédez comme suit :

  1. Dans la console de Forefront TMG, cliquez sur Stratégie d'accès au Web et sélectionnez Configurer l'inspection HTTPS sous Tâche de protection Web dans le volet Tâches.
  2. Sous l'onglet Général de l'écran Inspection sortante HTTPS, activez la case à cocher Activer l'inspection HTTPS comme illustré à la figure 7.

 

Figure 7 Activation de l'inspection HTTPS

Pour cet exemple, nous utiliserons un certificat auto-signé Forefront TMG. Cliquez sur Générer ; une page semblable à celle de la figure 8 s'affiche.

 

Figure 8 Fenêtre Générer un certificat

  1. Dans la page Générer un certificat, spécifiez le nom de l'émetteur, la date d'expiration et la déclaration de l'émetteur en fonction des besoins de votre entreprise, puis cliquez sur Générer le certificat.
  2. Un nouveau certificat est généré et la page Certificat s'affiche. Vérifiez la configuration du certificat et cliquez sur Fermer.
  3. Cliquez sur OK pour fermer la fenêtre.
  4. Dans la fenêtre Inspection HTTPS sortante, cliquez sur le bouton Options de certificat d'autorité de certification racine de confiance d'inspection HTTPS. La fenêtre Options de déploiement de certificat s'affiche, comme illustré à la figure 9.

 

Figure 9 Choix du mode de déploiement de certificat

  1. Si TMG appartient à un domaine, le mode de déploiement recommandé est « Automatiquement par le biais d'Active Directory ». Lorsque vous choisissez cette option, le certificat d'Autorité de certification TMG est déployé automatiquement sur les ordinateurs clients à l'aide de la stratégie de groupe. Cliquez sur le bouton Informations d'identification d'administrateur de domaine et tapez les informations d'identification qui seront utilisées pour cette opération. Cliquez sur OK. Notez qu'il ne faut pas inclure le domaine dans le champ de nom d'utilisateur.
  2. Étant donné que Forefront TMG fait appel à l'outil certutil pour publier le certificat d'Autorité de certification TMG dans Active Directory, il se peut que vous constatiez le bref affichage d'une fenêtre d'invite de commandes. Cliquez sur OK dans la boîte de message « Le déploiement du certificat automatique a réussi »et sur OK dans la fenêtre Options de déploiement de certificat.
  3. Cliquez sur OK pour terminer.

Important : en plus de satisfaire aux exigences de sécurité de votre organisation, vous devez également évaluer les réglementations juridiques et en matière de conformité avant d'activer l'inspection HTTPS. Tout site où l'inspection HTTPS est jugée inappropriée peut être ajouté à la liste d'exceptions.

Expérience utilisateur améliorée

L'inspection HTTPS et le filtrage d'URL dans Forefront TMG aident non seulement à fournir un environnement de navigation protégé pour les utilisateurs finaux, mais ils offrent également des fonctionnalités qui améliorent l'expérience des utilisateurs finaux grâce à des messages d'information et des messages d'erreur précis ou personnalisés compréhensibles par l'utilisateur final.  

Notification du client HTTPS

Pour rester en conformité avec les stratégies de confidentialité de l'entreprise, vous pouvez activer la notification côté client afin d'avertir l'utilisateur lorsqu'un site SSL est inspecté et lui donner la possibilité de quitter le site afin de protéger des informations qu'il juge personnelles ou confidentielles. Ce comportement est illustré par la figure 10.

 

Figure 10 Notification côté client de l'inspection HTTPS

Pour que l'utilisateur puisse recevoir des notifications d'inspection HTTPS, le client Forefront TMG doit être installé sur l'ordinateur client et l'Autorité de certification racine de confiance d'inspection HTTPS doit être installée dans le magasin Autorités de certification racines de confiance de l'ordinateur local. N'oubliez pas que si vous avez une configuration TMG en amont et en aval, les notifications HTTPS doivent être activées sur le proxy en aval plutôt que sur le proxy en amont.

Pour implémenter les notifications d'inspection HTTPS côté client, vous devez les activer à la fois sur le serveur et sur le client Forefront TMG. Pour activer les notifications d'inspection HTTPS sur le serveur

  1. Dans la console de gestion de Forefront TMG, cliquez sur Stratégie d'accès au Web.
  2. Sous Tâches dans le volet droit, cliquez sur Configurer l'inspection HTTPS.
  3. Sous l'onglet Notification du client, cliquez sur Signaler aux utilisateurs que le contenu HTTPS est inspecté, puis cliquez sur OK.

Pour activer les notifications sur le client Forefront TMG

  1. Cliquez avec le bouton droit sur l'icône de client Forefront TMG dans la barre d'état système, puis cliquez sur Configurer.
  2. Sous l'onglet Inspection des connexions sécurisées, sélectionnez M'avertir lorsque le contenu envoyé à des sites Web sécurisés est inspecté, puis cliquez sur OK.

Messages d'erreur de filtrage d'URL

Un administrateur peut autoriser ou refuser l'accès au Web aux utilisateurs finaux en fonction des catégories d'URL. Si un utilisateur essaie d'accéder à un site auquel l'accès a été refusé, une page d'erreur telle que celle de la figure 11 s'affiche et signale que l'accès au site a été refusé car il a été classé comme tel par l'administrateur de Forefront TMG.

 

Figure 11 Page Web d'accès refusé

Le message d'erreur peut être personnalisé par l'administrateur de TMG. Pour ce faire :

  1. Ouvrez la console de gestion de Forefront TMG et cliquez sur Stratégie d'accès au Web.
  2. Double-cliquez sur la règle d'autorisation ou de refus d'accès créée par l'administrateur afin de l'ouvrir.
  3. Cliquez sur l'onglet Action comme illustré à la figure 12.

 

Figure 12 Personnalisation d'un message d'erreur de filtrage d'URL

Vous pouvez afficher n'importe quel message personnalisé à la zone de texte Afficher une notification de refus à l'utilisateur. Vous pouvez même utiliser du contenu HTML, à condition que le code HTML soit valide dans le contexte d'un élément <body> HTML, mais vous ne pouvez pas inclure de script.

Vous pouvez également choisir d'afficher la catégorie sous laquelle l'accès au site a été refusé. Pour cela, activez la case à cocher Ajouter la catégorie de refus de demande à la notification. Ceci est particulièrement utile si un site est mal classé ; l'utilisateur final pourra ainsi vous le faire savoir. À votre tour, vous pouvez envoyer ce retour d'informations à Microsoft par le biais de la télémétrie, et en même temps configurer une catégorie de substitution afin de rectifier le classement jusqu'à ce qu'il soit corrigé de manière définitive.

Si vous souhaitez modifier l'apparence de la page de message d'erreur de filtrage d'URL entière, vous devez modifier la page HTML 12232.htm. Vous trouverez des informations à ce sujet dans la page Personnalisation de la page de refus sur Forefront TMG 2010 du blog de l'équipe de produit Forefront TMG (ISA Server).

Jim Harrison a rejoint l'équipe ISA Server Sustained Engineering en qualité de testeur QFE en janvier 2003. Il est aujourd'hui responsable de programme auprès de Forefront Edge CS et un ardent implémenteur système et supporter d'ISA Server, ainsi que co-auteur de la page de communauté Forefront intitulée « Tales from the Edge ».

**Yuri Diogenes  *** *travaille chez Microsoft comme ingénieur technicien spécialisé dans le support de sécurité au sein de l'équipe ISA Server/IAG. Il est co-auteur de la page de communauté Forefront intitulée « Tales from the Edge ».

**Mohit Saxena  *** *est responsable technique au sein de l'équipe de support Microsoft ISA Server, groupe d'ingénieurs de support technique qui collaborent avec les clients sur des incidents techniques critiques, des bogues et des demandes de modification de conception.

Contenu associé