Pare-feu : fonctionnement et règles de filtrage

Un pare-feu (firewall) est un équipement ou un logiciel qui laisse passer ou bloque le trafic réseau entre des zones, selon des règles écrites par l'administrateur : adresse source, adresse de destination, protocole, port, et parfois application ou utilisateur. Ce chapitre explique comment il décide, la différence entre filtrage sans état et avec état, et comment écrire un tableau de règles de filtrage juste, l'exercice le plus fréquent de l'E7 SISR.

À quoi sert un pare-feu

Le pare-feu se place à un point de passage obligé : entre le réseau de l'entreprise et Internet (pare-feu périmétrique), entre deux zones internes (pare-feu interne, par exemple devant les serveurs), ou sur la machine elle-même (pare-feu local de Windows ou de Linux). Il applique une politique de filtrage : la liste des flux autorisés entre les zones.

Il ne fait pas tout. Un pare-feu qui autorise HTTPS vers Internet laisse passer un rançongiciel téléchargé en HTTPS ; il ne voit rien du trafic entre deux postes branchés sur le même switch ; il ne corrige pas une faille du serveur web qu'il expose. C'est une couche de la défense en profondeur, pas la défense entière.

Les types de pare-feu

Comment le pare-feu décide

Pour chaque nouvelle connexion, le pare-feu parcourt ses règles de haut en bas et applique la première qui correspond ; les suivantes sont ignorées. Si aucune ne correspond, il applique la politique par défaut.

• Politique par défaut : tout refuser. C'est la seule acceptable. Tout ce qui n'est pas explicitement autorisé est bloqué. pfSense (comme OPNsense) bloque par défaut tout trafic entrant sur une interface qui n'a pas de règle.
• Ordre des règles. Une règle large placée trop haut masque les règles plus précises en dessous. Les règles d'exception (un refus précis, une autorisation précise) vont avant les règles générales.
• Refuser ou rejeter. Bloquer (drop) jette le paquet sans réponse : l'émetteur attend jusqu'au délai d'expiration. Rejeter (reject) renvoie un refus immédiat (TCP RST ou message ICMP). On bloque en général côté Internet, pour ne rien révéler, et on rejette côté interne, pour que les utilisateurs aient un message d'erreur rapide.
• Journaliser. Les refus importants sont journalisés : c'est là qu'on repère un balayage de ports ou une machine compromise qui cherche à joindre l'extérieur.

Écrire une règle de filtrage

Une règle se lit comme une phrase : « sur telle interface, autoriser (ou bloquer) le trafic de telle source vers telle destination, pour tel protocole et tel port ». Les sujets demandent un tableau de cette forme (sujet 2026, question B2.3 du sujet 2025) :

Chez Sorbier Logistique, chaque VLAN arrive sur sa propre interface du pare-feu (POSTES, SERVEURS, DMZ…), comme tu le verras au chapitre 3 : les règles d'une interface filtrent le trafic qui entre par elle, donc celui dont la source est dans ce VLAN.

Quelques règles d'écriture qui évitent la plupart des erreurs :

• Le port source vaut presque toujours *. Le client choisit un port éphémère au hasard pour chaque connexion : entre 49152 et 65535 sous Windows (la plage dynamique de l'IANA), entre 32768 et 60999 par défaut sous Linux. Seul le port de destination, celui du service, est connu.
• La source et la destination sont aussi précises que possible : un réseau (192.168.10.64/26) plutôt que any, une adresse de serveur plutôt qu'un réseau.
• Le protocole de transport est indiqué : DNS utilise UDP et TCP, HTTPS utilise TCP (et UDP 443 pour HTTP/3, à décider explicitement).
• L'interface est celle où le trafic entre dans le pare-feu, pour pfSense (comme pour OPNsense).
• La dernière règle est un refus explicite, même si la politique par défaut refuse déjà : elle rend la politique lisible et permet de journaliser.

Les ports à connaître

Le rappel sur TCP, UDP et la notion de port est dans le cours Réseaux fondamentaux.

De la matrice des flux aux règles

On n'écrit pas des règles au fil de l'eau : on part d'une matrice des flux, un tableau qui dit, pour chaque couple de zones, quels flux sont autorisés et pourquoi. Chaque case non vide donne une ou plusieurs règles ; une case vide signifie « refusé ».

Cette matrice est celle de Sorbier Logistique, que tu retrouves au chapitre 3 avec ses adresses. Elle se lit ligne par ligne : la ligne « Internet » ne contient qu'un seul flux, vers la DMZ. Aucun flux ne va d'Internet vers les postes ou les serveurs : c'est tout l'intérêt de la DMZ.

NAT et redirection de port

Le réseau interne utilise des adresses privées, non routées sur Internet. Le pare-feu fait donc aussi de la traduction d'adresses (NAT) :

• NAT source (ou masquerading) : les postes sortent sur Internet avec l'adresse publique du pare-feu (203.0.113.17 chez Sorbier). C'est automatique sur pfSense et OPNsense.
• NAT de destination (redirection de port, port forwarding) : une connexion qui arrive sur l'adresse publique, port 443, est redirigée vers le serveur web de la DMZ (192.168.10.225, port 443).

Une redirection de port ne suffit pas : il faut aussi une règle de filtrage qui autorise le flux. pfSense et OPNsense proposent de créer cette règle associée automatiquement. Dans un tableau de réponse, écris les deux : la redirection (adresse et port publics vers adresse et port internes) et la règle (Internet vers 192.168.10.225, TCP 443, autoriser).

Le pare-feu local d'un serveur

Le pare-feu périmétrique ne voit pas le trafic entre deux machines d'une même zone. Le pare-feu local de chaque serveur complète le dispositif : il n'accepte que les flux prévus, même depuis une machine voisine.

Sous Linux (Debian 13), on utilise nftables. Voici le jeu de règles d'un serveur web de la DMZ qui n'accepte que HTTPS depuis partout, SSH depuis le réseau d'administration, et le ping limité. Il s'enregistre dans /etc/nftables.conf et s'active avec systemctl enable --now nftables :

#!/usr/sbin/nft -f
flush ruleset

table inet filtre {
  chain entree {
    type filter hook input priority 0; policy drop;

    ct state established,related accept   # réponses des connexions acceptées
    ct state invalid drop
    iif "lo" accept                         # trafic local de la machine

    tcp dport 443 accept                    # HTTPS pour tout le monde
    ip saddr 192.168.10.208/28 tcp dport 22 accept   # SSH depuis le réseau d'administration
    icmp type echo-request limit rate 5/second accept
    meta l4proto ipv6-icmp accept           # indispensable au fonctionnement d'IPv6

    log prefix "nft-refus " counter         # journalise ce qui va être refusé
  }
}

La politique drop de la chaîne refuse tout ce qui n'a pas été accepté plus haut. nft list ruleset affiche les règles chargées, et les compteurs montrent combien de paquets chacune a traités.

Sous Windows Server, le pare-feu Windows Defender se règle par stratégie de groupe ou en PowerShell :

New-NetFirewallRule -DisplayName "HTTPS entrant" -Direction Inbound -Protocol TCP -LocalPort 443 -Action Allow
Get-NetFirewallProfile | Select-Object Name, Enabled, DefaultInboundAction

Les erreurs fréquentes dans un tableau de règles

Exercices