Je voudrais savoir si les utilisateurs de notre Wi-Fi 802.1X (WPA2-EAP / WPA2-Enterprise) indiquent leur identifiant complet, c'est-à-dire avec le realm. Comment journaliser ce dernier avec freeRADIUS ?
Dans le protocole réseau RADIUS, un realm joue le rôle d'un domaine. Il désigne une organisation, une entité. Ainsi, un identifiant est composé d'une partie locale, d'un (ou plusieurs) délimiteur, et d'un (ou plusieurs) realm. Ça ressemble à l'email ou à Jabber, hein ? Le principe est le même. Dans l'email, la partie à droite de l'arobase désigne l'organisation dans l'Internet et la partie de gauche, un identifiant unique au sein de cette organisation. Ce realm permet de transmettre une requête d'authentification à un RADIUS plus compétent.
Exemple concret ? Eduroam est un service Wi-Fi qui permet à un membre d'une université (étudiant, enseignant, personnel, etc.) de se connecter en Wi-Fi depuis une autre université. C'est ce qu'on nomme itinérance. Comment ça fonctionne ? Le contrôleur Wi-Fi de l'université d'accueil reçoit la demande de connexion d'un client Wi-Fi (ordinateur, ordiphone, etc.). Il transmet la requête d'authentification aux serveurs RADIUS de l'université. Ceux-ci analysent un realm qui n'est pas le leur. Ils transmettent la requête aux serveurs RADIUS nationaux (en France, ils sont gérés par RENATER, le fournisseur d'accès à Internet ‒ et bien plus ‒ des entités d'enseignement supérieur et de recherche, par exemple). Ceux-ci analysent également le realm. Si l'université d'affectation est française, la requête est transmise à ses serveurs RADIUS. Sinon, on remonte à la racine d'eduroam, et on redescend jusqu'à l'université d'affectation en passant par le pays. C'est donc l'université d'affectation qui autorise (ou non) la connexion sur le Wi-Fi de l'université d'accueil. L'université d'accueil n'a pas a connaître le mot de passe de l'utilisateur. Mieux, elle ne le voit pas passer puisque l'on utilise PEAP ou EAP-TTLS, c'est-à-dire des tunnels chiffrés entre le client Wi-Fi et le serveur RADIUS de l'entité d'affectation.
C'est aussi comme cela que fonctionnent les accès à Internet (ADSL, fibre, etc.) quand on est chez un Fournisseur d'Accès à Internet qui ne dispose pas de machines dans chaque répartiteur téléphonique. Exemple : l'opérateur associatif FDN utilise une offre de l'opérateur commercial Liazo qui loue les lignes à Orange ou SFR. Un identifiant imaginaire "toto/fdn@liazo.sfr" (notons la présence de deux realms, chaque opérateur, Liazo et SFR, utilisant un séparateur différent, « / » pour Liazo, « @ » pour SFR) permet aux RADIUS de SFR (qui répondent aux équipements réseaux de SFR qui sont à l'autre bout de la ligne de l'abonné, dans le central téléphonique) d'envoyer la requête d'authentification vers les serveurs RADIUS de Liazo qui enverront à FDN pour validation et pour savoir où envoyer le trafic de l'abonné. Ainsi SFR n'a pas à enregistrer les clients de Liazo dans son système d'information et encore moins les abonnés de FDN.
Bref, on nomme proxy RADIUS cette fonctionnalité de renvoi des requêtes.
Je pense que tu auras compris pourquoi nous voulons journaliser temporairement l'identifiant complet saisi par nos utilisateurs : certains ne mettent pas le realm et se plaignent que "Internet marche pas quand je suis en déplacement !!! c'est un scandale d'envergure internationale !!! J'exige que…". Forcément, sans realm, le RADIUS de l'organisation d'accueil croit que l'identifiant est local, donc il cherche dans ses bases de données locales (LDAP, etc.), trouve rien et envoie bouler. L'idée est donc d'avoir des statistiques sur le nombre d'utilisateurs concernés, leur type, etc. afin d'envisager (ou non) des campagnes de prévention ciblées plus ou moins automatisées.
Par défaut, RADIUS journalise ce genre de message : « Auth: Login OK: [guigui] ». Il reste donc que la partie locale, plus le realm.
On pourrait ajouter l'option nostrip
dans la définition de notre realm ? Erreur, car, alors, notre RADIUS cherchera, dans notre annuaire LDAP, un utilisateur dont l'identifiant sera identifiant + realm. Notre annuaire LDAP ne trouvera pas un tel objet et l'authentification sera refusée.
Ce qu'on va faire, c'est journaliser les attributs contenus dans la requête RADIUS d'authentification (Access-Request) émise par le contrôleur Wi-Fi (ou un proxy RADIUS connu) avant son traitement.
Pour ce faire, on va se reposer sur le module « detail » de freeRADIUS, l'implémentation libre la plus connue d'un serveur RADIUS.
Si l'on le souhaite, on peut modifier la configuration du module « detail », mais ce n'est pas obligatoire. La conf' qui nous intéresse est dans le fichier /etc/freeradius/3.0/mods-enabled/detail.log
(dans les vieilles versions de freeRADIUS, c'est dans modules/detail.log). Perso, je change :
Dans le bloc « detail auth_log », je commente « detailfile = ${radacctdir}/%{Client-IP-Address}/auth-detail.log » et j'ajoute une ligne « detailfile = ${logdir}/realm.log ». Motif : je n'ai pas envie d'avoir un dossier par utilisateur, ça va être ingérable. Je veux un unique journal pour tous mes utilisateurs et tous mes NAS ;
Dans le sous-bloc « Suppress » qui prévoit déjà de ne pas journaliser l'attribut « User-Password », j'ajoute les lignes suivantes afin de supprimer tous les attributs sauf le User-Name et ainsi de maîtriser l'occupation disque de mon journal :
Packet-Type
FreeRADIUS-Proxied-To
EAP-Message
MS-CHAP-Challenge
MS-CHAP2-Response
State
Il nous reste à déclencher la journalisation là où nous en avons besoin. Le commentaire dans la conf' nous indique que ça se passe dans le bloc authorize
. Oui, mais dans quel serveur virtuel ? Default ou inner-tunnel ?
Si nous journalisons dans le serveur virtuel default, nous allons récolter toutes les demandes d'authentification adressées à notre RADIUS, y compris celles émanant de notre portail captif. Or, sur ce dernier, il est normal de ne pas saisir son realm, car il n'est pas accessible en itinérance. Au contraire, saisir son realm ne fonctionne pas. Pour nos stats, nous voulons uniquement les clients WPA2-EAP.
De plus, avec EAP, il est possible d'indiquer une identité anonyme, qui sera émise avant que soit établi le tunnel chiffré qui, lui, contiendra le vrai identifiant ainsi que le mot de passe. Ce mécanisme protège d'une interception passive du trafic (bah, ouais, les ondes Wi-Fi, c'est super simple à intercepter : une interface Wi-Fi en mode monitor, un wireshark
et hop). Parfois, on n'a pas envie de crier qui l'on est tout autour de soi. Notons que, dans un système d'itinérance comme eduroam, il est nécessaire indiquer a minima le realm dans l'identité anonyme (exemple : « anonymous@monUniversité.example ») afin que les proxy RADIUS intermédiaires transmettent la requête EAP jusqu'au RADIUS de l'organisation d'affectation. Il s'agit donc d'une identité anonyme toute relative.
Pour ces deux raisons, nous comprenons que nous voulons journaliser à l'intérieur du tunnel EAP. Nous modifions donc le fichier /etc/freeradius/3.0/sites-enabled/inner-tunnel
. Au début du bloc authorize
, nous ajoutons une ligne auth_log
.
Un petit redémarrage du serveur (systemctl restart freeradius
) et c'est prêt. Le journal sera créé lorsque le premier utilisateur se présentera.
Si l'on a peur que le journal occupe beaucoup d'espace disque (pour 3 000 utilisateurs réguliers, j'ai journalisé environ 3 mo/jour), on peut demander à logrotate de compresser les vieux journaux tous les jours. Pour ce faire, on ajoute les lignes suivantes dans /etc/logrotate.d/freeradius
:
/var/log/freeradius/realm.log {
copytruncate
}
Voilà.
Sources d'inspiration : freeradius-sp et freeradius-idp.