Matrice de flux et règles de pare-feu

Document de référence : qui a le droit de parler à qui, et pourquoi. À rédiger avant de toucher à l’interface de pfSense (tâche 4.1 du suivi). Les problèmes rencontrés lors de la mise en œuvre sont dans Troubleshooting.md. Les schémas de l’infrastructure sont dans Architecture.md. Dernière mise à jour : 12/11/2026 — limiteurs de 50 Mbit/s sur la sortie Internet de VISITEURS (étape 76) ; relecture : alias à jour, matrice de synthèse complétée (agents Wazuh, LDAPS 636, agents GLPI) ; 11/11/2026 — WEB → AD-Core-01 : 636 LDAPS (règle 3 quater, phase 19) ; 03/11/2026 — agents Wazuh (alias SRV_WAZUH, PORTS_WAZUH, une règle par zone) ; zone VISITEURS (VLAN 50, §4.4 bis), alias RESEAUX_PRIVES ; règles de supervision et de journaux (phase 14)

1. Les 5 principes de lecture

2. Alias à créer au préalable

Firewall → Aliases → Add

Les alias évitent d’écrire des adresses en dur. Si le plan d’adressage change, les règles suivent automatiquement.

Réseaux

Hôtes

Ports

Flux sans règle pfSense (même zone ADM) (03/11) : srv-supervision → srv-wazuh UDP 514 (copie des seules alertes de Suricata, tâche 16.9) ; srv-wazuh → srv-supervision TCP 514 (ses journaux, dont les alertes graves de Wazuh). pfSense → srv-supervision UDP 514 existait déjà.

Pourquoi tant de ports pour l’AD ? Active Directory n’est pas un protocole mais un empilement : DNS (53) pour trouver le contrôleur, Kerberos (88/464) pour s’authentifier, LDAP (389/636) pour l’annuaire, SMB (445) pour les GPO et le partage SYSVOL, NTP (123) car Kerberos refuse un écart d’horloge supérieur à 5 minutes, et RPC (135 + la plage dynamique 49152-65535) pour la réplication. La plage dynamique est le point qui bloque tout le monde : Windows négocie un port au hasard dans cet intervalle, impossible de le prévoir.

PORTS_GALERA ne sera utilisé par aucune règle — et c’est normal. Les trois nœuds du cluster sont dans le même VLAN 20 : leur trafic de réplication est commuté et ne traverse jamais pfSense. Aucune règle ne peut donc le filtrer, ni n’est nécessaire.

L’alias est créé pour deux raisons : documenter les ports réellement employés (4567 contrôle du groupe, 4568 transfert incrémental IST, 4444 synchronisation complète SST), et être prêt si les nœuds étaient un jour répartis sur plusieurs sites.

C’est la même leçon que la diagonale « — » de la matrice : on ne filtre pas ce qui ne passe pas par le routeur. Un cluster dans un seul VLAN est un choix d’architecture qui a pour conséquence d’échapper au pare-feu.

3. Matrice de synthèse

Lecture : ligne = source, colonne = destination.

Ce que le répartiteur change dans cette matrice — le point à retenir du sujet.

   AVANT                             APRÈS
   ─────                             ─────
   USERS  → SRV_WEB   : 80/443       USERS  → SRV_HA       : 80/443
   SRV_WEB → SRV_MYSQL : 3306        SRV_HA → GALERA_NODES : 3306
               ▲                                  ▲
     les serveurs web joignent          ils ne la joignent PLUS DU TOUT
     la base                            une seule machine y accède

On ajoute une machine, trois nœuds de base et deux serveurs web — et pourtant le nombre de machines autorisées à parler à la base passe de 1 à 1, alors qu’elles sont maintenant deux à en avoir besoin fonctionnellement. Une couche supplémentaire a restreint les autorisations au lieu de les élargir. C’est le meilleur argument du sujet.

Légende : autorisé large · autorisé mais restreint · temporaire, à désactiver · interdit · — intra-VLAN, non filtré

La diagonale — est essentielle à comprendre : deux machines du même VLAN communiquent sans passer par pfSense. Le trafic est commuté dans le même domaine de diffusion. Aucune règle ne peut le filtrer. C’est pourquoi on ne met pas ensemble deux machines qui doivent être isolées l’une de l’autre.

4. Règles détaillées, par interface

L’ordre indiqué est impératif (principe n°2).

Vocabulaire des menus déroulants (pfSense 2.9)

Changement de vocabulaire depuis pfSense 2.7. Ce qui s’appelait X net s’appelle désormais X subnets, et Single host or alias est devenu Address or Alias. La plupart des tutoriels en ligne emploient encore l’ancienne terminologie.

Où saisir les ports

La colonne Port de toutes les tables ci-dessous désigne le Destination Port Range, jamais le Source Port Range.

Pourquoi jamais de port source ? Dans une connexion TCP/UDP, le port destination identifie le service demandé (53 = DNS, 3306 = MySQL, 443 = HTTPS) : c’est lui qui a un sens à filtrer. Le port source est un numéro tiré au hasard par le système du client dans la plage éphémère 49152-65535, différent à chaque connexion. Le filtrer reviendrait à écrire « j’autorise le DNS, mais seulement si le client a tiré le 54321 » — la règle ne correspondrait quasiment jamais.

pfSense affiche d’ailleurs cet avertissement dans le formulaire dès qu’on déplie Display Advanced : « this setting must remain at its default value, any ».

Pourquoi le pluriel ? « net » ne disait pas s’il s’agissait du réseau ou de l’interface. « subnets » est plus exact : si une interface porte plusieurs sous-réseaux (adresses virtuelles, réseaux additionnels), l’entrée les couvre tous. Ici chaque interface n’a qu’un seul /24, donc c’est strictement équivalent.

4.1 Onglet USERS — VLAN 40

Le mécanisme de la règle 6 est la clé de toute la configuration. Elle refuse tout l’interne après les autorisations ciblées. La règle 7 vise any — qui inclut normalement les réseaux internes — mais comme la règle 6 les a déjà interceptés, any ne désigne plus en pratique qu’Internet. C’est le motif canonique : autorisations précises, puis blocage interne, puis sortie large.

Pourquoi la règle 1 doit être en premier : le DHCP distribue 10.0.40.1 (pfSense) comme serveur DNS. Or USERS address appartient à 10.0.40.0/24, donc à LAB_NETS — la règle 6 l’intercepterait. Sans cette autorisation placée avant, les clients obtiendraient une IP, pingueraient 8.8.8.8 sans problème, mais ne résoudraient aucun nom. Panne classique et trompeuse.

92-pfsense-regle-users-syslog.png (onglet USERS le 21/10 : la règle des journaux en tête)

Le Log de la règle 6 est coché volontairement : c’est lui qui produira la preuve, en phase 7, qu’un flux interdit a bien été refusé (Status → System Logs → Firewall).

4.2 Onglet WEB — VLAN 10

La règle 3 est le cœur pédagogique du TP. Remarque qu’elle est écrite d’hôte à hôte (SRV_WEB → SRV_MYSQL) et non de réseau à réseau. Même si tu ajoutes un jour une seconde machine dans le VLAN 10, elle n’aura pas accès à la base. C’est ça, le moindre privilège.

Pourquoi la règle 1 en premier ? WEB address (10.0.10.1) appartient à 10.0.10.0/24, donc à LAB_NETS. Sans cette règle placée avant le Reject, tes serveurs Linux ne pourraient plus résoudre de nom — et tu chercherais longtemps.

4.3 Onglet BDD — VLAN 20

Aucune règle n’autorise l’entrée du serveur web vers la base. C’est normal et c’est correct : le flux est autorisé sur l’onglet WEB (règle 4.2 n°3), et les réponses reviennent grâce à la table d’états (principe n°4). Si tu ajoutes une règle d’entrée ici, tu ouvres la base dans un sens qui ne devrait jamais l’être.

Règle 4 — Ne pas la supprimer, la DÉCOCHER. pfSense permet de désactiver une règle sans l’effacer : elle reste grisée dans la liste. Elle devient la trace documentaire de ta démarche — « j’ai ouvert pour installer, j’ai refermé ensuite ». Excellent argument en soutenance.

4.4 Onglet ADM — VLAN 30

Règle 1 — PORTS_ADMIN_FW est un 12ᵉ alias à créer (Port(s) : 443, 22, description Administration pfSense). Ne réutilise pas PORTS_ADMIN (22, 3389) : il désigne les protocoles sortants du bastion, pas l’accès au pare-feu. Deux usages différents, deux alias — sinon une modification de l’un casse silencieusement l’autre.

La règle 4 est la traduction du bastion. Seul SRV_BASTION (10.0.30.12) — pas tout le VLAN 30 — peut atteindre les autres réseaux, et uniquement en RDP et SSH. Un serveur AD compromis ne peut rien faire vers les autres VLAN : la règle 5 l’arrête.

La règle 4 bis est la plus étroite possible : un hôte, un port. Le connecteur de l’accès externe (Pangolin) tourne sur SRV_BASTION et hérite de ce que cet hôte atteint. Plutôt que d’élargir la règle 4 (tous les LAB_NETS), on autorise uniquement SRV_BASTION → SRV_HA : 8404. Elle est avant le refus (règle 5) et numérotée « 4 bis » pour ne pas décaler les renvois des autres documents. Voir l’étape 42 de la documentation.

Ces repères (4 bis, 4 ter, 4 quater, 3 bis, 2 bis) n’existent que dans la documentation. Dans pfSense, les règles ajoutées après coup sont en haut de la liste ; entre règles « Pass » ciblées qui ne se recoupent pas l’ordre est sans importance, seule compte la position avant le Refus (règle 5). L’état réel de l’onglet ADM est sur la capture 81.

Les règles 4 ter et 4 quater préparent la supervision (étape 45) : l’une laisse srv-supervision écrire dans le cluster, l’autre laisse srv-metriques lire les exporteurs. Pas de règle pour le VLAN 30 lui-même : AD, bastion et PBS sont dans le même VLAN, leur trafic ne traverse pas le pare-feu. Depuis le 21/10, l’onglet USERS a sa règle (0 bis) : poste-win11 envoie ses journaux par Fluent Bit (étape 48).

En service le 21/10 (étape 48) : la règle 4 ter ne voit passer qu’une machine, srv-supervision, par son HAProxy local (127.0.0.1:3306 → les 3 nœuds). pfSense envoie ses propres journaux (UDP 514, depuis son adresse ADM 10.0.30.1) vers srv-supervision : ce trafic part du pare-feu lui-même, il n’est soumis à aucune règle d’interface. srv-supervision n’accepte l’UDP que de 10.0.30.1.

Mails d’alerte (29/10, étape 54) : Grafana, sur srv-supervision, envoie ses alertes à smtp.gmail.com sur le port 587 (STARTTLS). Ce flux sortant vers Internet est déjà permis par la règle ADM de sortie (ADM → toutes destinations) : aucune règle ajoutée.

La règle 6 ouvre un second chemin de résolution DNS, et c’est assumé. AD-Core-01 redirige vers 10.0.30.1 les noms dont il n’est pas l’autorité. Mais son serveur DNS conserve UseRootHint = True : si le résolveur de pfSense ne répond pas, il interroge directement les serveurs racine d’Internet — et la règle 6, large, le lui permet effectivement.

Le flux correspondant n’apparaît donc pas forcément comme ADM → ADM address : 53, mais peut sortir en ADM → any : 53. À savoir avant de lire les journaux : une requête DNS sortante vers une adresse publique n’est pas une anomalie ici.

Ce qui reste unique	Le pare-feu : le trafic passe par lui en tant que routeur, filtrable et journalisable
Ce qui cesse de l’être	Le résolveur, et uniquement en mode dégradé

Décision et justification complètes dans MO-6, section 8.3. Registre : T-11.

Les deux ports de PORTS_ADMIN servent au même portail. Termix ouvre des sessions SSH sur le 22 vers les machines Linux, et des sessions de bureau à distance sur le 3389 vers les machines Windows — il embarque le moteur de rendu nécessaire. Un seul bastion, une seule adresse à filtrer, une seule règle à justifier.

Conséquence à assumer : pour administrer srv-web ou srv-mysql, tu passeras par Termix, pas par un SSH direct depuis le serveur AD. C’est exactement le comportement attendu d’un bastion — et c’est ce qui rend la règle démontrable. Si tu préfères un accès large pour toute la zone ADM : élargir la règle 4 en ADM net → LAB_NETS : any. Mais le bastion perd alors sa raison d’être.

06/11, étape 69 : règle ADM en tête, Pass TCP ADM subnets → SRV_HA : 443, « Agents et API GLPI vers SRV_HA » (créée par Axel) : inventaire GLPI des machines ADM et API de GLPI depuis le bastion (l’API elle-même est filtrée par adresse dans HAProxy : bastion et srv-supervision seulement).

Site public de GSB et Matomo (10-11/11, étape 72) : aucune règle ajoutée. Le site public arrive par Pangolin sur srv-docker (zone ADM), qui joint SRV_HA : 443 avec la règle ADM ci-dessus ; Matomo est servi par srv-ha (stats.sio.internal) ; les sondes de srv-metriques (ADM) passent par la même règle ; la base matomo est dans Galera (flux WEB vers BDD déjà ouverts) ; les deux agents Wazuh des serveurs web utilisent la règle WEB vers SRV_WAZUH existante. Le filtrage se fait dans HAProxy (administration, connexion, API, auteurs refusés pour le nom public ; l’intranet renvoyé vers le nom interne).

LogAnalyzer (06/11, étape 67) : srv-supervision écoute aussi en HTTPS 8443 (lecture des journaux). Aucune règle ajoutée : le poste d’administration arrive par l’onglet Tailscale (Pass any → any, comme pour Grafana 3000) ; aucune autre zone n’a de règle vers ADM:8443 — vérifié depuis USERS et WEB (bloqué).

4.4 bis Onglet VISITEURS — VLAN 50 (30/10/2026)

La zone la plus fermée : des invités qui n’ont droit qu’au DNS, au DHCP et à Internet (modèle de la zone « Visiteurs » de GSB).

Pourquoi RESEAUX_PRIVES et pas LAB_NETS : LAB_NETS ne contient que le lab. Un visiteur ne doit pas non plus atteindre le réseau de l’école (10.1.0.0/16, dont l’hyperviseur) : la règle 5 l’y laisserait passer en 80/443. Les réseaux privés (RFC 1918) couvrent les deux.

Règle 1 : protocole TCP/UDP et ports PORTS_DNS_NTP. La première version (TCP, port *) ouvrait l’interface web de pfSense aux visiteurs et ne laissait pas passer le DNS, qui est en UDP (corrigée le 30/10).

Testé le 30/10 (tâche 15.6) : DNS et HTTP/2 200 vers Internet ; 6 cibles internes refusées et journalisées. Détail : Documentation-pfSense.md, étape 55.

4.5 Onglet WAN

État au 15/10/2026 : UNE seule règle entrante active, générée par la redirection de port vers PBS (§5).

Pourquoi une exception à « zéro règle entrante » : l’hyperviseur de l’école (10.1.0.253) doit envoyer les sauvegardes des VM au serveur PBS, placé dans le VLAN 30. Il est côté WAN et ne connaît pas les réseaux 10.0.x.0/24 : il vise donc l’adresse WAN de pfSense (10.1.0.197:8007), que pfSense redirige vers 10.0.30.13:8007. L’ouverture est la plus étroite possible : une source (l’hyperviseur seul), un port, une destination. Toute autre machine du réseau de l’école reste refusée.

Correction du 25/09. Ce document décrivait une règle n°2 POSTE_ADMIN → WAN address : 443, présentée comme une dérogation assumée. Cette règle n’a jamais été créée : l’analyse des quatre sauvegardes XML (17/09 → 25/09) montre que l’onglet WAN n’a jamais contenu que la règle allow all. La dérogation décrite ici était théorique. POSTE_ADMIN reste un alias valide, simplement inutilisé.

La cible est atteinte, et elle est meilleure que le compromis prévu : zéro règle entrante sur le WAN. L’accès distant passe intégralement par le tunnel Tailscale, qui n’ouvre aucun port en entrée. C’est le canon, pas un compromis.

Filet de sécurité en cas de panne du tunnel : la console Proxmox, qui ne dépend d’aucune règle de pare-feu. Un accès de secours ne doit jamais dépendre du système qu’il secourt.

4.6 Onglet LAN — 10.0.0.0/24

Interface de secours sur le trunk, sans machine raccordée. On conserve la règle allow all créée à l’installation : c’est le filet de sécurité en cas d’erreur de configuration sur les VLAN.

5. NAT

Firewall → NAT → Outbound

Laisser le mode Automatic outbound NAT rule generation (valeur par défaut).

pfSense crée alors automatiquement les règles de traduction pour tous les réseaux internes vers le WAN. Tes VLAN sortent donc en 10.1.0.197, l’adresse de pfSense côté école.

Pourquoi du NAT ici ? Le réseau de l’école ne connaît pas tes réseaux 10.0.x.0/24 et n’a aucune route vers eux. Sans traduction, les paquets partiraient mais aucune réponse ne reviendrait. Le NAT fait passer tout ton lab pour une machine unique aux yeux de l’école.

On passera en mode Hybrid seulement si tu as besoin d’une règle de NAT particulière pour une machine donnée.

Une seule règle NAT entrante (Port Forward), depuis le 15/10 : le site web, lui, n’est toujours pas publié vers l’école (décision validée).

Firewall → NAT → Port Forward

Vérifié le 15/10 depuis l’hyperviseur : curl -k https://10.1.0.197:8007/ répond 200.

« Associée » plutôt que « passer » : pfSense crée la règle WAN correspondante et la tient à jour avec la redirection. Changer la source ou le port dans la redirection met la règle à jour seule.

6. Durcissement prévu en phase 8

Le log sur les règles Reject est indispensable pour la phase 7. C’est ce qui te permettra de montrer, capture à l’appui (Status → System Logs → Firewall), qu’un flux interdit a bien été refusé. Un pare-feu qui bloque sans le prouver ne démontre rien.

7. Correspondance avec les tests de la phase 7