Conclusion

l’application est encapsulé dans des paquets HTTP); chose impossible avec un pare-feu classique ! La vérification de la conformité des en-têtes et paquets HTTP est aussi un plus car elle permet d’éviter certaines attaques envoyant des paquets déformés (grand classique notamment sur les trames/paquets ICMP). De plus, le filtre HTTP permet de filtrer le trafic HTTP indifféremment du type de règle considéré (règle d’accès ou règle de publication) et sa configuration peut être personnalisée pour chaque règle considérée

Cependant, le filtre HTTP n’est pas parfait. Un des premiers inconvénients que l’on remarque, même s’il est intrinsèque, est l’augmentation de la charge de travail du serveur ! En effet lorsque le filtre HTTP est activé et configurée, le service pare-feu est obligé de lire et d’analyser le contenu de tous les paquets HTTP, ce qui engendre une charge de travail supplémentaire. Il faut donc prévoir un serveur relativement robuste si l’on souhaite utiliser le filtre HTTP. Si le serveur est déjà en production, il faut analyser la montée en charge à l’aide d’un outil spécifique comme la console Performance par exemple et comparer les résultats avec la ligne de base pour pouvoir se faire une idée de l’impact réelle sur les performance.

Un autre inconvénient du filtre HTTP est le manque de documentation notamment au niveau des en-têtes, méthodes et signatures qui peuvent être bloquées. Il aurait été appréciable que Microsoft intègre des assistants de configuration pour le filtre HTTP ou alors que certains champs soient préconfigurés (par exemple, des listes déroulantes contenant déjà les signatures, les méthodes et les champs d’en-têtes standards serait très pratiques à l’usage!!!). En effet actuellement, la configuration du filtre HTTP demande des connaissances avancées qu’un administrateur lambda ne possède pas toujours. Une fois encore, les meilleurs outils de l’administrateur réseau/sécurité se révèlent être l’analyseur de trames (comme l’excellent Ethereal ou bien encore le Moniteur réseau Microsoft) et la documentation en ligne…

Une des fonctionnalités du filtre HTTP les plus intéressantes est la modification à la volée de la valeur de certains en-têtes dans les requêtes et les réponses HTTP. Cependant, l’interface de configuration est faite de telle manière qu’il est impossible de modifier ou de supprimer plus d’un champ par règle (d’accès ou de publication), ce qui enlève beaucoup à cette fonctionnalité et la rend à peine utilisable… 🙁 Parmi les points "gênants", on note aussi le manque d’informations sur des options comme la vérification de la normalisation ou encore le blocage des caractères étendus, et de ce fait, il est assez difficile de prévoir leur impact sur une utilisation en entreprise…

Après lecture de cet article, il ressort que le filtre HTTP répond à la problématique complexe de l’encapsulation HTTP. C’est donc une grande avancée dans le domaine de la sécurité même s’il reste encore du travail à faire pour optimiser cette fonctionnalité et la rendre plus facilement appréhendable…