Segmenter son réseau d'entreprise avec des VLANs, la méthode et la vérification

Premier article d’une série sur la sécurisation du réseau d’une petite entreprise, brique par brique : segmentation, Wi-Fi, identité, accès distant, postes de travail, messagerie, supervision, sauvegardes. Ce premier volet s’attaque à ce qui conditionne tout le reste : découper le réseau avant de penser à le défendre.

Je n’ai pas de commutateur manageable sous la main pour cet article : les schémas ci-dessous sont des illustrations pédagogiques, pas des captures d’écran. En revanche, la syntaxe de configuration et les commandes de vérification sont réelles — à adapter à votre matériel, mais directement utilisables.

Un réseau plat, et ce qu’il laisse passer

Voici le point de départ le plus courant dans une petite structure : un routeur, un ou deux commutateurs, et tout le monde — postes, serveurs, imprimantes — dans le même sous-réseau. Rien n’est « mal configuré » à proprement parler ; c’est simplement l’état par défaut quand personne n’a encore eu de raison de le changer.

Premier souci : tout le monde voit tout le monde

Sur ce schéma, le cercle qui s’étend depuis PC-01 représente un simple balayage réseau (arp-scan, nmap -sn, ou même le comportement normal d’un ver). Il atteint sans obstacle les deux autres postes, le serveur de fichiers, l’imprimante, puis — un peu plus tard — les appareils de l’autre commutateur. Un attaquant qui obtient l’exécution de code sur n’importe quel poste connaît en quelques secondes la cartographie complète du réseau : qui est serveur, qui est imprimante, qui répond sur quels ports. C’est la phase de reconnaissance d’une intrusion, et sur un réseau plat, elle est entièrement gratuite.

Deuxième souci, plus grave : rien n’empêche un accès direct

Voir n’est qu’une étape. Le point rouge qui part de PC-01 vers SRV-WEB-01 — sur l’autre commutateur — illustre le vrai problème : aucune barrière technique ne sépare un poste utilisateur d’un serveur, même physiquement raccordé ailleurs. Une fois le poste compromis, une tentative de connexion vers le serveur de fichiers ou le serveur web n’a besoin de franchir ni pare-feu, ni liste de contrôle d’accès : juste un routeur qui, par défaut, route tout vers tout à l’intérieur du même sous-réseau. C’est la différence entre « on peut me voir » et « on peut m’atteindre » — et c’est la seconde qui transforme un poste compromis en brèche sur les données de l’entreprise.

Segmenter ne rend aucune intrusion impossible. Ça réduit ce qu’un attaquant peut atteindre depuis un point d’entrée, et ça donne du temps et des points d’observation à la détection — le principe du moindre privilège, appliqué au réseau plutôt qu’aux permissions.

Les VLANs en deux minutes

Un VLAN (Virtual LAN) découpe un commutateur physique en plusieurs domaines de diffusion isolés : deux machines sur des VLANs différents ne se voient pas au niveau 2, même branchées sur le même commutateur, à moins qu’un équipement de niveau 3 (un routeur ou un pare-feu) ne les relie explicitement.

• Port d’accès (access port) : relié à un poste, une imprimante, un point d’accès Wi-Fi. Il appartient à un seul VLAN ; l’appareil branché dessus n’a pas conscience des VLANs.
• Port trunk : relie deux équipements réseau entre eux (commutateur-pare-feu, commutateur-commutateur). Il transporte plusieurs VLANs simultanément, chaque trame étant marquée (taguée) avec son numéro de VLAN — c’est la norme 802.1Q.
• VLAN natif : sur un port trunk, le seul VLAN dont les trames circulent sans tag. Le piège classique : laisser le VLAN natif sur le VLAN par défaut (1) des deux côtés du lien, qui est aussi, très souvent, celui de l’administration du matériel.

Le principe qui structure la suite de l’article : l’isolation entre VLANs se fait au niveau 2 (le commutateur), le contrôle de ce qui peut quand même passer d’un VLAN à l’autre se fait au niveau 3 (le pare-feu). Ce sont deux mécanismes distincts, et c’est précisément ce que montre le schéma suivant.

• Même VLAN : communication directe, sans passer par le pare-feu
• VLANs différents : isolés au niveau 2, aucun chemin direct
• Flux autorisé : routé et filtré explicitement par le pare-feu
• Flux refusé : les invités ne joignent pas l'administration

Comparé au premier schéma : le balayage de PC-01 s’arrête à la frontière de son VLAN, et l’accès direct vers un serveur d’un autre VLAN n’existe plus — tout doit désormais passer par le pare-feu, qui décide.

Construire un plan d’adressage

Un sous-réseau /24 par VLAN, avec le numéro de VLAN repris dans le troisième octet : facile à retenir, facile à filtrer.

Le VLAN 99 mérite une ligne à lui seul : en réassignant le VLAN natif à un numéro inutilisé (plutôt que de le laisser sur le VLAN 1 par défaut), une trame mal taguée ou une attaque de saut de VLAN (VLAN hopping par double tag 802.1Q) atterrit dans un VLAN qui ne mène nulle part, au lieu d’atterrir directement dans l’administration.

Configurer le commutateur

La syntaxe exacte dépend du fabricant, mais la plupart des commutateurs manageables (Cisco, et la majorité des équivalents « Cisco-like » chez d’autres marques) suivent cette logique :

! Créer les VLANs
vlan 10
 name ADMINISTRATION
vlan 20
 name UTILISATEURS
vlan 30
 name INVITES
vlan 99
 name NATIF-INUTILISE

! Port d'accès pour un poste utilisateur
interface GigabitEthernet0/1
 switchport mode access
 switchport access vlan 20

! Port d'accès pour le point d'accès Wi-Fi invités
interface GigabitEthernet0/8
 switchport mode access
 switchport access vlan 30

! Port trunk vers le pare-feu : seuls 10, 20 et 30 y circulent
interface GigabitEthernet0/24
 switchport mode trunk
 switchport trunk allowed vlan 10,20,30
 switchport trunk native vlan 99

Deux lignes à ne jamais oublier : switchport trunk allowed vlan (sans elle, un trunk autorise tous les VLANs par défaut sur beaucoup d’équipements — la segmentation n’existe alors que sur le papier) et switchport trunk native vlan 99 (sans elle, le VLAN natif reste sur le VLAN 1).

Configurer le routage inter-VLAN sur le pare-feu

Avec un pare-feu de type OPNsense ou pfSense (déjà utilisé dans mon laboratoire Proxmox), la démarche est la suivante :

1. Interfaces → Affectations → VLANs : créer les VLANs 10, 20 et 30 sur l’interface physique reliée au port trunk du commutateur.
2. Interfaces → Affectations : assigner chaque VLAN à une nouvelle interface (VLAN10, VLAN20, VLAN30), lui donner son adresse de passerelle (10.10.10.1/24, etc.) et l’activer.
3. Services → DHCP Server : activer un serveur DHCP par interface VLAN, avec la plage d’adresses correspondante.
4. Firewall → Rules : par défaut, chaque interface n’autorise que son propre trafic sortant vers Internet — aucune règle n’autorise encore le trafic entre VLANs, et c’est volontaire : tant qu’aucune règle explicite n’est écrite, le pare-feu bloque tout flux inter-VLAN.

Stratégie de gestion des règles de pare-feu entre VLANs

Créer les VLANs ne suffit pas : la segmentation ne vaut que ce que valent les règles qui décident de ce qui peut quand même les traverser. C’est là que la plupart des mises en place de VLAN s’érodent avec le temps — une règle large ajoutée pour dépanner un jour, jamais retirée.

Partir fermé, ouvrir au cas par cas. Dès la création des interfaces VLAN sur le pare-feu, aucune règle n’autorise le trafic inter-VLAN — c’est l’état par défaut, et c’est celui qu’il faut garder comme référence. Chaque flux inter-VLAN nécessaire s’ajoute ensuite comme une exception explicite, jamais l’inverse (tout ouvrir puis essayer de fermer au cas par cas).

Une règle, une justification, un destinataire précis. Plutôt que VLAN20 net → VLAN10 net any (qui autorise les utilisateurs à atteindre tout le VLAN Administration), écrire VLAN20 net → 10.10.10.10 port 53,88,389 avec un commentaire du type « Authentification des postes utilisateurs sur le contrôleur de domaine ». Une règle qu’on ne peut pas justifier en une phrase est une règle à remettre en question.

Restreindre aux ports nécessaires, pas seulement à l’hôte — c’est là que la plupart des segmentations fuient. Limiter une règle à un hôte précis ne suffit pas si le port reste ouvert à tout. VLAN20 net → 10.10.10.10 any (destination précise, port « any ») semble raisonnable au premier regard, mais autorise en réalité les postes utilisateurs à atteindre tous les services du contrôleur de domaine : le partage d’administration SMB (445), RDP (3389), WinRM (5985/5986) — rien de tout ça n’a de raison d’être joignable depuis le VLAN Utilisateurs au quotidien. Avec cette seule règle trop permissive, un poste compromis dans le VLAN Utilisateurs retrouve, sur cet unique hôte, une surface d’attaque équivalente à celle d’un réseau plat. C’est exactement le chemin qu’ouvrent des vulnérabilités comme EternalBlue (MS17-010, SMB 445) ou ZeroLogon (CVE-2020-1472, RPC vers un contrôleur de domaine) : un accès réseau non restreint au port suffit à les exploiter, sans qu’aucune authentification valide ne soit nécessaire au départ — la segmentation par VLAN ne protège de rien si le port vulnérable reste accessible. La règle correcte énumère les ports strictement utiles à l’usage prévu (53 DNS, 88 Kerberos, 389 LDAP pour une authentification — jamais 445, 3389 ou 5985 depuis un VLAN utilisateurs) et rien d’autre ; tout le reste doit être explicitement refusé, y compris vers un hôte par ailleurs autorisé.

Ordonner du plus spécifique au plus général. La plupart des pare-feu de type OPNsense évaluent les règles dans l’ordre et s’arrêtent à la première correspondance : une règle large placée trop haut masque les règles précises qui suivent, même si elles semblent correctes isolément.

Journaliser les refus, pas seulement les autorisations. Une règle de blocage silencieuse ne laisse aucune trace exploitable. Activer la journalisation sur les règles de refus inter-VLAN transforme chaque tentative en signal exploitable par la supervision — un sujet qui reviendra dans cette série.

Revoir la liste des règles périodiquement, pas seulement quand quelque chose casse. Une règle ajoutée pour un besoin ponctuel (un prestataire pendant un projet, par exemple) qui n’est jamais retirée est l’une des façons les plus communes dont une segmentation se dégrade. Une revue trimestrielle, même rapide, suffit à l’éviter.

La matrice de flux reste l’outil de référence pour documenter l’intention, avant de la traduire en règles :

Vérifier que la segmentation tient vraiment

La configuration n’est une preuve de rien tant qu’elle n’a pas été testée. Depuis un poste du VLAN Utilisateurs :

# Un autre poste du même VLAN : doit répondre, direct, sans passer par le pare-feu
ping 10.10.20.50

# Un poste du VLAN Administration : doit être refusé (timeout, pas "unreachable")
ping 10.10.10.10
# --> Request timed out. (si le pare-feu DROP) ou
# --> Destination host unreachable. (si le pare-feu REJECT)

# Vérifier que ça passe bien par le pare-feu et pas directement
tracert 10.10.10.10     # Windows
traceroute 10.10.10.10  # Linux/macOS
# --> le premier saut doit être 10.10.20.1 (la passerelle), jamais l'IP cible directement

Trois résultats à obtenir, dans cet ordre : le ping intra-VLAN passe, le ping inter-VLAN non autorisé échoue, et le traceroute montre bien un premier saut par la passerelle (preuve que la tentative a été routée — donc vue et filtrée par le pare-feu — et non simplement perdue). Si le ping inter-VLAN réussit alors qu’aucune règle ne l’autorise, la cause la plus fréquente est une règle pare-feu trop large déjà en place, ou un trunk qui laisse passer tous les VLANs malgré la configuration du commutateur — à vérifier avec show vlan brief et show interfaces trunk côté commutateur.

Pièges courants

• Port d’administration du commutateur laissé sur le VLAN natif. Si ce VLAN n’est pas isolé, l’interface de gestion du commutateur est potentiellement joignable depuis n’importe quel VLAN mal configuré.
• Trunk sans restriction (switchport trunk allowed vlan all, ou absence de cette ligne). La segmentation fonctionne en test sur un port d’accès et ne sert à rien sur le trunk qui relie tout.
• Une règle pare-feu « any any » temporaire pour dépanner, jamais retirée. La cause la plus commune de segmentation qui ne segmente plus rien, six mois après la mise en place.
• DHCP désactivé par erreur sur un VLAN après un redémarrage du pare-feu, qui fait retomber les postes sur une adresse APIPA et masque un problème de VLAN derrière un faux problème réseau.

Suite

Le prochain article de la série s’attaque au Wi-Fi d’entreprise : pourquoi un mot de passe partagé (PSK) est une faille d’identité autant que de réseau, et comment basculer vers une authentification par utilisateur (802.1X / WPA3-Enterprise) qui s’appuie sur cette segmentation.