Portail captif NoCatAuth Présentation MIs 11/08/05 Marc Vesin
1. présentation générale de NoCatAuth, 2. détail d une connexion sur le réseau captif, 3. analyse et test de NoCAtAuth, 4. la maquette INRIA Sophia.
Portail captif synonymes : portail d authentification, authentication gateway, captive portal, etc. mécanisme général de sécurisation du réseau, identification et authentification des utilisateurs, contrôle d accès des utilisateurs ( filtres, QoS ), applicable au cas Wi-Fi. largement issu du monde des hot-spots/kiosques, applicable aux réseaux d entreprises.
Portail captif NoCatAuth offre abondante de portails captifs et de produits hybrides, produits commerciaux ( BlueSocket, Vernier, ), produits open-source ( NoCatAuth/NoCatSplash, ChilliSpot, et Wifidog ont retenu notre attention ). NoCatAuth écrit en PERL pour le projet de réseau communautaire NoCat, licence GPL, stable ( terminé en 2003 ), NoCatSplash : ré-écriture en C, plus compacte, en développement.
NoCatAuth : principe serveur d authentification NoCatAuth ( authserver ) réseau captif de niveau 2 ou de niveau 3 connexion filaire ou Wi-Fi au réseau captif.. extérieur (dont Internet ) passerelle de connexion NoCatAuth ( gateway ) réseau captif... et obtention d une adresse par DHCP.. avec le portail captif comme point de passage obligé vers l extérieur poste client
NoCatAuth : principe authserver (b) authentification d un utilisateur extérieur gateway X réseau captif poste client (a) le trafic non autorisé est bloqué
NoCatAuth : principe authserver extérieur (c) Ouverture d accès pour un équipement gateway réseau captif poste client (d) Le trafic autorisé est routé par le gateway
NoCatAuth : poste client pré-requis sur le poste client : une pile TCP/IP, un browser qui supporte HTTP, HTTPS et JavaScript, Configuration du poste en client DHCP,.. et un compte sur lequel s authentifier.
NoCatAuth : réseau captif le réseau captif est un réseau de niveau 2 ou 3, avec un service DHCP et accès à un service DNS, NoCatAuth ne sécurise pas l accès au réseau Wi- Fi et au réseau captif : NoCatAuth fonctionne indépendamment du réseau captif et des bornes Wi-Fi, donc a priori pas d authentification pour la connexion Wi-Fi, la négociation DHCP, les requètes DNS ; pas de chiffrement Wi-Fi. le gateway peut faire du NAT ( non testé ).
NoCatAuth : gateway la passerelle de connexion ( gateway ) : relaie le trafic autorisé entrant et sortant dans le réseau captif ( fonction routeur ), bloque le trafic non-autorisé entrant et sortant du réseau captif ( fonction contrôleur et firewall ), redirige les utilisateurs vers le serveur d authentification ( authserver ) pour authentification, ouvre ( et ferme ) des accès de/vers l extérieur à certains équipements.
NoCatAuth : gateway lorsqu un utilisateur s authentifie sur l authserver, son équipement devient autorisé, la passerelle autorise le trafic pour cet équipement par vérification sur trafic : sur l @IP, en entrant et en sortant du réseau captif, optionnellement sur l @MAC source, en sortant ( réseau captif de niveau 2 ), tout le trafic est autorisé pour l équipement ; pas de droits d accès plus fins ou de QoS prévus pour les utilisateurs authentifiés.
NoCatAuth : gateway expiration de l authentification utilisateur : au bout de 600 secondes ( par défaut ), facilité de ré-authentification automatique toutes les 450 secondes ( par défaut ). expiration optionnelle de la connexion de l équipement : toutes les 300 secondes ( par défaut ) le gateway vérifie le contenu de la table ARP, si l équipement en est absent 3 fois de suite ( par défaut ), il n est plus autorisé ( déconnecté ).
NoCatAuth : authserver le serveur d authentification ( authserver ) : authentifie des utilisateurs, fait en sorte que ces utilisateurs authentifiés puissent communiquer à travers le gateway ne contacte pas directement le gateway, donne un ticket de connexion ( auth message ) à l utilisateur authentifié, à transmettre au gateway.
NoCatAuth : authserver la source d authentification est à choisir parmi : fichiers locaux de type /etc/passwd ( testé ), serveur RADIUS ( testé ), annuaire LDAP, serveur NIS, serveur SAMBA, serveur IMAP, base de donnée DBI, PAM,... mais une seule source d authentification active sur un authserver.
Démonstration NoCatAuth pour illustrer cela par une connexion.
1. présentation générale de NoCatAuth, 2. détail d une connexion sur le réseau captif, 3. analyse et test de NoCAtAuth, 4. la maquette INRIA Sophia.
La phase de connexion authserver 1 connexion au réseau filaire ou Wi-Fi ( niveau physique, niveau 2 ) réseau captif client 2 connexion au niveau 3 : négociation DHCP gateway
La phase de connexion authserver 4a- capture + redirection vers gateway:5280 4c- masquerade de gateway:5280 en serveur-externe.com 4b connexion pending 3- HTTP http://serveur-externe.com/chemin.html HTTP GET /chemin.html 5- HTTP HTTP/1.1 302 Moved client Location: https://authserver/cgi-bin/login? redirect=http://gateway:5280&timeout=600& gateway=gateway:5280&mac=00:0d:56:e3:77:a7& token=xa3..2z&
La phase de connexion authserver 6- HTTPS https://authserver/cgi-bin/login GET /cgi-bin/login?redirect=gateway:5280& 7- HTTPS HTTP/1.1 200 OK <html> <form method= post action=https://gateway/cgi-bin/login> [ ] <input type= text name= user > <input type= password name= pass > <input type= hidden name= token > [ ] <html> client gateway
La phase de connexion 9- authentification ( réussie ) 8- HTTPS https://authserver/cgi-bin/login POST /cgi-bin/login gateway 10a HTTPS HTTP/1.1 200 OK <html> <head> <meta http-equiv= Refresh content= 5; URL=http://gateway:5280/? ticket=oa.12rt > </head> <script language=javascript > window.open( https://authserver/cgi-bin/login?pass=mot_de_passe &user=mvesin@guest.inria.fr&timeout=600&... <script> [ ] <html> client
La phase de connexion authserver 12 validation des droits + ouverture des accès pour le client 11- HTTP http://gateway:5280 GET /?ticket=oa 12Rt 13- HTTP HTTP/1.1 302 Moved client Location: http://serveur-externe.com/chemin.html gateway
La phase de connexion authserver 14- HTTP http://serveur-externe.com/chemin.html GET /chemin.html 15- HTTP HTTP/1.1 200 OK client gateway 16- toutes communications avec l extérieur, dès le 12-
La phase de connexion authserver 10b- HTTPS https://authserver/cgi-bin/login... GET /cgi-bin/login?pass=mot_de_passe&user= mvesin@guest.inria.fr&... 10c- HTTPS HTTP/1.1 200 OK <head> <meta http-equiv= Refresh content= 450; URL=https://gateway /cgi-bin/login?pass=mot_de_passe&user= & </head> <input type= hidden name= pass value= mot_de_passe > <input type= hidden name= user value=mvesin@guest.inria.fr> [ ] client gateway
La phase de connexion après la connexion initiale : ré-authentification périodique automatique avec la fenêtre de réauthentification, toutes les 450s par défaut ( paramétrable ). déconnexion explicite logout sur la fenêtre de réauthentification, immédiate. fermeture de la fenêtre de ré-authentification périodique Fermeture du browser, fermeture de la session utilisateur, Pas de réauthentification Expiration des accès après 600s par défaut ( paramétrable ). déconnexion du poste client du réseau captif.
Token, ticket et GPG mécanisme par lequel l authserver informe le gateway des droits d accès accordés à un équipement, à l ouverture d une session : un ticket d autorisation est généré par l authserver à l authentification, il est transmis jusqu au gateway lors de la phase de connexion, ce ticket est signé, par le moyen d un chiffrement GPG sur l authserver, ce ticket ne contient pas d information confidentielle, le gateway vérifie la signature à réception du ticket par déchiffrement GPG et interprétation.
Token, ticket et GPG lors de l installation de NoCatAuth : une paire de clefs GPG est générée sur l authserver, la public key ring est propagée manuellement sur le gateway, exemple de ticket ( auth message chiffré ) : [2005-08-10 15:29:40] Got auth msg: Member ANY Mac 00:02:2D:09:68:4F Action Permit User mvesin@guest Mode renew Timeout 450 Token $1$1$uBR/.YykVdet9w0wgyIwr/
Token, ticket et GPG authserver 4- capture + redirection + masquerade génération d un token: tok1 = random_token() 3- HTTP http://serveur-externe.com/ 5- HTTP HTTP/1.1 302 Moved token=tok1 client
Token, ticket et GPG authserver 6- HTTPS https://authserver/cgi-bin/login token=tok1 7- HTTPS HTTP/1.1 200 OK token=tok1 client gateway
Token, ticket et GPG 8- HTTPS https://authserver/cgi-bin/login token=tok1 9- authentification génération d un ticket, tick1=chiffre_gpg(tok1) 10a HTTPS HTTP/1.1 200 OK ticket=tick1 client gateway
Token, ticket et GPG authserver 12 validation des droits + ouverture des accès pour le client déchiffre_gpg(tick1), validation du ticket 11- HTTP http://gateway:5280 ticket=tick1 13- HTTP HTTP/1.1 302 Moved client gateway
Token, ticket et GPG authserver 10b- HTTPS https://authserver/cgi-bin/login... token=tok1 nouveau token : tok2=f_dérivation(tok1) nouveau token : tok2=f_dérivation(tok1) 10c- HTTPS HTTP/1.1 200 OK token=tok2 client gateway
Token, ticket et GPG le token initial (tok1) est généré aléatoirement par le gateway pour chaque session, la fonction de dérivation ( f_dérivation ) des tokens est bien connue, les tokens suivants d une session sont dérivés sur le gateway et sur l authserver (indépendamment), le token dérivé (tok2) est utilisé pour la première ré-authentification automatique d une session, et ainsi de suite.
1. présentation générale de NoCatAuth, 2. détail d une connexion sur le réseau captif, 3. analyse et test de NoCAtAuth, 4. la maquette INRIA Sophia.
Architecture : rappel l authserver ne fait que de l authentification et de l autorisation : il ne voit passer aucun trafic utilisateur. le gateway ne fait que du contrôle d accès : ne fait pas d authentification, ne connait pas les mots de passe des utilisateurs, utilise les tickets d accès délivrés par l authserv. le gateway et l authserver ne dialoguent pas directement : utilisent des redirections de requètes HTTP utilisateur, et la fourniture de tickets d autorisation ( auth message ) par l authserver au gateway.
Architecture : généralités quelle localisation pour l authserver? gateway et authserver sur la même machine ( déconseillé ), authserver coté extérieur du gateway, vraisemblablement dans une zone sécurisée de serveur ( bon ). authserver sur le réseau captif (?). penser à la sécurisation du backend : communication entre l authserver et la source d authentification ( LDAP, RADIUS, etc. )
Architecture : cas complexes on peut déployer plusieurs réseaux captifs indépendants qui utilisent le même authserver un gateway par réseau, c est le cas sur le réseau NoCat. architecture robuste? a priori non prévu, on pourrait déployer plusieurs gateways sur un même réseau ((?)avec redondance par le routage ; clustering ), un seul serveur d authentification (@IP ou nom DNS ) est possible par contre ( à cluster-er? ), assurer la robustesse du backend ( RADIUS, LDAP ) et des communications réseau entre les éléments.
Architecture : cas complexes servir plusieurs communautés d utilisateurs? il existe un mode sans authentification ( mode Open ) de NoCatAuth ; les utilisateurs doivent juste s identifier ( non testé ), dans le mode avec authentification de NoCatAuth il existe des classes optionnelles ( non testées ) : classe Public d utilisateurs non-authentifiés avec des droits restreints ( filtrage, QoS ), classe Owner d utilisateurs avec un accès privilégié aux ressources ( QoS ).
Architecture : cas complexes servir et isoler plusieurs communautés d utilisateurs? a priori non prévu une possibilité : des VLANs distincts sur le réseau captif, à supporter par les équipements Wi-Fi ( 2 SSID ) et filaire du réseau captif, autre possibilité : 2 préfixes réseau distincts sur le réseau captif, à supporter par le serveur DHCP du réseau captif dans tous les cas : la séparation en aval du réseau captif ( extérieur ) se fait sur le routage et le filtrage le gateway utilise la même table de routage pour toutes les communautés. autres possibilités : 2 NoCatAuth distincts ; 2 gateways NoCatAuth distincts
Sécurité : analyse de l architecture l architecture de NoCatAuth semble valide par rapport à ses objectifs pas de donnée sensible de l utilisateur ( mot de passe ) transmise en clair sur le réseau, seul le authserver a une connaissance des données sensibles ; il est authentifié par certificat par l utilisateur, le ticket signé donnant accès est transmis du authserver au gateway, et ne semble pas simplement usurpable protection contre le rejeu, mais qu en dirait un cryptanalyste? Cette partie n est pas un algorithme connu, mais une méthode spécifique à NoCatAuth.
Sécurité : un problème un problème d implémentation très génant : le mot de passe utilisateur apparait en clair dans : dans les logs du serveur d authentification ( via les URLs des requètes ), génant mais doit pouvoir se configurer, dans le code source de page HTML sur le poste client, on n en a pas trouvé trace dans le cache Web, mais est-ce garanti par NoCatAuth?
Sécurité : les limites de NoCatAuth NoCatAuth ne vise pas à : sécuriser les communications Wi-Fi ou réseau ( pas de chiffrement ), protéger les équipements du réseau captif les uns des autres.
Sécurité : les limites de NoCatAuth possibilité de vol de droits d accès d un équipement ( attaque ) : déconnecter l équipement et utiliser ses droits jusqu à expiration, ou attendre une déconnexion non-explicite et spoofer son @MAC/@IP. possibilité d attaque par saturation de l espace DHCP, possibilité d attaque par spoofing du service DNS, ou du gateway, déni de service, mais pas de vol de crédentiels du réseau captif (?).
Sécurité : squat de droits d accès le squat ( accès sans authentification, opportuniste mais non malveillant ) implique l intervention d un utilisateur autorisé, si on fait du contrôle sur les @MAC : si un utilisateur prête la carte réseau de son équipement à un autre utilisateur, il lui prête ses droits jusqu à expiration, si un utilisateur ferme sa session et passe l équipement à un autre utilisateur, il lui prête ses droits jusqu à expiration ( sauf déconnexion explicite ), cas des postes multi utilisateurs, par contre, si un utilisateur se débranche du réseau et qu un autre équipement ( autre @MAC ) récupère la même @IP par DHCP, il ne récupère pas les droits NoCatAuth, l utilisateur est redirigé vers la page de connexion.
Sécurité : squat de droits d accès le squat est facilité, si on ne fait pas de contrôle sur les @MAC : si un utilisateur se débranche du réseau et qu un autre équipement récupère la même @IP par DHCP, il récupère les droits d accès jusqu à expiration. d un point de vue sécurité, un réseau captif de niveau 2 avec vérification sur l @MAC est donc préférable.
Sécurité : choix d authentification deux approches différentes de l authentification sont possibles avec NoCatAuth : délai court d expiration des accès ( par défaut : 600 s ), et utilisation de la fenêtre de réauthentification automatique : problème du mot de passe en clair ; contraintes sur la configuration du browser. délai long d expiration des accès ( exemple : 1 jour ), on compte alors fortement sur l expiration ARP ( donc réseau captif de niveau 2 ) pour éviter le squat, la fenêtre de réauthentification automatique est moins utile.
Implémentation le gateway : est écrit en PERL, implémente un serveur Web en PERL sur port 5280, tourne en tant que root, utilise les iptables Linux pour le filtrage, les droits d accès, l interception et la mascarade, le routage du trafic est effectué par la pile TCP/IP Linux.
Implémentation l authserver : utilise un serveur HTTPS Apache, qui peut tourner en tant que nobody, consiste en des CGI sur ce serveur, est écrit en PERL, utilise de nombreux packages PERL pour s interfacer avec les différentes sources d authentification.
Implémentation stabilité : globalement, la stabilité parait bonne, au vu des premiers tests effectués, à valider sur un réseau en charge et sur une période plus longue. un problème génant constaté à 2 reprises en FC3 + konqueror 3.3.1 : la ré-authentification automatique échoue, mais le gateway oublie de refermer les droits pour un équipement (à creuser).
Implémentation performance : sur un bipro Pentium III, 2 interfaces 100 Mbps, à la fois gateway et authserv : on tient un flux TCP à 90 Mbps en chargeant la CPU de < 30%, la vitesse de routage/filtrage est celle du kernel Linux et des iptables.
Utilisation : les clients testés on a testé NoCatAuth avec succès en : Windows XP SP2 + IE 6.0 ou Netscape 7.1 Linux Fedora core 3 + konqueror 3.3.1 ou Firefox 1.0.3 normalement, cela fonctionne avec tous les clients contraintes de configuration du poste client : le browser doit accepter les fenêtres popup depuis l authserver ( pour la ré-authentification automatique ), le serveur ne doit pas demander de confirmation quand on quitte une page chiffrée ( pour la ré-authentification automatique ).
Utilisation : ré-authentification manuelle l utilisateur évite le plus souvent la réauthentification manuelle : mobilité sur le réseau Wi-Fi : si l on reste sur le réseau captif, et que l on fait du roaming de niveau 2, pas de réauthentification nécessaire. déconnexion et reconnexion d un client ( ou perte de signal/traversée de zone d ombre en Wi-Fi ) : si on garde la même carte réseau et que l on récupère la même adresse par DHCP, pas de réauthentification sauf si on rate la ré-authentification automatique, ou si on dépasse le délai d expiration ARP.
Utilisation : divers utilisation d un client VPN depuis le réseau captif : avec un client VPN Cisco, cela fonctionne et semble stable ( à confirmer dans la durée ), pas testé avec NAT activé sur le gateway. poste client avec plusieurs cartes réseau ( sur le réseau captif et un autre réseau ) : cela fonctionne, mais peut être déroutant pour l utilisateur, seule la carte utilisée pour communiquer avec NoCatAuth ( avec le gateway? ) a des droits d accès NoCatAuth/ la redirection automatique des requètes HTTPS vers l authserv pour authentification ne fonctionne pas : (?) car l on a installé gateway et authserv sur la même machine.
Administration : surveillance sur le gateway, une trace des ajouts de droits d accès est constituée dans nocat.log : [2005-08-10 08:37:54] Received notify from 193.51.208.244 [2005-08-10 08:37:55] Got auth msg: Member ANY Mac 00:02:2D:09:68:4F User mvesin@guest Token $1$41178067$0XrbUCrXRiqiuD2hU5Fr3/ Redirect http://www-sop/ Action Permit Mode login Timeout 600 [2005-08-10 08:37:55] User mvesin@guest permitted in class Member
Administration : surveillance trace du renouvellement de droits d accès : [2005-08-10 08:58:28] Received notify from 193.51.208.244 [2005-08-10 08:58:28] Got auth msg: Member ANY Mac 00:02:2D:09:68:4F Action Permit User mvesin@guest Mode renew Timeout 450 Token $1$5$tV4GY.qBzEybNGQv3X8Yu/ [2005-08-10 08:58:28] User mvesin@guest renewed in class Member
Administration : surveillance trace de la suppression de droits d accès : [2005-08-10 03:14:35] Expiring connection from 193.51.208.244. [2005-08-10 03:14:35] User mvesin@guest denied service. Connected since Tue Aug 9 16:14:00 2005. il manque des outils de consolidation des logs : associer @IP et auth message, historique des droits d accès sur le gateway, état actuel du gateway ( qui a des droits accès à l instant? ).
1. présentation générale de NoCatAuth, 2. détail d une connexion sur le réseau captif, 3. analyse et test de NoCAtAuth, 4. la maquette INRIA Sophia.
Maquette INRIA Sophia : objectif meilleure couverture radio du campus, sécurisation du réseau Wi-Fi et/ou du réseau visiteur de l INRIA Sophia : authentification des utilisateurs, prise en compte des besoins des communautés : collaborateurs INRIA et visiteurs de passage, solution déployable rapidement et sans gros investissement.
Maquette INRIA Sophia : principe sur un réseau de type visiteur, en filaire et en Wi-Fi : on la voit comme une évolution ( remplacement ) éventuelle du Wi-Fi et/ou du réseau visiteur actuel, pas de cloisonnement des 2 communautés INRIA et visiteur, on utiliserait donc 1 seul SSID au niveau des bornes Wi-Fi, et pas de sécurisation au niveau Wi-Fi, l accès aux ressources internes se ferait toujours par les VPN. gateway et authserv sont sur la même machine : si on déploie NoCatAuth en production, on les séparera, l authserv doit être dans une zone de serveurs.
Maquette INRIA Sophia : comptes l authserv utilise un serveur RADIUS comme source d authentification le serveur RADIUS permet de combiner plusieurs sources d authentification, le serveur RADIUS authentifie les collaborateurs INRIA dans l annuaire LDAP, et le serveur RADIUS authentifie les visiteurs de passage dans un fichier de type /etc/passwd, mais distinct de celui du système.
Maquette INRIA Sophia : comptes tous les collaborateurs INRIA ont donc un compte actif sans action préalable, il manque un outil pour simplifier la déclaration des comptes des visiteurs, et des règles politiques ( qui peut déclarer un compte? ).
Maquette INRIA Sophia : comptes nomenclature des comptes : un login mvesin est authentifié en LDAP sur l attribut inrialocallogin des comptes de Sophia uniquement, un login mvesin@irisa.fr, mvesin@loria.inria.fr, etc.. est authentifié en LDAP sur le inriavpnlogin, un login mvesin@guest ou mvesin@guest.inria.fr est authentifié en local sur le nom de compte, pas d ambiguité au niveau RADIUS ou LDAP ; privilégie la simplicité pour les utilisateurs locaux. c est un exemple, d autres choix sont possibles : mais risquent de provoquer des ambiguités RADIUS ou LDAP, à tester.
Maquette INRIA Sophia : divers manque-t-il un bypass de NoCatAuth pour les communications avec les serveurs VPN INRIA? utilité d une double authentification NoCatAuth/VPN? le bypass implique de customiser le code NoCatAuth. il manque des outils de consolidation des logs, le filtrage des accès autorisés de/vers l extérieur se fait au niveau du firewall de site : donc ce n est pas génant que NoCatAuth autorise tous les accès pour un équipement autorisé.
avez-vous des questions? merci à toutes et a tous!