Portailcaptif“NoCatAuth” - Inria · – un browser qui supporte HTTP, HTTPS et JavaScript, –...

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

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


réseau

captifextérieur

poste

client

authserver

gateway

X(a) le trafic non autorisé est bloqué

(b) authentification d’un utilisateur


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.

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,


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


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


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>


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>


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


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


client

gateway

authserver 10b- HTTPS https://authserver/cgi-bin/login...GET /cgi-bin/login?pass=mot_de_passe&user=

[email protected]&...

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]>

[…]


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.


• 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/


client

authserver

3- HTTP http://serveur-externe.com/4- capture + redirection

+ masquerade


génération d’un token:

tok1 = random_token()

token=tok1


client

gateway

authserver6- HTTPS https://authserver/cgi-bin/login

7- HTTPS HTTP/1.1 200 OK

token=tok1

token=tok1


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


client

gateway

authserver

11- HTTP http://gateway:528012 – validation des

droits + ouverture des

accès pour le client


ticket=tick1

déchiffre_GPG(tick1),

validation du ticket


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)


• 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.


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.


• 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 ).


• 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


• 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


• 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

? ).


2. détail d’une connexion sur le réseau captif,

3. analyse et test de NoCAtAuth,


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.


• 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 ?

).


• 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é.

avez-vous des questions ?

merci à toutes et a tous !

Portailcaptif“NoCatAuth” - Inria · – un browser qui supporte HTTP, HTTPS et JavaScript, –...

Documents

Transcript of Portailcaptif“NoCatAuth” - Inria · – un browser qui supporte HTTP, HTTPS et JavaScript, –...