Pare-feu à état & flux réseau

Le concept en une phrase

Un pare-feu à état ne juge pas des paquets isolés : il suit des connexions, et n’autorise que le trafic qui appartient à une conversation déjà légitime.

Le SI d’une base australe est cloisonné en zones — supervision, applicatif, base de données, administration. Un pare-feu se tient entre ces zones et tranche, en permanence : qui a le droit de parler à qui, et dans quel sens. Ce n’est pas un mur binaire ouvert/fermé — c’est un arbitre qui se souvient de chaque conversation en cours pour la laisser continuer, et qui rejette par défaut tout ce qu’il ne reconnaît pas.

Les grands principes

1. Sans état vs à état (stateless vs stateful)

Deux façons radicalement différentes de filtrer :

Stateless (sans état) — chaque paquet est jugé isolément, sur ses seuls en-têtes (IP source/destination, port). Le pare-feu n’a aucune mémoire de ce qui s’est passé avant. Conséquence pratique : pour laisser passer une réponse, il faut écrire une règle dans les deux sens — une pour l’aller, une pour le retour.
Stateful (à état) — le pare-feu mémorise les connexions établies dans une table d’état. Un paquet qui appartient à une connexion déjà autorisée est reconnu et passe automatiquement, y compris le trafic retour.

Retenez : avec un pare-feu à état, on n’écrit la règle que dans un seul sens — celui qui initie la connexion. Le retour est implicite. C’est ce qui rend les jeux de règles lisibles au lieu d’être une purée symétrique de lignes.

2. La table d’état

Concrètement : un paquet SYN (début de connexion TCP) qui correspond à une règle d’ouverture crée une entrée dans la table d’état (souvent appelée conntrack). Tous les paquets suivants de cette même connexion sont reconnus par cette entrée et passent, sans être réévalués contre le jeu de règles complet. Un paquet qui ne correspond ni à une connexion suivie, ni à une règle d’ouverture est rejeté.

flowchart TD
    A[Paquet entrant] --> B{Correspond à une<br/>connexion suivie ?}
    B -->|Oui| C[Autorisé — trafic retour<br/>d'une conversation légitime]
    B -->|Non| D{Correspond à une<br/>règle d'ouverture ?}
    D -->|Oui| E[Nouvelle entrée créée<br/>dans la table d'état]
    D -->|Non| F[Rejeté — default-deny]

3. Default-deny — la posture de base

Le principe qui rend tout le reste cohérent : tout ce qui n’est pas explicitement autorisé est refusé. On ne rédige jamais la liste de ce qu’on interdit — on rédige la liste, courte, de ce qu’on ouvre. Tout le reste tombe par défaut.

C’est la différence entre une posture défensive (« je bloque ce que je connais de mauvais ») et une posture de confinement (« je n’autorise que ce que je connais de nécessaire »). En environnement isolé — une base australe coupée du monde une bonne partie de l’année — c’est la seule posture qui tienne : on ne peut pas compter sur une mise à jour rapide de signatures pour rattraper un oubli.

4. Nord-sud vs est-ouest

Le point pédagogique central de cette page. Tout flux réseau se range dans l’un de ces deux axes :

Nord-sud — le trafic qui traverse un périmètre, qui franchit une frontière entre deux zones de niveaux différents. Internet ↔ DMZ, poste client ↔ serveur applicatif, zone externe ↔ zone interne. C’est le trafic que l’architecture est conçue pour surveiller : il passe par une porte, et cette porte a un garde.
Est-ouest — le trafic latéral, entre machines d’une même zone, à l’intérieur du SI. Serveur web ↔ serveur web, poste ↔ poste sur le même réseau applicatif. Historiquement, c’est le trafic le moins surveillé — on fait confiance à « l’intérieur ».

flowchart TB
    Internet((Internet)) -->|Nord-Sud| DMZ[Zone DMZ]
    DMZ -->|Nord-Sud| App[Zone Applicatif]
    App -->|Nord-Sud| DB[Zone Base de données]
    App <-->|Est-Ouest| App2[Autre hôte<br/>même zone]
    DB <-->|Est-Ouest| DB2[Autre hôte<br/>même zone]

	Direction	Exemple	Risque principal
Nord-sud	Traverse une frontière de zone	Internet → DMZ, poste → serveur applicatif	Point d’entrée de l’attaquant
Est-ouest	Latéral, dans une même zone	Serveur web → serveur web, poste → poste	Déplacement latéral une fois entré

Le danger classique, celui que raconte quasiment tout incident réel : un attaquant entre par le nord-sud — il compromet le frontal web exposé — puis se déplace en est-ouest — il rebondit, machine par machine, à l’intérieur de la même zone, jusqu’à atteindre les données qui l’intéressent. Un pare-feu qui ne surveille que le nord-sud laisse cette seconde étape totalement libre.

5. Macro vs micro-segmentation

Deux granularités de filtrage, qui répondent chacune à un des deux axes :

Macro-segmentation — filtrage entre zones, par un pare-feu central. Dans TAAF : OPNsense, qui tient les frontières entre les grandes zones du SI. C’est l’axe nord-sud.
Micro-segmentation — filtrage entre hôtes d’une même zone, poste par poste (par exemple avec UFW sur chaque machine). C’est l’axe est-ouest.

La macro-segmentation contient l’attaquant entre les zones — elle l’empêche de sortir de la DMZ pour atteindre l’applicatif. La micro-segmentation limite le déplacement latéral à l’intérieur d’une zone — elle empêche un frontal web compromis de scanner tranquillement ses voisins.

Les deux sont complémentaires : la macro sans la micro laisse un est-ouest ouvert dès qu’on est entré dans une zone ; la micro sans la macro n’a aucune frontière de zone à protéger en premier lieu.

6. La règle d’or TAAF, en exemple

Prenons la règle la plus simple et la plus révélatrice du SI TAAF : Front-end → Backend, uniquement sur PostgreSQL

; tout le reste en default-deny.

Cette seule ligne incarne les trois principes précédents en même temps :

Stateful — on n’écrit la règle que dans le sens Front-end → Backend ; le retour des requêtes SQL est implicite, porté par la table d’état.
Default-deny — rien d’autre n’est ouvert entre ces deux zones. Pas de SSH, pas de partage de fichiers, pas de ping libre : seul le port 5432 existe.
Contrôle nord-sud — c’est une frontière entre deux zones de niveaux différents, exactement le type de flux que la macro-segmentation est censée arbitrer.

Conséquence concrète pour un attaquant qui prend pied sur le frontal : il ne peut pas scanner le backend. Il ne voit qu’un seul port ouvert, vers un seul service, dans un seul sens. Toute la surface qu’il espérait trouver (SSH ouvert, partages, autres services) n’existe simplement pas sur le fil.

Où ça intervient dans TAAF

TP1 — Segmentation & pare-feu — le cœur pratique de cette page. Les ingénieurs construisent la segmentation en zones et écrivent eux-mêmes les ACLs qui appliquent default-deny et le contrôle nord-sud.
Segmentation & micro-segmentation — le socle : sans zones définies, un pare-feu à état n’a rien à cloisonner. Cette page-ci explique comment il filtre ; l’autre explique quelles zones filtrer.
VPN IPsec — le tunnel transporte le trafic entre deux bases ; le pare-feu à l’arrivée décide qui a le droit d’entrer dans quelle zone. Les deux sujets sont complémentaires, pas redondants.

Ressources associées

Ces liens sont des points de départ pour vos propres recherches. Croisez-les : une vidéo pour l’intuition, un guide ANSSI pour la rigueur, une doc officielle pour la pratique.

Comprendre (intuition)

Practical Networking (practicalnetworking.net) : l’explication visuelle de référence des tables d’état et du filtrage (en anglais, très clair).
Xavki — réseau & sécurité (chaîne YouTube) : tutoriels en français, du concept à la pratique.
Blog de Stéphane Robert (blog.stephane-robert.info) : la référence francophone infra/réseau/sécurité.

Faire (mise en œuvre)

Documentation OPNsense — pare-feu (docs.opnsense.org) : la config des règles et de l’état côté pare-feu du TP1.

Approfondir (rigueur & normes)

ANSSI — cloisonnement & interconnexion (cyber.gouv.fr) : les recommandations françaises sur le cloisonnement des SI (cherchez « cloisonnement » ou « interconnexion » dans les publications).
NIST SP 800-207 — Zero Trust Architecture (csrc.nist.gov) : quand la segmentation ne suffit plus, la logique qui va plus loin que le périmètre.

À chercher par vous-même : « stateful vs stateless firewall », « connection tracking conntrack », « default-deny », « east-west traffic lateral movement », « micro-segmentation », « zero trust ».