RadSec : Comment RADIUS sur TLS améliore la sécurité de l'authentification WiFi

RadSec : comment RADIUS over TLS améliore la sécurité de l'authentification WiFi Un briefing Purple Enterprise WiFi Intelligence Durée approximative : 10 minutes - - - [INTRODUCTION & CONTEXTE - env. 1 minute] Bienvenue dans la série Purple Enterprise WiFi Intelligence. Je suis votre hôte et, aujourd'hui, nous abordons un sujet qui se situe précisément à l'intersection de la sécurité réseau et du risque opérationnel : RadSec - formellement défini dans l'RFC 6614 - et pourquoi il devrait figurer sur votre feuille de route d'infrastructure si ce n'est pas déjà le cas. Si vous êtes responsable informatique, architecte réseau ou CTO responsable du WiFi d'entreprise pour un groupe hôtelier, un parc de points de vente, un stade ou un campus du secteur public, ce briefing est pour vous. Nous allons détailler ce qu'est réellement RadSec, pourquoi le protocole RADIUS traditionnel vous expose, comment déployer RadSec dans un environnement réel et les pièges qui piègent les équipes. Pas de théorie pour le plaisir de la théorie - juste les informations dont vous avez besoin pour prendre une décision ce trimestre. C'est parti. - - - [ANALYSE TECHNIQUE APPROFONDIE - env. 5 minutes] Commençons donc par le problème. Le protocole RADIUS - Remote Authentication Dial-In User Service - est l'épine dorsale de l'authentification WiFi d'entreprise depuis les années 1990. Lorsqu'un utilisateur ou un appareil se connecte à votre WiFi d'entreprise ou invité, le point d'accès agit comme un client RADIUS, transmettant les demandes d'authentification à un serveur RADIUS, qui valide les identifiants par rapport à votre annuaire - Active Directory, LDAP ou un fournisseur d'identité cloud - et autorise ou refuse l'accès. Il s'agit du modèle d'authentification 802.1X qui sous-tend les réseaux WPA2-Enterprise et WPA3-Enterprise. Le problème est que le protocole RADIUS traditionnel a été conçu pour une autre époque. Il fonctionne sur UDP - User Datagram Protocol - sur les ports 1812 et 1813. UDP est un protocole sans connexion, ce qui signifie qu'il n'y a pas de handshake, pas d'état de session et, surtout, pas de chiffrement natif. La seule protection entre votre point d'accès et votre serveur RADIUS est un secret partagé - essentiellement un mot de passe - utilisé pour masquer le mot de passe de l'utilisateur en transit à l'aide du hachage MD5. MD5, comme la plupart d'entre vous le savent, est cryptographiquement obsolète. Il l'est depuis des années. Qu'est-ce que cela signifie en pratique ? Cela signifie que sur n'importe quel segment de réseau où un attaquant peut intercepter le trafic RADIUS - ce qui inclut les commutateurs compromis, les appareils malveillants sur votre VLAN de gestion ou tout point situé entre un point d'accès distant et un serveur RADIUS hébergé dans le cloud - il peut potentiellement capturer les échanges d'authentification, tenter des attaques par dictionnaire hors ligne contre le secret partagé et, dans certaines configurations, exposer entièrement les identifiants des utilisateurs. Pour un groupe hôtelier qui gère un WiFi invité sur 200 propriétés, ou une chaîne de magasins avec des points d'accès dans chaque magasin qui renvoient le trafic vers un serveur RADIUS central via l'internet public, ce n'est pas un risque théorique. C'est une surface d'attaque bien réelle.C'est exactement ce que RadSec résout. RadSec - défini dans la RFC 6614 et mis à jour par la RFC 7360 - enveloppe le trafic RADIUS dans un tunnel TLS. Au lieu d'utiliser UDP, il utilise TCP sur le port 2083. Au lieu d'un secret partagé et de MD5, il utilise une authentification TLS mutuelle avec des certificats X.509. Le client RADIUS et le serveur RADIUS présentent tous deux des certificats, vérifient l'identité de l'autre et établissent une session chiffrée avant tout échange de données d'authentification. TLS 1.3 est la version actuellement recommandée, offrant une confidentialité persistante et éliminant une série de vulnérabilités liées aux algorithmes de chiffrement hérités. L'effet pratique est significatif. Les données d'identification, les attributs des utilisateurs et les jetons de session sont chiffrés de bout en bout entre le point d'accès - ou un proxy RadSec - et le serveur RADIUS. Un attaquant interceptant le trafic sur le réseau ne voit que des enregistrements TLS chiffrés. Le secret partagé est toujours présent pour des raisons de compatibilité ascendante, mais il n'assure plus aucune fonction de sécurité significative - TLS prend tout en charge. Il existe une autre dimension de plus en plus pertinente ici : l'itinérance. La fédération Eduroam, utilisée par les universités et les institutions de recherche à travers l'Europe et au-delà, utilise RadSec depuis des années dans le cadre de son infrastructure d'itinérance interinstitutionnelle. Plus récemment, la norme OpenRoaming de la Wi-Fi Alliance - qui permet une itinérance WiFi transparente à travers les sites participants - impose RadSec pour tout le trafic de la fédération. Si vous déployez une infrastructure compatible OpenRoaming, RadSec n'est pas facultatif ; c'est un prérequis. Purple prend en charge OpenRoaming sous sa licence Connect, agissant en tant que fournisseur d'identité au sein de la fédération, et RadSec est au cœur du fonctionnement de cette structure d'itinérance sécurisée. D'un point de vue de la conformité, RadSec est de plus en plus pertinent pour PCI-DSS 4.0, qui renforce les exigences relatives à la protection des données d'authentification en transit. Si votre infrastructure WiFi touche aux environnements de cartes de paiement - et c'est fréquemment le cas dans le commerce de détail et l'hôtellerie - la faille de chiffrement du RADIUS traditionnel est une anomalie qui ne demande qu'à être détectée. Le GDPR exige de la même manière des mesures techniques appropriées pour protéger les données personnelles ; les identifiants des utilisateurs et les métadonnées de session qui circulent non chiffrés sur votre réseau sont difficiles à défendre lors d'un audit de protection des données. Parlons maintenant d'architecture. Il existe deux principaux modèles de déploiement pour RadSec. Le premier est la prise en charge native de RadSec sur votre serveur RADIUS et vos points d'accès. FreeRADIUS 3.0 et versions ultérieures prennent en charge RadSec nativement. Microsoft NPS ne prend pas en charge RadSec nativement dans ses versions actuelles, ce qui constitue une contrainte importante pour les organisations qui exploitent une infrastructure centrée sur Windows. Cisco ISE prend en charge RadSec. Aruba ClearPass prend en charge RadSec. Si votre serveur RADIUS et votre fournisseur de points d'accès prennent tous deux en charge RadSec nativement, c'est la voie la plus simple : configurez les certificats TLS des deux côtés, ouvrez le port TCP 2083 sur votre pare-feu, et vous chiffrez le trafic RADIUS de bout en bout.Le second modèle est un proxy RadSec. C'est le déploiement le plus courant en pratique, en particulier pour les organisations disposant d'une infrastructure RADIUS existante ou d'environnements multi-constructeurs. Un proxy RadSec - radsecproxy est l'implémentation open-source la plus largement déployée - se situe entre vos points d'accès et votre serveur RADIUS. Les points d'accès envoient du RADIUS standard via UDP au proxy sur le réseau local. Le proxy met fin à cette connexion, ré-encapsule le trafic RADIUS dans un tunnel TLS et le transmet au serveur RADIUS amont via TCP 2083. Cette approche vous permet d'ajouter RadSec à une infrastructure existante sans remplacer votre serveur RADIUS, et elle est particulièrement utile lorsque votre serveur RADIUS est hébergé dans le cloud ou accessible via l'internet public. La gestion des certificats est la complexité opérationnelle que vous devez planifier. Vous aurez besoin d'une PKI - Public Key Infrastructure - pour émettre et gérer les certificats X.509 utilisés pour le TLS mutuel. Cela implique une autorité de certification, l'émission de certificats pour chaque client et serveur RADIUS, et un processus de rotation des certificats avant expiration. Les certificats qui expirent sans que l'on s'en aperçoive interrompent l'authentification de tous les utilisateurs de votre réseau simultanément - et c'est un scénario que vous voulez éviter. Automatisez le renouvellement des certificats à l'aide d'ACME ou de l'API de votre autorité de certification, et configurez des alertes de surveillance bien avant les dates d'expiration. --- [RECOMMANDATIONS DE MISE EN ŒUVRE ET PIÈGES À ÉVITER - environ 2 minutes] Laissez-moi vous donner des recommandations pratiques. Premièrement : auditez avant de déployer. Cartographiez chaque client RADIUS - points d'accès, concentrateurs VPN, commutateurs faisant du 802.1X - et chaque serveur RADIUS de votre environnement. Identifiez ceux qui prennent en charge RadSec nativement et ceux qui auront besoin d'un proxy. Cet audit met généralement en évidence les anciens appareils qui ne prennent pas du tout en charge le TLS, et ceux-ci doivent figurer sur votre feuille de route de remplacement. Deuxièmement : commencez par le trafic le plus risqué. Si vous avez du trafic RADIUS qui traverse l'internet public - sites distants, RADIUS hébergé dans le cloud, groupes hôteliers multi-sites - c'est votre priorité absolue. Le trafic RADIUS local sur un VLAN de gestion bien segmenté présente un risque plus faible, mais il doit tout de même figurer sur votre feuille de route. Troisièmement : testez minutieusement le TLS mutuel avant la mise en production. Le mode de défaillance le plus courant dans les déploiements RadSec est lié aux erreurs de validation de certificats - des Common Names non correspondants, des certificats intermédiaires expirés ou des clients qui ne font pas confiance à l'autorité de certification qui a signé le certificat du serveur. Utilisez openssl s_client pour tester les handshakes TLS avant de basculer le trafic de production. Quatrièmement : ne négligez pas la surveillance. RadSec ajoute une couche de connexion TCP que le RADIUS traditionnel n'a pas. Les échecs de connexion TCP, les délais d'attente de handshake TLS et les erreurs de certificat se manifesteront par des échecs d'authentification pour vos utilisateurs. Assurez-vous que les journaux de votre serveur RADIUS et ceux de votre proxy alimentent votre SIEM ou votre plateforme de surveillance afin de pouvoir distinguer un problème de connectivité RadSec d'un problème de politique d'authentification. Le piège que je vois le plus souvent est celui des organisations qui déploient RadSec côté serveur mais oublient de mettre à jour les règles de leur pare-feu. Le port TCP 2083 doit être ouvert entre chaque client RADIUS et le serveur ou proxy RADIUS. Si vous avez l'habitude de gérer les règles UDP 1812, le port TCP 2083 peut facilement être oublié lors du processus de modification du pare-feu. - [QUESTIONS-RÉPONSES RAPIDES - env. 1 minute] Permettez-moi de passer en revue quelques questions que j'entends régulièrement. "Est-ce que RadSec remplace le 802.1X ?" Non. RadSec sécurise la couche de transport entre le point d'accès et le serveur RADIUS. Le 802.1X est le protocole d'authentification entre l'appareil client et le point d'accès. Ils fonctionnent à des couches différentes et sont complémentaires. "RadSec est-il pris en charge par tous les fabricants de points d'accès ?" Pas de manière universelle. Cisco, Aruba, Ruckus et Meraki offrent tous différents niveaux de prise en charge de RadSec - vérifiez la version spécifique de votre firmware. En l'absence de prise en charge native, un proxy RadSec est votre solution. "Qu'en est-il de DTLS - RADIUS sur DTLS ?" La RFC 7360 définit RADIUS sur DTLS, qui utilise UDP plutôt que TCP, préservant ainsi certaines caractéristiques sans connexion du RADIUS traditionnel tout en ajoutant le chiffrement. Il est moins largement déployé que RadSec sur TLS mais mérite d'être évalué si la latence est un problème dans les environnements à haut débit. "Quel est l'impact sur les performances de l'itinérance ?" La connexion TCP de RadSec est persistante, ce qui peut en réalité améliorer les performances d'itinérance dans les environnements fédérés en réduisant la surcharge d'établissement de connexion pour les demandes d'authentification ultérieures. - [RÉSUMÉ ET PROCHAINES ÉTAPES - env. 1 minute] Pour résumer : RadSec est la réponse mature et normalisée à une véritable faille de sécurité du RADIUS traditionnel. Si vous gérez un réseau WiFi d'entreprise à grande échelle - sur plusieurs sites, via Internet ou dans des environnements soumis à la PCI-DSS ou au GDPR - la question n'est pas de savoir s'il faut déployer RadSec, mais quand et comment. Vos prochaines étapes : auditez votre infrastructure RADIUS cette semaine. Identifiez vos flux de trafic les plus risqués. Consultez la documentation du fabricant de votre serveur RADIUS et de vos points d'accès pour vérifier la prise en charge native de RadSec. Si vous utilisez FreeRADIUS, vous pouvez mettre en place un déploiement RadSec de test en une journée. Si vous utilisez Microsoft NPS, commencez à évaluer un proxy ou une voie de migration vers un serveur compatible RadSec. La plateforme de Purple est conçue pour s'intégrer à l'infrastructure RADIUS d'entreprise, prenant en charge les flux d'authentification sécurisés pour les environnements WiFi d'entreprise et invités. Si vous souhaitez comprendre comment RadSec s'intègre dans votre déploiement spécifique, l'équipe de Purple peut vous guider. Merci pour votre écoute. À la prochaine. - FIN DU SCRIPT