Informatique
Programmation
On désigne sous le nom de Firewall un dispositif, placé au point de connexion d'un système (ou groupe de systèmes) avec l'extérieur, et qui permet de contrôler les flux entrant ou sortant.
Ce dispositif était initialement conçu pour empêcher le piratage, et de cette finalité vient l'origine du terme employé. Un firewall, ou pare-feu, est en effet une barrière qui empêche la propagation d'un incendie. Il s'agit en général d'un système de portes ou de cloisons fixes ou amovibles, ignifugées et complètement étanches, placées aux endroits stratégiques d'un bâtiment. Leur fermeture en cas d'incendie permet de contenir le feu dans des zones réduites, d'où il ne se propagera pas.
De la même façon, un firewall était à l'origine placé en un point stratégique d'un réseau, afin d'éviter que l'incendie que représentait la compromission d'une ou plusieurs machines du système ne se répande en direction des serveurs stratégiques.
On peut donc traduire firewall par pare-feu, ou mur pare-feu. Le terme “mur de feu” qu'on rencontre parfois est en revanche un contre-sens.
Aujourd'hui, les fonctions d'un firewall se sont étendues, puisqu'il est aussi bien question d'empêcher la compromission de machines du réseau que d'empêcher la sortie de certaines informations du réseau local, voire l'utilisation de certains logiciels, par exemple de type IRC.
| Que protège-t-on, et contre quoi |
Installer un firewall n'est pas une fin en soi. On dit souvent que son installation ne protège que le sommeil de l'administrateur, mais certainement pas le réseau ! En fait, il convient avant tout de savoir ce que l'on veut protéger, et de quoi... En fonction de cette analyse, on décidera si un firewall s'avère utile, où le placer et comment le paramétrer.
Ces concepts paraissent évidents, mais combien de systèmes sont faciles à compromettre parce que cette réflexion a été menée trop vite, voire pas du tout ! A quoi sert-il en effet de mettre un firewall en entrée sur le serveur Web, si une machine du réseau est publiquement accessible à tout visiteur ? A quoi bon construire une zone de décontamination, si tous les commerciaux emportent chez eux leur portable, d'où ils surferont sur le Net sans filtre et récolteront toutes les backdoors du monde sous la forme de kits d'accès à des sites disons... plus visuels qu'intellectuels ? Sans parler des pseudo cracks du dernier logiciel à la mode, criblés de javascripts et de Troyens... Un pare-feu n'est pas plus utile sur un système couvert de failles de protocoles, ou d'applications dites faibles... On oublie souvent que le trou principal s'appelle le port 80, et qu'il faudrait presque protéger chaque segment du réseau... nous y reviendrons dans le cours IDS.
Quoi qu'il en soit, la première question à se poser est : quelles sont les machines que je veux protéger, et comment accède-t-on à ces machines ? Il ne sert à rien d'installer un Raptor à 7000 euros sur un serveur NT 4 qui est un simple serveur de fichiers, même si l'on tient à ses fichiers chéris... Raptor n'arrêtera pas par ailleurs un virus, ou une injection PHP bien conçue. Nous y reviendrons dans la partie strucutures de réseau.
| Cas initial: un réseau sans firewall |
Une connexion client serveur peut se produire de différentes manières. Pour prendre un exemple simple, analysons une connexion Web dans laquelle un navigateur va lire la page d'accueil d'un site quelconque, puis va se connecter sur un serveur de mail.
Dans la pratique, le navigateur constitue un client http qui va demander au serveur http la page que l'on veut lire. Cette demande prend la forme d'une requête http, dans laquelle le client explicite la page qui est demandée, et donne aussi d'autres informations, comme la version du navigateur utilisé, la langue, etc.
Cette requête est encapsulée dans une communication TCP, qui décompose la requête en segments, et chaque segment est envoyé dans un sens ou dans l'autre par l'intermédiaire d'adresses IP.
HTTP est un protocole non connecté. Cela signifie que, une fois la connexion avec le fournisseur d'accès établi, la demande de la page n'obéit pas à une nécessité d'authentification. Le navigateur, anonyme, demande une page accessible publiquement, et le serveur la renvoie, sans connaître autre chose du client que son adresse IP, puis coupe la connection.
Dans le cas d'une connexion à un serveur Webmail, il y a nécessité d'une authentification : autrement dit, le serveur va demander aux clients, en plus de sa requête, de s'authentifier, sous la forme d'un nom d'utilisateur est d'un mot de passe. Sans autre paramétrage, ces informations apparaissent en clair dans les fragments envoyés. Par la suite, le contenu des messages qui est renvoyé par le serveur circulent en clair jusqu'au client.
Ces informations s'appuient, outre l'adresse IP, sur un numéro de port, qui permet d'identifier quelle application est concernée par les informations. C'est ce qui permet à un fenêtre de lire la page web, pendant que l'autre lit les mails. Ces ports fonctionnent des deux côtés, une machine de l'extérieur peut tout à fait appeler un serveur mail interne, même si cette demande paraît abhérente du point de vue de l'utilisation du réseau.
| Premier type : firewall simple, ou stateless |
Pour se protéger de la lecteure des informations qui circulent en clair, la meilleure solution est le cryptage. Le firewall est difficilement opérant à cet égard.
En revance, la première entreprise de filtrage consiste à autoriser ou interdire certaines adresses IP, et certains ports, en entrée et en sortie de la connection Internet.
Il paraît évident qu'on interdira à une machine de l'internet de demander le serveur mail interne, si des commerciaux ne sont pas supposés accéder au réseau depuis l'extérieur. Classiquement, on interdira aussi le requêtes externes sur le port 139, celui du partage windows. On interdira aussi les requêtes internes venant de l'extérieur, autrement dit une machine qui prétendrait avoir une IP du réseau, et qui se trouverait sur l'internet, évitant ainsi une partie de l'IP spoofing. On empêchera enfin les requêtes broadcast ou multicast dans un sens ou dans l'autre, pour éviter les DOS ou DDOS.
Cette interdiction peut se programmer sur une machine spécifique, qui comportera deux cartes réseau, l'une tournée vers le réseau, l'autre vers l'internet. On peut aussi paramétrer certains routeurs directement, et certains switchs. De fait, il s'agit ici d'une mise en oeuvre simple. La machine filtrante examine chaque paquet, l'accepte, le rejette ou le transmet ailleurs, selon des principes très basiques.
Cette machine a rarement besoin d'être très puissante, contrairement aux idées reçus, puisque son travail est minimaliste.
Le défaut de ce type de firewalling est son aspect manichéen. On interdit ou on autorise un port par exemple en général, sans se préoccuper de savoir s'il est parfois normal (et parfois non) d'autoriser ce port. De la sorte, ce type de filtrage est souvent soit trop restrictif et bloquant pour l'activité du réseau, soit inefficace... Par exemple, une base de données SQL Server locale qui devra se connecter en synchronisation ou distribution avec une application externe au réseau local pourra ouvrir un port aléatoirement choisi au dessus de 1024, ce qui oblige à laisser tous les ports de cette tranche ouverts. Mais c'est aussi un de ces ports qu'ouvrira un Troyen pour permettre le contrôle du serveur d'authentification ! Ce principe est donc très vite limité.
| Deuxième type : Firewalls élaborés : stateful |
Il s'agit de la première des deux réponses possibles aux limitations du firewall stateless. Son principe consiste à enregistrer les connections que lit le firewall, et à maintenir un état de ces connections, afin d'appuyer sa politique de filtrage.
Ainsi, plutôt que d'autoriser ou non un port 1433, on autorisera les demandes de connection en provance du réseau local et les réponses externes. On peut aller plus loin, en exigeant par exemple qu'un paquet entrant ne soit autorisé que s'il répond à une requête sortante. De la sorte, on limite les risques d'intrusion.
Cependant, comme on le verra plus loin, la mise en oeuvre de ce filtrage requiert de la prudence, afin de ne pas par exemple empêcher lres requêtes DNS extérieures, le cas échéant, ou interdire les connections extérieures voulues (ICQ et autres).
Par ailleurs, il faut examiner si le firewall connaît tous les protocoles utilisés sur le réseau ! En effet, certains d'entre eux nécessitent l'ouverture et la fermeture de ports changeants, comme par exemple FTP, et ce firewall ne les filtrera correctement que s'il les prend en charge dans sa rédaction.
Le choix d'un firewall stateful repose donc sur cet examen, mais aussi sur son mécanisme de fonctionnement interne.
En effet, ce type de filtrage tend à ralentir le réseau, et pose un problème en cas de paquets mal formés. Certains firewalls statefuls examinent les en-tête TCP pour établir la position du paquet dans la transaction (SYN, ACK, etc.), ce qui améliore la performance et la fluidité, et limite les besoins du tampon de la machine filtrante : un simple examen suffit àdécider du sort du paquet.
Cependant, si une telle optique paraît attirante, elle offre peu de protection face aux paquets forgés manuellement, et spécifiquement destinés à tromper ce type de système (un attaquant extérieur envoie un paquet avec les drapeaux SYN ACK au lieu de SYN seul, ce qui laisse croire au firewall que ce paquet répond à une demande de connection interne, et le laisse passer).
Un autre mécanisme consiste donc à garder en mémoire les transactions en cours pendant une certaine durée (souvent de l'ordre de la minute), afin d'établir précisément la position du paquet, sans abus possible. Cependant, ce type de mise en oeuvre est beaucoup plus lourd en ressources et en baisse de performance. Le problème est aussi de savoir quelle est la durée nécessaire de ce tampon (le temps du timeout du keep alive, ou plus ?).
Enfin, ce type de firewall, comme le premier, ne protège pas complètement le réseau d'attaques sur des ports autorisés ! Ainsi, on pourra tout à fait autoriser la connection de la base SQL Server évoquée plus haut, sans réaliser que la requête envoyée est un 'drop database', ce que le pare feu ne prend pas en compte. De même, de nombreuses failles de IIS se fondent sur des requêtes sur le port 80, qui sont a priori autorisées, puisque 'naturelles' !
| Troisième type : proxy applicatif |
Il s'agit de la réponse la plus récente aux problèmes évoqués plus haut. Là, le firewall joue un rôle proche de celui du proxy, c'est à dire qu'il traite les demandes en lieu et place du réseau interne, examine les réponses du réseau externe, et décide de la politique à appliquer en conséquence.
L'intérêt est que l'examen ne porte plus sur une connection, mais sur le contenu des paquets. En d'autres termes, le filtrage portera sur le contenu.
Ainsi, le 'drop database' évoqué plus haut, en provenance de l'extérieur, sera rejeté systématiquement. L'objectif est de déterminer ce qui constitue un paquet mal formé, de le re-former si possible avant de le transmettre, ou de le rejeter s'il est excessivement déformé (ainsi, un 'select * form clients' pourra être lu comme 'select * from clients', mais pas un 'select from clients'), mais aussi de repérer ce qui constitue une attaque manifeste (bogues connus, ou injections de type 'drop database' ou autres injections SQL, mais aussi PHP ou champs de formulaires complétés de façon étrange).
Les grands firewalls d'aujourd'hui offrent ce niveau de protection, qui est le plus haut. C'est le cas de Raptor ou Sidewinder, par exemple.
Cependant, on voit bien que ce filtrage ne fonctionne que si le firewall connaît le protocole filtré. Pourquoi 'toto or 1=1” est-il inacceptable comme mot de passe dans un formulaire1 ?
La conséquence est d'une part qu'il faut que tous les protocoles utilisés sur le réseau soient pris en charge par le firewall, ce qui interdit certains protocoles, trop rares ou qui ne sont pas maîtrisés par les concepteurs de la solution choisie, d'autre part s'attendre à ce que ce type de firewall présente des problèmes de fonctionnement, liés à certaines bizarreries des protocoles, auxquelles les concepteurs n'ont pu faire face (c'est le cas des nombreux buffer overflows dont la possibilité est régulièrement découverte dans tel ou tel protocole, et qu'évidemment les concepteurs du proxy applicatif installé antérieurement dans l'entreprise n'ont pas protégé, ou de 'surprises' qui font qu'en filtrant telle exécution on interdise telle autre dont on a besoin et qui ne semble pourtant pas liée directement à la première).
Par ailleurs, la création de ce type de produit consiste à implémenter une foule de protocoles sur une application supplémentaire, ce qui ouvre la porte bien sûr à de nombreuses failles spécifiques, en plus des failles propres aux protocoles ! (un exemple typique2 est le processus TCP CONNECT, autorisé par de nombreux proxies applicatifs, et pour cause (!), mais qui permettaient du coup d'utiliser le firewall comme relais d'attaque vers un autre système !).
Enfin, il faut noter que la mise en oeuvre de ce type de protection ralentit considérablement le réseau, puisqu'il ne s'agit plus d'examiner chaque paquet l'un à la suite de l'autre, mais bien toute la séquence qui doit être transmise !
| Conclusion |
On voit donc qu'il n'existe pas de solution miracle concernant le firewalling. Chaque solution offre ses avantages et ses limitations. Idéalement, on mettra en place un proxy applicatif, précédé d'un firewall stateful. Mais il faudra garder en mémoire que la solution implémentée, si elle est fonctionnelle à un instant t, nécessite cependant une surveillance permanente afion de détecter les faiblesses qu'elle ne corrige pas, ou celles nouvellement apparues.
Une fois que les principes de ce que l'on veut installer sont clairs, il convient d'examiner à quel emplacement du réseau on va placer tel ou tel outil. A cet égard, on distingue la position des filtres de celles des analyseurs de contenu.
| Filtres |
On en a déterminé deux types : les routeurs équipés de fonction de firewalling, et les firewalls positionnés sur des machines spécifiques.
| Principes |
Ces deux outils d'interconnection peuvent être paramétrés comme filtre. Leur action se place au niveau IP (couche 3) ou TCP (couche 4). Mais il faut remarquer qu'il s'agit d'extensions des fonctionnalités de base de ces objets, puisqu'un switch fonctionne en couche 2, et ne se préoccupe normalement pas de l'adresse IP, et encore moins du protocole, et le routeur ne s'intérésse supposément qu'à la couche 3.
L'implémentation la plus simple prend la forme d'acces-list, dans laquelle on va autoriser ou refuser en couche 3 telle ou telle adresse, ou telle tranche d'adresses. Les limitations apparaissent vite, comme on l'a vu plus haut.
C'est donc naturellement que les listes d'accès passent en mode “étendu” ces dernières années, pour examiner le protocole envoyé ou le port, montant en couche 4.
Cependant, le travail d'un routeur est... de router ! Ajouter des access-lists trop complexes alourdit considérablement le travail de routage. On a donc souvent tendance à limiter l'examen des en-têtes à la présence ou l'absence d'un flag SYN.
Par ailleurs, ce type de fitrage présente deux faiblesses majeures : d'abord, le routeur est crédule ! Il croit le champ adresse-source : il est donc susceptible de répondre au spoofing IP3. Par ailleurs, un routeur transmet toujours un paquet de moins de 68 octets (RFC 791). Or la constitution d'un paquet TCP permet de placer le flag SYN vers la fin de cette limite4, et, même en son absence, un routeur transmettra le paquet, ce qui autorise un hack fragmenté.
Certains routeurs plus récents et plus évolués ont des optimisations dans ce domaine, mais ils restent coûteux. De plus, encore une fois, le travail d'un routeur... est de router, il est plus logique de s'en tenir conceptuellement à ce principe. Les access-list seront mises en place, mais dans une logique administrative, afin d'interdire au service compta d'accéder au port 153 du serveur marketing, par exemple, mais pas dans l'idée de faire office de firewall complet.
| Mise en place |
Le routeur sera connecté en général à l'Internet. Celui-là fera l'objet d'un paramétrage interdisant le spoofing (on refuse le réseau interne s'il entre par l'Internet) et on ne filtre pas en sortie.
Les routeurs internes au réseau auront le paramétrage requis par la disposition spécifique locale, comme décrit plus haut (exemple comptabilité-marketing), et ne filtreront pas l'Internet.
| Principes |
Nous n'évoquons ici que le cas du Firewall Stateful.
Dans une situation idéale, il se place derrière le routeur connecté à l'internet, et dispose de deux sorties : l'une vers un brin réseau qui représente le LAN, un autre vers un autre sous-réseau, qui contient les machines lisibles depuis l'Internet, telles que serveur de mail ou serveur Web. Ces machines sont accessibles, et leur compromission, idéalement, n'affecte pas le LAN. Elles sont en quelques sortes isolées, et constituent une forme de tampon entre l'intérieur et l'extérieur. On appelle parfois cette zone une DMZ (De Militarised Zone, en référence au no man's land créé entre les deux Corées après la guerre).
On verra plus bas que ce type de firewall filtre un paquet en entrée, forward ou sortie, c'est à dire au moment où il pénètre dans le firewall, au moment où il doit circuler dans le firewall, ou en sortie après traitement. Ce procédé permet notamment de rejeter certains paquets avant qu'ils n'affectent la pile IP du firewall lui-même.
| Mise en place |
Dans cette configuration, on autorisera les flux en provenance de l'Internet, mais à la seule destination de la DMZ.
On autorisera aussi les entrées et sorties en port 25 du serveur smtp.
Du réseau interne vers la DMZ, on autorisera les flux type smtp, pop et http, ainsi que les accès ssh depuis les IP internes des administrateurs.
| Principes |
Bien qu'on décrive cette implémentation comme représentant le niveau le plus haut du filtrage, on retiendra cependant qu'elle implique un ralentissement notable de flux du réseau : quoi qu'en disent les fabricants, un proxy applicatif, par définition, fonctionne en couche 7 ! Il faut donc remonter les couches, ce qui est plus long mécaniquement que de filtrer en couche 3 ou 4.
Par ailleurs, on gardera en mémoire les réserves émises plus haut.
| Mise en place |
Dans la mesure du possible, on positionnera ces dispositifs en renforcement des firewalls statefuls, en accès des machines supportant les applications stratégiques (et elles seules). Cet outil pourra donc tout à fait être positionné en plusieurs endroits du réseau, avec un paramétrage spécifique à chaque point. La difficulté provient du fait que ce type de filtre permet en général un firewalling stateful, et qu'on tend soit à les positionner à la position des firewalls statefuls, ce qui pose un problème de débit et risque d'interdire des flux qu'on souhaiterait autoriser en fonction de leur source ou leur destination finale, soit à les positionner en position proxy applicatif, ce qui laisse la porte ouverte à des tentatives de pénétration basées sur les protocoles. Dans le cas d'une implémentation unique, la position firewall reste à privilégier.
La mise en place d'un firewall reste une étape importante dans une démarche de sécurité, mais elle doit rester un simple outil. Un réseau, même protégé par un pare-feu, reste vulnérable. Dès lors qu'on DROP certains paquets, une pirate attentif remarquera évidemment qu'un tel paquet devrait produire un RESET et non une absence de réponse. Il en déduira donc la présence du firewall et pourra reconstituer ses règles, détecter quels ports sont ouverts, puis encapsuler dans ces ports une attaque vers d'autres ports. Il n'y a pas de solution miracle, seul un monitoring permanent permettra de détecter ces tentatives. On pourra d'ailleurs s'aider d'outils de détection d'intrusion, comme snort, qui reste, même s'ila beacuoup été décrié (mais c'est souvent une sorte de mode), l'un des meilleurs IDS disponible grâce à son excellente base de données sur les outils d'intrusion. Mais ceci est l'objet d'un autre cours...
Merci à Jérôme Henry