Projet 2
Segmentation réseau et règles de pare-feu
Le problème que je voulais résoudre
Au départ, mon lab était un réseau « à plat » : toutes les machines pouvaient se parler. Si un poste utilisateur est compromis, l'attaquant atteint directement les serveurs critiques et les sauvegardes. Il fallait cloisonner.
Mon raisonnement
J'ai découpé le réseau en zones de confiance, avec un principe simple : seuls les flux strictement nécessaires au métier sont ouverts, tout le reste est bloqué par défaut. Une zone compromise ne doit pas permettre d'atteindre les autres. J'ai aussi voulu des règles lisibles et maintenables — d'où l'usage systématique d'alias plutôt que d'adresses IP en dur.
Ce que j'ai mis en place
Six interfaces derrière pfSense, chacune avec son rôle :
| Interface | Réseau | Rôle |
|---|---|---|
| LAN / FSEC.ADM | 10.10.10.0/24 | Administration et tests — zone de confiance |
| FSEC.SRV | 10.10.20.0/24 | Serveurs d'infrastructure (AD, supervision, bases) |
| FSEC.CLT | 10.10.30.0/24 | Postes utilisateurs |
| FSEC.BCK | 10.10.40.0/24 | Sauvegardes — zone isolée |
| DMZ | 172.16.0.0/24 | Site web exposé |
| WAN | — | Entrée Internet — première ligne de défense |
Chaque interface suit le même modèle de rangement des règles : accès au pare-feu d'abord, exceptions ICMP utiles, autorisations métier, blocages de sécurité, puis « tout bloquer » en règle finale. Pour rester maintenable, j'ai défini des alias : groupes d'hôtes (DC01, serveur Zabbix, TrueNAS…) et groupes de ports (AD_PORTS, WEB_PORT, WazuhAgent…), pour écrire des règles par rôle plutôt que par adresse.
Les règles, zone par zone — un aperçu représentatif
FSEC.CLT Zone clients — accès au strict nécessaire métier
| Source | Destination | Port | Action | Raison |
|---|---|---|---|---|
| Clients | pfSense (interface) | — | Bloquer | Pas d'accès admin au pare-feu depuis les postes |
| Clients | DC01 | AD_PORTS | Autoriser | Authentification Windows |
| Clients | TrueNAS | SMB (445) | Autoriser | Accès aux fichiers partagés |
| Clients | Wazuh | 1514-1515 | Autoriser | Envoi des logs de sécurité |
| Clients | Internet | 80 / 443 | Autoriser | Navigation web |
| Clients | * | * | Bloquer | Tout le reste — notamment serveurs et sauvegardes |
FSEC.SRV Zone serveurs — durcissement du contrôleur de domaine
| Source | Destination | Action | Raison |
|---|---|---|---|
| DC01 | Mises à jour Microsoft | Autoriser | Maintien en condition |
| DC01 | DNS (port 53) | Autoriser | Résolution indispensable |
| DC01 | FSEC.BCK / FSEC.CLT / DMZ | Bloquer | Un DC compromis ne doit pas rebondir ailleurs |
| Serveur Zabbix | Réseaux internes 10050 | Autoriser | Collecte des métriques sur les agents |
DMZ Zone exposée — ne peut rien initier vers l'intérieur
| Source | Destination | Action | Raison |
|---|---|---|---|
| DMZ | Réseaux internes (ADM/SRV/CLT/BCK) | Bloquer | Principe de la DMZ : isolée du réseau interne |
| DMZ | Internet | Autoriser | Sortie web pour le serveur publié |
| WAN | Serveur web DMZ 80 / 443 | Autoriser (NAT) | Publication du site vers l'extérieur |
Comment j'ai validé
Depuis un poste de la zone clients, j'ai vérifié que les services autorisés (authentification AD, partages SMB, supervision, navigation) fonctionnent — et que tout le reste, notamment l'accès direct aux sauvegardes et aux interfaces serveurs, est bien refusé. Les logs de blocage de pfSense confirment les tentatives rejetées, et servent aussi à repérer une erreur de configuration ou une tentative d'intrusion.