En informatique, un pare-feu dynamique (tout pare-feu qui effectue une inspection dynamique des paquets (SPI) ou une inspection dynamique) est un pare-feu qui garde une trace de l’état des connexions réseau (par exemple, les flux TCP, les communications UDP) qui le traversent. Le pare-feu est programmé pour distinguer les paquets légitimes correspondant à différents types de connexions. Seuls les paquets correspondant à une connexion active connue seront autorisés par le pare-feu ; les autres seront rejetés.
L’inspection dynamique, également connue sous le nom de filtrage dynamique des paquets, est une fonction de sécurité souvent incluse dans les réseaux d’entreprise. Check Point Software a introduit l’inspection dynamique dans l’utilisation de son FireWall-1 en 1994.
Historique
Avant l’avènement des pare-feu avec état, il existait des pare-feu sans état, un pare-feu qui traitait chaque trame de réseau (ou paquet) de manière isolée. Ces filtres de paquets opéraient au niveau de la couche réseau (couche 3) et fonctionnaient plus efficacement, car ils ne vérifiaient que l’en-tête d’un paquet. L’inconvénient des filtres de paquets purs est qu’ils sont sans état ; ils ne se souviennent pas des paquets précédents, ce qui les rend vulnérables aux attaques par usurpation d’identité. Un tel pare-feu n’a aucun moyen de savoir si un paquet donné fait partie d’une connexion existante, s’il tente d’établir une nouvelle connexion ou s’il s’agit simplement d’un paquet de virus. Les pare-feu modernes tiennent compte des connexions (ou de l’état), ce qui permet aux administrateurs de réseau d’exercer un contrôle plus précis sur le trafic du réseau.
L’exemple classique d’une opération réseau qui peut échouer avec un pare-feu sans état est le protocole de transfert de fichiers (FTP). De par leur conception, ces protocoles doivent être en mesure d’ouvrir des connexions arbitraires vers des ports élevés afin de fonctionner correctement. Étant donné qu’un pare-feu sans état n’a aucun moyen de savoir si le paquet destiné au réseau protégé (à un hôte dont le port de destination est 4970, par exemple) fait partie d’une session FTP légitime, il rejettera le paquet. Les pare-feu dynamiques dotés de l’application Inspection résolvent ce problème en conservant un tableau des connexions ouvertes, en inspectant la charge utile de certains paquets et en associant intelligemment les nouvelles demandes de connexion aux connexions légitimes existantes.
Les premières tentatives de pare-feu qui ont été produites opèrent au niveau de la couche application, qui est la partie la plus élevée du modèle OSI à sept couches. Cette méthode nécessite une puissance de calcul exorbitante et n’est pas couramment utilisée dans les implémentations modernes.
Description
Un pare-feu dynamique conserve un enregistrement de l’état des connexions réseau (telles que les flux TCP ou UDP) de communication et est capable de conserver en mémoire des attributs importants de chaque connexion. Ces attributs sont collectivement connus sous le nom d’état de la connexion et peuvent inclure des détails tels que les adresses IP et les ports impliqués dans la connexion et les numéros de séquence des paquets traversant la connexion. L’inspection dynamique surveille les paquets entrants et sortants au fil du temps, ainsi que l’état de la connexion, et stocke les données dans des tables d’état dynamiques. Ces données cumulées sont évaluées, de sorte que les décisions de filtrage ne reposent pas uniquement sur les règles définies par l’administrateur, mais également sur le contexte établi par les connexions précédentes, ainsi que par les paquets précédents appartenant à la même connexion.
Le contrôle le plus intensif en termes de CPU est effectué au moment de l’établissement de la connexion. Des entrées sont créées uniquement pour les connexions TCP ou UDP qui satisfont à une politique de sécurité définie. Ensuite, tous les paquets (par session) sont traités rapidement car il est simple et rapide de déterminer s’ils appartiennent à une session existante et présélectionnée. Les paquets associés à ces sessions sont autorisés à traverser le pare-feu. Les sessions qui ne correspondent à aucune politique sont refusées, tout comme les paquets qui ne correspondent pas à une entrée de table existante.
Afin d’éviter que le tableau d’état ne se remplisse, les sessions sont interrompues si aucun trafic n’est passé pendant un certain temps. Ces connexions périmées sont supprimées de la table d’état. C’est pourquoi de nombreuses applications envoient périodiquement des messages keepalive afin d’empêcher un pare-feu d’interrompre la connexion pendant les périodes d’inactivité de l’utilisateur, bien que certains pare-feu puissent recevoir l’instruction d’envoyer ces messages aux applications.
Selon le protocole de connexion, le maintien de l’état d’une connexion est plus ou moins complexe pour le pare-feu. Par exemple, le protocole TCP est lui-même un protocole avec état, car les connexions sont établies avec un protocole à trois voies (« SYN, SYN-ACK, ACK ») et terminées par un commutateur « ACK END ». Cela signifie que tous les paquets dont l’en-tête contient la mention « SYN » et qui sont reçus par le pare-feu sont interprétés comme ouvrant de nouvelles connexions. Si le service demandé par le client est disponible sur le serveur, celui-ci répond par un paquet « SYN-ACK », qui suivra également le pare-feu. Lorsque le pare-feu reçoit la réponse « ACK » du client, il transfère la connexion avec le statut « ESTABLISHED », car la connexion a été authentifiée de manière bidirectionnelle. Cela permet de suivre les futurs paquets via la connexion établie. Parallèlement, le pare-feu bloque tous les paquets qui ne sont pas associés à une connexion existante enregistrée dans sa table d’état (ou paquets « SYN »), empêchant ainsi les connexions non sollicitées vers la machine protégée par le piratage informatique (black hat hacking).
D’autres protocoles de connexion, à savoir UDP et ICMP, ne reposent pas sur des connexions bidirectionnelles comme TCP, ce qui rend le pare-feu un peu moins sûr. Afin de suivre l’état d’une connexion dans ces cas, un pare-feu doit transférer les sessions à l’état ESTABLISHED après avoir vu le premier paquet valide. La connexion ne peut alors être retracée qu’à travers les adresses source et destination et les ports des paquets suivants. Contrairement aux connexions TCP, qui peuvent être fermées par un commutateur « ACK END », ces protocoles sans connexion ne permettent de mettre fin à une session que par dépassement de délai. Cela rend, par exemple, le protocole UDP vulnérable au poinçonnage UDP.
En gardant une trace de l’état de la connexion, les pare-feu offrent une efficacité accrue en termes d’inspection des paquets. En effet, les connexions existantes du pare-feu n’ont qu’à vérifier la table d’état, plutôt que de vérifier le paquet par rapport à l’ensemble des règles du pare-feu, qui peuvent être nombreuses. En outre, en cas de correspondance avec la table d’état, le pare-feu n’a pas besoin d’effectuer une inspection approfondie des paquets.
Filtres de la couche application
Le filtrage des paquets à lui seul n’est pas considéré comme une protection suffisante. Pour bloquer efficacement le trafic réseau d’égal à égal, il faut un pare-feu qui filtre les applications, ce qui peut être considéré comme une extension de l’inspection de l’état des paquets. L’inspection de l’état des paquets peut déterminer quel type de protocole est envoyé sur chaque port, mais les filtres au niveau de l’application voient à quoi sert un protocole. Par exemple, un filtre d’application peut être capable de faire la différence entre le trafic HTTP utilisé pour accéder à une page web et le trafic HTTP utilisé pour le partage de fichiers, alors qu’un pare-feu qui ne ferait que du filtrage de paquets traiterait tout le trafic HTTP de la même manière.
Les pare-feu d’application sont généralement plus lents que les pare-feu d’inspection avec état. Les pare-feux de la couche application sont parfois mis en œuvre à l’aide de proxys d’application. Deux connexions TCP sont établies : l’une entre la source du paquet et le pare-feu, l’autre entre le pare-feu et la destination du paquet. Les mandataires d’application interceptent les paquets arrivant au nom de la destination, examinent la charge utile de l’application et transmettent ensuite les paquets autorisés jusqu’à la destination. Les données suspectes sont abandonnées et le client et le serveur ne communiquent pas directement l’un avec l’autre. Les mandataires impliquent nécessairement une surcharge de la pile de protocoles plus importante que l’inspection des paquets au niveau de la couche réseau. En outre, étant donné qu’un proxy unique est nécessaire pour chaque application, les pare-feu proxy peuvent être moins flexibles et plus lents à mettre à jour que les pare-feu d’inspection avec état. Toutefois, comme les mandataires au niveau de l’application sont sensibles aux applications, ils peuvent plus facilement gérer des protocoles complexes tels que H.323 ou SIP, qui sont utilisés pour la vidéoconférence et la VoIP (voix sur IP).
Traps
Il existe un risque que des vulnérabilités dans les décodeurs de protocoles individuels permettent à un attaquant de prendre le contrôle du pare-feu. Cette préoccupation souligne la nécessité de maintenir les logiciels de pare-feu à jour.
Certains pare-feu offrent également la possibilité de tromper les hôtes individuels pour qu’ils demandent des connexions externes. Cette possibilité ne peut être complètement éliminée qu’en vérifiant le logiciel de l’hôte. Certains pare-feu peuvent être déjoués de cette manière par la simple consultation d’une page web (soit avec Javascript activé, soit après avoir cliqué sur un bouton).