Table des matières

Les Firewalls

Dans la page précédente, nous avons fait du « firewalling » sans le savoir. Pour donner quelques indications de plus, il est nécessaire de se pencher d'un peu plus près sur les diverses méthodes de construction d'un « firewall ».

D'abord, c'est quoi, un « firewall » ?

Typiquement, une installation complète contient :

Les trois types de communications marquées 1,2 et 3 sur l'illustration seront donc soumis à des règles de passage différentes. Le dispositif qui va permettre d'établir ces règles de passages s'appelle un firewall. Techniquement, ce pourra être un logiciel de contrôle installé sur un routeur.

Nous aurons, par exemple :

Le routeur cumule ici deux fonctions :

Bien entendu, qui peut le plus peut le moins, il peut ne pas y avoir de DMZ, si l'on n'a pas besoin d'exposer de serveurs sur le Net.

Sur des petites structures, la DMZ peut être implantée sur le routeur lui-même. En effet, un routeur peut très bien n'être rien d'autre qu'un serveur avec plusieurs interfaces réseau et un logiciel de routage. Ce n'est bien entendu pas une solution très « propre » au sens de la sécurité.

Les trois passages

Revenons à notre schéma initial.

1- Entre le réseau privé et le Net

Toujours typiquement, ce sont les clients du réseau (les utilisateurs) à qui l'on va donner des possibilités d'accéder au Net comme par exemple le surf ou la messagerie. Toutes les requêtes partent du réseau privé vers le Net. Seules les réponses à ces requêtes doivent entrer dans cette zone. Les accès peuvent être complètement bridés (les clients du réseau privé n'ont aucun droit d'accès vers le Net, ça nuit à leur productivité. Seul le patron y a droit). Ou alors, les utilisateurs ne pourront consulter qu'un nombre de sites limités, dans le cadre de leurs activités professionnelles exclusivement. Très généralement, cette zone est construite sur une classe d'adresses privées et nécessite donc une translation d'adresse pour accéder au Net. C'est le routeur qui se chargera de cette translation.

2- Entre la DMZ et le Net

Ici, nous avons des serveurs qui doivent être accessibles depuis le Net. Un serveur Web, un serveur de messagerie, un FTP… Il faudra donc permettre de laisser passer des connexions initiées depuis l'extérieur. Bien entendu, ça présente des dangers, il faudra surveiller étroitement et ne laisser passer que le strict nécessaire.

Si l'on dispose d'adresses IP publiques, le routeur fera un simple routage. Si l'on n'en dispose pas, il devra faire du « port forwarding » pour permettre, avec la seule IP publique dont on dispose, d'accéder aux autres serveurs de la DMZ. Cette technique fonctionne bien sur un petit nombre de serveurs, mais devient très vite un casse-tête si, par exemple, plusieurs serveurs HTTP sont présents dans la DMZ.

3- Entre le réseau privé et la DMZ

Les accès devraient être à peu près du même type qu'entre la zone privée et le Net, avec un peu plus de souplesse. En effet, il faudra

En revanche, depuis la DMZ, il ne devrait y avoir aucune raison pour qu'une connexion soit initiée vers la zone privée.

Les divers types de FireWall

Bien. Maintenant que nous savons à peu près ce que l'on peut et ce que l'on ne peut pas faire entre les diverses zones, voyons comment construire ce firewall.

Il y a déjà deux moyens différents de s'y prendre. Soit l'on travaille au niveau TCP et UDP en s'intéressant aux adresses IP des sources et des cibles, ainsi qu'aux ports employés, nous ferons du filtrage de paquets, soit l'on travaille au niveau de l'application (HTTP, SMTP, FTP). Nous ferons alors du « proxying ».

Rien d'ailleurs n'interdit de faire les deux.

Si l'on travaille au niveau des paquets, il y a encore deux méthodes, l'une triviale et l'autre plus fine. Pour comprendre la différence entre les deux, ce n'est pas facile. Disons qu'une connexion entre un client et un serveur peut engendrer plusieurs connexions sur des ports différents.

Sans aller très loin, une simple consultation de page web suffit à expliquer ce qu'il se passe. Si le client envoie bien la requête toujours sur le port 80 du serveur, il attend en revanche la réponse sur un port qu'il va choisir aléatoirement, généralement en dessus de 1024. Comme le port de réponse est aléatoire, ça va être difficile de laisser passer les réponses sans ouvrir tous les ports au dessus de 1024 en entrée vers la zone privée.

Pour être efficace, il faut être capable d'assurer un suivi de la connexion, en analysant la requête initiale pour découvrir le port sur lequel le client recevra la réponse et agir dynamiquement en fonction. C'est ce que l'on appelle le suivi de connexion ( »conntrack » en jargon informatico-anglo-saxon).

Le Firewall par filtrage simple de paquets ( « stateless »)

C'est donc le plus trivial. Il ne sait que vérifier si les « sockets » (Couple adresse IP : port) source et destination sont conformes ou non à des autorisations de passage. Dans la pratique, si la machine cliente d'IP 217.146.35.25 doit pouvoir accéder au serveur web 124.8.3.251 et, bien entendu, recevoir ses réponses, nous dirons en français :

Si nous voulons étendre à tous les serveurs web possibles, nous ne pourrons plus tenir compte de l'IP des serveurs, ça aura pour conséquence que tout le Net pourra accéder à 217.146.35.25 sur tous les ports au dessus de 1024.

Si nous voulons que toute la zone privée puisse accéder à tous les serveurs web du Net, alors, tout le réseau privé sera accessible sur les ports au dessus de 1024.

L'exemple est minimaliste, les IP des clients sont des IP publiques, il n'y a pas de translation d'adresse mise en oeuvre, ce qui rend les risques maximums. Dans la pratique, le cas est rarissime. Il ne sert ici qu'à montrer les limites de ce filtrage simple. Notez qu'avec de tels systèmes, la translation d'adresse est de toutes manières rendue impossible. Pour faire de la translation d'adresse, il faut être capable de suivre les connexions.

Le Firewall par suivi de connexion ( « statefull »)

Ici, nous mettons en oeuvre le suivi des connexions. Par un procédé que nous conserverons obscur pour le moment, le firewall va savoir si une connexion est :

Là, ça va devenir plus facile. Nous dirons en français :

Certains suivis de connexions ne sont pas simples à faire et nécessitent des algorithmes spécifiques, comme principalement le FTP.

Netfilter, avec son interface IPTables, dans les noyaux 2.4 de Linux savent très bien travailler de cette manière.

Les FireWalls applicatifs

Ici, on ne travaille plus au niveau du transport, mais au niveau de l'application, c'est à dire au niveau du protocole applicatif, comme HTTP, FTP ou autre. Un tel « FireWall » est en réalité un serveur « Proxy », c'est à dire que le client s'adressera toujours à lui, quelle que soit la cible finale et n'acceptera de réponse que de sa part. Le Proxy reformule la requête pour son propre compte vers le Net et, lorsqu'il reçoit la réponse, la transmet au client comme si c'était lui qui répondait directement.

En gros, ça veut dire que le proxy est le seul à accéder au Net et qu'il est donc le seul à risquer de subir des attaques.

Cette méthode, si elle est simple à mettre en oeuvre avec des clients HTTP ou FTP, qui sont pratiquement tous prévus pour fonctionner dans ce cadre, peut poser des problèmes avec des applications qui ne le prévoient pas, comme c'est souvent le cas pour les clients de messagerie.

Avantages et inconvénients

Reprenons à l'envers.

Le Proxy

Ca pourrait apparaître comme la solution ultime, puisqu'il y a effectivement une barrière entre le Net et la zone protégée. Sauf que ces logiciels sont complexes et qu'ils peuvent contenir des bugs que les pirates, tôt ou tard, découvriront et exploiteront pour passer quand même. De plus, ils consomment pas mal de ressources et nécessitent des machines relativement musclées.

Le FireWall « StateFull »

C'est pas mal, c'est souple à paramétrer, ça consomme peu de ressources, mais le suivi de connexion est délicat et, s'il y a un bug dans le système, ça ouvre des portes aux pirates. Les premières versions de Netfilter en ont présenté beaucoup, surtout sur les protocoles délicats comme FTP.

Le Firewall « StateLess »

C'est très simple, ça consomme très peu de ressources, il n'y a quasiment aucun risque de bug, mais ça ouvre trop de portes pour qu'un protocole applicatif ne risque pas de rester planté à un moment ou à un autre.

Vous le voyez, il n'y a pas de solution miracle.

Et avec, ça va mieux ?

Oui, bien sûr, un firewall est indispensable. Pour autant, se croire à l'abri parce que son firewall a passé les tests de sécurité classiques relève de la plus pure utopie. Pourquoi ?

Il n'existe pas de firewall inviolable, tout simplement. Pour plusieurs raisons :

Nous pouvons multiplier les barrages en les diversifiant, mais ça ne procure pas une protection absolument certaine. Pour obtenir une sécurité maximale, (mais jamais absolue), il faut travailler à tous les niveaux :

Vous le voyez, la sécurité informatique oblige à devenir complètement paranoïaque. Mais réfléchissez bien… Dans la vie, c'est pareil. Si vous voulez vivre avec un risque zéro, vous aurez les mêmes problèmes :)

Sueurs froides