Filtrage, segmentation, NAC et Zero Trust
- Accueil
- Fondations techniques
- Réseaux
- Filtrage, segmentation, NAC et Zero Trust
Parcours « Administrateur système » — étape 08/15
07Durcir un serveur Linux avant la mise en production, checklist09VPN, tunnels, bastions et interconnexions protégées
Filtrage, segmentation, NAC et Zero Trust
Section intitulée « Filtrage, segmentation, NAC et Zero Trust »Un réseau se défend d’abord par sa forme : des zones séparées, des flux décrits un par un, un refus par défaut pour tout le reste, et un contrôle de ce qui a le droit de se brancher. Cette fiche détaille les outils du filtrage, du routeur filtrant au WAF (Web Application Firewall), la conception des zones, le contrôle d’accès au réseau ou NAC (Network Access Control) avec 802.1X, puis ce que recouvre réellement le Zero Trust une fois débarrassé de son vernis commercial.
Un immeuble de bureaux bien organisé distribue des badges différents selon les étages, accueille les visiteurs à part, et garde fermées les portes qui ne concernent pas chacun. Ce chapitre explique comment appliquer ces principes à un réseau informatique : le découper en zones, contrôler qui s’y branche et n’ouvrir que le nécessaire.
→ Lire l’explication complète de la marmotte
Filtrer explicitement
Section intitulée « Filtrer explicitement »Les sept attributs d’une règle
Section intitulée « Les sept attributs d’une règle »Une règle de filtrage utile répond à sept questions : quelle source (adresse ou préfixe), quelle destination, quel protocole (TCP, Transmission Control Protocol, UDP, User Datagram Protocol, ICMP, Internet Control Message Protocol), quel port de destination, quel état de connexion, quelle interface d’entrée ou de sortie, et dans quelle direction. Une règle qui omet l’un de ces attributs l’autorise implicitement en entier. « Autoriser le port 443 » sans source ni destination l’ouvre depuis n’importe où vers n’importe quoi, ce qui est rarement l’intention et toujours le résultat.
La direction compte autant : écrire la bonne règle sur la mauvaise interface, ou dans le mauvais sens, produit une politique parfaitement rédigée et parfaitement inopérante.
Sans état et avec état
Section intitulée « Sans état et avec état »Un filtrage sans état (stateless) examine chaque paquet isolément. Pour laisser revenir les réponses d’une connexion sortante vers un serveur web, il faut alors autoriser explicitement le trafic entrant depuis le port 443 vers les ports éphémères du client, soit une plage de plusieurs dizaines de milliers de ports, ouverte à quiconque prend la peine d’émettre depuis le port source 443. C’est le modèle des ACL (Access Control List) classiques des routeurs : rapides, simples, et naïves.
Un filtrage avec état (stateful) maintient une table des connexions en cours. Sous Linux, cette table est tenue par conntrack, le module de suivi de connexions de Netfilter, qui classe chaque paquet dans un état : new pour le premier paquet d’un flux, established pour un flux déjà vu dans les deux sens, related pour un flux annexe lié à une connexion connue (un message ICMP d’erreur, par exemple), invalid pour ce qui ne correspond à rien de cohérent. La politique n’a plus qu’à décrire les ouvertures de connexion ; les réponses sont acceptées parce qu’elles appartiennent à un flux déjà autorisé. Le suivi s’applique aussi à UDP, protocole sans connexion, par le biais d’une pseudo-connexion qui expire après un délai d’inactivité. La table a une taille finie : une inondation de connexions peut la remplir et faire refuser des flux légitimes.
# Voir les connexions suivies et leur étatconntrack -L | head# Taille courante et maximale de la tablesysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_maxRouteur filtrant, pare-feu, proxy, WAF
Section intitulée « Routeur filtrant, pare-feu, proxy, WAF »Ces quatre outils filtrent à des niveaux différents et ne se remplacent pas.
| Outil | Ce qu’il voit | Ce qu’il décide |
|---|---|---|
| Routeur filtrant (ACL) | En-têtes IP et ports, paquet par paquet | Passe ou ne passe pas, souvent sans état |
| Pare-feu | En-têtes, état des connexions, parfois l’application | Autorise des flux entre zones |
| Proxy (mandataire) | La requête applicative complète, émise en son nom | Autorise ou refuse une destination, une catégorie, un type de contenu |
| WAF | Les requêtes HTTP (HyperText Transfer Protocol) vers une application | Bloque des motifs d’attaque applicative (injections, chemins anormaux) |
Un routeur décide où envoyer un paquet ; un pare-feu décide s’il a le droit d’y aller. Un routeur doté d’ACL filtre, mais reste un routeur. Le proxy sortant agit pour le compte des postes internes vers Internet ; le reverse proxy, placé devant des serveurs, reçoit les requêtes des clients externes et les relaie vers l’intérieur. Même mécanique de relais, sens opposé, rôle opposé. Le WAF est en général un reverse proxy spécialisé : il protège une application web précise, pas le réseau.
Construire un default deny exploitable
Section intitulée « Construire un default deny exploitable »La politique default deny refuse tout ce qui n’est pas explicitement autorisé. Elle n’est exploitable qu’à trois conditions. D’abord, un inventaire des flux réels, sans lequel le premier jour se passe à rouvrir ce qui manquait. Ensuite, une journalisation des refus, faute de quoi un flux bloqué ressemble à une panne réseau. Enfin, une règle par besoin, commentée avec un propriétaire et une date de revue, pour éviter la dette de règles : ces centaines d’autorisations dont personne ne sait plus si elles servent, et que personne n’ose retirer.
Voici une politique minimale avec nftables, le cadre de filtrage qui remplace iptables dans les distributions Linux récentes. Trois zones sont reliées à un routeur Linux : lan (postes), dmz (serveurs exposés) et admin (postes d’administration).
table inet filtre { chain forward { type filter hook forward priority filter; policy drop;
ct state established,related accept # réponses des flux déjà autorisés ct state invalid drop # paquets incohérents
# Postes vers le serveur web de la DMZ, en HTTPS uniquement iifname "lan" oifname "dmz" ip daddr 10.20.0.10 tcp dport 443 accept
# Administration SSH de la DMZ, depuis le seul réseau d'administration iifname "admin" oifname "dmz" ip saddr 10.30.0.0/24 tcp dport 22 accept
# Tout le reste est journalisé puis refusé par la politique log prefix "fwd-refus: " counter }}La lecture se fait de haut en bas : la première règle qui conclut (accept ou drop) termine l’évaluation. La famille inet couvre IPv4 et IPv6 dans une même table, ce qui évite d’oublier le second. Rien n’autorise la DMZ à initier une connexion vers lan ou admin : si le serveur web est compromis, il ne peut pas rebondir vers les postes, ce qui est exactement la raison d’être d’une DMZ. La commande nft list ruleset affiche la politique effectivement chargée, seule à faire foi.
Segmenter et contrôler
Section intitulée « Segmenter et contrôler »Concevoir les zones
Section intitulée « Concevoir les zones »Une zone regroupe des machines de même niveau de confiance et de même exposition. Un découpage de départ raisonnable distingue :
- la DMZ (DeMilitarized Zone), qui héberge les services exposés à Internet et n’initie presque rien vers l’intérieur ;
- les serveurs internes, joignables depuis les postes sur des ports précis ;
- les postes de travail, qui n’ont aucune raison de se parler entre eux ;
- l’administration, seule zone autorisée à joindre les interfaces de gestion des équipements ;
- les invités, qui ne voient qu’Internet ;
- l’IoT (Internet of Things) et les équipements techniques (caméras, imprimantes, automates), réputés fragiles et rarement mis à jour.
On parle de flux nord-sud pour ce qui entre ou sort du système d’information, et est-ouest pour ce qui circule entre zones ou entre machines internes. Les pare-feu périmétriques voient le premier ; le second, qui porte l’essentiel des déplacements latéraux d’un attaquant, passe souvent sans contrôle, d’où la microsegmentation décrite plus bas. Le découpage technique en VLAN (Virtual Local Area Network) est décrit dans la fiche VLAN, trunks et boucles ; l’adressage qui va avec, dans IPv4, CIDR et plans d’adressage.
Segmenter sans inventaire de flux est la meilleure façon de découvrir, le lundi matin, qu’une application métier interrogeait une base de données située dans la zone qu’on vient de fermer.
802.1X, RADIUS et VLAN dynamique
Section intitulée « 802.1X, RADIUS et VLAN dynamique »Le NAC contrôle l’accès au moment du branchement, sur une prise filaire ou un point d’accès sans fil. Le mécanisme normalisé est IEEE 802.1X (Institute of Electrical and Electronics Engineers), qui fait intervenir trois acteurs :
Le poste, appelé supplicant, présente une identité par EAP (Extensible Authentication Protocol), transporté sur le lien local (EAPoL, EAP over LAN). Le commutateur, l’authenticator, ne décide rien : il relaie l’échange vers un serveur RADIUS (Remote Authentication Dial-In User Service). Tant que l’authentification n’a pas abouti, le port ne laisse passer que l’EAP. La méthode la plus robuste est EAP-TLS (Transport Layer Security), fondée sur un certificat machine, qui suppose une infrastructure de certificats ; les méthodes à mot de passe comme PEAP (Protected EAP) sont plus simples à déployer et plus faciles à abuser si le poste ne vérifie pas le certificat du serveur.
La réponse RADIUS peut porter un VLAN dynamique : les attributs Tunnel-Type (valeur 13, VLAN), Tunnel-Medium-Type (valeur 6, 802) et Tunnel-Private-Group-ID (numéro ou nom du VLAN), décrits dans le RFC 3580, placent le poste dans le bon segment quel que soit le bureau où il se branche. Un poste reconnu mais non conforme, antivirus éteint ou correctifs absents selon l’évaluation de posture, peut être envoyé en quarantaine : un VLAN qui ne donne accès qu’aux serveurs de mise à jour. Un message de changement d’autorisation (CoA, Change of Authorization, RFC 5176) permet au serveur RADIUS de reclasser un port en cours de session.
Exceptions, pannes et secours
Section intitulée « Exceptions, pannes et secours »Tout ne parle pas 802.1X. Imprimantes, téléphones et capteurs sont souvent admis par MAB (MAC Authentication Bypass), qui se contente de l’adresse MAC (Media Access Control) de l’équipement. Cette adresse se lit sur une étiquette et se recopie en une commande : un équipement admis par MAB doit donc atterrir dans une zone étroite, pas dans le VLAN des serveurs.
Il faut aussi décider de ce qui se passe quand le serveur RADIUS ne répond plus. Fermer tous les ports protège le réseau et arrête l’entreprise ; tout ouvrir maintient l’activité et annule le contrôle. La plupart des commutateurs proposent un comportement intermédiaire (maintien des sessions déjà authentifiées, VLAN de secours restreint pour les nouvelles), à condition de l’avoir configuré et testé avant la panne. Des serveurs RADIUS redondants restent la meilleure assurance.
Zero Trust moderne
Section intitulée « Zero Trust moderne »Les principes
Section intitulée « Les principes »Le Zero Trust part d’un constat : l’emplacement réseau ne prouve rien. Une connexion venant de l’intérieur n’est pas plus digne de confiance qu’une autre. Le NIST (National Institute of Standards and Technology) en a fixé un cadre de référence dans la publication SP 800-207, Zero Trust Architecture, parue en août 2020. Les principes se résument en trois verbes : vérifier explicitement chaque accès (identité de l’utilisateur, état de l’appareil, contexte), accorder le moindre privilège (une ressource précise, pas un réseau), et supposer la compromission, donc limiter ce qu’un accès volé permet d’atteindre. Les fondations côté identité sont traitées dans Principes de sécurité et identité.
ZTNA, SASE, SSE et bastions
Section intitulée « ZTNA, SASE, SSE et bastions »Le ZTNA (Zero Trust Network Access) remplace l’accès distant de type VPN, qui pose l’utilisateur sur le réseau, par un courtier qui ne publie qu’une application à la fois, après vérification de l’identité et de l’appareil. L’utilisateur ne voit ni les adresses internes ni les autres services.
Le SASE (Secure Access Service Edge), terme introduit par le cabinet Gartner en 2019, désigne la convergence dans un service en nuage des fonctions réseau (SD-WAN, Software-Defined Wide Area Network) et des fonctions de sécurité. Le SSE (Security Service Edge), proposé par le même cabinet en 2021, en désigne la seule partie sécurité : ZTNA, passerelle web sécurisée (SWG, Secure Web Gateway), courtier d’accès au nuage (CASB, Cloud Access Security Broker) et souvent pare-feu fourni en service. Ce sont des catégories de marché, pas des normes : deux offres « SASE » peuvent couvrir des périmètres très différents.
Le bastion, point de passage unique, authentifié fortement et journalisé, seul autorisé à joindre les interfaces de gestion, appliquait ces principes aux comptes les plus dangereux bien avant que le mot soit à la mode ; voir VPN, tunnels et bastions.
Microsegmentation, identité et flux autorisés
Section intitulée « Microsegmentation, identité et flux autorisés »Le Zero Trust ne supprime pas le réseau : il change la clé des règles. Au lieu de « le préfixe 10.20.0.0/24 peut joindre 10.40.0.5 sur le port 5432 », la règle devient « le service facturation, sur un hôte conforme, peut joindre la base facturation ». La microsegmentation applique ces règles au plus près de chaque charge de travail (machine virtuelle, conteneur, service), à partir d’étiquettes ou d’identités plutôt que d’adresses qui changent. Le prérequis reste l’inventaire des flux ; un produit acheté sans revoir droits ni flux laisse le réseau aussi plat qu’avant, avec une facture en plus. Les liens avec les déplacements d’attaquant sont détaillés dans Mouvement latéral et segmentation.
Exemples et ateliers
Section intitulée « Exemples et ateliers »Politique entre trois zones. Avec lan, dmz et admin, la matrice des flux s’écrit avant la moindre règle :
| De \ Vers | lan | dmz | admin |
|---|---|---|---|
| lan | interdit entre postes | 443 vers le serveur web | interdit |
| dmz | interdit | interdit sauf besoin documenté | interdit |
| admin | 22 et 3389 si nécessaire | 22 vers les serveurs | (zone elle-même) |
Chaque case non vide devient une règle, les autres relèvent de la politique par défaut. La matrice se relit en réunion sans savoir lire nftables, ce qui en fait le vrai document de référence.
Lire des règles nftables. Devant un ensemble de règles inconnu, trois questions suffisent pour commencer : quelle est la politique de chaque chaîne (policy drop ou policy accept) ? Les réponses sont-elles acceptées par une règle ct state established,related placée en tête ? Existe-t-il une règle accept sans ip saddr ni iifname, qui ouvrirait un port au monde entier ?
Dessiner poste, commutateur, RADIUS. Le schéma d’authentification ci-dessus se complète en y ajoutant le chemin d’échec (Reject, port fermé ou VLAN invités), le chemin de non-conformité (VLAN de quarantaine) et le chemin de panne (RADIUS injoignable, VLAN de secours). Un schéma limité au chemin nominal décrit le réseau tel qu’on l’espère.
Pièges classiques
Section intitulée « Pièges classiques »Ouvrir largement pour dépanner est le plus répandu : une règle any any posée à 18 heures pour débloquer une application devient permanente, personne n’ayant noté qu’elle était temporaire. Une date d’expiration dans le commentaire limite la casse. Segmenter sans inventaire de flux conduit soit à casser la production, soit à rouvrir en urgence des passages trop larges, ce qui ramène au piège précédent. Appliquer le Zero Trust comme un slogan, enfin, renomme l’existant sans changer un seul droit.
À ne pas confondre
Section intitulée « À ne pas confondre »Un pare-feu et un routeur : le second choisit un chemin, le premier autorise ou refuse un flux ; un routeur avec ACL filtre sans suivre les connexions. Un proxy et un reverse proxy : le premier représente les clients internes vers l’extérieur, le second représente des serveurs auprès des clients. Le NAC et l’authentification applicative : le NAC décide si un appareil peut se brancher et dans quel segment ; l’application décide ensuite si l’utilisateur peut lire tel dossier. Réussir l’un ne dispense jamais de l’autre. Et la traduction d’adresses ne filtre rien : voir NAT, translations et publication de services.
🐝 Ce qui arrive si on s’en passe
Section intitulée « 🐝 Ce qui arrive si on s’en passe »Un réseau plat, sans zones ni refus par défaut, transforme la première machine compromise en point de départ vers toutes les autres : les déplacements latéraux empruntent des flux jamais recensés, donc jamais interdits. Sans contrôle d’accès au branchement, la moindre prise libre d’une salle de réunion livre le même accès qu’un poste de travail. Les règles ouvertes « pour dépanner » ne se referment pas d’elles-mêmes, et la dette qu’elles forment finit par rendre la politique réelle illisible, y compris pour ceux qui l’administrent. Le jour de l’incident, impossible alors de dire quelles zones l’intrus a pu atteindre, puisque la réponse honnête est : toutes.
🦫 Explication de la marmotte 🍫
Section intitulée « 🦫 Explication de la marmotte 🍫 »Défendre un réseau commence par le découper en zones : postes des employés, serveurs exposés à Internet, administration, invités, objets connectés. Entre les zones, des équipements de filtrage appliquent des règles qui décrivent la source, la destination, le port, le protocole, le sens et l’état de la connexion. Un filtrage sans mémoire examine chaque paquet isolément ; un filtrage avec mémoire suit les connexions en cours et laisse passer les réponses qui correspondent à une demande autorisée. La bonne politique refuse tout par défaut et n’autorise que les flux nécessaires, ce qui suppose de les avoir d’abord inventoriés. D’autres outils agissent à d’autres niveaux : un relais qui fait les demandes à la place des postes, ou un pare-feu spécialisé dans les applications web. Le contrôle d’accès au réseau vérifie l’identité d’un appareil au moment où il se branche : le commutateur interroge un serveur d’authentification, puis place l’appareil dans le bon réseau virtuel, ou en quarantaine s’il n’est pas conforme. Il faut prévoir les pannes de ce contrôle et les exceptions. La microsegmentation pousse le découpage jusqu’à chaque service. L’approche dite de confiance zéro n’accorde aucune confiance à une connexion simplement parce qu’elle vient de l’intérieur : chaque accès est vérifié selon l’identité et limité au strict nécessaire. Avec le temps, les règles s’accumulent, et ouvrir largement pour dépanner crée une dette qu’il faut ensuite rembourser.
À lire aussi
- Wi-Fi d’entreprise et sécurité radioComprendre le Wi-Fi comme un réseau partagé, radio et mobile, avec ses normes, son association, son itinérance, sa QoS et ses risques propres.
- WireGuard et VPN maillés, fonctionnement, AllowedIPs et limitesCe que WireGuard garantit, ce qu'il laisse volontairement de côté, et ce que les réseaux maillés bâtis dessus changent pour l'architecture et la confiance.
- Topologies, composants d’interconnexion et LAN sécuriséChoisir et documenter une topologie locale en comprenant modes de communication, méthodes d’accès au support et rôle des composants d’interconnexion.
- GRE, IPsec ou GRE dans IPsec pour un tunnel site à siteChoisir entre GRE, IPsec et GRE dans IPsec pour relier deux sites, selon le chiffrement, le routage dynamique, le multicast et le coût en MTU.
Pages voisines
La citent
- GRE, IPsec ou GRE dans IPsec pour un tunnel site à site
- Protocole SSH, clés d'hôte, authentification et durcissement
- TLS ou tunnel VPN IPsec contre l'homme du milieu
- WireGuard et VPN maillés, fonctionnement, AllowedIPs et limites
- Comprendre pourquoi les systèmes communiquent
- Décision de chemin, routes statiques et routage système
Filtrage, segmentation, NAC et Zero Trust
Elle cite
- Lien dans les deux sens :VPN, tunnels, bastions et interconnexions protégées
- Lien dans les deux sens :IPv4, CIDR et plans d’adressage
- Lien dans les deux sens :NAT, translations et publication de services
- Lien dans les deux sens :VLAN, trunks, boucles et liens agrégés
- Lien dans les deux sens :Le VPN d'entreprise est-il mort ?
- Lien dans les deux sens :Principes de sécurité, identité et cryptographie utile au réseau
: les deux pages se citent l’une l’autre.
