AAA / Radius - Synaps Network Academy

AAA (Authentication, Authorization, Accounting) désigne le triptyque sur lequel repose le contrôle des accès administratifs : qui a le droit de se connecter, ce qu'il peut faire une fois connecté, et la trace de ce qu'il a fait. RADIUS est l'un des protocoles les plus répandus pour déporter cette logique vers un serveur centralisé plutôt que de gérer un compte local sur chaque équipement : un commutateur ou un routeur devient alors un simple client qui interroge le serveur à chaque tentative de connexion, avec une base locale en filet de sécurité si ce serveur devient injoignable. Ce laboratoire met ce mécanisme en pratique de bout en bout, du serveur jusqu'au paquet RADIUS observé sur le fil.

Le laboratoire

La maquette associe trois éléments. VM-1-NUX, une machine virtuelle Linux à l'adresse 172.20.10.50, héberge le serveur RADIUS. ESW1, un commutateur Cisco, joue le rôle de client RADIUS (le NAS, Network Access Server) avec une interface sur chacun des deux réseaux : 172.20.10.0/24 côté serveur, 10.0.0.0/24 côté cœur de réseau. R1, enfin, sert simplement à ouvrir une session Telnet vers ESW1 pour déclencher le dialogue d'authentification et observer ce qui se passe. Le panneau de droite reprend la configuration appliquée sur ESW1 : activation d'AAA, méthodes d'authentification, comptes locaux de secours, adressage des interfaces et déclaration du serveur RADIUS.

Topologie du laboratoire AAA/RADIUS : VM-1-NUX (serveur RADIUS, 172.20.10.50) relié à ESW1 (172.20.10.1 et 10.0.0.1), lui-même relié à R1 (10.0.0.10), avec la configuration AAA et RADIUS du commutateur ESW1 — **Topologie et configuration :** VM-1-NUX (serveur RADIUS), ESW1 (client RADIUS / NAS) et R1, avec le détail de la configuration appliquée sur le commutateur : aaa new-model, méthodes d'authentification, comptes locaux et déclaration du serveur.

Le serveur RADIUS : une VM Linux intégrée à la maquette

GNS3 simule très bien des routeurs et des commutateurs, mais ne fournit aucun serveur RADIUS prêt à l'emploi : il faut donc en raccorder un vrai. La solution retenue ici consiste à importer une machine virtuelle Linux gérée par VirtualBox et à la relier à ESW1 par un tunnel UDP. Côté GNS3, le nœud VM-1-NUX est autorisé à utiliser les adaptateurs réseau déclarés dans VirtualBox ; côté VirtualBox, son adaptateur est basculé en pilote générique UDPTunnel, avec des ports source et destination qui se répondent. Une fois le pont monté, la VM apparaît dans la topologie comme n'importe quel autre nœud, à l'adresse 172.20.10.50.

Configuration du nœud VM-1-NUX dans GNS3 : option Allow GNS3 to use any configured VirtualBox adapter activée dans l'onglet Network — **Côté GNS3 :** le nœud VM-1-NUX est configuré pour utiliser les adaptateurs réseau déclarés dans VirtualBox.

Configuration de l'adaptateur réseau dans VirtualBox : pilote générique UDPTunnel avec adresse de destination 127.0.0.1, port de destination 10001 et port source 10000 — **Côté VirtualBox :** l'adaptateur de la VM est basculé en pilote générique UDPTunnel, avec les ports source et destination qui construisent le pont vers GNS3.

Une fois la VM raccordée, il ne reste qu'à y faire tourner un serveur RADIUS : FreeRADIUS, l'implémentation libre la plus courante, est installée sur cette machine Ubuntu. Sa configuration tient pour l'essentiel dans un fichier déterminant, clients.conf, qui énumère les équipements autorisés à interroger le serveur (leur adresse ou leur sous-réseau) ainsi que la clé partagée à présenter pour que la conversation soit acceptée. Cette clé doit être strictement identique à celle déclarée sur le commutateur avec radius-server key : la moindre différence, même un seul caractère, et le serveur rejette silencieusement les requêtes du client.

Bureau Ubuntu de la machine virtuelle VM-1-NUX hébergeant le serveur FreeRADIUS — **La VM serveur :** bureau Ubuntu de VM-1-NUX, la machine Linux qui héberge FreeRADIUS à l'adresse 172.20.10.50.

Extrait du fichier clients.conf de FreeRADIUS : déclaration d'un client autorisé avec son réseau et la clé partagée secret attendue — **Le fichier clients.conf :** déclaration du commutateur comme client autorisé : réseau d'origine accepté et clé partagée (secret) attendue pour valider l'échange.

Activer AAA sur le commutateur, étape par étape

1. Activer le sous-système AAA : la commande aaa new-model fait basculer le commutateur d'une authentification locale classique vers le cadre Authentication, Authorization, Accounting (AAA), point d'entrée indispensable pour brancher RADIUS par la suite.
2. Définir les méthodes d'authentification : aaa authentication login default group radius local enable crée la liste par défaut (RADIUS en premier, base locale ensuite, mot de passe enable en dernier recours), et aaa authentication login TELNET_LINES group radius définit une liste nommée dédiée aux lignes de terminal virtuel.
3. Garder des comptes locaux de secours : username synaps privilege 15 password 0 synaps et username sna privilege 15 password 0 sna assurent un accès administratif même si le serveur RADIUS devient injoignable, le maillon local de la cascade de méthodes.
4. Déclarer le serveur RADIUS et sa clé : radius-server host 172.20.10.50 auth-port 1812 acct-port 1813 indique où envoyer les requêtes, et radius-server key fixe la clé partagée, qui doit correspondre au caractère près à celle du fichier clients.conf du serveur.
5. Appliquer la liste nommée aux lignes vty : sous line vty 0 4, la commande login authentication TELNET_LINES branche les sessions Telnet/SSH entrantes sur la liste de méthodes qui interroge RADIUS avant de retomber sur les comptes locaux.

Vérification : suivre une connexion de bout en bout

La meilleure preuve qu'AAA fonctionne, c'est de se connecter pour de vrai. Depuis R1, une session Telnet vers 10.0.0.1 (l'interface de ESW1 côté cœur de réseau) déclenche aussitôt l'invite d'authentification : le commutateur n'a plus de base locale à consulter en premier, c'est désormais le serveur RADIUS qui valide, ou refuse, le compte raduser. Côté commutateur, un coup d'œil sur les sessions TCP confirme qu'une connexion est bel et bien établie entre les deux équipements sur le port 23.

Invite d'authentification lors d'une connexion Telnet de R1 vers ESW1 : Username raduser, Password masqué — **L'invite, côté client :** R1 ouvre une session vers 10.0.0.1 et reçoit aussitôt l'invite User Access Verification, avec le compte raduser.

Sortie de show tcp brief all sur ESW1 montrant une session établie (ESTAB) entre 10.0.0.1 et 10.0.0.10 sur le port 23 — **La session, côté commutateur :** show tcp brief all confirme l'état ESTAB de la connexion entre 10.0.0.1 (ESW1) et 10.0.0.10 (R1) sur le port 23 (Telnet).

Une fois connecté, raduser se retrouve d'abord en mode utilisateur. Le passage en mode privilégié suit sa propre logique d'authentification, indépendante du login initial : une première tentative échoue (Access denied), la seconde aboutit. Les commandes show users et show users all confirment ensuite que raduser occupe bien la ligne vty 0, connecté depuis 10.0.0.10, soit l'adresse de R1.

Session complète sur ESW1 : authentification Telnet, tentative d'accès au mode privilégié avec un échec puis une réussite, et sorties de show tcp brief et show users confirmant la connexion de raduser depuis 10.0.0.10 — **La session complète, pas à pas :** de l'invite de connexion jusqu'à show users / show users all, avec un aller-retour sur le mot de passe du mode privilégié au passage.

Pour aller plus loin que la simple observation du résultat, l'activation de debug radius verbose sur ESW1 expose le détail du protocole : le commutateur encode une demande de nom d'utilisateur (GET_USER) puis de mot de passe (GET_PASSWORD), construit la requête avec le type de composant EXEC et l'adresse du NAS, choisit l'adresse locale la plus appropriée pour joindre 172.20.10.50, et reçoit en retour un Access-Accept en provenance du serveur. Tout le cycle de vie d'une requête RADIUS, de la frappe au clavier jusqu'à la réponse du serveur, devient lisible ligne par ligne.

Sortie de debug radius verbose sur ESW1 montrant l'encodage de la requête (GET_USER, GET_PASSWORD, adresse du NAS, type EXEC) et la réception d'un Access-Accept depuis 172.20.10.50 — **Le protocole, ligne par ligne :** debug radius verbose détaille l'encodage de la requête côté client, puis la réponse Access-Accept renvoyée par le serveur RADIUS.

Le débogage expose la mécanique RADIUS de l'intérieur, telle que le commutateur la vit. En parallèle, une capture Wireshark tournait sur ce même segment. Parmi les trames récoltées, l'une d'elles n'a rien à voir avec RADIUS, mais mérite tout de même un coup d'œil : une annonce CDP (Cisco Discovery Protocol) émise par ESW1 à destination de ses voisins directs.

Capture Wireshark d'une trame CDP émise par ESW1, détaillant le nom de l'équipement, sa plateforme Cisco 3725, sa version logicielle et son port d'origine FastEthernet0/0 — **Hors sujet, mais instructif :** trame CDP capturée sur le segment : ESW1 y annonce son nom, sa plateforme (Cisco 3725), sa version logicielle et son port d'origine, en clair, à ses voisins directs.

Cette trame, à elle seule, dévoile le nom de l'équipement, sa plateforme, sa version logicielle et le port d'où elle provient, le tout en clair, sans la moindre authentification pour pouvoir l'écouter. Un rappel utile : sécuriser les accès administratifs avec AAA est une étape essentielle, mais une vraie posture de sécurité s'intéresse aussi à ce qu'un équipement choisit de raconter de lui-même à qui veut bien l'entendre.