Avec freeRADIUS, implémentation libre d'un serveur RADIUS, on peut tester la configuration banale en simulant des requêtes avec l'outil radtest livré de base. Mais cet outil ne prend pas en charge les protocoles EAP (utilisés, entre autres, dans 802.1X donc dans le WiFi WPA2-Enterprise, nom commercial de WPA2-EAP). Le logiciel fourni par freeRADIUS, radeapclient, est compliqué à utiliser : il faut saisir les paquets RADIUS qui seront envoyés au serveur RADIUS… On ne va quand même pas faire clignoter le Wi-Fi de production ? :-

Heureusement, le projet hostapd, logiciel libre permettant de transformer son ordinateur en un point d'accès Wi-Fi, a créé un outil de test EAP adapté nommé eapol_test.

L'ennui, c'est qu'il n'est pas livré dans le paquet Debian de freeRADIUS ni dans celui d'hostapd… ÉDIT DU 09/10/2022 : depuis Debian Bullseye (Debian 11), eapol_test est livré par le paquet eapoltest des dépôts officiels. FIN DE L'ÉDIT.

Un guide existe déjà pour compiler eapol_test depuis ses sources. Je copie :

• Installer les dépendances : sudo apt-get install git libssl-dev devscripts pkg-config libnl-3-dev libnl-genl-3-dev ;
  
  
• Récupérer les sources de eapol_test (de tout freeRADIUS, en fait) : git clone --depth 1 --no-single-branch https://github.com/FreeRADIUS/freeradius-server.git ;
  
  
• Se déplacer dans les sources : cd freeradius-server/scripts/ci ;
  
  
• Exécuter le script de compilation : ./eapol_test-build.sh ;
  
  
• Déplacer le binaire au bon endroit (et dans un dossier couvert par $PATH, surtout) : sudo cp ./eapol_test/eapol_test /usr/local/bin/.

Ensuite, il faut un fichier de config' pour eapol_test. Je recopie ici celui qui m'intéresse le plus, celui qui permet de tester EAP-TTLS-PAP :

network={
    key_mgmt=WPA-EAP
    eap=TTLS
    identity="a_user@<your-instiutions-domain>"
    anonymous_identity="anonymous@<your-instiutions-domain>"

    # Uncomment to validate the server's certificate by checking
    # it was signed by this CA.
    [#ca_cert](./add-tag/ca_cert)="raddb/certs/ca.pem"
    password="changeme"
    phase2="auth=PAP"
}

Ensuite, il faut s'assurer que l'IP de la machine qui exécutera eapol_test est bien un client RADIUS autorisé dans le fichier clients.conf de freeRADIUS.

Il y a plus qu'à tester : eapol_test -c <nom_fichier_conf_récupéré_précédemment> -a <IP_serveur_RADIUS> -s <secret_partage_avec_le_serveur_RADIUS_voir_clients.conf>. Ça débite bien, mais nous, tout ce qui nous intéresse, c'est le « SUCCESS » ou le « FAILURE » final.

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.

Pffff… Ma banque est passée au clavier virtuel pour saisir le mot de passe de mon espace client sur son site web… Seulement 8 chiffres. Que des chiffres. Que 8, ni plus, ni moins. Pffff…

Je suis fatigué de ce genre d'incompétence technique…

Côté client, les logiciels malveillants ne sont plus bloqués par un clavier virtuel depuis longtemps. Un logiciel malveillant peut enregistrer ce qui est affiché ou intercepter le trafic web (y'a même des antivirus qui le font, mais c'est pour notre sécurité, bien sûr) ou autre…

Côté banque, mon ancien mot de passe (10 ‒ max autorisé ‒ chiffres + lettres majuscules ‒ seuls caractères autorisés ‒) était plus solide que le nouveau en cas de piratage (car nul doute que les gens vont réutiliser les mêmes chiffres partout où on les y force).

Avec exactement 8 chiffres autorisés, combien de clients vont mettre une date importante pour eux ou un cumul de deux dates (genre « ma date de naissance et celle de ma meuf parce qu'on s'aime trop trop trop ») ? Des dates connues par les proches voire facilement trouvables sur le web…

Bref, le client est forcément perdant.

L'ami Aeris a publié une bonne critique sur la non sécurité des banques dans la Revue Banque, la revue des Directeurs des Systèmes d'Information (DSI) du monde de la banque et de l'assurance : Identification : le secteur bancaire, royaume de la sécurité ?. Les claviers virtuels y sont évoqués.

J'ai bloqué le popup "changez de mot de passe pour un qu'avec des chiffres" aussi longtemps que j'ai pu. Ça s'est fait très facilement avec le mode sélecteur d’uBlock Origin (la pipette sous le bouton on/off quand tu cliques sur son icône).