Le tableau qu'on aurait dû faire avant de toucher au pare-feu

Mon plan pour la semaine était clair : monter OPNsense, créer les interfaces, taguer les VLAN, et enchaîner sur les services.

L'encadrant a lu mon plan et a posé une question. Quelle machine a le droit de parler à quelle machine, et sur quel port ?

Silence de ma part. J'avais une architecture dans la tête, pas de réponse à ça.

Pourquoi on segmente

Un réseau à plat, c'est un réseau où compromettre un poste donne accès à tout. Le NAS de sauvegarde, l'interface web de l'hyperviseur, le gestionnaire de mots de passe : tout est à un ping de distance.

Segmenter n'empêche personne d'entrer. Ça limite ce qu'on peut faire une fois dedans. En cours, on appelle ça la défense en profondeur, et je trouvais l'expression un peu creuse jusqu'à ce que je doive la traduire en règles concrètes.

Sur mon homelab j'avais deux VLAN, un « services » et un « perso ». C'était déjà mieux que rien, mais j'aurais été bien incapable de justifier pourquoi telle machine avait le droit de joindre telle autre. C'était de l'empilement au fil des besoins.

Quatre zones, découpées par rôle

Le découpage s'est fait selon ce que font les machines, pas selon qui les utilise ni où elles sont physiquement.

Le VLAN 99 est celui qu'on oublie le plus souvent et c'est le plus sensible. L'interface web de Proxmox permet d'ouvrir une console sur n'importe quelle VM de l'infra. La laisser sur le même réseau que les postes de travail aurait annulé l'intérêt de tout le reste du découpage.

Le fameux tableau

Avant la première règle, on a rempli une matrice. Une ligne par couple source/destination, une décision, une justification.

Deux trucs m'ont marqué en le relisant.

La DMZ ne parle à personne. Ça m'a paru absurde sur le moment : un reverse proxy en DMZ doit bien joindre les applis derrière, non ? En fait non, parce que c'est le sens de la connexion qui compte. Le LAN initie vers la DMZ, la DMZ répond. Mais elle ne peut jamais ouvrir une connexion vers l'intérieur d'elle-même. Si quelqu'un prend la main sur le conteneur Traefik, il atterrit dans une zone d'où il ne peut rien atteindre.

Et puis MGMT parle à tout le monde alors que personne ne parle à MGMT. C'est cette asymétrie qui protège l'administration.

Côté OPNsense

La config a pris moins longtemps que le tableau. Le truc qui m'a le plus servi : poser la règle de blocage final en premier, puis ouvrir au cas par cas au-dessus.

# Interface LAN, OPNsense évalue de haut en bas
1. LAN -> DMZ   tcp/443    autoriser   services publiés
2. LAN -> SRV   tcp/443    autoriser   applis internes via le proxy
3. LAN -> SRV   udp/53     autoriser   résolution DNS interne
4. LAN -> any              bloquer     fin de chaîne (log activé)

Ce log sur la dernière règle est devenu mon outil de débogage principal pendant tout le stage. Quand un service ne répondait pas, le journal me disait quel paquet avait été jeté, depuis où, vers quel port. Plus besoin de deviner.

Deux plantages

Le DNS, d'abord. J'ouvre le 443 du LAN vers les services, je teste, rien ne marche. Les machines ne résolvaient plus les noms internes. Le serveur DNS est dans SRV, et je n'avais pas ouvert le port 53. Évident après coup. Une heure de perdue quand même.

Ensuite je me suis mis dehors tout seul. En verrouillant MGMT, je me suis coupé l'accès à l'interface Proxmox depuis mon poste. Obligé de repasser par la console de l'hyperviseur pour rouvrir une route. Depuis, je teste toujours la règle qui protège mon propre accès en dernier, et je garde une session ouverte ailleurs.

Le lien avec les cours

Les cours réseau m'avaient donné le vocabulaire : 802.1Q, trunk, table de routage, adressage. Ce qu'ils ne m'avaient pas donné, c'est la discipline du tableau. L'idée qu'une règle de pare-feu n'est pas une commande qu'on tape, mais une décision qu'il faut pouvoir justifier six mois plus tard devant quelqu'un d'autre.

J'ai repris mon homelab depuis, avec une matrice écrite d'abord. J'ai supprimé quatre règles dont j'étais incapable d'expliquer la raison d'être.