Atténuer les vulnérabilités RADIUS : un guide de sécurisation
Ce guide fournit une référence complète et exploitable pour les responsables informatiques, les architectes réseau et les CTO responsables de l'infrastructure WiFi d'entreprise dans les secteurs de l'hôtellerie, du commerce, des événements et du secteur public. Il couvre l'ensemble de la surface d'attaque des déploiements de serveurs RADIUS - des vulnérabilités de collision MD5 et des secrets partagés faibles au transport UDP non chiffré et aux méthodes EAP mal configurées - et fournit une feuille de route de sécurisation prioritaire conforme aux exigences IEEE 802.1X, PCI-DSS et GDPR. Les organisations qui mettent en œuvre ces recommandations réduiront considérablement leur exposition aux attaques réseau basées sur les identifiants, respecteront leurs obligations de conformité et construiront une posture de sécurité défendable pour leur infrastructure WiFi invités et d'entreprise.
Video overview
Écouter ce guide
Voir la transcription du podcast
Fait partie de notre série principale : Guide de sécurité WiFi d'entreprise →
Synthèse
RADIUS (Remote Authentication Dial-In User Service) reste le protocole principal de contrôle d'accès au réseau pour les déploiements de WiFi d'entreprise, prenant en charge l'authentification 802.1X dans l'hôtellerie, les points de vente, les stades, les centres de congrès et les bâtiments du secteur public. Cependant, l'architecture de RADIUS remonte aux années 1990, et plusieurs de ses choix de conception fondamentaux - la dépendance aux hachages MD5, le transport UDP sans chiffrement natif et les secrets partagés statiques - constituent des risques majeurs dans le paysage actuel des menaces.
En juillet 2024, la vulnérabilité BlastRADIUS (CVE-2024-3596) a démontré qu'un attaquant de type "homme du milieu" (MitM) pouvait falsifier des réponses RADIUS Access-Accept en exploitant une vulnérabilité d'intégrité MD5 dans les paquets Access-Request. Cette faille affecte toutes les implémentations majeures de RADIUS, notamment FreeRADIUS, Cisco ISE et Microsoft NPS. Les déploiements non corrigés restent exposés.
Ce guide propose une feuille de route de sécurisation priorisée, couvrant la gestion des correctifs, l'hygiène des secrets partagés, la sélection des méthodes EAP, le déploiement de RadSec, l'authentification multifacteur pour l'accès de gestion et l'intégration SIEM pour la détection des anomalies. Il est rédigé pour les professionnels de l'IT qui doivent prendre des décisions concrètes ce trimestre, et non l'année prochaine.
Analyse Technique Approfondie
Fonctionnement de RADIUS et ses points faibles
RADIUS fonctionne sur un modèle client - serveur entre un serveur d'accès réseau (NAS) - généralement des points d'accès WiFi, des commutateurs ou des concentrateurs VPN - et un serveur RADIUS, qui valide les identifiants par rapport à un annuaire d'identités centralisé tel qu'Active Directory ou LDAP. L'échange d'authentification suit un modèle requête - défi - réponse défini dans la RFC 2865, tandis que la comptabilité est gérée séparément sous la RFC 2866.
Le protocole transporte les paquets d'authentification via UDP, en utilisant le port 1812 pour l'authentification et le port 1813 pour la comptabilité. Le secret partagé - une clé pré-partagée configurée sur le NAS et le serveur RADIUS - est utilisé pour générer le champ Response Authenticator et chiffrer l'attribut User-Password via un chiffrement XOR basé sur MD5. Il ne s'agit pas d'un chiffrement au sens moderne du terme ; c'est un simple masquage qui repose entièrement sur le secret et la force de la clé partagée.
Les cinq grandes catégories de vulnérabilités d'un déploiement RADIUS classique sont présentées ci-dessous.
Collisions MD5 et vulnérabilités d'intégrité. L'attaque BlastRADIUS (CVE-2024-3596) exploite l'absence de protection de l'intégrité dans les paquets Access-Request. Comme de nombreuses configurations n'incluent pas l'attribut Message-Authenticator provenant du NAS par défaut, un attaquant positionné en MitM peut injecter des attributs spécialement conçus avant que le paquet n'atteigne le serveur RADIUS. En utilisant une technique de collision MD5 à préfixe choisi, l'attaquant peut manipuler le paquet de sorte que le serveur RADIUS calcule un Response Authenticator valide pour le paquet modifié, renvoyant un Access-Accept pour une requête qui aurait dû être refusée. La correction consiste à imposer l'attribut Message-Authenticator sur tous les paquets Access-Request, ce qui assure une protection d'intégrité HMAC-MD5 sur l'ensemble du paquet. Cela nécessite des modifications de configuration sur le NAS et le serveur RADIUS, et non un simple correctif du serveur.
Secrets partagés faibles ou statiques. Le secret partagé est le pilier cryptographique de l'échange RADIUS. Si la clé est courte, prévisible ou jamais renouvelée, un attaquant capturant le trafic RADIUS (via une attaque d'empoisonnement ARP ou un équipement réseau compromis) peut forcer l'attribut User-Password hors ligne. Les directives NIST SP 800-63B sur les clés mémorisées s'appliquent ici : les clés doivent comporter au moins 20 caractères, être générées de manière aléatoire et être stockées dans un système de gestion des clés. Pour les grands réseaux comportant des dizaines ou des millions de périphériques NAS, le renouvellement manuel est impossible sur le plan opérationnel ; l'automatisation via HashiCorp Vault ou un gestionnaire de secrets similaire est la solution à privilégier.
Transport UDP non chiffré. Le protocole RADIUS standard sur UDP n'offre pas de confidentialité au niveau de la couche de transport. L'attribut User-Password est masqué mais non chiffré. Tous les autres attributs - y compris les noms d'utilisateur, les adresses IP des NAS et les métadonnées de session - transitent en texte clair. RadSec (RADIUS over TLS), défini dans la RFC 6614 et mis à jour dans la RFC 7360, résout ce problème en encapsulant le protocole RADIUS dans un tunnel TLS sur le port TCP 2083, établissant ainsi une session TLS 1.2 ou TLS 1.3. RadSec assure une authentification mutuelle par certificat entre le NAS et le serveur RADIUS, un chiffrement complet de la charge utile et une protection contre le rejeu. C'est le mode de transport requis pour tout trafic RADIUS traversant des réseaux non sécurisés.
Sélection de la méthode EAP. Le protocole EAP (Extensible Authentication Protocol) définit les méthodes d'authentification interne utilisées au sein du framework 802.1X. EAP-MD5 est obsolète et doit être immédiatement retiré de tous les déploiements - il n'offre pas d'authentification mutuelle et ne protège pas contre les attaques de vol d'identifiants. PEAP (Protected EAP) et EAP-TTLS établissent un tunnel TLS à l'aide d'un certificat serveur avant de transmettre les identifiants, offrant ainsi une authentification mutuelle et protégeant la méthode interne contre l'écoute passive. EAP-TLS élimine complètement les mots de passe en exigeant des certificats X.509 à la fois sur le serveur et sur le client. Insensible aux attaques de phishing et de force brute, c'est la méthode recommandée pour les environnements à haute sécurité.
Journalisation et surveillance insuffisantes. La comptabilité RADIUS enregistre chaque événement d'authentification - succès, échecs, début de session, fin de session. Ces données sont précieuses sur le plan opérationnel pour la planification des capacités, hautement stratégiques pour l'analyse commerciale via WiFi Analytics , et constituent également une source essentielle de télémétrie de sécurité. Les vagues d'échecs d'authentification, les tentatives provenant d'adresses MAC inconnues et les modèles d'accès en dehors des heures de travail peuvent être détectés à partir des journaux de comptabilité RADIUS. La plupart des organisations n'envoient pas ces données à leur SIEM, et celles qui le font configurent rarement des seuils d'alerte.
Détails de l'attaque BlastRADIUS
BlastRADIUS a été révélée en juillet 2024 par des chercheurs de l'Université de Boston et de l'Université de Californie à San Diego. L'attaque nécessite une position d'homme du milieu (MitM) entre le NAS et le serveur RADIUS - ce qui est réalisable via un empoisonnement ARP sur un segment réseau partagé, un routeur compromis ou un utilisateur interne malveillant disposant d'un accès réseau.
Le processus d'attaque se déroule comme suit : l'attaquant intercepte un paquet Access-Request provenant du NAS. Comme ce paquet ne contient pas l'attribut Message-Authenticator (la configuration par défaut sur de nombreux systèmes), l'attaquant est libre de modifier la liste des attributs du paquet. En utilisant une collision de préfixes choisis sur MD5, l'attaquant construit un paquet modifié pour lequel le serveur RADIUS calculera le même Response Authenticator que pour le paquet original. Par conséquent, le serveur renvoie un Access-Accept pour une requête contenant des attributs contrôlés par l'attaquant - y compris l'attribut Administrative Service-Type qui accorde un accès réseau complet.
Cette attaque est efficace contre les déploiements PEAP et EAP-TTLS utilisant MSCHAPv2 comme méthode interne. Elle n'affecte pas les déploiements EAP-TLS, car l'authentification mutuelle basée sur des certificats offre une protection de l'intégrité que MD5 ne peut pas compromettre.
Pour les organisations qui gèrent à la fois du Guest WiFi et du 802.1X d'entreprise, les instances RADIUS du réseau invités doivent également être corrigées, même s'ils utilisent le MAC Authentication Bypass au lieu d'EAP. Les spécifications de sécurité des clés secrètes partagées et les exigences de Message-Authenticator s'appliquent de la même manière.
Guide de mise en œuvre
Étape 1 : Remédiation immédiate (Semaines 1 - 2)
L'application des correctifs est la première étape. FreeRADIUS 3.2.5 et 3.0.27 intègrent les correctifs pour BlastRADIUS et imposent le Message-Authenticator par défaut. Cisco ISE 3.1 Patch 8, 3.2 Patch 4 et 3.3 Patch 1 résolvent cette vulnérabilité. Microsoft a publié la mise à jour KB5040434 pour Windows Server 2022 NPS en juillet 2024. Vérifiez votre version actuelle et appliquez ces correctifs lors de votre prochaine fenêtre de maintenance planifiée.
Parallèlement, auditez le micrologiciel de vos équipements NAS. L'application du Message-Authenticator n'est efficace que si le NAS envoie également cet attribut. Consultez les avis de sécurité des fabricants de vos points d'accès et commutateurs - Aruba, Ruckus, Cisco et Juniper ont tous publié des mises à jour de micrologiciel pour BlastRADIUS. Si vous utilisez du matériel Ruckus, le wireless access point Ruckus guide fournit des informations contextuelles sur la gestion des micrologiciels.
Pour résoudre les éventuels problèmes de troubleshooting Windows 11 802.1X authentication issues après l'application des correctifs, sachez que la cause la plus fréquente est le rejet par le serveur NPS des connexions clients n'incluant pas le Message-Authenticator - un comportement de sécurité correct qui peut nécessiter une reconfiguration du demandeur (supplicant) sur les clients Windows plus anciens.
Étape 2 : Hygiène des clés secrètes partagées (Semaines 2 - 4)
Exportez la liste complète des clients NAS enregistrés sur vos serveurs RADIUS. Documentez la longueur de la clé secrète partagée de chaque entrée et la date de sa dernière modification. Toute clé de moins de 20 caractères ou n'ayant pas été modifiée depuis plus de 24 mois doit être renouvelée immédiatement.
Pour les nouvelles clés, utilisez un générateur de nombres aléatoires cryptographiques - openssl rand -base64 32 génère une chaîne base64 de 44 caractères, idéale pour une clé secrète partagée RADIUS. Stockez toutes les clés dans un système de gestion des secrets. Mettez en place un calendrier de rotation : annuel pour les équipements NAS à faible risque, et tous les six mois pour les équipements NAS entrant dans le champ d'application de la norme PCI-DSS.
Étape 3 : Rationalisation des méthodes EAP (Mois 1 - 2)
Auditez les méthodes EAP autorisées sur votre serveur RADIUS. Désactivez EAP-MD5. Si vous utilisez PEAP-MSCHAPv2, vérifiez que tous les demandeurs (supplicants) imposent la validation du certificat du serveur - un demandeur mal configuré qui accepte n'importe quel certificat de serveur est vulnérable aux attaques par faux serveur RADIUS. Pour les environnements soumis à la norme PCI-DSS, EAP-TLS est recommandé. Si vous ne disposez pas d'une infrastructure de certificats active, commencez la planification d'une PKI.
Pour la sécurisation des réseaux Guest WiFi (securing guest wifi networks), notez que les réseaux d'invités utilisent généralement l'authentification par Captive Portal plutôt que le 802.1X, le renforcement des méthodes EAP s'applique donc principalement aux SSID d'entreprise et des employés.
Étape 4 : Déploiement de RadSec (Mois 2 - 3)
Identifiez chaque chemin de trafic RADIUS traversant des limites de réseau non approuvées. Les scénarios courants incluent un serveur RADIUS central desservant des sites hôteliers distants via Internet, des équipements NAS locaux se connectant à un service RADIUS cloud, ou des chaînes de proxy RADIUS où le trafic traverse plusieurs domaines réseau.
Configurez RadSec pour chaque chemin identifié. Sur FreeRADIUS, cela consiste à activer l'écouteur tls sur le port 2083 et à configurer le TLS mutuel avec des certificats issus de votre PKI. Sur Cisco ISE, RadSec se configure sous Administration > Network Devices. Assurez-vous d'utiliser au minimum TLS 1.2 et désactivez explicitement TLS 1.0 et 1.1.
Étape 5 : Authentification multifacteur pour l'accès d'administration (Mois 2 - 3)
L'interface d'administration de votre serveur RADIUS est une cible de choix. Un attaquant qui compromet un serveur RADIUS peut modifier les politiques d'authentification, extraire des clés secrètes partagées et rediriger le trafic d'authentification. Imposez le MFA pour toutes les connexions administrateur aux serveurs RADIUS et à leurs systèmes d'exploitation sous-jacents. Limitez l'accès d'administration à un VLAN de gestion hors bande dédié. Mettez en œuvre un contrôle d'accès basé sur les rôles : un ingénieur réseau ne doit pas disposer des mêmes privilèges qu'un administrateur de sécurité.
Étape 6 : Intégration SIEM et alertes (Mois 3 - 4)
Configurez votre serveur RADIUS pour transférer les journaux de comptabilisation (accounting) en temps réel vers votre SIEM. Définissez les seuils d'alerte initiaux suivants :
| Alerte | Seuil | Niveau de gravité |
|---|---|---|
| Échecs d'authentification multiples pour une seule adresse MAC | >5 en 60 secondes | Élevé |
| Pic du taux de rejet d'accès (Access-Reject) | >200 % par rapport à la moyenne sur 7 jours | Moyen |
| Authentification depuis une nouvelle adresse MAC sur un SSID d'entreprise | Première occurrence | Moyen |
| Expiration imminente du certificat du serveur RADIUS | 90 / 30 / 7 jours | Élevé / Urgent / Urgent |
| Erreur de non-correspondance du secret partagé | N'importe quelle occurrence | Élevé |
Vous avez des questions sur votre configuration spécifique ?
Notre équipe collabore avec des exploitants de sites, des responsables informatiques et des ingénieurs réseau au sein de 80 000 sites. Réservez un appel de 20 minutes et nous vous montrerons comment d'autres professionnels comme vous ont résolu ce problème.
Meilleures pratiques
Les recommandations suivantes synthétisent le consensus issu d'IEEE 802.1X, NIST SP 800-63B, PCI-DSS v4.0 et des avis de sécurité des constructeurs.
Gestion des certificats. Tout déploiement utilisant EAP-TLS ou RadSec intègre des certificats X.509 dans son parcours d'authentification. L'expiration des certificats est la cause unique la plus fréquente de pannes d'authentification soudaines et totales dans les déploiements WiFi d'entreprise. Mettez en œuvre une gestion automatisée du cycle de vie des certificats. Configurez des alertes de supervision 90, 30 et 7 jours avant l'expiration. Pour les certificats de serveur RADIUS, utilisez des clés RSA d'au moins 2048 bits ou ECDSA de 256 bits, ainsi qu'un algorithme de signature SHA-256 ou plus robuste. N'utilisez pas SHA-1.
Segmentation réseau. Le serveur RADIUS doit être localisé dans un segment réseau d'administration dédié, isolé des réseaux invités et d'entreprise classiques. L'accès aux ports RADIUS (UDP 1812, 1813 et TCP 2083 pour RadSec) doit être restreint via des ACL de pare-feu aux adresses IP spécifiques des équipements NAS enregistrés. N'autorisez aucun accès direct aux ports RADIUS depuis Internet.
Redondance et haute disponibilité. Un serveur RADIUS unique constitue un point de défaillance unique pour l'ensemble de votre infrastructure de contrôle d'accès réseau. Déployez au moins deux serveurs RADIUS dans une configuration actif - passif ou actif - actif. Pour les déploiements dans le secteur de l' hôtellerie avec des exigences de connectivité invité 24h/24 et 7j/7, une interruption du serveur RADIUS se traduit directement par une panne du WiFi invité - un risque réputationnel et commercial majeur. WPA3 et 802.1X. Le mode WPA3-Enterprise avec sécurité 192 bits est une exigence essentielle pour les déploiements gouvernementaux et hautement sécurisés, imposant l'usage d'AES-256-GCMP pour le chiffrement des données et HMAC-SHA-384 pour l'authentification. Pour la majorité des déploiements d'entreprise, WPA3-Enterprise associé à la protection de sécurité standard 128 bits offre déjà une amélioration significative par rapport à WPA2-Enterprise, en particulier lorsqu'il est combiné avec EAP-TLS. Les environnements de vente au détail traitant des paiements par carte doivent considérer l'adoption de WPA3-Enterprise comme une mesure de réduction des risques vis-à-vis de PCI-DSS.
Rythme de correctifs constructeurs. Abonnez-vous aux avis de sécurité de vos constructeurs de serveurs RADIUS et de vos équipements NAS. FreeRADIUS, Cisco, Microsoft, Aruba et Ruckus publient régulièrement des avis CVE. Intégrez ces informations dans votre programme de gestion des vulnérabilités et définissez des SLA clairs : correction des vulnérabilités critiques (CVSS ≥ 9.0) sous 72 heures ; correction des vulnérabilités élevées (CVSS 7.0 - 8.9) sous 14 jours.
Dépannage et atténuation des risques
Modes de défaillance courants
Échec de l'authentification après application de correctifs. Suite à l'application du correctif BlastRADIUS, si le firmware de certains équipements NAS ne prend pas en charge l'attribut Message-Authenticator, cela peut entraîner des échecs d'authentification. Symptômes : augmentation soudaine des réponses Access-Reject sans modification des identifiants des utilisateurs. Diagnostic : activez les journaux de débogage RADIUS et recherchez l'erreur "Message-Authenticator required but not present" (Message-Authenticator requis mais absent). Résolution : mettez à jour le firmware du NAS ou, à titre temporaire durant la planification de la mise à jour, configurez le serveur RADIUS pour accepter les requêtes sans Message-Authenticator provenant des IP spécifiques des NAS concernés.
Échec de validation de certificat dans EAP-TLS. Symptômes : le client reçoit un message d'erreur "échec d'authentification", mais aucun Access-Reject correspondant n'apparaît dans les journaux RADIUS. Diagnostic : vérifiez la chaîne de certificats du serveur RADIUS - l'autorité de certification (CA) émettrice est-elle approuvée par le demandeur client ? Le certificat du serveur est-il toujours valide ? Résolution : assurez-vous que la chaîne de certificats complète (certificat final + certificats intermédiaires + certificat racine) est configurée sur le serveur RADIUS. Diffusez le certificat de la CA racine vers les appareils clients via MDM ou stratégie de groupe.
Échec de la liaison TLS RadSec. Symptômes : les équipements NAS ne parviennent pas à établir une connexion RadSec après une modification de configuration. Diagnostic : vérifiez la compatibilité des versions TLS - les firmwares de NAS plus anciens peuvent ne pas prendre en charge TLS 1.2. Vérifiez la validation mutuelle des certificats - les deux parties doivent faire confiance aux CA respectives. Résolution : validez la prise en charge de la version TLS dans les notes de version du firmware du NAS ; assurez-vous que le certificat du NAS est émis par la même CA approuvée par le serveur RADIUS.
Non-correspondance du secret partagé. Symptômes : chaque authentification provenant d'un NAS spécifique échoue avec une erreur "invalid authenticator" (authentificateur non valide). Diagnostic : non-correspondance du secret partagé entre la configuration du NAS et la fiche client sur le serveur RADIUS. Résolution : saisissez à nouveau le secret partagé des deux côtés, en vérifiant l'absence d'espaces finals ou de problèmes d'encodage de caractères. Copiez-collez depuis votre gestionnaire de clés pour éviter les erreurs de saisie.
Registre des risques
| Risque | Probabilité | Impact | Mesure d'atténuation |
|---|---|---|---|
| Exploitation de la vulnérabilité BlastRADIUS | Élevée (si non corrigée) | Critique | Correctif + application obligatoire du Message-Authenticator |
| Attaque par force brute sur le secret partagé | Moyenne | Élevé | Clé de 32 caractères aléatoires, rotation annuelle |
| Serveur RADIUS malveillant | Moyenne | Élevé | Authentification mutuelle EAP-TLS, association de certificats |
| Expiration du certificat du serveur RADIUS | Élevée | Critique | Supervision automatisée, alertes 90 jours à l'avance |
| Attaque par bourrage d'identifiants via 802.1X | Moyenne | Élevé | Stratégie de verrouillage de compte, alertes SIEM |
| Compromission du serveur RADIUS | Faible | Critique | MFA pour l'accès administrateur, segmentation réseau |
Retour sur investissement (ROI) et impact métier
Quantification des risques
La justification économique du durcissement de RADIUS apparaît le plus clairement lorsque l'on considère le coût d'une violation de données. En 2024, le coût moyen d'une violation de données au Royaume-Uni s'élevait à 3,58 millions de livres sterling, englobant les amendes réglementaires, les mesures correctives, les frais juridiques et la perte de réputation. Pour les organisations concernées par le périmètre PCI-DSS - ce qui inclut en pratique tous les exploitants de Retail et de Hospitality acceptant les paiements par carte via le WiFi - une faille de contrôle d'accès réseau exposant les données des titulaires de cartes déclenchera des enquêtes médico-légales obligatoires, des amendes potentielles de la part des réseaux de cartes et une possible suspension des privilèges de traitement des cartes.
Pour les organisations de Healthcare , l'accès aux données des patients via un serveur RADIUS compromis entraînant une violation du GDPR expose l'entité à des amendes pouvant atteindre 4 % du chiffre d'affaires annuel mondial en vertu de l'article 83(5). Les décisions de l'ICO démontrent que les failles de cybersécurité sont traitées comme de la négligence et non comme un simple incident technique.
Repères de coûts de mise en œuvre
Les estimations de coûts suivantes sont basées sur un réseau de 500 appareils :
| Activité de sécurisation | Coût estimé | Calendrier |
|---|---|---|
| Correctifs (FreeRADIUS / NPS / ISE) | Main-d'œuvre interne uniquement | 1 - 2 semaines |
| Audit et rotation des clés partagées | Main-d'œuvre interne + licence de gestionnaire de clés (env. 2 000 £/an) | 2 - 4 semaines |
| Déploiement PKI EAP-TLS | 15 000 - 30 000 £ (outils + services professionnels) | 2 - 3 mois |
| Implémentation RadSec | Main-d'œuvre interne + coût des certificats (env. 1 500 £) | 4 - 6 semaines |
| Intégration SIEM et alertes | Variable selon le SIEM existant ; 0 - 10 000 £ | 4 - 8 semaines |
L'investissement total de sécurisation pour une entreprise de taille moyenne se situe entre 20 000 et 45 000 £ environ. Comparé au coût de référence d'une violation de données s'élevant à 3,58 millions de livres sterling, le ROI ajusté au risque reste extrêmement convaincant, même en adoptant des hypothèses prudentes quant à la probabilité de survenue d'une faille.
Des avantages opérationnels au-delà de la sécurité
Une infrastructure RADIUS renforcée génère également des dividendes opérationnels. Une authentification fiable et bien surveillée réduit le nombre de tickets d'assistance liés à la connectivité WiFi. Lorsque les données de comptabilisation RADIUS sont intégrées avec WiFi Analytics , elles offrent une visibilité au niveau des sessions sur les profils d'utilisation du réseau, les temps de présence et les types d'appareils - des données qui possèdent une valeur commerciale directe pour les exploitants de sites dans les secteurs de l' Hospitality et des Transport .
Pour les organisations du secteur public et de la santé , un plan documenté de sécurisation RADIUS fournit la preuve des contrôles techniques pour les évaluations Cyber Essentials Plus, ISO 27001 et NHS DSPT - ce qui réduit la charge d'audit et démontre la diligence requise auprès des autorités de réglementation.
Définitions clés
RADIUS (Remote Authentication Dial-In User Service)
Un protocole client-serveur défini dans la RFC 2865 qui fournit une authentification, une autorisation et une comptabilité (AAA) centralisées pour l'accès au réseau. Les serveurs RADIUS valident les identifiants soumis par les équipements réseau (NAS) par rapport à un répertoire d'identités sous-jacent tel que Active Directory ou LDAP.
Les équipes informatiques rencontrent RADIUS en tant que moteur d'authentification pour le WiFi 802.1X, l'authentification des ports filaires, l'accès VPN et la gestion des équipements réseau. C'est le protocole qui détermine qui accède au réseau.
IEEE 802.1X
Une norme IEEE pour le contrôle d'accès réseau basé sur les ports qui définit l'encapsulation de l'EAP sur LAN (EAPOL). Elle fournit un framework d'authentification pour les réseaux filaires et sans fil, exigeant que les appareils s'authentifient avant d'obtenir l'accès au réseau.
Le 802.1X est la norme qui permet le fonctionnement de l'authentification WiFi d'entreprise. Lorsqu'un membre du personnel se connecte à un SSID d'entreprise et qu'il est invité à saisir ses identifiants, le 802.1X est le framework qui orchestre cet échange, avec RADIUS en arrière-plan.
EAP-TLS (Extensible Authentication Protocol - Transport Layer Security)
Une méthode EAP qui utilise des certificats X.509 pour l'authentification mutuelle entre le client et le serveur RADIUS. Les deux parties doivent présenter des certificats valides, ce qui élimine totalement les mots de passe de l'échange d'authentification.
EAP-TLS est la référence absolue pour l'authentification WiFi d'entreprise. Il est protégé contre le hameçonnage d'identifiants et les attaques par force brute. La seule exigence opérationnelle est une infrastructure PKI pour émettre et gérer les certificats clients.
RadSec (RADIUS over TLS)
Un protocole défini dans la RFC 6614 qui encapsule les paquets RADIUS dans une session TLS sur le port TCP 2083. Il fournit un chiffrement de la couche transport, une authentification mutuelle par certificat et une protection contre le rejeu pour le trafic RADIUS.
RadSec est requis pour tout trafic RADIUS qui traverse une limite de réseau non approuvée - liaisons WAN, connexions Internet ou infrastructures réseau partagées. C'est le remplaçant idéal du protocole RADIUS standard sur UDP dans les déploiements multisites.
BlastRADIUS (CVE-2024-3596)
Une attaque de l'homme du milieu (man-in-the-middle) divulguée en juillet 2024 qui exploite l'absence de protection de l'intégrité sur les paquets RADIUS Access-Request. En utilisant des techniques de collision MD5 à préfixe choisi, un attaquant peut forger une réponse Access-Accept, accordant ainsi un accès réseau à un utilisateur non authentifié.
BlastRADIUS affecte toutes les principales implémentations RADIUS, notamment FreeRADIUS, Cisco ISE et Microsoft NPS. Les organisations qui n'ont pas appliqué les correctifs publiés en juillet 2024 restent exposées à cette attaque.
Message-Authenticator
Un attribut RADIUS (Attribut 80) qui fournit une protection d'intégrité HMAC-MD5 sur l'ensemble du paquet RADIUS. Lorsqu'il est présent dans un Access-Request, il empêche l'attaque par modification de paquet utilisée dans BlastRADIUS.
L'application de Message-Authenticator sur tous les paquets Access-Request est la principale mesure de correction contre BlastRADIUS. Il doit être configuré à la fois sur le serveur RADIUS (pour exiger l'attribut) et sur l'appareil NAS (pour inclure l'attribut dans les requêtes).
NAS (Network Access Server)
Dans la terminologie RADIUS, le NAS est l'appareil réseau - généralement un point d'accès WiFi, un commutateur ou un concentrateur VPN - qui fait office de client RADIUS. Il intercepte les demandes de connexion des appareils finaux et transmet les demandes d'authentification au serveur RADIUS.
Les appareils NAS sont les clients RADIUS au sein d'un déploiement. Les secrets partagés sont configurés par NAS. La correction de BlastRADIUS nécessite des mises à jour de firmware sur les appareils NAS ainsi que des correctifs sur le serveur RADIUS.
PEAP (Protected Extensible Authentication Protocol)
Une méthode EAP qui établit un tunnel TLS à l'aide d'un certificat côté serveur avant de transmettre la méthode d'authentification interne (généralement MSCHAPv2). Elle offre une authentification mutuelle et protège les identifiants contre l'écoute clandestine.
PEAP-MSCHAPv2 est la méthode d'authentification WiFi d'entreprise la plus largement déployée. Elle est conforme à la norme PCI DSS et plus simple à gérer sur le plan opérationnel que EAP-TLS car elle ne nécessite pas de certificats clients. Cependant, elle est vulnérable aux attaques par faux serveurs RADIUS si la validation des certificats côté client n'est pas imposée.
Secret Partagé
Une clé pré-partagée configurée à la fois sur le serveur RADIUS et sur chaque appareil NAS. Elle est utilisée pour générer le champ Response Authenticator et pour masquer l'attribut User-Password. Il ne s'agit pas d'un mot de passe pour les utilisateurs finaux - c'est un identifiant d'authentification de serveur à serveur.
Les secrets partagés faibles ou statiques constituent l'une des vulnérabilités RADIUS les plus courantes. Un attaquant qui capture le trafic RADIUS peut mener une attaque hors ligne par force brute contre un secret partagé faible. La longueur minimale recommandée est de 32 caractères générés de manière aléatoire.
PCI DSS (Payment Card Industry Data Security Standard)
Un ensemble de normes de sécurité imposées par les principaux réseaux de cartes (Visa, Mastercard, Amex) pour les organisations qui traitent, stockent ou transmettent des données de titulaires de cartes. La version 4.0, en vigueur depuis mars 2024, comprend des exigences spécifiques pour le contrôle d'accès au réseau et l'authentification forte.
Les entreprises du secteur du commerce de détail et de l'hôtellerie possédant des terminaux de point de vente connectés en WiFi entrent dans le champ d'application de la norme PCI DSS. Les vulnérabilités des serveurs RADIUS qui pourraient permettre un accès réseau non autorisé aux environnements de données de titulaires de cartes représentent un risque direct de non-conformité.
Exemples concrets
Un groupe hôtelier de 12 établissements (350 chambres) utilise un serveur RADIUS centralisé hébergé dans le centre de données de son siège social. Chaque établissement se connecte via un réseau WAN MPLS partagé. Un audit de sécurité a signalé que le trafic RADIUS n'est pas chiffré sur le WAN, que les secrets partagés sont des chaînes de 8 caractères définies lors du déploiement initial il y a cinq ans, et que le serveur RADIUS fonctionne sous FreeRADIUS 3.0.21. Le groupe traite les paiements par carte via des terminaux de paiement connectés en WiFi dans ses restaurants et spas. Quels sont les priorités de remédiation et l'ordre de mise en œuvre ?
L'ordre de remédiation doit être structuré selon la gravité du risque et la rapidité de mise en œuvre. Étape 1 (immédiate, sous 72 heures) : Installez le correctif FreeRADIUS pour passer à la version 3.2.5 ou 3.0.27. Cela corrige BlastRADIUS et impose Message-Authenticator par défaut. Simultanément, vérifiez les versions de firmware des points d'accès des 12 établissements et planifiez des mises à jour de firmware pour tous les équipements NAS qui ne prennent pas en charge Message-Authenticator. Étape 2 (semaines 1 et 2) : Renouvelez tous les secrets partagés. Générez des secrets aléatoires de 32 caractères en utilisant openssl rand -base64 32 pour chacun des enregistrements NAS des 12 établissements. Stockez-les dans HashiCorp Vault ou un outil équivalent. Documentez la date de rotation. Étape 3 (mois 1 et 2) : Implémentez RadSec sur le chemin WAN. Configurez le serveur FreeRADIUS pour accepter les connexions RadSec sur le port TCP 2083. Émettez des certificats TLS à partir d'une autorité de certification (CA) interne pour les équipements NAS de chaque établissement. Mettez à jour les règles de pare-feu pour autoriser le port TCP 2083 depuis les plages IP des NAS des établissements vers le serveur RADIUS. Désactivez le port UDP 1812/1813 sur les interfaces orientées WAN dès que le fonctionnement de RadSec est confirmé. Étape 4 (mois 2 et 3) : Pour le SSID WiFi des terminaux de paiement soumis aux normes PCI-DSS, passez de PEAP-MSCHAPv2 à EAP-TLS. Déployez une PKI interne (Microsoft ADCS ou le moteur PKI HashiCorp Vault). Émettez des certificats clients pour les terminaux de paiement via un MDM. Mettez à jour la politique RADIUS pour exiger EAP-TLS pour le SSID des terminaux de paiement. Étape 5 (mois 3) : Intégrez les journaux d'imputation RADIUS dans le SIEM. Configurez des alertes pour les pics d'échecs d'authentification et les expirations de certificats.
Une chaîne de vente au détail régionale de 45 magasins utilise le WPA2-Personal (clé pré-partagée) pour le WiFi du personnel et un réseau ouvert pour le WiFi des clients. Le directeur informatique souhaite migrer le WiFi du personnel vers une authentification 802.1X à l'aide de Microsoft NPS comme serveur RADIUS, intégré à Active Directory. Les magasins disposent d'un parc mixte de points d'accès Aruba et Cisco. La chaîne entre dans le champ d'application de la norme PCI DSS. Quelle architecture doivent-ils déployer et quelles sont les décisions de configuration clés ?
L'architecture recommandée est le 802.1X avec PEAP-MSCHAPv2 comme méthode EAP initiale, avec une feuille de route documentée vers EAP-TLS. Le serveur NPS doit être déployé en paire redondante (primaire + secondaire) dans le centre de données central, avec une configuration de proxy RADIUS sur les points d'accès pour basculer automatiquement en cas de panne. Décisions de configuration : (1) Stratégie réseau NPS : créez une stratégie correspondant au SSID du personnel avec PEAP-MSCHAPv2, exigeant l'appartenance à un groupe de sécurité AD (par ex., "WiFi-Staff-Access"). Définissez le délai d'expiration de la session à 8 heures pour forcer une ré-authentification. (2) Certificat : déployez un certificat de serveur NPS à partir d'une autorité de certification ADCS Microsoft interne. Distribuez le certificat de l'autorité de certification racine à tous les appareils du personnel via une stratégie de groupe (Windows) et un MDM (iOS/Android). (3) Configuration du demandeur : configurez les appareils Windows via la stratégie de groupe (Configuration ordinateur > Paramètres Windows > Paramètres de sécurité > Stratégies de réseau sans fil). Pour les appareils iOS et Android, utilisez un profil MDM. Imposez la validation du certificat du serveur - n'autorisez pas les utilisateurs à accepter des certificats arbitraires. (4) Configuration des points d'accès : sur Aruba, configurez le serveur RADIUS sous Authentification > Serveurs. Définissez le secret partagé sur une chaîne aléatoire de 32 caractères. Activez RadSec si le firmware Aruba le prend en charge (AOS 8.9+). Sur Cisco, configurez sous Sécurité > AAA > RADIUS. (5) Journalisation NPS : activez la journalisation de la comptabilité NPS vers une base de données SQL Server. Configurez une période de conservation des journaux de 90 jours minimum pour la conformité PCI DSS. (6) Post-migration : désactivez le WPA2-Personal sur le SSID du personnel. Conservez-le uniquement comme SSID de secours avec une clé PSK complexe stockée dans le gestionnaire de secrets, à utiliser uniquement lorsque NPS n'est pas disponible.
Questions d'entraînement
Q1. Votre organisation gère un serveur FreeRADIUS 3.0.21 prenant en charge l'authentification 802.1X pour 800 appareils du personnel sur un campus unique. Le serveur RADIUS se trouve sur le même VLAN d'administration que tous les points d'accès. Un test d'intrusion a révélé que les points d'accès envoient des paquets Access-Request sans l'attribut Message-Authenticator. L'équipe de sécurité souhaite imposer Message-Authenticator immédiatement, mais l'équipe des opérations réseau craint d'interrompre l'authentification de 800 utilisateurs. Comment organisez-vous la séquence de remédiation pour minimiser l'interruption de service ?
Conseil : Considérez la différence entre le serveur RADIUS exigeant l'attribut Message-Authenticator et les appareils NAS qui l'envoient. Il s'agit de deux modifications de configuration distinctes avec des profils de risque différents.
Voir la réponse type
La séquence correcte est : (1) Tout d'abord, mettre à jour FreeRADIUS vers la version 3.2.5. Cette version impose Message-Authenticator par défaut mais inclut un mode de compatibilité qui enregistre un avertissement dans les journaux plutôt que de rejeter les paquets dépourvus de l'attribut. Cela vous permet d'appliquer le correctif sans interrompre immédiatement l'authentification. (2) Auditer les versions de firmware des points d'accès. Identifier les modèles et versions de firmware qui prennent en charge Message-Authenticator dans les paquets Access-Request. (3) Mettre à jour le firmware des points d'accès par lots, en commençant par un groupe pilote de 50 appareils. Vérifier que l'authentification continue de fonctionner après chaque lot. (4) Une fois qu'il est confirmé que tous les points d'accès envoient Message-Authenticator, activer l'application stricte sur le serveur FreeRADIUS (require_message_authenticator = yes dans clients.conf). (5) Surveiller les journaux RADIUS pour détecter tout avertissement restant de type "Message-Authenticator missing", ce qui indiquerait des appareils NAS ayant manqué la mise à jour du firmware. Le principe clé est que vous pouvez d'abord corriger le serveur sans rien bloquer, car le mode de compatibilité permet une période de transition. L'application du rejet strict sur le serveur doit être la dernière étape, après la mise à jour de tous les appareils NAS.
Q2. Un exploitant de centre de conférences gère un serveur RADIUS unique prenant en charge à la fois le SSID du personnel de l'entreprise (802.1X avec PEAP-MSCHAPv2) et le WiFi invité des événements (Captive Portal avec MAC Authentication Bypass). Le responsable informatique demande si l'instance RADIUS du WiFi invité doit être sécurisée selon les mêmes normes que l'instance RADIUS de l'entreprise, étant donné que les invités ne s'authentifient pas avec des identifiants d'entreprise. Quelle est votre recommandation ?
Conseil : Considérez les vecteurs d'attaque qui s'appliquent au MAC Authentication Bypass par rapport à l'authentification basée sur EAP, ainsi que le risque de mouvement latéral entre les instances RADIUS des invités et de l'entreprise.
Voir la réponse type
L'instance RADIUS du WiFi invité nécessite un durcissement, mais les contrôles spécifiques diffèrent de ceux de l'instance d'entreprise. Le correctif BlastRADIUS s'applique de la même manière - la vulnérabilité affecte le serveur RADIUS indépendamment de la méthode d'authentification utilisée par les clients. L'hygiène des secrets partagés s'applique également - un secret partagé faible entre le contrôleur du Captive Portal invité et le serveur RADIUS est exploitable, que EAP soit utilisé ou non. Le principal risque supplémentaire réside dans le serveur RADIUS partagé : si les demandes d'authentification SSID des invités et de l'entreprise sont traitées par le même processus de serveur RADIUS, une vulnérabilité dans le chemin RADIUS des invités pourrait être utilisée pour pivoter vers la politique d'authentification de l'entreprise. L'architecture recommandée consiste à exécuter des instances RADIUS distinctes (ou au minimum des serveurs virtuels distincts au sein de FreeRADIUS) pour l'authentification des invités et de l'entreprise, avec des secrets partagés et des ensembles de politiques distincts. Cela permet d'isoler les flux afin qu'un compromis du chemin RADIUS invité ne compromette pas les informations d'identification de l'entreprise. Pour l'instance invité spécifiquement : appliquez le correctif pour BlastRADIUS, renouvelez les secrets partagés et assurez-vous que l'instance RADIUS invité n'a pas accès à l'Active Directory de l'entreprise. Les exigences EAP-TLS et RadSec sont moins pertinentes pour un déploiement de Captive Portal, mais RadSec doit tout de même être envisagé si le contrôleur du Captive Portal se trouve dans un segment de réseau différent de celui du serveur RADIUS.
Q3. Un groupe hospitalier prévoit de migrer son WiFi clinique d'une authentification WPA2-Personal vers une authentification 802.1X. Le groupe dispose de 1 200 appareils cliniques, notamment des ordinateurs portables Windows, des tablettes iOS et des terminaux portables Android. Le CISO souhaite que EAP-TLS soit l'état cible. Le directeur informatique s'inquiète de la complexité du déploiement de la PKI et propose PEAP-MSCHAPv2 comme solution permanente. Comment conseillez-vous le CISO et le directeur informatique, et quelle est la feuille de route d'implémentation recommandée ?
Conseil : Examinez le modèle de menace spécifique à un environnement de santé - quelles sont les conséquences d'une compromission d'identifiants, et comment EAP-TLS répond-il aux risques que PEAP-MSCHAPv2 ne couvre pas ?
Voir la réponse type
L'instinct du CISO est correct, mais l'inquiétude du directeur informatique est légitime. Le conseil recommandé est de mettre en œuvre PEAP-MSCHAPv2 dès maintenant comme solution intermédiaire, avec une feuille de route engagée sur 12 mois pour passer à EAP-TLS. Les raisons pour ne pas accepter PEAP-MSCHAPv2 comme solution permanente dans le secteur de la santé sont : (1) PEAP-MSCHAPv2 est vulnérable aux attaques de serveurs RADIUS illégitimes si la validation des certificats côté client n'est pas appliquée. Dans un environnement hospitalier où le personnel clinique peut connecter des appareils personnels, appliquer une configuration de demandeur de manière cohérente sur 1 200 appareils est un défi opérationnel. (2) Les identifiants MSCHAPv2, s'ils sont capturés via une attaque de serveur RADIUS illégitime, peuvent être déchiffrés hors ligne à l'aide d'outils comme hashcat. Dans un contexte de santé, ces identifiants permettent probablement aussi d'accéder aux systèmes cliniques. (3) Les évaluations NHS DSPT et CQC exigent de plus en plus de contrôles d'authentification forts pour l'accès aux réseaux cliniques. EAP-TLS offre une meilleure position en matière de conformité et d'audit. La feuille de route de mise en œuvre : Mois 1-2 : Déployer PEAP-MSCHAPv2 avec validation obligatoire des certificats de serveur via des profils MDM sur l'ensemble des 1 200 appareils. Mois 3-6 : Déployer Microsoft ADCS en tant qu'infrastructure PKI. Enrôler les appareils Windows via l'auto-enrôlement par stratégie de groupe. Mois 6-9 : Enrôler les appareils iOS et Android via les profils de certificats MDM. Mois 9-12 : Migrer la politique du SSID clinique de PEAP vers EAP-TLS. Conserver PEAP comme solution de repli pour les appareils qui échouent à l'enrôlement de certificat, avec une surveillance renforcée. Pour en savoir plus sur l'architecture de sécurité des réseaux cliniques, le guide WiFi dans les hôpitaux fournit un contexte de déploiement pertinent.
Continuer la lecture de cette série
Comment révoquer l'accès WiFi lorsqu'un employé s'en va
Ce guide montre aux équipes informatiques et opérationnelles comment supprimer l'accès WiFi du personnel lorsqu'un employé s'en va, sans perturber le reste des collaborateurs. Il compare le protocole 802.1X basé sur des certificats, l'iPSK spécifique à l'identité et le déprovisionnement via SCIM, puis fournit un plan d'action pour le jour même, une méthode de test et un modèle de preuves d'audit.
WiFi BYOD sécurisé : intégration de certificats Passpoint vs xPSK (iPSK)
Un guide technique complet pour les équipes informatiques sur la sécurisation des appareils non gérés des employés et des étudiants (BYOD) à l'aide de certificats Passpoint EAP-TLS sans intervention vs les solutions xPSK spécifiques aux constructeurs (iPSK/easyPSK, DPSK, PPSK, MPSK).
Configuration de l'authentification RADIUS pour les réseaux WiFi invités et collaborateurs
Ce guide de référence technique présente l'architecture, la configuration et le déploiement de l'authentification RADIUS pour les réseaux WiFi d'entreprise destinés aux invités et aux collaborateurs. Il fournit aux architectes réseau et aux responsables informatiques les protocoles exacts, les normes de sécurité et les méthodologies de dépannage requis pour concevoir des systèmes de contrôle d'accès sans fil sécurisés et évolutifs.
Vous avez des questions sur votre configuration spécifique ?
Notre équipe collabore avec des exploitants de sites, des responsables informatiques et des ingénieurs réseau au sein de 80 000 sites. Réservez un appel de 20 minutes et nous vous montrerons comment d'autres professionnels comme vous ont résolu ce problème.