Vous êtes sur la page 1sur 6

Firewall : Origine et Fonctionnement Origine du "firewall"

On dsigne sous le nom de Firewall un dispositif, plac au point de connexion d'un systme (ou groupe de systmes) avec l'extrieur, et qui permet de contrler les flux entrant ou sortant. Ce dispositif tait initialement conu pour empcher le piratage, et de cette finalit vient l'origine du terme employ. Un firewall, ou pare-feu, est en effet une barrire qui empche la propagation d'un incendie. Il s'agit en gnral d'un systme de portes ou de cloisons fixes ou amovibles, ignifuges et compltement tanches, places aux endroits stratgiques d'un btiment. Leur fermeture en cas d'incendie permet de contenir le feu dans des zones rduites, d'o il ne se propagera pas. De la mme faon, un firewall tait l'origine plac en un point stratgique d'un rseau, afin d'viter que l'incendie que reprsentait la compromission d'une ou plusieurs machines du systme ne se rpande en direction des serveurs stratgiques. 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'empcher la compromission de machines du rseau que d'empcher la sortie de certaines informations du rseau local, voire l'utilisation de certains logiciels, par exemple de type IRC.

Que protge-t-on, et contre quoi


Installer un firewall n'est pas une fin en soi. On dit souvent que son installation ne protge que le sommeil de l'administrateur, mais certainement pas le rseau ! En fait, il convient avant tout de savoir ce que l'on veut protger, et de quoi... En fonction de cette analyse, on dcidera si un firewall s'avre utile, o le placer et comment le paramtrer. Ces concepts paraissent vidents, mais combien de systmes sont faciles compromettre parce que cette rflexion a t mene trop vite, voire pas du tout ! A quoi sert-il en effet de mettre un firewall en entre sur le serveur Web, si une machine du rseau est publiquement accessible tout visiteur ? A quoi bon construire une zone de dcontamination, si tous les commerciaux emportent chez eux leur portable, d'o ils surferont sur le Net sans filtre et rcolteront toutes les backdoors du monde sous la forme de kits d'accs des sites disons... plus visuels qu'intellectuels ? Sans parler des pseudo cracks du dernier logiciel la mode, cribls de javascripts et de Troyens... Un pare-feu n'est pas plus utile sur un systme couvert de failles de protocoles, ou d'applications dites faibles... On o ublie souvent que le trou principal s'appelle le port 80, et qu'il faudrait presque protger chaque segment du rseau... nous y reviendrons dans le cours IDS. Quoi qu'il en soit, la premire question se poser est : quelles sont les machines que je veux protger, et comment accde-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, mme si l'on tient ses fichiers chris... Raptor n'arrtera pas par ailleurs un virus, ou une injection PHP bien conue. Nous y reviendrons dans la partie strucutures de rseau.

Les diffrents types de firewall

Cas initial: un rseau sans firewall


Une connexion client serveur peut se produire de diffrentes manires. 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 requte http, dans laquelle le client explicite la page qui est demande, et donne aussi d'autres informations, comme la version du navigateur utilis, la langue, etc. Cette requte est encapsule dans une communication TCP, qui dcompose la requte en segments, et chaque segment est envoy dans un sens ou dans l'autre par l'intermdiaire d'adresses IP. HTTP est un protocole non connect. Cela signifie que, une fois la connexion avec le fournisseur d'accs tabli, la demande de la page n'obit pas une ncessit d'authentification. Le navigateur, anonyme, demande une page accessible publiquement, et le serveur la renvoie, sans connatre autre chose du client que son adresse IP, puis coupe la connection. Dans le cas d'une connexion un serveur Webmail, il y a ncessit d'une authentification : autrement dit, le serveur va demander aux clients, en plus de sa requte, de s'authentifier, sous la forme d'un nom d'utilisateur est d'un mot de passe. Sans autre paramtrage, ces informations apparaissent en clair dans les fragments envoys. 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 numro de port, qui permet d'identifier quelle application est concerne par les informations. C'est ce qui permet un fentre de lire la page web, pendant que l'autre lit les mails. Ces ports fonctionnent des deux cts, une machine de l'extrieur peut tout fait appeler un serveur mail interne, mme si cette demande parat abhrente du point de vue de l'utilisation du rseau.

Premier type : firewall simple, ou stateless


Pour se protger de la lecteure des informations qui circulent en clair, la meilleure solution est le cryptage. Le firewall est difficilement oprant cet gard. En revance, la premire entreprise de filtrage consiste autoriser ou interdire certaines adresses IP, et certains ports, en entre et en sortie de la connection Internet. Il parat vident qu'on interdira une machine de l'internet de demander le serveur mail i nterne, si des commerciaux ne sont pas supposs accder au rseau depuis l'extrieur. Classiquement, on interdira aussi le requtes externes sur le port 139, celui du partage windows. On interdira aussi les requtes internes venant de l'extrieur, autrement dit une machine qui prtendrait avoir une IP du rseau, et qui se trouverait sur l'internet, vitant ainsi une partie de l'IP spoofing. On empchera enfin les requtes broadcast ou multicast dans un sens ou dans l'autre, pour viter les DOS ou DDOS. Cette interdiction peut se programmer sur une machine spcifique, qui comportera deux cartes rseau, l'une tourne vers le rseau, l'autre vers l'internet. On peut aussi paramtrer 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 trs basiques. Cette machine a rarement besoin d'tre trs puissante, contrairement aux ides reus, puisque son travail est minimaliste. Le dfaut de ce type de firewalling est son aspect manichen. On interdit ou on autorise un port par

exemple en gnral, sans se proccuper 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 rseau, soit inefficace... Par exemple, une base de donnes SQL Server locale qui devra se connecter en synchronisation ou distribution avec une application externe au rseau loca l pourra ouvrir un port alatoirement 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 contrle du serveur d'authentification ! Ce principe est donc trs vite limit.

Deuxime type : Firewalls labors : stateful


Il s'agit de la premire des deux rponses 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, plutt que d'autoriser ou non un port 1433, on autorisera les demandes de connection en provance du rseau local et les rponses externes. On peut aller plus loin, en exigeant par exemple qu'un paquet entrant ne soit autoris que s'il rpond une requte 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 empcher lres requtes DNS extrieures, le cas chant, ou interdire les connections extrieures voulues (ICQ et autres). Par ailleurs, il faut examiner si le firewall connat tous les protocoles utiliss sur le rseau ! En effet, certains d'entre eux ncessitent 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 rdaction. Le choix d'un firewall stateful repose donc sur cet examen, mais aussi sur son mcanisme de fonctionnement interne. En effet, ce type de filtrage tend ralentir le rseau, et pose un problme en cas de paquets mal forms. Certains firewalls statefuls examinent les en-tte TCP pour tablir la position du paquet dans la transaction (SYN, ACK, etc.), ce qui amliore la performance et la fluidit, et limite les besoins du tampon de la machine filtrante : un simple examen suffit dcider du sort du paquet. Cependant, si une telle optique parat attirante, elle offre peu de protection face aux paquets forgs manuellement, et spcifiquement destins tromper ce type de systme (un attaquant extrieur envoie un paquet avec les drapeaux SYN ACK au lieu de SYN seul, ce qui laisse croire au firewall que ce paquet rpond une demande de connection interne, et le laisse passer). Un autre mcanisme consiste donc garder en mmoire les transactions en cours pendant une certaine dure (souvent de l'ordre de la minute), afin d'tablir prcisment 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 problme est aussi de savoir quelle est la dure ncessaire de ce tampon (le temps du timeout du keep alive, ou plus ?). Enfin, ce type de firewall, comme le premier, ne protge pas compltement le rseau d'attaques sur des ports autoriss ! Ainsi, on pourra tout fait autoriser la connection de la base SQL S erver voque plus haut, sans raliser que la requte envoye est un 'drop database', ce que le pare feu ne prend pas en compte. De mme, de nombreuses failles de IIS se fondent sur des requtes sur le port 80, qui sont a priori autorises, puisque 'naturelles' !

Troisime type : proxy applicatif


Il s'agit de la rponse la plus rcente aux problmes voqus plus haut. L, le firewall joue un rle proche de celui du proxy, c'est dire qu'il traite les demandes en lieu et place du rseau interne, examine les rponses du rseau externe, et dcide de la politique appliquer en consquence.

L'intrt 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'extrieur, sera rejet systmatiquement. L'objectif est de dterminer 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 dform (ainsi, un 'select * form clients' pourra tre lu comme 'select * from clients', mais pas un 'select from clients'), mais aussi de reprer 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 complts de faon 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 connat le protocole filtr. Pourquoi 'toto or 1=1 est-il inacceptable comme mot de passe dans un formulaire1 ? La consquence est d'une part qu'il faut que tous les protocoles utiliss sur le rseau soient pris en charg e par le firewall, ce qui interdit certains protocoles, trop rares ou qui ne sont pas matriss par les concepteurs de la solution choisie, d'autre part s'attendre ce que ce type de firewall prsente des problmes de fonctionnement, lis certaines bizarreries des protocoles, auxquelles les concepteurs n'ont pu faire face (c'est le cas des nombreux buffer overflows dont la possibilit est rgulirement dcouverte dans tel ou tel protocole, et qu'videmment les concepteurs du proxy applicatif install antrieurement dans l'entreprise n'ont pas protg, ou de 'surprises' qui font qu'en filtrant telle excution on interdise telle autre dont on a besoin et qui ne semble pourtant pas lie directement la premire). Par ailleurs, la cration de ce type de produit consiste implmenter une foule de protocoles sur une application supplmentaire, ce qui ouvre la porte bien sr de nombreuses failles spcifiques, en plus des failles propres aux protocoles ! (un exemple typique2 est le processus TCP CONNECT, aut oris par de nombreux proxies applicatifs, et pour cause (!), mais qui permettaient du coup d'utiliser le firewall comme relais d'attaque vers un autre systme !). Enfin, il faut noter que la mise en oeuvre de ce type de protection ralentit considrablem ent le rseau, puisqu'il ne s'agit plus d'examiner chaque paquet l'un la suite de l'autre, mais bien toute la squence 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. Idalement, on mettra en place un proxy applicatif, prcd d'un firewall stateful. Mais il faudra garder en mmoire que la solution implmente, si elle est fonctionnelle un instant t, ncessite cependant une surveillance permanente afion de dtecter les faiblesses qu'elle ne corrige pas, ou celles nouvellement apparues.

Mise en place des firewalls


Une fois que les principes de ce que l'on veut installer sont clairs, il convient d'examiner quel emplacement du rseau 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 dtermin deux types : les routeurs quips de fonction de firewalling, et les firewalls positionns sur des machines spcifiques.

Routeurs/switches Principes
Ces deux outils d'interconnection peuvent tre paramtrs 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 fonctionnalits de base de ces objets, puisqu'un switch fonctionne en couche 2, et ne se proccupe n ormalement pas de l'adresse IP, et encore moins du protocole, et le routeur ne s'intrsse supposment qu' la couche 3. L'implmentation 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'accs passent en mode tendu ces dernires annes, 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 considrablement le travail de routage. On a donc souvent tendance limiter l'examen des en-ttes la prsence ou l'absence d'un flag SYN. Par ailleurs, ce type de fitrage prsente deux faiblesses majeures : d'abord, le routeur est crdule ! Il croit le champ adresse-source : il est donc susceptible de rpondre au spoofing IP3. Par ailleurs, un routeur transmet toujours un paquet de moins de 68 o ctets (RFC 791). Or la constitution d'un paquet TCP permet de placer le flag SYN vers la fin de cette limite4, et, mme en son absence, un routeur transmettra le paquet, ce qui autorise un hack fragment. Certains routeurs plus rcents et plus volus ont des optimisations dans ce domaine, mais ils restent coteux. 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'accder au port 153 du serveur marketing, par exemple, mais pas dans l'ide de faire office de firewall complet.

Mise en place
Le routeur sera connect en gnral l'Internet. Celui-l fera l'objet d'un paramtrage interdisant le spoofing (on refuse le rseau interne s'il entre par l'Internet) et on ne filtre pas en sortie. Les routeurs internes au rseau auront le paramtrage requis par la disposition spcifique locale, comme dcrit plus haut (exemple comptabilit-marketing), et ne filtreront pas l'Internet.

Firewalling Principes
Nous n'voquons ici que le cas du Firewall Stateful. Dans une situation idale, il se place derrire le routeur connect l'internet, et dispose de deux sorties : l'une vers un brin rseau qui reprsente le LAN, un autre vers un autre sous-rseau, qui contient les machines lisibles depuis l'Internet, telles que serveur de mail ou serveur Web. Ces machines sont accessibles, et leur compromission, idalement, n'affecte pas le LAN. Elles sont en quelques sortes isoles,

et constituent une forme de tampon entre l'intrieur et l'extrieur. On appelle parfois cette zone une DMZ (De Militarised Zone, en rfrence au no man's land cr entre les deux Cores aprs la guerre). On verra plus bas que ce type de firewall filtre un paquet en entre, forward ou sortie, c'est dire au moment o il pntre dans le firewall, au moment o il doit circuler dans le firewall, ou en sortie aprs traitement. Ce procd permet notamment de rejeter certains paquets avant qu'ils n'affectent la pile IP du firewall lui-mme.

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 entres et sorties en port 25 du serveur smtp. Du rseau interne vers la DMZ, on autorisera les flux type smtp, pop et http, ainsi que les accs ssh depuis les IP internes des administrateurs.

Proxy applicatifs Principes


Bien qu'on dcrive cette implmentation comme reprsentant le niveau le plus haut du filtrage, on retiendra cependant qu'elle implique un ralentissement notable de flux du rseau : quoi qu'en disent les fabricants, un proxy applicatif, par dfinition, fonc tionne en couche 7 ! Il faut donc remonter les couches, ce qui est plus long mcaniquement que de filtrer en couche 3 ou 4. Par ailleurs, on gardera en mmoire les rserves mises plus haut.

Mise en place
Dans la mesure du possible, on positionnera ce s dispositifs en renforcement des firewalls statefuls, en accs des machines supportant les applications stratgiques (et elles seules). Cet outil pourra donc tout fait tre positionn en plusieurs endroits du rseau, avec un paramtrage spcifique chaque point. La difficult provient du fait que ce type de filtre permet en gnral un firewalling stateful, et qu'on tend soit les positionner la position des firewalls statefuls, ce qui pose un problme de dbit 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 pntration bases sur les protocoles. Dans le cas d'une implmentation uniqu e, la position firewall reste privilgier.

Conclusion
La mise en place d'un firewall reste une tape importante dans une dmarche de scurit, mais elle doit rester un simple outil. Un rseau, mme protg par un pare-feu, reste vulnrable. Ds lors qu'on DROP certains paquets, une pirate attentif remarquera videmment qu'un tel paquet devrait produire un RESET et non une absence de rponse. Il en dduira donc la prsence du firewall et pourra reconstituer ses rgles, dtecter 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 dtecter ces tentatives. On pourra d'ailleurs s'aider d'outils de dtection d'intrusion, comme snort, qui reste, mme s'ila beacuoup t dcri (mais c'est souvent une sorte de mode), l'un des meilleurs IDS disponible grce son excellente base de donnes sur les outils d'intrusion. Mais ceci est l'objet d'un autre cours...