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

RadSec : Comment RADIUS sur TLS améliore la sécurité de l'authentification WiFi Un briefing d'intelligence WiFi Purple Enterprise Durée approximative : 10 minutes - - - [INTRODUCTION & CONTEXTE - env. 1 minute] Bienvenue dans la série d'intelligence WiFi Purple Enterprise. Je suis votre hôte, et aujourd'hui nous abordons un sujet situé au carrefour de la sécurité réseau et du risque opérationnel : RadSec - formellement défini par la 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 en charge 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 vous est destiné. Nous allons voir ce qu'est réellement RadSec, pourquoi le protocole RADIUS traditionnel vous expose à des risques, comment déployer RadSec dans un environnement réel et les pièges qui guettent les équipes. Pas de théorie pour la forme - uniquement les informations nécessaires pour prendre votre décision ce trimestre. Entrons dans le vif du sujet. - - - [ANALYSE TECHNIQUE APPROFONDIE - env. 5 minutes] Commençons par le problème. RADIUS - Remote Authentication Dial-In User Service - est le pilier 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 en tant que 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 - puis accorde 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 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 poignée de main (handshake), pas d'état de session et, surtout, aucun 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 lors du transit à l'aide d'un hachage MD5. Le MD5, comme la plupart d'entre vous le savent, est obsolète sur le plan cryptographique. Il est contourné depuis des années. Qu'est-ce que cela signifie en pratique ? Cela signifie que sur tout segment de réseau où un attaquant peut intercepter le trafic RADIUS - y compris les commutateurs compromis, les appareils suspects 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 accès WiFi invité sur 200 établissements, ou une chaîne de magasins dont les points d'accès de chaque boutique renvoient le trafic vers un serveur RADIUS central via l'internet public, ce risque n'est pas théorique. Il s'agit d'une surface d'attaque bien réelle. C'est exactement ce que RadSec résout. RadSec - défini dans le RFC 6614 et mis à jour par le RFC 7360 - enveloppe le trafic RADIUS dans un tunnel TLS. Au lieu du protocole 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 chiffrements 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 sécurité significative - TLS prend tout en charge. Il existe une autre dimension de plus en plus pertinente : l'itinérance. La fédération Eduroam, utilisée par les universités et les instituts de recherche en 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 fluide à 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 optionnel ; 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 des environnements de cartes de paiement - ce qui 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 signalée. Le GDPR exige de la même manière des mesures techniques appropriées pour protéger les données personnelles ; des identifiants d'utilisateurs et des métadonnées de session circulant 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 exploitant 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 aux deux extrémité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 étant l'implémentation open-source la plus largement déployée - se positionne entre vos points d'accès et votre serveur RADIUS. Les points d'accès envoient du RADIUS standard sur 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 leur expiration. Des certificats qui expirent sans que l'on s'en aperçoive bloqueront simultanément l'authentification de tous les utilisateurs de votre réseau - 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 gérant le 802.1X - et chaque serveur RADIUS de votre environnement. Identifiez ceux qui prennent en charge RadSec nativement et ceux qui nécessiteront un proxy. Cet audit révèle généralement des équipements existants qui ne prennent pas du tout en charge TLS, et ceux-ci doivent figurer sur votre feuille de route de remplacement. Deuxièmement : commencez par le trafic présentant le risque le plus élevé. 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 première priorité. 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 la feuille de route. Troisièmement : testez minutieusement le TLS mutuel avant la mise en service. Le mode de défaillance le plus courant dans les déploiements RadSec est lié aux erreurs de validation de certificats - Common Names non correspondants, certificats intermédiaires expirés, ou clients qui ne font pas confiance à l'autorité de certification qui a signé le certificat du serveur. Utilisez openssl s_client pour tester les liaisons 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épassements de délai de liaison TLS et les erreurs de certificat se traduiront par des échecs d'authentification pour vos utilisateurs. Assurez-vous que les journaux de votre serveur RADIUS et 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 être oublié lors du processus de modification du pare-feu. - [Q&R RAPIDE - environ 1 minute] Laissez-moi passer en revue quelques questions que j'entends régulièrement. "RadSec remplace-t-il 802.1X ?" Non. RadSec sécurise la couche de transport entre le point d'accès et le serveur RADIUS. 802.1X est le framework 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 ont tous des niveaux de prise en charge RadSec variables - 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 certaines des caractéristiques sans connexion du RADIUS traditionnel tout en ajoutant du chiffrement. Il est moins largement déployé que RadSec sur TLS mais mérite d'être évalué si la latence est une préoccupation dans des environnements à haut débit. "Quel est l'impact sur les performances d'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 - environ 1 minute] Pour résumer : RadSec est la réponse mature et basée sur des normes à une véritable faille de sécurité du RADIUS traditionnel. Si vous gérez du WiFi d'entreprise à grande échelle - sur plusieurs sites, via Internet, ou dans des environnements soumis à la conformité 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 à plus haut risque. Vérifiez la documentation de votre serveur RADIUS et du fabricant de votre point d'accès pour connaître 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 stratégie 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 des 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 Purple peut vous accompagner. Merci pour votre écoute. À la prochaine. - FIN DU SCRIPT