Objectifs du Projet

Ce projet fait suite à mon lab SOC/Homelab, dans lequel je notais déjà que la politique de filtrage pfSense était trop permissive et qu’une refonte selon les standards de l’ANSSI était nécessaire. J’ai pu récupérer un FortiGate 90D, qui va me permettre d’administrer un pare-feu physique largement utilisé en entreprise.

L’objectif est simple : remplacer des règles “tout autorisé” par une politique structurée, précise et documentée, en suivant la note technique DAT-NT-006 de l’ANSSI : Recommandations pour la définition d’une politique de filtrage réseau d’un pare-feu.

Le résultat attendu est une configuration qui pourrait tenir dans un contexte professionnel : chaque flux est justifié, le pare-feu lui-même est protégé, et les journaux permettent de tracer les événements.

Architecture et Contexte

Infrastructure

L’infrastructure est la suivante :

[Internet]
    │
[Freebox — 192.168.1.1]
    │
    ├── [PC Admin — 192.168.1.x]
    │
[FortiGate 90D — WAN : 192.168.1.148]
    │
    ├── [LAN interne — 10.0.0.x]
    │       └── [Proxmox — 10.0.0.10]
    ├── [VLAN10-LAN — 10.10.10.0/24]
    │       └── [VM Portfolio — 10.10.10.3]
    ├── [VLAN20-LAN — 10.20.20.0/24]
    ├── [VLAN30-LAN — 10.30.30.0/24]
    └── [VLAN40-LAN — 10.40.40.0/24]

Le FortiGate est connecté en sortie sur ma box. Mon PC d’administration est lui aussi connecté à la box, ce qui signifie qu’il accède à l’interface d’administration du FortiGate depuis le WAN, c’est un point critique à sécuriser correctement.

État initial — Ce qui posait problème

Voici les règles en place avant intervention :

Ces règles permettent de faire fonctionner l’accès à mon proxmox, mais elles posent plusieurs problèmes :

• Trop permissives : les règles 1 et 2 autorisent tout depuis le LAN/VLAN10 vers Internet, tous services confondus.
• Pas de restriction des services entrants : la règle 3 autorise tous les protocoles depuis Internet vers Proxmox — aucune raison d’exposer autre chose que le port de gestion.
• Pas de protection du pare-feu lui-même : rien n’empêche explicitement d’envoyer du trafic vers les interfaces du FortiGate.
• Pas de documentation : aucun commentaire sur les règles, impossible de savoir pourquoi elles existent en l’état.

C’est exactement ce que la note ANSSI décrit comme une dérive naturelle des configurations : règles surchargées, utilité méconnue, lisibilité nulle.

Le Modèle ANSSI — 6 Sections

La note technique DAT-NT-006 propose un modèle d’organisation en 6 sections rigoureusement ordonnées, basé sur un principe de sécurité positif : tout ce qui n’est pas explicitement autorisé est interdit.

Les conditions d’application sont simples : les règles sont évaluées séquentiellement de haut en bas, et la première règle correspondante s’applique. C’est exactement le comportement du FortiGate.

Application sur FortiGate

Compromis homelab

La note ANSSI recommande d’administrer le pare-feu depuis une interface réseau physique dédiée, isolée du reste du trafic. Dans mon homelab, cette séparation physique n’est pas toujours possible. Ici, le PC d’administration est connecté à la box sur le même réseau que le WAN du FortiGate (192.168.1.x). C’est un compromis acceptable à condition de restreindre précisément qui peut accéder à l’interface d’administration.

Section 1 — Flux à destination du pare-feu

Cette section concerne les règles qui autorisent l’accès à l’administration du FortiGate. L’objectif est de réduire la surface d’attaque au strict minimum.

Restriction des protocoles sur l’interface WAN

Tous les protocoles d’administration sont désactivés sauf HTTPS. SSH, Telnet, HTTP et PING ne doivent pas être exposés sur le WAN.

Restriction par IP — Trusted Hosts

La restriction Trusted Hosts est configurée sur le compte admin avec l’adresse IP du PC d’administration uniquement. Toute autre IP est rejetée avant même d’atteindre la page de login.

Section 2 — Flux émis par le pare-feu

Ces flux sont les communications initiées par le FortiGate lui-même : résolution DNS et synchronisation NTP. L’horloge doit être correcte. C’est une condition de fiabilité des journaux.

Section 3 — Règle de protection du pare-feu

La protection du pare-feu est assurée par deux mécanismes complémentaires déjà en place : la restriction des protocoles sur l’interface WAN et les Trusted Hosts. Ensemble, ils font que le FortiGate n’est joignable que depuis le PC admin, sur HTTPS uniquement.

La règle implicite DENY (section 6) complète cette protection en bloquant et journalisant tout trafic non couvert, y compris les tentatives d’accès au pare-feu lui-même.

Section 4 — Flux métiers

C’est ici que se trouvent les règles de transit, les flux qui traversent le FortiGate d’une interface à une autre. C’est l’essentiel de la politique, et c’est là que les règles initiales “all → all” ont été remplacées par des règles précises.

J’organise les règles en trois sous-groupes : les flux sortants vers Internet, l’accès admin aux VLANs, et l’accès admin à Proxmox.

Flux sortants — VLANs vers Internet

Chaque VLAN dispose d’une règle de sortie limitée aux protocoles strictement nécessaires. Une règle par VLAN pour maintenir la lisibilité et la traçabilité :

Flux sortants — LAN interne (Proxmox)

Proxmox a besoin d’accéder à Internet pour les mises à jour système et le téléchargement d’images. NTP est ajouté pour la synchronisation de l’horloge :

Flux entrants — Accès admin aux VLANs

Le PC d’administration accède aux VMs des différents VLANs (HTTP/HTTPS pour les interfaces web, SSH pour l’administration). Une seule règle couvre les quatre VLANs grâce à la vue Global View du FortiGate :

Flux entrants — Accès à Proxmox depuis le PC admin

L’accès à l’interface web Proxmox (port 8006) est restreint au seul PC admin :

Section 5 — Règles antiparasites (optionnel)

Cette section est facultative. Elle sert à supprimer des journaux certains flux non légitimes mais bruyants, typiquement les broadcasts NetBIOS ou autres flux de découverte réseau qui polluent les logs sans valeur ajoutée.

Cette section n’est pas implémentée dans la configuration actuelle. Les logs restent exploitables sans filtrage supplémentaire à ce stade.

Section 6 — Règle d’interdiction finale

Sur FortiGate, une règle implicite DENY existe en dernière position de la politique et ne peut pas être supprimée. Elle est journalisée par défaut. Elle couvre exactement ce que demande la section 6 du modèle ANSSI : bloquer et tracer tout trafic non explicitement autorisé.

La Politique Finale

Voici un récapitulatif de la politique complète après refonte, en suivant les 6 sections ANSSI :

Validation

Une politique de filtrage n’a de valeur que si elle est testée. J’ai validé chaque flux attendu après la mise en place des nouvelles règles.

Quelques exemples :

Sécurité Globale — Résumé

Ce que ce projet m’a apporté

Ce projet m’a permis de passer d’une configuration “ça marche” à une configuration “c’est justifié”.

Le modèle en 6 sections de l’ANSSI s’est révélé être une méthode de mise en place efficace d’une politique de filtrage. Il ne s’agit pas d’une contrainte bureaucratique mais d’un cadre qui force à catégoriser chaque règle et à se poser la question “pourquoi ce flux existe-t-il ?”. Et c’est exactement cette rigueur qui manquait dans la configuration initiale. Appliqué méthodiquement, il permet de construire une politique lisible, justifiable et auditables en peu de temps.

Ce projet m’a également permis de prendre en main l’administration d’un FortiGate, pare-feu physique largement déployé en entreprise. L’interface FortiOS, la gestion des objets, la distinction entre trafic transit et trafic local (Local-In Policies), la vue Global View pour gérer des règles multi-interfaces. Autant de spécificités que l’on ne retrouve pas sur pfSense et qui sont directement transposables en environnement professionnel.

Enfin, la partie validation est souvent sous-estimée. Créer des règles prend du temps, mais les tester et vérifier que les compteurs de hits correspondent à ce qu’on attend, c’est la seule façon de s’assurer que la politique fonctionne vraiment comme prévu.