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 ».

Typiquement, une installation complète contient :

• Un réseau privé, dont on considère (souvent à tort) qu'il ne sera pas utilisé pour attaquer notre système informatique. Dans cette zone, il n'y a que des clients du réseau et des serveurs qui sont inaccessibles depuis l'Internet. Normalement, aucune connexion, au sens TCP du terme, aucun échange, au sens UDP du terme,  ne peuvent être initiés depuis le Net vers cette zone.
• Une « DMZ » (Zone DéMilitarisée), qui contient des serveurs accessibles depuis le Net et depuis le réseau privé. Comme ils sont accessibles depuis le Net, ils risquent des attaques. Ceci induit deux conséquences :
  • Il faut étroitement contrôler ce que l'on peut faire dessus depuis le Net, pour éviter qu'ils se fassent « casser » trop facilement,
  • Il faut s'assurer qu'ils ne peuvent pas accéder aux serveurs de la zone privée, de manière à ce que si un pirate arrivait à en prendre possession, il ne puisse directement accéder au reste du réseau.

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 réseau privé dans une classe d'adresses IP privées, comme 192.168.0.0,
• la DMZ dans une autre classe privée comme 192.168.1.0 ou, si l'on a les moyens, dans un morceau de classe publique, de manière à pouvoir accéder à ces machines depuis le Net sans translation d'adresse,
• une adresse publique attribuée au routeur sur le Net par le FAI (Fixe ou dynamique. Dans ce type d'installation, il vaut mieux qu'elle soit fixe).

Le routeur cumule ici deux fonctions :

• Le routage proprement dit, pour permettre aux paquets de passer d'une zone à l'autre alors que ces zones ne sont pas situées dans le même réseau IP,
• Le filtrage du trafic entre les diverses zones, c'est la fonction de FireWall.

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é.

Revenons à notre schéma initial.

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.

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.

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

• Mettre à jour les serveurs web,
• Envoyer et recevoir les messages, puisque le SMTP est dedans
• Mettre à jour le contenu du FTP (droits en écriture).

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

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).

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 :

• Les paquets venant de 217.146.35.25 vers 124.8.3.251, port 80 passent.
• Les paquets venant de 124.8.3.251, port 80 vers 217.146.35.25, ports >=1024 passent.

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.

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 :

• NEW.
  C'est à dire qu'elle est créée. Par exemple, un client envoie sa première requête vers un serveur web.
• ESTABLISHED.
  Cette connexion a déjà été initiée. Elle suit dans les faits une connexion NEW que l'on a déjà vu passer.
• RELATED.
  Ce peut être une nouvelle connexion, mais elle présente un rapport direct avec une connexion déjà connue.
• INVALID.
  Un paquet qui a une sale tête, un paquet qui n'a rien à faire là dedans, un paquet qui sent l'ail.

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

• Toutes les connexions NEW qui viennent du réseau privé et qui vont sur le NET port 80 sont acceptées. Tous les clients du réseau privé peuvent interroger tous les serveurs web du Net.
• Toutes les connexions RELATED et ESTABLISHED qui viennent du Net port 80 sont autorisées à rentrer. Les serveurs peuvent répondre.
• Toutes les connexions RELATED et ESTABLISHED qui sortent du réseau privé vers le Net sont autorisées à sortir. Les connexions peuvent se poursuivre, même si elles ouvrent de nouvelles connexions.
• Toutes les connexions INVALID, d'où qu'elles viennent sont jetées à la poubelle, on n'aime pas l'odeur de l'ail.

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.

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.

Reprenons à l'envers.

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.

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.

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.

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 l'avons vu, les systèmes puissants comme un firewall statefull ou un proxy renferment des logiciels complexes qui ne peuvent pas être totalement exempts de failles. Il suffit au pirate d'en trouver une.
• Les règles de filtrage placées sur ces outils sont obligatoirement un compromis entre la sécurité maximale et une certaine liberté d'usage de l'Internet. Là où il y a compromission, il y a aussi faiblesse.
• Les proxys travaillent sur les couches hautes, on peut les percer en passant sur les couches basses.
• Les filtres de paquets travaillent sur les couches basses, on peut les percer en exploitant les failles des couches hautes.

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 :

• Configurer ses serveurs avec le plus grand soin, en éliminant tous les risques connus à leur niveau,
• s'assurer que l'on n'a pas dans un coin un serveur qui tourne sans qu'on le sache. Ne riez pas, le cas est assez fréquent,
• protéger le tout avec un système de filtrage efficace, bien adapté à ses besoins,
• surveiller avec le plus grand soin tout se qu'il se passe, aussi bien sur les serveurs que sur les filtres, pour détecter le plus rapidement possible toute activité anormale,
• avoir perpétuellement à l'esprit qu'il y a forcément quelque part une faille que l'on ne connaît pas, et qu'un pirate peut trouver.

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 :)

• Votre réseau est bien à l'abri, derrière tous les murs pare-feu de la création, avec une surveillance de tous les instants sur les points d'accès au Net. Mais dans votre réseau, il y a des utilisateurs qui se servent de portables. Lorsqu'ils rentrent chez eux, ils connectent leur portable au Net sans aucune sécurité et se gavent de virus, de backdoors et autres spywares. Le lendemain, ils reviennent se connecter sur votre beau réseau tout propre.
• Un proxy travaille dans les couches hautes. On peut le casser en passant par les couches basses ou en exploitant des failles logicielles. Donc, on ajoute aussi un filtre de paquets. Mais le filtrage de paquets peut plus ou moins être contourné, si l'on arrive à installer dessus une autre pile IP, parallèle à celle qui est utilisée par le filtre. Une sorte de super backdoor qui permettra de construire un routeur pirate à côté du votre, très étroitement surveillé, et qui ne s'apercevra de rien.