Le filtre HTTP intégré à  ISA SERVER 2004

Suite à la sortie d'ISA Server 2004, Microsoft a beaucoup communiqué sur les fonctionnalités de filtrage et de sécurité avancée intégrées au produit comme la mise en quarantaine des clients VPN, le support de méthodes d'authentification puissantes (RSA SecureID, RADIUS, certificats numériques)...
Cet article est dédié à l'une de ces fonctionnalités d'ISA Server 2004 : le filtrage au niveau applicatif et plus particulièrement le filtre HTTP.Pour comprendre l'intérêt de ce nouvel outil, nous commencerons par évoquer les forces et surtout les faiblesses des pare-feu classiques, puis nous étudierons la problématique posée par les attaques au niveau applicatif (et surtout le problème de l'encapsulation HTTP) et enfin nous verrons comment ISA Server permet d'empêcher cette nouvelle forme de piratage !

A l'instar de n'importe quel autre pare-feu, ISA 2004 peut analyser l'en-tête d'un paquet IP en entrée ou en sortie de l'une des interfaces réseau du serveur, puis décider d'une action à accomplir. Cela passe par la création de règles d'accès.

Voici un petit exemple de ce qui peut être mis en place à l'aide de règles d'accès :
• rejeter le trafic provenant du réseau 172.17.0.0
• accepter le trafic entrant sur le port 80
• rejeter le trafic provenant du réseau 10.3.40.0/24 sur le port TCP 1247 et à destination du serveur 10.3.41.200 sur le port TCP 443

Il est bien entendu possible d'affiner ces règles d'accès en utilisant des éléments de stratégie spécifiques. Une règle d'accès peut s'appliquer à une destination précise (par exemple à l'aide des éléments de stratégie ensemble d'URL ou ensemble de noms domaines), pendant une période donnée (à l'aide de l'élément de stratégie planification) et ce uniquement pour un groupe d'utilisateurs donné. Pour plus d'informations concernant les divers éléments de stratégie disponibles sous ISA Server 2004, consultez cette section de notre précédent article.

En étudiant la structure d'un paquet IP, on comprend mieux comment le serveur ISA utilise l'en-tête pour déterminer si le paquet est oui ou non autorisé à passer. Voir figure 1.

Les règles d'accès basées sur le numéro et le type de port (par exemple le port 993 en TCP utilisé par le protocole IMAP4s) seraient suffisantes si chaque port était dédié à une application ou un protocole donné et si les applications et les protocoles étaient exempts de failles. Cependant certains numéros de ports et certains protocoles sont utilisés par plusieurs applications (tel le protocole HTTP qui est notamment utilisé par MSN Messenger ou eMule lorsque le port par défaut est bloqué). Quand aux failles applicatives, elles semblent inévitables contenu de la conception même du matériel informatique. Le protocole HTTP a notamment subit plusieurs évolutions qui permettent maintenant à n'importe quel protocole de transiter à l'intérieur d'un paquet HTTP. Ce procédé est désigné par le terme encapsulation HTTP. On peut notamment citer le protocole RPC over HTTP qui permet à un client MAPI (comme Outlook 2003), de se connecter à un serveur Exchange tout en n'envoyant que des requêtes HTTP. Voir figure 2.

Etant donné l'utilisation massive de l'encapsulation HTTP, on peut considérer qu'un pare-feu sur lequel le port 80 est ouvert en sortie est totalement inefficace. Certains éditeurs de logiciels fournissent même des programmes permettant d'établir un tunnel HTTP avec un serveur situé sur Internet et ainsi de permettre le fonctionnement de n'importe quelle application en dépit des règles configurées sur le pare-feu de l'entreprise. C'est pourquoi il est nécessaire de mettre en place un système d'analyse plus poussé permettant de vérifier le contenu des paquets IP en plus de leur en-tête.