Firewalls « Stateless » et « Stateful »

Le mot Firewall vient de la sécurité physique (incendie) et désigne une « porte/paroi coupe-feu » qui empêche de propager l’incendie d’une partie d’un bâtiment à l’autre. De manière similaire, un Firewall va contenir les menaces réseau pour empêcher qu’elles ne se propagent pas plus loin dans le réseau de l’entreprise.
Le premier firewall de « première génération » est né en 1992 (Digital), tandis que  son évolution dite de « deuxième génération » est développée par Checkpoint dès 1994 pour se démocratiser rapidement.

Les firewalls sont des équipements réseau de contrôle d’accès multi-interfaces (une gateway dans le vocabulaire TCP/IP) qui embarquent une politique de sécurité leur indiquant ce qu’ils doivent faire avec les paquets qu’ils reçoivent (Rule-Based Access Control). Un firewall qui n’implémente aucune règle de politique de sécurité, qui ne filtre rien, n’est rien d’autre qu’un routeur.
Typiquement, un firewall est un équipement réseau qui est placé « en coupure » d’un trafic, c’est-à-dire que le trafic passe obligatoirement par lui. Les firewalls les plus basiques travaillent en couche Internet et Transport.

Les firewalls captent les paquets qui proviennent de leurs cartes réseau (niveau IP) et, avant de les transférer à la bonne interface, interrogent les règles de la politique de sécurité qu’ils embarquent. Pour que le firewall fonctionne correctement, il doit, tout comme un routeur, être en mesure de capter le trafic entrant (ingress ou inbound) et sortant (egress ou outbound). On a coutume de distinguer les firewalls avec maintien (compréhension) d’état d’une connexion (stateful) et ceux sans maintien d’état (stateless). Aujourd’hui, il ne me semble pas qu’il soit encore possible de rencontrer des firewalls sans maintien d’état …

Les firewalls sans maintien d’état (stateless)

Ils sont également appelés Filtrage Statique de Paquets (Static Packet Filtering firewalls) et sont considérés comme de « première génération ». Ils tiennent compte uniquement des éléments statiques d’une connexion TCP, en se basant sur les informations contenues dans l’en-tête du paquet (l’adresse IP source, destination, le port source et le port destination).
Parce qu’ils ne maintiennent pas d’information sur le contexte d’une connexion TCP, leurs règles doivent être très explicites et distinguer chaque connexion entrante et sortante, même si elle fait partie d’une session déjà autorisée, c’est-à-dire si un client a déjà été autorisé à communiquer avec un serveur distant et que la connexion n’a pas encore été terminée par l’un des deux protagonistes.
L’absence de maintien d’état a deux conséquences : sur l’administration et sur la sécurité des échanges.
Sur l’administration d’abord, parce qu’il faudra coder une règle pour chaque sens de connexion, et que le logiciel de firewall examinera les règles à chaque fois qu’il recevra un paquet. Il travaillera donc davantage et la politique contiendra beaucoup de règles pour tenir compte de chaque sens de connexion.
Sur la sécurité des échanges ensuite, parce que le logiciel de firewall laissera passer un paquet ACK par exemple, sans tenir compte de l’existence préalable d’un paquet SYN … c’est-à-dire que si une règle explicite autorise un serveur légitime à répondre au client, une machine pirate qui spooferait (usurperait) l’adresse IP du serveur légitime sera en capacité d’envoyer des paquets au client, sans que le firewall ne trouve rien à redire. De nombreuses attaques ont reposé sur cette absence de maintien de contexte.

Les firewalls avec maintien d’état (stateful)

Ils tiennent compte de l’état d’une connexion TCP en cours (jusqu’à expiration de celle-ci, selon les paramètres  définis) : soit par une fermeture protocolaire (paquet FIN), soit par expiration de la connexion, à cause d’un incident réseau (l’hôte ne répond pas dans les temps impartis par exemple). La gestion de la session étant pris en charge par la couche Application du modèle TCP/IP, ces firewalls de « deuxième génération » travaillent donc sur toute la pile protocolaire.
Ces firewalls possèdent une « table des connexions » qui fonctionne comme une mémoire cache. Tant que sa table possède en mémoire une initialisation de connexion (valable uniquement pour TCP qui fonctionne en mode connecté), il pourra laisser passer les paquets correspondants à cette connexion jusqu’à la fin de celle-ci.
Deux implications également pour l’administration et pour la sécurité.
Pour l’administration d’abord, on ne codera pas une règle pour chaque sens de connexion pour une même communication, une seule règle suffit, celle qui autorise l’initialisation de la connexion (qu’elle soit entrante ou sortante lui est égal). Tous les paquets correspondant à un même échange TCP ne nécessiteront pas de parcourir toutes les règles de sécurité séquentiellement, ils seront acceptés implicitement. Il faudra donc moins de règles explicites comparé au firewall sans maintien d’état.
Pour la sécurité ensuite, si une machine tente de rejouer une partie de l’échange TCP en dehors d’une connexion ne cours (mémorisée dans la table des connexions), en envoyant un paquet ACK par exemple sans qu’aucun paquet SYN d’établissement de la connexion n’ait été envoyé, alors le paquet ACK sera rejeté automatiquement par le firewall, sans même passer par les règles de sécurité de sa politique. L’effet pervers de cette fonctionnalité, c’est que la mémoire peut être saturée si trop de connexions persistantes s’accumulent, ralentissant le firewall ou tout simplement l’empêchant d’accepter toute nouvelle connexion (déni de service).

Les deux types de politique de sécurité : whitelist ou blacklist

Bien que les termes sont davantage utilisés par les proxies (qui peuvent être vus comme des firewalls applicatifs particuliers acceptant ou bloquant l’accès à des URLs), la philosophie de filtrage est identique. Nous avons deux choix à faire : dans le mode blacklist, on accepte par défaut tous les paquets, et il faudra alors coder des règles bloquant les connexions qu’on souhaite interdire (la liste des connexions explicitement bloquées) ; dans le mode whitelist, on bloque implicitement toutes les connexions (en excluant en général les connexions d’administration du firewall, contenues dans un jeu de règles dites implicites) et on autorise une à une les règles de manière explicite, sur la base des informations simples telles que : l’adresse source, l’adresse destination, le port (ou service réseau) ou encore en ajoutant des limites d’horaire. On appelle la règle générique qui bloque tout trafic une règle « drop all » (rejetant tout).
Je n’ai personnellement jamais vu de politique de sécurité de type blacklist sur un firewall, seulement sur un proxy.

Un exemple de politique de sécurité exigerait par exemple que « seules les connexions en SSH sont autorisées pour administrer à distance un serveur ou un équipement réseau ». Le jeu de règles (appelé souvent abusivement « politique de sécurité ») devra donc posséder au moins deux règles explicites :

1/ 192.168.1.10 (adresse source de l’administrateur) –> 172.17.0.182 (adresse destination d’un serveur) –> TCP/22 (SSH) –> Accept –> Log

2/ Any (toute adresse) –> Any (toute adresse) –> Any (tout port) –> Drop

La première règle autorise bien ce qui est décrit dans la politique de sécurité. La seconde est, par facilité et par sécurité, ce qui exclut toute autre connexion non explicitement autorisée.

Dans la vraie vie, le fait qu’il existe cette règle de rejet par défaut, pose des problèmes administratifs car cela suppose que toutes communications de toutes les applications et de tous les systèmes ont été correctement cartographiées. Comme ce n’est pas toujours le cas, c’est une source de plaintes répétées des responsables d’applications ou d’utilisateurs qui ne parviennent plus à travailler comme avant. Voilà pour l’aspect pessimiste. D’un autre côté, c’est une excellente manière d’enfin cartographier les flux réseau d’une entreprise, pour peu qu’on ait du temps devant soi et beaucoup de sang froid. Voilà pour l’aspect optimiste …
Mais cela met en avant un point très important : on n’installe de firewall dans une entreprise que si une cartographie des flux a été préalablement faite, de manière exhaustive au moins pour les flux les plus critiques !

Les nouvelles technologies de firewall (nouvelle génération)

Les « Next Generation Firewalls » sont des firewalls de « troisième génération » qui ne se contentent pas sagement de travailler à la couche Internet et Transport, offrant par la même occasion des fonctionnalités de VPN et de Network Address Translation (NAT)/Port Address Translation (PAT), mais vont prendre en compte la couche applicative également. Plus clairement, plutôt que d’avoir des équipements distincts, les firewalls embarqueront des Proxies et des Intrusion Prevention Systems (IPS), qui seront capables d’examiner plus d’informations jusqu’à la couche Application. Cela règle le problème d’efficacité du firewall, car jusqu’à la deuxième génération, les firewalls étaient incapables de savoir ce qui était conforme ou non à l’intérieur de protocoles applicatifs de type FTP et HTTP par exemple. Cela a conduit à des techniques d’évitement du firewall par encapsulation protocolaire … il suffisait de cacher du code malveillant dans un paquet sur un port de service autorisé (HTTP par exemple) pour le délivrer à destination en profitant d’une connexion légitime. L’examen des informations de la couche Applicative, à sensiblement réduit les techniques classiques d’évitement de firewall.
Parmi les tchnologies qui sont aujourd’hui courantes, on peut citer Deep Packet Inspection (DPI), IPS (Intrusion Detection System) un peu en repli, filtrage de sites web (auparavant une fonctionnalité de proxy), gestion de la qualité (QoS), etc. Le DPI n’a fonctionnellement rien de révolutionnaire. Tout équipement fonctionnant avec TCP/IP est potentiellement capable d’examiner les paquets jusqu’au la « charge utile » (payload). Ce qui a permis l’explosion de cette « nouvelle » fonctionnalité c’est l’amélioration de la puissance des équipements qui peuvent scruter les paquets sans diminuer leurs performances, alors qu’auparavant il fallait utiliser des équipements dédiés à chaque couche TCP/IP ou presque.

Les différentes architectures de Firewall

Le Bastion host

Un bastion est, dans la terminologie des fortifications, une avancée de la muraille, ayant deux faces vers l’ennemi et deux faces vers chaque partie de la muraille, pour offrir plus d’angle de défense. De manière similaire, un « firewall bastion » sera un point de contrôle d’accès basique en frontal d’Internet, généralement représentant la seule coupure de trafic depuis l’externe vers l’interne.
Le bastion est considéré comme la partie la plus exposée des défenses périmétriques, sans autre défense, pour ralentir et prendre en charge le plus gros des attaques externes.
Dans cette architecture, le réseau est fonctionnellement découpé en deux zones : la « zone de confiance » (réseau interne, Trusted Network) et la « zone non fiable » (Internet ou réseau externe, Untrusted Network).

….

> Le document du NIST SP800-41 (révision 1) présentant les technologies de firewall.