De la matrice des flux aux règles : la politique de Sorbier

Écrire une politique de filtrage, c'est traduire une matrice des flux (qui doit joindre quoi, sur quel port, pourquoi) en règles, interface par interface, en commençant par les exceptions et en terminant par un refus journalisé. Ce chapitre écrit la politique complète du pare-feu de Sorbier, explique les pièges qui la rendraient fausse, puis donne la méthode pour trouver la règle qui bloque un flux : journaux, table d'états, capture de paquets.

La méthode en cinq étapes

1. Partir de la matrice des flux, validée avec les responsables : chaque ligne dit une source, une destination, un service et une raison. Celle de Sorbier est dans le cours Cybersécurité des infrastructures ; elle est reprise ci-dessous avec les outils du laboratoire (Wazuh, Zabbix).
2. Ranger chaque ligne sous l'interface d'entrée : celle par laquelle le premier paquet de la connexion entre dans le pare-feu, donc l'interface de la source. Un flux « POSTES vers srv-gestion » s'écrit dans l'onglet POSTES, pas dans SERVEURS.
3. Créer les alias dont les règles ont besoin (chapitre 4).
4. Ordonner : dans chaque onglet, les autorisations vers des destinations internes précises, puis le refus vers le pare-feu lui-même, puis le refus vers les autres réseaux internes, puis les autorisations vers Internet, et enfin le refus final journalisé.
5. Tester chaque flux autorisé et un flux voisin interdit, et garder la trace des tests.

La matrice des flux de Sorbier

La ligne « srv-journaux vers les équipements d'ADMIN » est la seule exception à la règle « aucune zone n'ouvre de connexion vers ADMIN » : elle est limitée à une source, un protocole et un port, et documentée. Une alternative est de placer un proxy Zabbix dans le VLAN ADMIN (cours Supervision).

Le piège du « any » qui inclut le pare-feu

Une règle « POSTES subnets vers any, TCP 80 et 443 » autorise la navigation… et l'accès à toutes les adresses du pare-feu sur ces ports, y compris son adresse publique 203.0.113.17, sur laquelle l'interface web d'administration écoute aussi. Un poste qui tape https://203.0.113.17 arrive sur la page de connexion du pare-feu. Même chose avec une destination « tout sauf les réseaux internes » : l'adresse publique n'est pas un réseau interne.

La parade : dans chaque onglet autre qu'ADMIN, une règle Reject vers This Firewall (self) placée après les autorisations explicites vers le pare-feu (DNS, ping) et avant les autorisations vers Internet.

Les règles, interface par interface

Les alias sont ceux du chapitre 4. « Journal » indique les règles dont la case Log est cochée.

Onglet POSTES

Les postes n'interrogent jamais un DNS d'Internet : ils utilisent les contrôleurs de domaine (règles 1 et 2), qui font suivre au pare-feu ce qu'ils ne connaissent pas (chapitre 8). Le trafic HTTP/3 (UDP 443) est refusé par la règle 11 : les navigateurs se replient aussitôt sur TCP 443. Pour l'autoriser, une règle UDP 443 vers any à côté de la règle 10.

Onglet ENTREPOT

Les terminaux n'ont pas besoin d'Internet : rien ne les y autorise. Le refus final couvre aussi le pare-feu lui-même.

Onglet TELEPHONIE

OPERATEUR_TOIP et PORTS_TOIP sont deux alias remplis avec les adresses et les ports que publie l'opérateur de téléphonie.

Onglet VISITEURS

Le relais DHCP et le portail captif ajoutent leurs propres règles automatiques, avant celles-ci (chapitres 8 et 11).

Onglet DMZ

DEPOTS_MAJ est un alias de noms DNS (deb.debian.org, security.debian.org) : pfSense les résout régulièrement. En DMZ, Block plutôt que Reject : un serveur compromis n'a pas à recevoir d'indice. La règle 1 est journalisée : c'est le seul chemin de la DMZ vers une donnée interne, on veut en garder chaque trace.

Onglet SERVEURS

Les serveurs d'un même VLAN (srv-fichiers et le stockage, Wazuh et ses agents dans ce VLAN) se parlent sans passer par le pare-feu. La règle 6 existe parce que DFS-R réplique dans les deux sens : chaque serveur ouvre ses propres connexions vers l'autre (chapitre 10).

Onglet ADMIN

Les ports d'administration des serveurs, de la DMZ, des équipements et de Mâcon ne s'ouvrent que depuis le bastion : c'est la décision du cours Cybersécurité des infrastructures, et le bastion n'a de sens que si les autres chemins sont fermés. La règle 2 refuse et journalise toute autre tentative depuis le VLAN ADMIN. Le poste d'administration (.209) se connecte au bastion dans le même VLAN, sans traverser le pare-feu. Il atteint l'interface web du pare-feu par la règle anti-lockout, évaluée avant ces règles ; quand on la remplace par une règle explicite (chapitre 14), celle-ci se place au-dessus de la règle 2.

Aucune règle ne vise ADMIN depuis les autres onglets, sauf l'exception de la supervision : ADMIN ouvre des connexions vers les autres zones, personne n'en ouvre vers ADMIN. Les réponses reviennent grâce à la table d'états.

Onglet WAN

Rien d'autre : le refus par défaut s'occupe du reste, et il est journalisé. Les règles 1 et 2 visent l'adresse interne du serveur, parce que pfSense applique la redirection de port avant le filtrage (chapitre 6). Le tunnel IPsec vers Mâcon n'a pas besoin de règle sur le WAN : pfSense ajoute automatiquement les règles IKE et ESP vers et depuis la passerelle distante déclarée (chapitre 10).

Tester une politique

Une règle n'est terminée que lorsqu'on l'a testée dans les deux sens : le flux autorisé passe, un flux voisin interdit est bloqué.

# Depuis un poste du VLAN 10 : les flux autorisés répondent True
Test-NetConnection 192.168.10.177 -Port 389
Test-NetConnection 192.168.10.179 -Port 443
# Les flux interdits répondent False
Test-NetConnection 192.168.10.179 -Port 3389
Test-NetConnection 203.0.113.17 -Port 443

Sous Linux, nc -zv 192.168.10.179 443 fait la même vérification. Pour chaque test interdit, le journal du pare-feu doit montrer la tentative et la règle qui l'a refusée : c'est la preuve à joindre à ta documentation et à ton dossier d'E6.

Trouver la règle qui bloque un flux

Quand un utilisateur dit « ça ne marche pas », la méthode tient en cinq questions.

1. Quel flux exactement ? Source, destination, protocole, port. « L'application ne s'ouvre pas » devient « 192.168.10.88 vers 192.168.10.179, TCP 443 ». Reproduis-le avec Test-NetConnection.
2. Le pare-feu l'a-t-il refusé ? Status > System Logs > Firewall, filtre avancé (icône en forme d'entonnoir) sur l'adresse source ou la destination. Une ligne de blocage donne l'interface d'entrée et la règle : un clic sur l'icône d'action affiche la règle complète.
3. Si aucune ligne de blocage : le flux est-il passé ? Diagnostics > States, filtre sur l'adresse : une ligne d'état prouve que le pare-feu a autorisé la connexion. Si elle est là, le problème est ailleurs : le serveur ne répond pas (service arrêté, pare-feu local du serveur), ou il répond par un autre chemin.
4. S'il n'y a ni blocage ni état : le paquet est-il arrivé ? Diagnostics > Packet Capture sur l'interface d'entrée, filtre sur l'adresse. Aucun paquet : le problème est avant le pare-feu (mauvaise passerelle sur le poste, VLAN absent du trunk, câble). Des paquets mais aucune ligne : une règle de blocage non journalisée les jette, relis l'onglet.
5. Corriger au plus juste, puis retester le flux et un flux voisin interdit.

La colonne States de Firewall > Rules affiche, pour chaque règle, le nombre d'états en cours et le volume qu'elle a laissé passer : une règle qui reste à « 0/0 B » alors que le flux devrait l'utiliser n'est jamais atteinte. Diagnostics > pfTop montre les connexions en temps réel, triables par débit. Et Status > Filter Reload dit si le dernier chargement des règles a réussi : une règle mal formée peut empêcher tout le jeu de règles de se charger.

Lire une ligne de journal brute

En vue brute (Status > System Logs > Firewall, puis l'option d'affichage brut dans les réglages) ou dans Wazuh, une ligne du filtre ressemble à ceci :

Nov  4 09:41:07 pf1 filterlog[51231]: 87,,,1770001234,vtnet1.10,match,block,in,4,0x0,,64,13377,0,DF,6,tcp,60,192.168.10.88,192.168.10.179,51544,3389,0,S,2915437763,,64240,,mss;sackOK;TS;nop;wscale

Ce poste tente le bureau à distance sur srv-gestion, et la règle d'identifiant 1770001234 le bloque. C'est ce format que Wazuh décode pour ses alertes (chapitre 15).

Exercices