Modifications entre les versions 9 et 18 (s'étendant sur 9 versions)

Sommaire

Authentification par MAC, VLANs dynamiques sur les Switches HP
1. Présentation générale
2. Configuration côté switch
Configuration côté RADIUS
1. Fonctionnement au Crans
2. Migration et anciennes machines
Authentification WiFi
1. Couple login/pass
2. Évolution possible: tagging de vlan
Enregistrement automatique des macs
Protection anti-squattage

Cette page est destinée à décrire l'utilisation et la configuration de radius au Cr@ns. Ce protocole est employé par les switchs et les points d'accès WiFi (NAS) pour l'authentification des ordinateurs à partir de leur adresse mac et éventuellement de leur login/mot de passe (WiFi uniquement). Une fois l'authentification effectuée, le serveur d'authentification radius peut fournir des informations supplémentaires aux NAS sur la manière dont les machines doivent être connectées au réseau. Sur le filaire, on indique le vlan auquel chaque machine doit être connectée.

Au Crans, les serveurs radius sont d'abord, radius pour le filaire,eap pour le wifi, et odlyd pour le backup.

Authentification par MAC, VLANs dynamiques sur les Switches HP

Présentation générale

Chaque prise de switchs connectée à une chambre d'adhérent est configurée pour effectuer, lorsqu'elle détecte une nouvelle adresse MAC, une requête à un serveur RADIUS. Outre la vérification et l'autorisation d'accès, cette requête permet au serveur RADIUS d'imposer le VLAN (non-taggué) sur lequel est placé la prise. Ceci nous permet de séparer dynamiquement les machines du réseau classique, les machines du réseau gratuit, et les machines n'étant pas inscrites.

Configuration côté switch

La génération des fichiers de configuration des switches est faite par re2o.. Si la prise est une prise adhérent, les directives de configuration aaa (Authentication, Authorization and Accounting) suivantes sont ajoutées :

aaa port-access mac-based 43
aaa port-access mac-based 43 addr-limit 3
aaa port-access mac-based 43 logoff-period 3600

La première ligne active, pour la prise 43, l'authentification basée sur l'adresse MAC (mettre "no" + esp. devant pour désactiver).
La seconde ligne impose une limite de 3 adresses mac par prise (en fait actuellement 1+2*(nombre de chambres sur la prise)).

Ceci indique que lors d'une connexion, le switch va effectuer une requête à ses serveurs RADIUS.

S'il reçoit une réponse, il place la prise sur le vlan que lui propose le serveur RADIUS.

Configuration côté RADIUS

FreeRADIUS, une implémentation libre du protocole, a été choisie au Cr@ns.

Fonctionnement au Crans

Freeradius appel un petit script python, /etc/freeradius/3.0/auth.py, qui en réalité pointe vers /var/www/re2o/freeradius_utils/auth.py, et qui est donc un script qui fait l'interface avec re2o. La fonction principale qui est appellée par freeradius lorsque quelqu'un essaye de se connecter au réseau est authorize.

À noter que le backend python de freeradius tourne en Python 2, ce qui nous oblige actuellement à avoir re2o pyhon2 compliant

Migration et anciennes machines

Avec re2o, la convention est de n'avoir qu'un unique mot de passe pour son compte et ses machines, alors qu'avant nous avions un mot de passe par machine. Nous avons mis en place un système legacy vouait à disparaitre pour faire la transition sans trop de douleur, en important dans un fichier les anciennes machines des adhérents, on le trouve dans /etc/freeradius/3.0/wifi_passwords et le auth.py gère ce sous cas.

Authentification WiFi

Les bornes WiFi peuvent aussi être vues comme des switchs, et utilisent également le protocole radius, en se connectent également au domU eap (un fallback sur le serveur radius est prévu, mais non configuré sur les bornes pour le moment). Ici, une vraie étape d'authentification a lieu pour le client (la machine qui se connecte à la borne). Pour le moment, elle consiste en la validation d'un login/mdp. Pour cela, une communication débute entre le client et la borne, à l'aide du protocole EAP. La borne redirige ensuite la requête au travers du protocole radius. Lorsque le client a réussi à s'authentifier auprès du serveur radius, celui-ci répond à la borne pour laisser passer le client.

EAP est modulaire, et nous utilisons ici les protocoles PEAP (ou TTLS) qui permettent d’encapsuler dans une connexion chiffrée, un nouveau protocole d'authentification (phase2). Au Crans, le protocole de phase2 est MsChapV2. Étant donné les défauts de sécurité de MsChapV2, il est important de valider le certificat de la connexion chiffrée : le certificat est au nom de wifi.crans.org et il est certifié par cacert.org, qui devrait être installé les postes clients.

Virtuellement, chaque authentification se déroule donc en deux sessions Radius:

Établissement d'un tunnel chiffré TLS à l'aide du protocole PEAP ou TTLS. Un login (anonyme) est transmis en clair sur le réseau (non utilisé au Cr@ns)
Authentification MsChapV2 dans le tunnel chiffré (inner-tunnel) : le couple login/mdp est vérifié.

L'ordre chronologique dans les logs est inversé : la connexion chiffrée (MsChapV2) émet une décision d'authentification PUIS la connexion maître suit cette décision.

Couple login/pass

Le couple login/pass à challenger est déterminé par l'adresse MAC du client s'authentifiant (variable Calling-Station-Id). Si la machine n'est pas trouvée, on considère le login fourni (et uniquement dans ce cas.)

Afin de pouvoir utiliser des variables telles que Calling-Station-Id, il est nécessaire de transmettre les informations venant de la connexion maîtresse vers la connexion chiffrée. Ceci se fait à l'aide de la directive copy_request_to_tunnel = yes dans eap.conf.

Il arrive également que Calling-Station-Id soit mal formaté ( séparé par des "-" tous les deux caractères au lieu de ":"), sa valeur étant renvoyée par la borne WiFi. On utilise une règle dans le fichier hints afin de corriger cela:

DEFAULT  Calling-Station-Id =~ "^([0-9A-F]{2})-([0-9A-F]{2})-([0-9A-F]{2})-([0-9A-F]{2})-([0-9A-F]{2})-([0-9A-F]{2})$"
     Calling-Station-Id := `%{1}:%{2}:%{3}:%{4}:%{5}:%{6}`

Évolution possible: tagging de vlan

Il serait possible, comme pour une connexion filaire d'attribuer un vlan différent en fonction du client trouvé. Les bornes WiFi utilisent en effet le démon hostapd qui supportent certaines directives venant de Radius. Ceci permettrait par exemple de gérer le blacklisting (passage en isolement) ou les connexions personnels ENS.

Plus d'infos sur cette fonctionnalité :

documentation d'hostapd
intégration à OpenWrt dans le cas du Crans

Enregistrement automatique des macs

En WiFi, ou plus largement en 802.1X, lorsque la mac de l'ordinateur se connectant n'existe pas dans la bdd, mais que l'authentification s'est correctement déroulée, re2o et le radius créent automatiquement la machine dans la base , renseigne sa mac, et en avise l'utilisateur par mail.

Protection anti-squattage

Lors d'une connexion filaire d'une machine adhérent dans une chambre autre que la sienne. Celle-ci doit être occupée par un adhérent ne possédant pas de blacklist (être à jour de paiement entre autre.)

Cette limitation permet de dissuader un grand nombre de cas de spoofing d'adresse MAC. Notons cependant qu'elle ne s'applique pas aux machines de membres actifs (à des fins de diagnostic, debug etc.) On espère cependant qu'en cas de spoof de machine d'un membre actif, celui-ci arrivera à nous faire remonter l'information rapidement.

-  ⇤ ← Version 9 à la date du 2013-09-12 01:12:57 → 
  Taille: 6817
  Éditeur: WikiB2moo
  Commentaire:
+   ← Version 18 à la date du 2018-12-25 20:43:20 → ⇥
  Taille: 8009
  Éditeur: WikiPollion
  Commentaire: BrokenLink
-Texte supprimé.
+Texte ajouté.
 Ligne 1:
+## page was renamed from CransTechnique/RaDius
-Ligne 2:
+Ligne 3:
-Ligne 6:
+Ligne 8:
-= Authentification MAC, VLANs dynamiques sur les Switches HP =
+Au Crans, les serveurs radius sont d'abord, [[CransTechnique/LesServeurs/Virtuels/ServeurRadius|radius]] pour le filaire,[[CransTechnique/LesServeurs/Virtuels/ServeurEap|eap]] pour le wifi, et [[CransTechnique/LesServeurs/ServeurOdlyd|odlyd]] pour le backup.


= Authentification par MAC, VLANs dynamiques sur les Switches HP =
-Ligne 10:
+Ligne 16:
-Chaque prise adhérent (c'est à dire sans borne ou serveur) est configurée pour effectuer, lorsqu'elle détecte une nouvelle adresse MAC, une requête à un serveur RADIUS (actuellement {{{radius}}} ou [[CransTechnique/LesServeurs/ServeurSable|sable]]). Outre la vérification et l'autorisation d'accès, cette requête permet au serveur RADIUS d'imposer le VLAN sur lequel est placé la prise. Ceci nous permet de séparer dynamiquement les machines du réseau classique, les machines du réseau gratuit, et les machines n'étant pas inscrites.
+Chaque prise de switchs connectée à une chambre d'adhérent est configurée pour effectuer, lorsqu'elle détecte une nouvelle adresse MAC, une requête à un serveur RADIUS. Outre la vérification et l'autorisation d'accès, cette requête permet au serveur RADIUS d'imposer le VLAN (non-taggué) sur lequel est placé la prise. Ceci nous permet de séparer dynamiquement les machines du réseau classique, les machines du réseau gratuit, et les machines n'étant pas inscrites.
-Ligne 14:
+Ligne 20:
-La génération des fichiers de configuration des switches, {{{/usr/scripts/gestion/gen_confs/switchs.py}}}, parcourt l'annuaire {{{/usr/scripts/gestion/annuaire.py}}} et la base LDAP pour déterminer les machines sur chaque prise. Si la prise est une prise adhérent, les directives de configuration {{{aaa}}} (Authentication, Authorization and Accounting) suivantes sont ajoutées :
+La génération des fichiers de configuration des switches est faite par re2o.. Si la prise est une prise adhérent, les directives de configuration {{{aaa}}} (Authentication, Authorization and Accounting) suivantes sont ajoutées :
-Ligne 20:
+Ligne 26:
-aaa port-access mac-based 43 unauth-vid 7
-Ligne 23:
+Ligne 28:
- * La première ligne active, pour la prise 43, l'authentification basée sur l'adresse MAC.
+ * La première ligne active, pour la prise 43, l'authentification basée sur l'adresse MAC (mettre "no" + esp. devant pour désactiver).
-Ligne 25:
+Ligne 30:
- * La troisième ligne fixe le timeout d'inactivité de l'authentification à 3600 secondes
 * Enfin, la dernière ligne fixe le VLAN pour les prises "non authentifiées" au VLAN 7
-Ligne 30:
+Ligne 33:
- * S'il reçoit une réponse de refus d'authentification, ou s'il ne reçoit pas de réponse, il place la prise sur le VLAN 7.
-Ligne 32:
+Ligne 34:
-== Configuration côté RADIUS ==
+= Configuration côté RADIUS =
-Ligne 35:
+Ligne 37:
+== Fonctionnement au Crans ==
-Ligne 36:
+Ligne 39:
-Le serveur RADIUS est configuré pour exécuter un script pour chaque requête d'authentification. Ce script n'est pas exécuté avec des arguments, mais dans un environnement contenant différentes variables, nommément :
 * {{{CHAP_PASSWORD}}} et {{{CHAP_CHALLENGE}}}, concernant l'authentification CHAP au serveur;
 * {{{USER_NAME}}}, contenant l'adresse MAC de la machine pour laquelle la requête est faite;
 * {{{NAS_IDENTIFIER}}}, contenant le numéro de prise sur laquelle la machine vient de se brancher.
+Freeradius appel un petit script python, {{{/etc/freeradius/3.0/auth.py}}}, qui en réalité pointe vers {{{/var/www/re2o/freeradius_utils/auth.py}}}, et qui est donc un script qui fait l'interface avec {{{re2o}}}. La fonction principale qui est appellée par {{{freeradius}}} lorsque quelqu'un essaye de se connecter au réseau est {{{authorize}}}.
 Ligne 41:
-Après vérification de l'authentification CHAP, la MAC est recherchée dans la base de données, et après quelques vérifications (par exemple que le propriétaire est bien en règle, qu'il n'a pas de restrictions), le serveur RADIUS détermine le VLAN sur lequel placer la machine. A cet effet, le script renvoie sur sa sortie standard {{{Tunnel-Type = VLAN, Tunnel-Medium-Type = IEEE-802, Tunnel-Private-Group-Id = "n"}}}, où {{{n}}} est le numéro de vlan.
+À noter que le backend python de {{{freeradius}}} tourne en Python 2, ce qui nous oblige actuellement à avoir {{{re2o}}} pyhon2 compliant :(

== Migration et anciennes machines ==

Avec re2o, la convention est de n'avoir qu'un unique mot de passe pour son compte et ses machines, alors qu'avant nous avions un mot de passe par machine. Nous avons mis en place un système legacy vouait à disparaitre pour faire la transition sans trop de douleur, en important dans un fichier les anciennes machines des adhérents, on le trouve dans {{{/etc/freeradius/3.0/wifi_passwords}}} et le {{{auth.py}}} gère ce sous cas.
-Ligne 44:
+Ligne 50:
-Les bornes WiFi se connectent également au domU {{{eap}}} (anciennement à [[CransTechnique/LesServeurs/ServeurGordon|gordon]]) en RADIUS pour vérifier les couples adresse login/mot de passe des clients WiFi.
+Les bornes WiFi peuvent aussi être vues comme des switchs, et utilisent également le protocole {{{radius}}}, en se connectent également au domU {{{eap}}} (un fallback sur le serveur {{{radius}}} est prévu, mais non configuré
sur les bornes pour le moment). Ici, une vraie étape d'authentification a lieu pour le client (la machine qui se connecte à la borne). Pour le moment, elle consiste en la validation d'un login/mdp. Pour cela, une communication
débute entre le client et la borne, à l'aide du protocole EAP. La borne redirige ensuite la requête au travers du protocole radius. Lorsque le client a réussi à s'authentifier auprès du serveur radius, celui-ci répond à la borne pour laisser passer le client.
-Ligne 46:
+Ligne 54:
-Les protocoles supportés sont PEAP et TTLS qui permettent d'encapulser dans une connexion chiffrée le protocole Ms``Chap``V2. Étant donné les défauts de sécurité de Ms``Chap``V2, il est important de valider le certificat de la connexion chiffrée: le certificat est au nom de {{{wifi.crans.org}}} et il est certifié par [[http://www.cacert.org/|cacert.org]], qui doit être installé les postes clients.
+EAP est modulaire, et nous utilisons ici les protocoles PEAP (ou TTLS) qui permettent d’encapsuler dans une connexion chiffrée, un nouveau protocole d'authentification (phase2). Au Crans, le protocole de phase2 est Ms``Chap``V2. Étant donné les défauts de sécurité de Ms``Chap``V2, il est important de valider le certificat de la connexion chiffrée : le certificat est au nom de {{{wifi.crans.org}}} et il est certifié par [[http://www.cacert.org/|cacert.org]], qui devrait être installé les postes clients.
-Ligne 48:
+Ligne 56:
-Virtuellement, chaque authentification se déroule en deux connexions Radius:
+Virtuellement, chaque authentification se déroule donc en deux sessions Radius:
-Ligne 53:
+Ligne 61:
-Ligne 54:
+Ligne 63:
-Le couple login/mdp est donné pour une machine donnée, et ne doit pas être utilisé pour une autre. Le login correspond soit au login, soit (backward compatibility) à l'adresse mac. Voici le filtre ldap correspondant: 
{{{
filter = "(&(macAddress=%{Calling-Station-Id:-*})(|(macAddress=%{Stripped-User-Name:-%{User-Name}})(host=    %{Stripped-User-Name:-%{User-Name}}.wifi.crans.org)))"
}}}
+Le couple login/pass à challenger est déterminé par l'adresse MAC du client s'authentifiant (variable {{{Calling-Station-Id}}}). Si la machine n'est pas trouvée, on considère le login fourni (et uniquement dans ce cas.)
-Ligne 75:
+Ligne 81:
+= Enregistrement automatique des macs =
En WiFi, ou plus largement en 802.1X, lorsque la mac de l'ordinateur se connectant n'existe pas dans la bdd, mais que l'authentification s'est correctement déroulée, re2o et le radius créent automatiquement la machine dans la base , renseigne sa mac, et en avise l'utilisateur par mail.

= Protection anti-squattage =
Lors d'une connexion filaire d'une machine adhérent dans une chambre autre que la sienne. Celle-ci doit être occupée par un adhérent ne possédant pas de blacklist (être à jour de paiement entre autre.)

Cette limitation permet de dissuader un grand nombre de cas de spoofing d'adresse MAC. Notons cependant qu'elle ne s'applique pas aux machines de membres actifs (à des fins de diagnostic, debug etc.) On espère cependant qu'en cas de spoof de machine d'un membre actif, celui-ci arrivera à nous faire remonter l'information rapidement.