Comment sécuriser un démarrage réseau PXE en entreprise

Le PXE (Preboot Execution Environment) permet à un poste de charger un environnement de démarrage depuis le réseau avant son système d’exploitation. C’est pratique pour installer, réparer et inventorier des machines, mais cette commodité transforme le premier réseau rencontré par le poste en autorité de démarrage.

→ Lire l’explication complète de la marmotte

PXE, DHCP et la chaîne de confiance absente

PXE s’appuie d’abord sur DHCP (Dynamic Host Configuration Protocol), le service qui attribue une configuration réseau à une machine. Le micrologiciel de la carte réseau diffuse une requête, reçoit une adresse Internet Protocol (IP) et l’emplacement d’un programme de démarrage. Selon l’architecture, ce programme peut être récupéré par TFTP (Trivial File Transfer Protocol), HTTP (Hypertext Transfer Protocol) ou HTTPS (HTTP Secure).

Le problème fondamental est brutal : DHCP n’authentifie pas le serveur qui répond, et TFTP ne chiffre ni n’authentifie rien. Un serveur DHCP pirate placé sur le même domaine de diffusion peut fournir une adresse, annoncer son propre chargeur et faire démarrer un code contrôlé par un attaquant. Le poste n’a pas besoin d’être compromis auparavant. Il lui suffit d’être éteint, ce qui reste une vulnérabilité étonnamment coopérative.

Le compromis central est là : PXE réduit le coût opérationnel du provisionnement, mais il étend la confiance au réseau avant toute authentification de l’utilisateur ou de l’agent de sécurité. La position à tenir est nette : PXE ne doit jamais être disponible sur un réseau utilisateur, bureautique ou invité. Il doit être confiné à des segments de déploiement explicitement administrés, avec des fenêtres d’accès et des règles de brassage documentées.

Le démarrage UEFI (Unified Extensible Firmware Interface) améliore la situation lorsque Secure Boot est activé. Secure Boot vérifie la signature du programme EFI chargé avant son exécution. Il ne sécurise pourtant pas DHCP, ne protège pas les métadonnées de déploiement et ne transforme pas TFTP en protocole fiable. Un chargeur signé qui télécharge un script non signé reste une chaîne de confiance trouée avec beaucoup d’élégance.

La page sur les réseaux couvre les principes de segmentation et de filtrage. Ici, la conséquence est plus stricte : le réseau de déploiement est une zone d’administration à privilège élevé, pas un service de commodité à étendre parce qu’un tableur contient une colonne « postes à installer ».

Segmentation PXE et protections de couche 2

Un serveur DHCP légitime ne suffit pas. Il faut empêcher les réponses DHCP venant de ports non autorisés. DHCP snooping, fonction des commutateurs qui filtre les messages DHCP selon la confiance attribuée aux interfaces, constitue le contrôle minimal. Les ports vers les serveurs DHCP et les relais DHCP sont déclarés fiables. Les ports d’accès ne le sont pas.

Sur les commutateurs qui le permettent, l’Option 82 DHCP ajoute l’identité du port et du relais aux requêtes. Le serveur peut alors limiter les baux PXE à des emplacements autorisés. Cette information ne doit pas être traitée comme une preuve cryptographique : elle est produite par l’infrastructure réseau, donc sa valeur dépend de l’administration des commutateurs et de l’absence de chemins de contournement.

L’inspection dynamique ARP (Address Resolution Protocol), alimentée par la table DHCP snooping, réduit les attaques de redirection locale après l’attribution d’adresse. Elle ne bloque pas un faux serveur DHCP si DHCP snooping est absent ou mal appliqué. Activer l’inspection ARP sans protéger DHCP revient à installer une serrure sur un placard laissé dans la rue.

Le cloisonnement doit séparer au minimum :

le réseau PXE des réseaux utilisateurs, serveurs et administration ;
le trafic de découverte DHCP des flux de transfert d’images ;
les environnements de production et de préproduction ;
les postes inconnus des machines autorisées à être reprovisionnées.

Le VLAN (Virtual Local Area Network) de déploiement ne doit pas être étendu en couche 2 entre sites par confort d’exploitation. Un relais DHCP contrôlé, des sous-réseaux locaux et des règles de pare-feu explicites limitent la portée d’un serveur pirate et les erreurs de configuration. Le pontage de diffusion intersite est le genre de raccourci qui finit par créer une réunion de crise avec beaucoup de flèches sur un schéma.

L’authentification IEEE 802.1X, fondée sur l’identité du poste ou de son utilisateur, peut interdire l’accès réseau avant autorisation. Elle pose toutefois un problème de poule et d’œuf pour PXE : le système à installer ne possède pas encore nécessairement de certificat ou d’identifiant. Prévoir un profil de préinstallation limité, associé au port, au matériel enregistré ou à un réseau physique dédié. L’authentification par adresse MAC reste un contrôle d’inventaire, pas une identité de sécurité : une adresse MAC (Media Access Control) se copie en quelques secondes.

Secure Boot, signatures et images de démarrage

Une chaîne PXE défendable commence par UEFI avec Secure Boot activé et verrouillé par politique de micrologiciel. Le premier chargeur EFI doit être signé par une autorité approuvée dans la base de clés UEFI. Les chargeurs suivants, noyaux, pilotes et environnements de récupération doivent conserver cette vérification. Le chargement d’un noyau ou d’un module non signé doit échouer, même si l’image arrive depuis le serveur officiel.

Le choix entre une autorité de certification publique et une PKI (Public Key Infrastructure) interne dépend du chargeur et de la gouvernance des clés. Une PKI interne donne le contrôle sur les autorités, les durées et la révocation, mais impose la distribution de la clé publique dans le micrologiciel ou par un mécanisme de signature reconnu. Les règles de cycle de vie sont détaillées dans PKI et TLS. Une clé de signature PXE ne doit pas être stockée sur le serveur de diffusion : ce serveur est exposé au réseau de démarrage et doit être considéré comme compromissible.

Conserver la clé privée dans un HSM (Hardware Security Module) ou dans un service de signature isolé réduit l’impact d’une compromission du dépôt d’images. La signature doit être effectuée dans la chaîne de fabrication, avant publication. Faire signer à la volée une image présente sur le serveur de démarrage rend la compromission de ce serveur beaucoup trop intéressante.

HTTPS apporte confidentialité et intégrité de transport si le chargeur valide effectivement le certificat du serveur. Ce dernier point est souvent escamoté. Une validation qui accepte n’importe quel certificat, ou une horloge absente qui contourne les contrôles de date, réduit HTTPS à une décoration de tableau de bord. Pour iPXE, embarquer l’autorité racine attendue et signer le binaire ou son script intégré évite que le premier script réseau devienne le maillon mou.

Secure Boot ne garantit pas qu’une image signée soit saine, récente ou autorisée pour une machine donnée. Une image vulnérable peut être parfaitement signée. La prévention du retour arrière impose un catalogue de versions autorisées, le retrait des images anciennes et la mise à jour de la liste de révocation UEFI, nommée dbx. Sans gestion de dbx, une signature révoquée sur le papier reste parfois exécutable sur le matériel. Le papier, cet excellent pare-feu passif.

Exemple de relais DHCP PXE restreint

Le relais DHCP doit envoyer les demandes de démarrage vers un serveur de déploiement identifié, sans faire du réseau PXE un service diffusé partout. L’exemple suivant configure dnsmasq sur un segment dédié. Il distingue les clients UEFI x86_64 et n’écoute que sur l’interface du réseau de provisionnement.

# Écouter uniquement le segment de déploiement, jamais le réseau bureautique.
interface=ens192
bind-interfaces

# Attribuer des baux limités au sous-réseau PXE.
dhcp-range=10.42.16.100,10.42.16.180,255.255.255.0,2h

# Identifier les clients UEFI 64 bits (architecture DHCP 7).
dhcp-match=set:uefi64,option:client-arch,7

# Fournir un chargeur EFI signé, servi ensuite par HTTPS.
dhcp-boot=tag:uefi64,ipxe.efi,10.42.16.10

# Ne jamais activer TFTP ici si le chargeur et les artefacts sont disponibles en HTTPS.
# enable-tftp
# tftp-root=/srv/tftp

Cette configuration ne remplace pas DHCP snooping. Si un port d’accès peut répondre aux requêtes DHCP, un attaquant peut annoncer un autre chargeur avant le serveur configuré. Le contrôle doit donc exister à la fois sur le commutateur et sur le serveur. Les deux couches répondent à des défaillances distinctes.

Tester les refus est obligatoire : connecter un serveur DHCP non autorisé sur un port d’accès doit produire un blocage et un événement de journalisation. Tester uniquement qu’un poste démarre est insuffisant. Une porte blindée qui s’ouvre correctement n’indique rien sur sa capacité à rester fermée.

Exploitation, secrets et reprise du service PXE

Les artefacts de démarrage doivent être versionnés, hachés et publiés depuis un dépôt à écriture restreinte. Le serveur PXE ne doit recevoir que des versions validées. Les identifiants de gestion, jetons d’API (Application Programming Interface), mots de passe locaux ou clés privées ne doivent jamais figurer dans une image de préinstallation. Une image PXE se télécharge souvent sans secret matériel et se copie très bien. Les secrets injectés avant le premier démarrage persistant finissent régulièrement dans des journaux, des caches ou des archives d’incident.

La rotation de la clé de signature exige une période de chevauchement : distribuer la nouvelle clé publique aux micrologiciels, signer les chargeurs avec l’ancienne et la nouvelle clé si le format le permet, vérifier les démarrages, puis révoquer l’ancienne. Révoquer immédiatement une clé compromise impose aussi de publier une liste dbx ou de retirer la confiance correspondante sur les postes. Sans mécanisme de mise à jour du micrologiciel, la révocation est théorique.

Superviser les réponses DHCP PXE, les téléchargements d’images, les échecs de validation de signature et les changements de configuration réseau. Une hausse de réponses DHCP sur un port non fiable, un chargeur inattendu ou un volume inhabituel de téléchargements doivent déclencher une investigation. Les journaux doivent relier adresse MAC, port de commutateur, image demandée, empreinte de l’artefact et résultat de démarrage.

La reprise après sinistre doit restaurer séparément le service de diffusion, le catalogue d’images, les autorités de signature et leurs sauvegardes protégées. Restaurer un vieux dépôt sans son historique de révocation peut remettre en circulation une image abandonnée. Le service PXE peut être indisponible sans arrêter les postes déjà installés, mais il peut bloquer une reconstruction massive. Cette dépendance doit apparaître dans le plan de continuité, avec le même sérieux que les identités d’administration qui autorisent le déploiement.

🐝 Ce qui arrive si on s’en passe

Sans authentification du démarrage réseau, le premier réseau rencontré par un poste devient son autorité de démarrage. Quiconque contrôle ce segment peut répondre à la place du serveur légitime et livrer un environnement d’amorçage arbitraire : la machine exécute alors, avant même son système habituel, du code choisi par un attaquant. Cela ouvre la voie à l’implantation d’un socle persistant sous le système d’exploitation, à la capture des identifiants saisis au démarrage et au déploiement massif d’une configuration malveillante sur tout un parc, puisque le même atelier prépare toutes les machines. Un PXE ouvert transforme ainsi une commodité d’installation en point de contrôle convoité : celui qui décide de ce que chaque poste fait au réveil précède toutes les protections qui s’activent plus tard, et aucune ne peut rattraper une amorce déjà détournée.

🦫 Explication de la marmotte 🍫

Au démarrage, un ordinateur peut demander sur le réseau où trouver un programme à lancer avant son système habituel. Un serveur lui donne une adresse réseau et indique où récupérer ce programme. Le programme charge ensuite les fichiers nécessaires pour installer, réparer ou contrôler la machine.

Le risque apparaît parce que l’ordinateur ne sait pas toujours vérifier qui répond à cette première demande. Une machine malveillante connectée au même réseau peut répondre plus vite, fournir sa propre adresse et demander à l’ordinateur de lancer un programme dangereux. Si les fichiers sont transférés sans protection, ils peuvent aussi être modifiés pendant le trajet.

La protection commence donc par séparer le réseau de préparation des ordinateurs des autres réseaux. Les équipements réseau doivent accepter les réponses du serveur autorisé et bloquer les autres. Le programme de démarrage doit aussi porter une signature numérique : une preuve mathématique liée à une clé de confiance enregistrée dans l’ordinateur. Si la signature est absente, inconnue ou révoquée, le démarrage doit s’arrêter.

Cette vérification ne protège pas contre un programme ancien mais encore autorisé, ni contre une clé de signature volée. Il faut donc retirer les anciennes versions, changer les clés selon un calendrier, protéger les clés privées, conserver des sauvegardes et surveiller les échecs. Si le service de démarrage tombe en panne, les ordinateurs déjà installés continuent généralement à fonctionner, mais les nouvelles installations et les réparations réseau deviennent impossibles.