Upload
vonguyet
View
228
Download
0
Embed Size (px)
Citation preview
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
réseau
captif
“réseau captif”de niveau 2
ou de niveau 3 …
.. avec le portail captif comme
point de passage obligé
vers l’extérieur
extérieur
(dont Internet )
poste
client
serveur d’authentification
NoCatAuth ( authserver )
passerelle de connexion
NoCatAuth ( gateway )
connexion
filaire ou
Wi-Fi au
réseau captif ..
... et obtention
d’une adresse
par DHCP
NoCatAuth : principe
réseau
captifextérieur
poste
client
authserver
gateway
X(a) le trafic non autorisé est bloqué
(b) authentification d’un utilisateur
NoCatAuth : principe
réseau
captifextérieur
poste
client
authserver
gateway
(c) Ouverture
d’accès pour un
équipement
(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 équipementpar 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.
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
client
gateway
authserver
réseau captif
1 – connexion au réseau
filaire ou Wi-Fi
( niveau physique,
niveau 2 )
2 – connexion au niveau 3 :
négociation DHCP
La phase de connexion
client
authserver
3- HTTP http://serveur-externe.com/chemin.html
HTTP GET /chemin.html
4a- capture + redirection
vers gateway:5280
4c- masquerade de
gateway:5280 en
serveur-externe.com
5- HTTP HTTP/1.1 302 Moved
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&…4b – connexion pending
La phase de connexion
client
gateway
authserver6- HTTPS https://authserver/cgi-bin/loginGET /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>
La phase de connexion
client
gateway
8- HTTPS https://authserver/cgi-bin/login
9- authentification( réussie … )
POST /cgi-bin/login
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
&[email protected]&timeout=600&...
<script>
[…]
<html>
La phase de connexion
client
gateway
authserver
11- HTTP http://gateway:5280
GET /?ticket=oa…12Rt
12 – validation des
droits + ouverture des
accès pour le client 13- HTTP HTTP/1.1 302 Moved
Location: http://serveur-externe.com/chemin.html
La phase de connexion
client
gateway
authserver
14- HTTP http://serveur-externe.com/chemin.htmlGET /chemin.html
16- toutes communicationsavec l’extérieur, dès le 12-
15- HTTP HTTP/1.1 200 OK
La phase de connexion
client
gateway
authserver 10b- HTTPS https://authserver/cgi-bin/login...GET /cgi-bin/login?pass=mot_de_passe&user=
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” [email protected]>
[…]
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
client
authserver
3- HTTP http://serveur-externe.com/4- capture + redirection
+ masquerade
5- HTTP HTTP/1.1 302 Moved
génération d’un token:
tok1 = random_token()
token=tok1
Token, ticket et GPG
client
gateway
authserver6- HTTPS https://authserver/cgi-bin/login
7- HTTPS HTTP/1.1 200 OK
token=tok1
token=tok1
Token, ticket et GPG
client
gateway
8- HTTPS https://authserver/cgi-bin/login
9- authentification10a – HTTPS HTTP/1.1 200 OK
token=tok1
génération d’un ticket,
tick1=chiffre_GPG(tok1) ticket=tick1
Token, ticket et GPG
client
gateway
authserver
11- HTTP http://gateway:528012 – validation des
droits + ouverture des
accès pour le client
13- HTTP HTTP/1.1 302 Moved
ticket=tick1
déchiffre_GPG(tick1),
validation du ticket
Token, ticket et GPG
client
gateway
authserver10b- HTTPS https://authserver/cgi-bin/login...
10c- HTTPS HTTP/1.1 200 OK
token=tok1
token=tok2
nouveau token :
tok2=f_dérivation(tok1)
nouveau token :
tok2=f_dérivation(tok1)
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 captifsindé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ésd’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’espaceDHCP,
• 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 ) impliquel’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 autreutilisateur, il lui prête ses droits jusqu’à expiration ( saufdé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, ilne 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ôlesur 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èsjusqu’à expiration.
• d’un point de vue sécurité, un réseau captif de niveau 2 avec vérification sur l’@MAC est doncpréférable.
Sécurité : choix d’authentification
• deux approches différentes de l’authentificationsont possibles avec NoCatAuth :– délai court d’expiration des accès ( par défaut : 600 s ),
et utilisation de la fenêtre de réauthentificationautomatique :
• 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 quandon quitte une page chiffrée ( pour la ré-authentificationautomatique ).
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 niveau2, 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 adressepar DHCP, pas de réauthentification …
• … sauf si on rate la ré-authentification automatique, ou si on dépassele 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éseaucaptif 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 versl’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 droitsd’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 “[email protected]”, “[email protected]”, etc.. estauthentifié en LDAP sur le “inriaVPNLogin”,
– un login “mvesin@guest”ou “[email protected]” estauthentifié 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é.