Comprendre les pare-feu avec ou sans état pour l'inspection des protocoles avec état

Les pare-feu sont depuis très longtemps un élément fondamental de la stratégie de cybersécurité des entreprises. Au fil des ans, les produits ont fait l'objet d'améliorations et d'ajouts massifs de fonctionnalités. Une caractéristique particulière qui remonte à 1994 est l'inspection avec état.

Qu'est-ce qu'une inspection avec état ?

L'inspection dynamique, ou filtrage dynamique des paquets, consiste pour un pare-feu à filtrer les paquets de données en fonction de l'ÉTAT et du CONTEXTE des connexions réseau. Voyons ce que signifient les termes "état" et "contexte" pour une connexion réseau.

État

Pour comprendre l'état de la connexion, utilisons le protocole de réseau TCP, basé sur la communication entre deux points d'extrémité. Dans le protocole TCP, les quatre bits (SYN, ACK, RST, FIN) des neuf bits de contrôle assignables sont utilisés pour contrôler l'état de la connexion. Les pare-feux peuvent appliquer une politique basée sur cet état de connexion ; cependant, vous devez également tenir compte de tout paquet restant, retransmis ou retardé qui passe par le pare-feux après la fin de la connexion.

Prenons un exemple simpliste de suivi d'état dans les pare-feux :

1. Lorsqu'une application client établit une connexion par le biais d'une poignée de main à trois voies, la pile TCP active le drapeau SYN pour indiquer le début de la connexion. Ce drapeau est utilisé par le pare-feu pour indiquer une NOUVELLE connexion.
2. Le serveur répond à la connexion en envoyant un SYN + ACK. À ce moment-là, le pare-feu a vu des paquets provenant des deux côtés et il fait passer son état de connexion interne à ESTABLISHED. Toutefois, du point de vue de TCP, la connexion n'est pas encore totalement établie tant que le client n'a pas envoyé de réponse (ACK).
3. De même, lorsqu'un pare-feu voit un paquet RST ou FIN+ACK, il marque l'état de la connexion pour suppression, et tous les futurs paquets pour cette connexion seront abandonnés.

Pseudo-état

Tous les protocoles de mise en réseau ne disposent pas d'un état comme TCP. UDP, par exemple, est un protocole très couramment utilisé qui est par nature sans état. Les applications qui utilisent ce protocole maintiennent l'état à l'aide de la logique d'application ou peuvent fonctionner sans elle. Quelques applications populaires utilisant UDP sont DNS, TFTP, SNMP, RIP, DHCP, etc.

Le pare-feu dynamique actuel crée un "pseudo-état" pour ces protocoles. Par exemple, lorsqu'un pare-feu voit un paquet sortant tel qu'une requête DNS, il crée une entrée en utilisant l'adresse IP et le port de la source et de la destination. Il utilise ensuite ces données de connexion ainsi que les données de délai de connexion pour permettre au paquet entrant, tel que le DNS, de répondre.

Context

Le contexte d'une connexion comprend les métadonnées associées aux paquets, telles que

• Adresse IP et port des points d'extrémité source et destination
• Délai de réception du dernier paquet pour le traitement des connexions inactives
• Longueur du paquet
• Numéros de séquence et drapeaux TCP de la couche 4
• Données de la couche 3 relatives à la fragmentation et au réassemblage pour identifier la session du paquet fragmenté, etc.

Inspection avec ou sans état

La principale différence entre un pare-feu avec état et un pare-feu sans état est qu'un pare-feu avec état analyse le contexte complet du trafic et des paquets de données, en gardant constamment la trace de l'état des connexions réseau (d'où le terme "avec état"). Un pare-feu sans état analysera le trafic et les paquets de données sans avoir besoin du contexte complet de la connexion.

Examinons maintenant de plus près les pare-feu d'inspection avec ou sans état.

Pare-feu sans état

Comment fonctionne un pare-feu sans état ?

La figure 1 permet de comprendre le fonctionnement interne d'un pare-feu sans état. Un pare-feu sans état applique la politique de sécurité aux données du trafic entrant ou sortant (1) en inspectant les en-têtes de protocole du paquet. Il examine les couches OSI 2 à 4. Après l'inspection, un pare-feu sans état compare ces informations avec le tableau des règles (2). Il décide ensuite de l'action politique (4.a & 4.b) : accepter, refuser ou réinitialiser le paquet.

Figure 1 : Organigramme montrant les décisions de politique pour un pare-feu sans état

Quels sont les avantages d'un pare-feu sans état ?

• Moins gourmande en ressources : La recherche de politique est effectuée sur les données statiques des paquets et la table de politique, de sorte que la quantité de ressources de CPU et de mémoire requise pour effectuer la recherche est faible. Cette méthode est efficace pour les dispositifs de recherche de politique statique tels que les routeurs et les commutateurs utilisant des fonctions telles que les listes de contrôle d'accès (ACL).
• Pas d'augmentation de la latence : Le traitement supplémentaire n'ajoute pas ou très peu de temps de latence ou, en termes simples, de traitement des paquets à la vitesse de la ligne.

Quels sont les inconvénients d'un pare-feu sans état ?

• Filtrage limité : Un pare-feu sans état ne fonde sa décision que sur des données peu fiables provenant du pare-feu, ce qui offre une capacité de filtrage limitée.
• Configuration des ACL :la configuration et la gestion des ACL sur ces appareils sont sujettes à des erreurs à petite échelle et presque impossibles à grande échelle.

Permettez-moi d'expliquer les défis que représentent la configuration et la gestion des listes de contrôle d'accès à petite et grande échelle. Prenons tout d'abord le cas d'un déploiement à petite échelle.

• Les pare-feu sans état sont unidirectionnels par nature, car ils prennent des décisions stratégiques en inspectant le contenu du paquet actuel, quel que soit le flux auquel il appartient. Pour rédiger une politique avec précision, les deux côtés de la connexion doivent être inscrits sur la liste blanche d'un protocole de communication bidirectionnel tel que TCP. La rédaction de deux règles pour contrôler une seule connexion devient problématique.
• Pensez maintenant à un protocole comme FTP où il y a deux ensembles de connexions pour chaque transaction et où la connexion de données peut avoir un port négocié, même si l'heure de connexion est inconnue, il n'y a aucun moyen pour un pare-feu sans état de mettre cela sur liste blanche. Cette incapacité à rédiger des politiques pour toutes les applications crée une grande faille dans la sécurité.
• Un autre cas d'utilisation peut être celui d'un hôte interne qui établit la connexion avec l'internet externe. Comment créer une politique à l'aide d'une liste de contrôle d'accès (ACL) pour autoriser tout le trafic de réponse ? Cet outil n'a pas été conçu pour des contrôles de politique plus fins et n'est pas très utile pour un cadre de micro-segmentation où la politique est très fine et directionnelle par nature.

Passons maintenant au problème à grande échelle.

• Imaginons un instant que vous disposiez d'une baguette magique pour surmonter tous les problèmes décrits dans le paragraphe précédent. Même dans ce cas, les ressources telles que la TCAM (mémoire ternaire adressable par le contenu) sur le matériel du commutateur ou du routeur sont tellement limitées qu'à une certaine échelle, vous ne pouvez pas écrire une politique pour toutes vos applications en raison de l'épuisement de l'espace de la TCAM.
• Même dans le cas d'une mise en œuvre non matérielle, le nombre d'ACL pose de nombreux problèmes. Par exemple, un produit sur lequel j'ai travaillé dans le passé prenait trente minutes ou plus pour analyser et construire une table de recherche efficace (Policy Table dans la figure 1 ci-dessus) sur un système ACL largement configuré. Ce processus se déclenche à chaque fois qu'une règle est ajoutée ou supprimée. Pensez à un tel temps d'arrêt et à un tel impact sur votre activité critique pour des tâches quotidiennes aussi banales.

Pare-feu réflexifs AKA ACL réflexives

Une ACL réflexive, également appelée ACL de filtrage de session IP, est un mécanisme qui permet de mettre sur liste blanche le trafic de retour de manière dynamique. La plupart des processus de décision en matière de politique sont similaires à ceux du pare-feu sans état, à l'exception du mécanisme permettant d'identifier un nouveau processus et d'ajouter une entrée ACL dynamique automatisée sans état. Voyons la vie d'un paquet à l'aide du diagramme de flux de travail ci-dessous.

Figure 2 : Organigramme montrant les décisions politiques pour une ACL réflexive

Lorsqu'une ACL réflexive détecte une nouvelle connexion IP sortante (6 dans la figure 2), elle ajoute une entrée ACL dynamique (7) en inversant l'adresse IP et le port source-destination. La nouvelle liste dynamique de contrôle d'accès permet de valider le trafic de retour par rapport à cette liste. De même, le pare-feu réflexif supprime l'ACL dynamique lorsqu'il détecte des paquets FIN des deux côtés, un paquet RST ou un éventuel dépassement de délai. Ainsi, lorsque la session se termine ou est interrompue, tous les paquets parasites à venir sont abandonnés.

Quels sont les avantages d'un pare-feu réflexif ?

Le seul et unique avantage d'un pare-feu réflexif par rapport à un pare-feu sans état est sa capacité à mettre automatiquement sur liste blanche le trafic de retour. Cela permet d'éviter d'écrire manuellement la règle ACL inverse.

Quels sont les inconvénients d'un pare-feu réflexif ?

Les ACL réflexives agissent encore entièrement sur les informations statiques contenues dans le paquet. La raison en est que, bien qu'elles constituent une avancée par rapport aux ACL standard en termes d'écriture des règles pour le trafic inverse, il est facile de contourner l'ACL réflexive. Le pare-feu réflexif souffre des mêmes déficiences que le pare-feu sans état. Une façon de tester cela serait de fragmenter le paquet de sorte que les informations sur lesquelles l'ACL réflexive agirait soient réparties sur plusieurs paquets. De cette manière, l'ACL réflexif ne peut pas décider d'autoriser ou d'abandonner le paquet individuel. Un pare-feu dynamique, en revanche, est capable de réassembler les fragments entiers répartis sur plusieurs paquets, puis de fonder sa décision sur les données STATE + CONTEXT + paquet pour l'ensemble de la session.

L'autre inconvénient des ACL réflexives est qu'elles ne peuvent fonctionner qu'avec certains types d'applications. Par exemple : une application très courante, FTP, utilisée pour transférer des fichiers sur le réseau, fonctionne en négociant dynamiquement les ports de données à utiliser pour le transfert sur une connexion séparée du plan de contrôle. Les ACL réflexives étant statiques, elles ne peuvent mettre sur liste blanche que les connexions bidirectionnelles entre deux hôtes utilisant le même quintuple. Ils ne peuvent donc pas prendre en charge des applications telles que FTP.

Pare-feu dynamique

Un pare-feu dynamique agit sur l'ÉTAT et le CONTEXTE d'une connexion pour appliquer la politique de pare-feu. Pour comprendre le fonctionnement interne d'un pare-feu dynamique, reportez-vous à l'organigramme ci-dessous.

Figure 3 : Organigramme montrant les décisions de politique pour un pare-feu dynamique

Comment fonctionne un pare-feu dynamique ?

1. Recherche de 5 tuple : Lorsqu'un paquet arrive au pare-feu (1 dans la figure 3), il tente d'effectuer une recherche de flux à l'aide de cinq couples (IP source, port source, IP de destination, port de destination, protocole) dans une table appelée table de flux ou de connexion afin de trouver une correspondance (2). Cela diffère du pare-feu sans état dans lequel la recherche de 5 tuple est effectuée sur la table de politique plutôt que sur la table de flux. Le tableau des flux et les tableaux associés non illustrés dans la figure contiennent le STATE+CONTEXT de tous les flux vus précédemment.
2. Chemin rapide / traitement du plan de données : Si une entrée est trouvée, le paquet passe par le chemin rapide ou le traitement du plan de données. Le traitement simple du chemin rapide comprendra des contrôles de débit, un contrôle d'assainissement de la couche 3 de l'IP pour éviter la fragmentation & attaque basée sur le réassemblage, un contrôle d'assainissement de la couche 4 pour prévenir les attaques telles que le spoofing, le DOS, etc. Si le pare-feu peut effectuer des tests de la couche 7, il passera par des filtres supplémentaires appelés Application Layer Gateways (ALG). Si toutes les vérifications se déroulent sans problème, le paquet est transmis au saut suivant (3.b).
3. Chemin lent / traitement du plan de contrôle : Si la recherche de flux aboutit à un échec (3.a), on suppose que le paquet correspond à une nouvelle connexion et qu'il doit passer par des contrôles de politique supplémentaires. Dans le chemin de traitement de contrôle, le pare-feu ne vérifie pas seulement tout ce qu'il fait dans un chemin rapide, mais il décide également si cette nouvelle connexion est autorisée par la politique du pare-feu.
4. Recherche de politique : Le pare-feu effectue ensuite une recherche de politique en utilisant l'état et le contexte de la connexion (5).
5. Si une politique correspond et qu'une action est spécifiée pour cette politique, comme ALLOW, DENY ou RESET, l'action appropriée est prise (8.a ou 8.b).Les pare-feux dynamiques avancés peuvent également être informés du type d'inspection de contenu à effectuer. Le pare-feu en tient compte et crée une entrée dans la table de flux (9), de sorte que les paquets suivants pour cette connexion peuvent être traités plus rapidement en évitant le traitement du plan de contrôle.

Quels sont les avantages d'un pare-feu dynamique ?

• Meilleure protection : Un pare-feu dynamique assure une inspection complète du protocole en tenant compte de l'ÉTAT et du CONTEXTE du flux, éliminant ainsi une surface d'attaque supplémentaire et améliorant la gestion des vulnérabilités dans un système.
• Plus avancé :un pare-feu dynamique sert d'élément de base pour des pare-feu ou des passerelles de couche d'application plus avancés.
• Capacité de configuration : Un pare-feu dynamique comprend le flux du réseau et peut identifier les paquets de données d'un flux, ce qui permet de rédiger des règles simples pour les connexions bidirectionnelles ou les protocoles de réseau à pseudo-état.
• Protocoles complexes : Étant donné qu'un pare-feu dynamique peut examiner plus en profondeur les données utiles des paquets, il peut comprendre des protocoles complexes qui négocient le port de communication et le protocole au moment de l'exécution et appliquer des politiques de pare-feu en conséquence. Pensez à des protocoles tels que FTP, les protocoles P2P, etc.
  

Quels sont les inconvénients d'un pare-feu dynamique ?

• Puissance de traitement : les pare-feu dynamiques effectuent des contrôles supplémentaires pour renforcer la sécurité, et ces autres contrôles nécessitent une plus grande puissance de traitement en termes de cycles d'unité centrale et de mémoire. Les architectes et les développeurs de pare-feu dynamiques ont réfléchi à ce problème, et la plupart des pare-feu les plus récents le surmontent ou le réduisent grâce à une conception algorithmique de pointe visant à séparer le traitement du plan de contrôle et le traitement du plan de données, ce qui permet d'obtenir des performances presque similaires pour les pare-feu sans état. Mais j'accorde une victoire au pare-feu sans état par rapport au pare-feu avec état.
• Surface d'attaque plus importante : Un pare-feu dynamique peut avoir une plus grande surface d'attaque qu'un pare-feu sans état en raison de l'empreinte plus importante de sa base de code. Une simple recherche sur Google permet de trouver de nombreux exemples. Bien qu'au fil du temps. certains types de pare-feu, comme ceux intégrés dans des systèmes d'exploitation tels que Linux et Windows, ont fait leurs preuves et servent aujourd'hui de pare-feu d'entreprise avec état.

Conclusion

Il n'existe pas de pare-feu parfait. Chaque type de pare-feu a sa place dans une stratégie de défense approfondie. Un pare-feu sans état peut être utile dans les cas où un contrôle à gros grain est suffisant, et un pare-feu avec état est utile lorsque des contrôles de politique plus fins et plus profonds et une segmentation ou une micro-segmentation du réseau sont nécessaires.

Aujourd'hui, il existe même différents types de pare-feu d'inspection du trafic de données, entre l'inspection de protocole sans état et l'inspection de protocole avec état. Il est important d'en tenir compte lors du choix d'un pare-feu pour votre environnement.

Maintenant que vous avez acquis la compréhension technique du statefulness, mon prochain article de blog traitera des raisons pour lesquelles le firewalling stateful est important pour la micro-segmentation et pourquoi vous devez vous assurer que votre fournisseur de segmentation le fait.

Learn more

Pour plus d'informations sur les pare-feu et d'autres décisions critiques concernant la stratégie de sécurité de votre entreprise, contactez-nous.