Le filtre HTTP intégré à ISA Server 2004 Accueil > Articles > Serveurs
Auteur  Matthieu MARTINEAU PI SERVICES (GOLD PARTNER MICROSOFT) Ingénieur systèmes et réseaux  Tous les articles de cet auteur Vincent TROTTIER MGI CONSULTANTS Ingénieur systèmes & réseaux  Tous les articles de cet auteur		4,3/5 Bien 73414 106/466

3. Le filtre HTTP

3.1 Présentation du filtre HTTP

Le filtre HTTP est une nouveauté d'ISA Server 2004. Comme son nom l'indique il permet d'analyser l'intégralité du trafic HTTP en fonction d'un certain nombre de paramètres. Les deux utilisations typiques de ce filtre sont :

• Le filtrage de l'accès Web pour les clients du réseau interne. Cela passe notamment par le blocage de certaines applications indésirables utilisant l'encapsulation HTTP (clients P2P, logiciels de messagerie instantanée...). Il est aussi de possible d'autoriser uniquement les méthodes HTTP indispensables (GET, HEAD, POST...) et de modifier ou de supprimer certaines champs sensibles renvoyés dans l'en-tête des requêtes HTTP (User-Agent en particulier).

• La sécurisation d'un site Web interne (cela peut être le site de l'entreprise ou bien n'importe quelle interface Web comme Outlook Web Access). Dans ce cas il est particulièrement intéressant de modifier les champs renvoyés dans les réponses HTTP du serveur Web ce qui permet de cacher un maximum d'informations sensibles comme la version du serveur Web ou bien les protocoles d'authentification supportés.

A l'inverse du filtre SMTP dont la configuration est générale (elle se réalise dans Configuration / Add-ins), celle du filtre HTTP est spécifique à chaque règle d'accès ou de publication. Il faut faire un clic droit sur la règle choisie puis sélectionner Configurer HTTP pour atteindre la fenêtre de configuration comme le montre la capture d'écran ci-contre. Attention car le paramètre Taille maximale des en-têtes (cf. partie 3.2) est commun à toutes les règles et ne peut donc être configuré qu'une seule fois. C'est la seule exception à la règle énoncée ci-dessus ! Nous allons maintenant expliquer comment paramétrer les cinq onglets du filtre HTTP en respectant l'ordre suivant : Options générales Blocage d'en-têtes et de méthodes Blocage de signatures Blocage d'extensions Nous terminerons ce chapitre en expliquant comment sauvegarder ou sauvegarder une configuration spécifique du filtre HTTP.

3.2 Les options générales du filtre HTTP

L'onglet Général du filtre HTTP permet de configurer les options suivantes : Le paramètre Taille maximale des en-têtes (octets) permet de bloquer toutes requêtes HTTP dont l'en-tête (+ la requête) dépasse la valeur indiquée. Par défaut, les requêtes possédant une en-têtes supérieure à 32768 octets sont arrêtées par le serveur ISA. Ce paramètre est commun à toutes les règles utilisant le protocole HTTP ! C'est d'ailleurs le seul du filtre HTTP qui n'est pas spécifique à une règle d'accès ou à une règle de publication donnée. Il est recommandé de ne pas modifier de manière trop importante la valeur de ce paramètre mais plutôt de jouer avec les paramètres Taille maximale des URL (octets) et Taille maximale des requêtes (octets) pour augmenter la sécurité. La somme des valeurs de ces deux derniers paramètres doit au passage, être inférieure à celle du paramètre Taille maximale des en-têtes (octets). Il est recommandé de baisser la valeur de ce paramètre à 10Ko et de l'augmenter uniquement si des problèmes sont rencontrés. Cela permet de se protéger de certaines attaques de type "Buffer Overflow" et "Denial Of Service" (DOS). Le paramètre Taille maximale des charges utiles (octets) permet de bloquer les requêtes HTTP dont le corps (lorsqu'il existe; par exemple avec la méthode POST) excède la valeur configurée. Par défaut ce paramètre n'est pas activé et il n'est pas recommandé de l'activer sur n'importe quelle règle. En effet, si ce paramètre est activé avec une valeur trop faible, certaines application ne fonctionneront plus ! Par exemple, sur la majorité des sites Web (ex. :  http://www.laboratoire-microsoft.org), les données d'identification sont envoyée via la méthode POST pour authentifier les utilisateurs. Si la valeur de la charge utile est trop faible, l'authentification sera impossible.

• Le paramètre Taille maximale des URL (octets) permet de bloquer les requêtes HTTP dont l'URL demandée dépasse le seuil configuré (par défaut, la limite est de 10240 octets). Il peut s'avérer très intéressant de réduire la taille prédéfinie à une valeur plus faible (ex. : 512 octets ou 1024 octets) surtout dans le cadre d'une publication de serveur Web. En effet, cela empêcherait un éventuel pirate d'utiliser un script dans la barre d'adresse. Dans l'exemple ci-dessous, la requête HTTP tente de télécharger le fichier http://www.laboratoire-microsoft.org/inc/css/site.css. Si la taille maximale autorisée pour les URL est configurée à 15, alors la requête sera bloquée par le serveur ISA car l'URL de cet exemple (entourée en rouge) fait 17 caractères (le caractère "/" est aussi compté).

• Le paramètre Taille maximale des requêtes (octets) permet de limiter la longueur des paramètres envoyés via la méthode GET au sein d'une requête HTTP. Il peut être intéressant de réduire la valeur de cette option au même titre celle de la taille maximale des charges utiles (c'est-à-dire pour limiter les attaques de type "SQL injection"). Bien évidemment si la taille configurée est trop basse cela posera des problèmes pour afficher certains sites (exemple : moteurs de recherche) ! Dans l'exemple ci-dessous, on tente d'effectuer une recherche sur le site http://www.google.fr avec les mots clefs laboratoire+microsoft. Si la taille maximale des requêtes est limitée à 30 alors notre requête HTTP sera bloquée car sa longueur est de 35 caractères (le caractère "?" n'est pas compté). La chaîne de caractères passée en paramètre dans notre exemple (recherche sur les mots laboratoire et microsoft) est encadrée en rouge dans la capture d'écran ci-dessous.

• La paramètre Vérifier la normalisation, lorsqu'il est activé, bloque toutes les URLs contenant des caractères d'échappement (ex. : \n).

• Le paramètre Bloquer les caractères étendus permet de bloquer toutes les URLs contenant des caractères non présents dans jeu de caractère ASCII. Certains caractères des jeux DBCS et latin-1 (ou ISO-8859-1) seront notamment bloqués. Par exemple, lorsque cette option est activée, si une page Web, une image ou un fichier possède des accents, il sera bloqué par le filtre HTTP au niveau du serveur ISA. De plus l'activation de ce paramètre peut aussi poser problème avec Outlook Web Access (OWA) ou bien encore Sharepoint Portal Server. Dans l'exemple ci-dessous, on peut remarquer que la version française d'OWA fait appel à des caractères latin-1 (l'accent de boite de réception) directement dans l'URL de certaine page :

• Le paramètre Bloquer les réponses contenant un exécutable Windows permet de bloquer le téléchargement d'exécutables. Lorsque ce paramètre est activé, le serveur ISA vérifie que le fichier commence bien par la chaîne de caractère "MZ" (cela permet au serveur de s'assurer que le fichier est bien un exécutable Windows).

3.3 Le blocage de méthodes

Le filtre HTTP permet aussi d'agir au niveau des méthodes utilisées dans les requêtes HTTP. Trois actions sont possibles : Autoriser toutes les méthodes (choix sélectionné par défaut) Autoriser uniquement les méthodes spécifiées Bloquer les méthodes spécifiées (autoriser toutes les autres) Il peut par exemple s'avérer particulièrement intéressant de bloquer toutes les méthodes sauf GET et POST sur une règle d'accès à Internet. Ceci évite que certains logiciels ou certaines applications Web (Windows Update, MSN Messenger, OWA...) utilisant des méthodes exotiques (méthodes non définies dans la RFC 2616) soient utilisées par les ordinateurs clients. Outlook Web Access un est l'exemple type d'une application utilisant des méthodes non standard. On peut notamment citer les méthodes SUBSCRIBE, SEARCH, POLL et PROPFIND qui gèrent des fonctions spécifiques comme l'affichage des nouveaux messages (la petite pop-up qui apparaît lorsqu'un nouveau message vient d'être téléchargé) ou bien encore la fenêtre de rappel du calendrier.

Il faut donc se montrer vigilant lorsque vous configurez le blocage de méthodes. Le mieux restant bien sur d'analyser à l'aide d'Ethereal ou du Moniteur réseau Microsoft l'ensemble des applications utilisant le protocole HTTP en place dans l'entreprise...

L'onglet Méthodes, peut aussi être utilisé dans le cadre d'une publication de serveur Web dans le but de limiter les actions réalisables par les clients Web sur le serveur interne. Dans ce dernier cas, vous devrez bien entendu connaître les méthodes HTTP nécessaire au bon fonctionnement des sites publié (les méthodes les plus employées restant GET et POST). Voici les autres méthodes HTTP (non standard) souvent utilisées :

• BCOPY, BDELETE, BMOVE, BPROPPATCH, MKCO, POLL, PROPFIND, PROPPATCH, SEARCH et SUBSCRIBE  utilisées par Outlook Web Access en mode "Expérience étendue". Ce mode est uniquement sous Internet Explorer puisque seul IE supporte ces méthodes HTTP non standard !!!
• PROPFIND, BMOVE et BDELETE utilisées lorsqu'un compte Hotmail est configuré dans Outlook pour utiliser le protocole HTTP (et non les protocoles de messagerie classique comme SMTP, POP3, IMAP4,...). Lorsque ces deux méthodes sont bloquées par le serveur ISA, voici le message d'erreur affiché par Outlook :

3.4 Le blocage de signatures

Le filtre HTTP offre aussi la possibilité de bloquer un paquet utilisant le protocole HTTP et ce en fonction de n'importe quel critère ! Le principe est simple : il suffit de définir une chaîne de caractère prédéfinie nommée signature ainsi que la partie du paquet qui doit être analysée (URL, en-tête ou corps dans le cas d'une requête; en-têtes ou corps dans le cas d'une réponse). Si cette signature est rencontrée par le serveur ISA dans la partie configurée alors le paquet est bloqué.

La principale utilité du blocage de signature est d'empêcher le fonctionnement des applications utilisant l'encapsulation HTTP. Il est par exemple possible d'interdire l'accès à Firefox tout en autorisant uniquement Internet Explorer :

Pour ce faire, il faut trouver une chaîne de caractères permettant d'identifier l'application (Windows Messenger, Internet Explorer, Firefox, eMule...). Le champ User-Agent est généralement utilisé pour définir le nom de l'application. Pour retrouver la signature d'une application utilisant le protocole HTTP, il suffit de réaliser une analyse de trames et de visualiser la valeur de ce champ. Lorsque l'on réalise une capture de trames à l'aide du logiciel Ethereal avec le navigateur Firefox, on obtient le résultat suivant :

On remarque qu'il existe deux manières de bloquer l'application Firefox :

• en utilisant la signature Firefox

• en utilisant la signature Gecko ce qui aura pour conséquence de bloquer tous les navigateurs basés sur le moteur Gecko (Firefox, Netscape, Mozilla...).

Pour configurer le blocage de signature, il faut faire un clic droit sur une règle d'accès ou d'une règle de publication faisant intervenir les protocoles HTTP, HTTPS ou Serveur HTTPS, puis sélectionner Configurer HTTP. Il suffit ensuite de cliquer sur l'onglet Signatures pour pouvoir bloquer des applications. Ci-contre, un exemple de configuration où de nombreux logiciels ont été ajoutés. On peut notamment remarquer des logiciels de Peer to Peer (P2P) comme eMule, Kazaa, Morpheus ou BitTorrent. des logiciels de messagerie instantanée comme MSN Messenger ou Windows Messenger des navigateurs comme Internet Explorer... Si l'une de ces applications tente d'accéder à Internet, un message d'erreur spécifique s'affichera. Ce message dépend bien évidemment de l'application considérée et varie d'un cas à un autre. Ci-dessous, voici l'erreur renvoyée par le navigateur Internet Explorer 6.0 lorsque sa signature (MSIE 6.0) a été bloquée :

Le tableau ci-dessous récapitule les signatures des applications courantes qu'un administrateur système peut être amené à bloquer :

3.5 La suppression ou la modification d'en-têtes

Comme nous l'avons vu plus haut, lorsqu'un client effectue une requête à un serveur WEB, il envoie un certain nombre d'informations à ce serveur via les en-têtes HTTP, et il en est de même lorsque le serveur répond au client. Ces en-têtes peuvent contenir des informations sur le type de navigateur du client, le nom NetBios du proxy par lequel le client est passé, la page par laquelle il est passé avant d'arriver sur cette page, etc. dans le cas d'une requête HTTP, et sur le type de serveur WEB, la dernière date de modification de la page, etc. dans le cas d'une réponse HTTP.

Afin de mieux comprendre, voici un exemple avec quelques en-têtes :

Pour des raisons évidentes de sécurité, on peut souhaiter que ces informations ne soient pas divulguées. Il peut même être intéressant dans certains cas de renvoyer ces en-têtes mais en les modifiant. En effet, il a été prouvé que dans 90% des attaques de serveurs WEB, le pirate tente d'abord d'obtenir le type de serveur ainsi que sa version, ce qui est assez aisé, afin d'exploiter les failles connues de ce serveur, puis laisse tomber. En se servant des fonctions du filtre HTTP, il est parfaitement possible de renvoyer un nom de serveur factice.

Par exemple, si l'on possède un serveur Apache, identifié par la chaine "Apache/1.3.33 (Linux) mod_perl/1.29 mod_ssl/2.8.22 OpenSSL/0.9.7f", on peut parfaitement modifier le champ "SERVER" des en-têtes HTTP et ainsi renvoyer "Microsoft-II/6.0", chaîne qui identifie un serveur IIS. Bien évidemment, cette technique est à utiliser dans le cas d'une publication de serveur. Une fois dans les paramètres du filtre HTTP de cette règle de publication et dans l'onglet En-têtes, il suffit de cliquer sur le bouton Ajouter et de choisir si l'on souhaite modifier les en-têtes dans une requête ou dans une réponse HTTP, puis de spécifier le nom du champ que l'on souhaite modifier ou supprimer. Trois actions s'offrent alors à nous : Envoyer l'en-tête original : cette option présente relativement peu d'interêt, en effet si l'on souhaite renvoyer l'en-tête d'origine, autant ne rien faire, cela déchargera le serveur ISA. Supprimer l'en-tête de la réponse : cette option être utile si l'on souhaite tout simplement ne pas envoyer un champ des en-têtes HTTP, mais peut être dangereuse car du point de vue d'un eventuel attaquant, cacher des informations de ce genre peut revenir à dire qu'il a des failles importantes derrière, ou du contenu sensible. Modifier l'en-tête dans la réponse : cette option est, selon moi, celle qui est la plus intéressante car personne ne pourra se douter que vous avez modifié un champ d'en-têtes. La dernière étape est bien évidemment de saisir la nouvelle valeur que l'on souhaite renvoyer pour ce champ d'en-têtes.

Une autre utilisation interressante, toujours dans un but de sécurité, pourait être de modifier le champ "VIA", qui correspond au nom NetBIOS du premier proxy utilisé par le client. En effet, dans le cas d'une organisation, le premier proxy est toujours un proxy du réseau interne de l'entreprise, et le dévoiler est en quelque sorte une brèche dans la sécurité de l'organisation. Il va de soi que cette modification possède un sens uniquement sur une règle d'accès, en effet son interêt serait assez limité, pour ne pas dire nul, sur une règle de publication. Uniquement pour cet en-tête, il possible d'agir sur la valeur qui sera renvoyée sans passer par le menu précédent. En effet, dans la fenêtre permettant de configurer le filtre HTTP, on peut également trouver un encart nommé "Via l'en-tête". C'est ici que l'on pourra modifier la valeur cu champ VIA qui sera retournée par le serveur. On dispose tout d'abord de deux options : Envoyer l'en-tête par défaut : de la même manière que précedement, cette option ne présente aucun interêt. Modifier l'en-tête dans la demande et la réponse : lorsque cette option est choisie, le champ de texte situé en dessous va devenir accessible. La dernière étape est de saisir le nom NetBIOS que l'on souhaite que le serveur renvoie.

3.6 Le blocage des extensions

Une autre fonctionnalité du filtre HTTP est la possibilité de bloquer certains types de fichiers. Voici le principe de fonctionnement du blocage d'extensions :

• Lorsque le serveur ISA reçoit une requête HTTP, il analyse l'URL demandée.
• Si cette URL contient une chaîne de caractère encadré par le caractère "." et le caractère "/" (ou le caractère "." et le caractère "?"), alors le serveur ISA consulte le filtre HTTP pour déterminer si cette chaîne de caractères fait partie ou non des extensions autorisées.

Pour mieux comprendre le fonctionnement du blocage des extensions voici un exemple :

Les extensions correspondant à des scripts et à des exécutables (vbs, bat, exe...) sont bloquées au niveau d'une règle d'accès à Internet. Le tableau suivant montre la réaction du serveur ISA à plusieurs exemples d'URLs : http://nom_du_serveur/repertoire_virtuel/worm.vbs http://nom_du_serveur/fichier.exe http://nom_du_serveur/download.php?file=virus.exe

On remarque que lorsque l'URL contient plusieurs extensions, seule la première est analysée par le serveur ISA. Dans le troisième cas, le serveur ISA remarque qu'un fichier possédant l'extension .php est demandé. Ce type d'extension étant autorisé, le serveur ISA interrompt son analyse et accepte le paquet (même si la fin de l'URL contient l'extension .exe qui n'est pas autorisée!!!). Le système de filtrage des extensions peut donc être contourné mais il est vrai que de telles URLs se rencontrent rarement.

Il est aussi possible de bloquer directement des types MIME (Multipurpose Internet Mail Extensions) via cet onglet Extensions. Voici une liste des principaux types MIME (*) :

(*) La liste complète des types MIME est disponible sur le site de l'IANA à cette adresse.

Il existe un autre moyen d'autoriser et/ou de bloquer certaines extensions de fichier. Cela passe tout simplement par l'utilisation de l'élément de stratégie Type de contenu dans les propriétés des règles d'accès et/ou des règles de publication. Le système de type de contenus fonctionne d'ailleurs de manière similaire au filtre HTTP pour analyser le contenu du paquet HTTP. L'exemple ci-contre montre la configuration du type de contenus Documents HTML. Cet élément de stratégie est préconfiguré et contient par défaut des extensions ainsi que des types MIME.

3.7 Sauvegarder/restaurer une configuration du filtre HTTP

Lorsque l’on sauvegarde une règle d’accès spécifique ou bien lorsque l’on réalise une sauvegarde générale des paramètres du serveur ISA, la configuration du filtre HTTP (qui peut être différente pour chaque règle faisant intervenir le protocole HTTP) n’est pas enregistrée.

Il est cependant possible de stocker la configuration du filtre HTTP sur une règle donnée dans un fichier au format XML à l'aide d'un script présent sur le CD-ROM d'ISA Server (dans le répertoire SDK\SAMPLES\ADMIN). Ce script nommé HttpFilterConfig.vbs permet aussi la restauration d'une configuration du filtre HTTP. Voici la syntaxe de ce script nommé HttpFilterConfig.vbs : HttpFilterConfig.vbs export "Nom de la règle" "Chemin de la sauvegarde"

Dans le cas d'une restauration des paramètres du filtre HTTP sur une règle donnée, il suffit de remplacer export par import !

Sommaire

1. Introduction au filtrage applicatif
      1.1 Les limitations inhérentes aux règles d'accès
      1.2 Présentation des filtres applicatifs d'ISA Server 2004

2. Etude du protocole HTTP (Hyper Text Transfer Protocol)
      2.1 Présentation du protocole HTTP
      2.2 Fonctionnement d'une requête HTTP
      2.3 Fonctionnement d'une réponse HTTP

3. Le filtre HTTP
      3.1 Présentation du filtre HTTP
      3.2 Les options générales du filtre HTTP
      3.3 Le blocage de méthodes
      3.4 Le blocage de signatures
      3.5 La suppression ou la modification d'en-têtes
      3.6 Le blocage des extensions
      3.7 Sauvegarder/restaurer une configuration du filtre HTTP

Conclusion

En Savoir Plus

Evaluez cet article  0 1 2 3 4 5 Pour afficher ou poster un commentaire, cliquez sur ce lien : Forum-Microsoft