Rapport Final Chillispot

Institut Universitaire de
Technologie de Blagnac
Projet tuteuré:
Mise en place d'un portail

captif Chillispot
2
Projet tuteuré:
Mise en place d'un portail

captif Chillispot
Luc MAYERHOFFER à l’attention de M.Gaël MANSALIER.

Jérémy RUSCASSIE
Diplôme: LPRMS
Date: Juin 2008
REMERCIEMENTS
Nous remercions l’ensemble des professeurs de la formation Licence
Professionnelle Réseaux Mobiles et Sécurité pour tous les renseignements qu'ils
3
nous ont apporté ainsi que pour les différents cours que ceux-ci nous ont
enseignés de manière à mener à bien ce projet. Nous remercions également tout
particulièrement M. Gaël Mansalier pour ses différentes critiques positives nous
ayant permis d'avancer de manière efficace tout le long de l'année. Ses conseils
et le temps qu’il nous a consacré malgré son emploi du temps chargé nous ont été
d'une grande utilité. Nous tenons aussi à remercier également M. Danielle
Caballero pour son aide dans l'aspect rédactionnel d’un projet tuteuré. Enfin nous
tenons à remercier M. François Gerthoffert pour ses études comparatives sur les
différentes solutions de portails captifs ainsi que tous les internautes qui nous ont
aidé à répondre aux différentes questions que nous nous posions et qui nous ont
permis d’appréhender au mieux les besoins du projet.
SOMMAIRE
• RESUME/ABSTRACT 6
• GLOSSAIRE 7
• INTRODUCTION 8
4
• Chapitre 1: Présentation du Projet 9
1. Description et usage 9
2. Fonctionnement général 9
3. Contexte d'installation 11
4. Résumé de la proposition 11
• Chapitre 2: Etude des différentes solutions 12
1. Tableau comparatif et analyse 12
a) NoCatSplash 13
b) Talweg 14
c) WifiDog 17
d) Chillispot 18
e) PublicIP 19
f) MonoWall 19
g) Bilan 20
2. Pourquoi Chillispot? 20
3. Intégration de Chillispot en environnement universitaire 20
• Chapitre 3: Réalisation du projet 24
1. Analyse du Cahier des Charges et de ses contraintes 24
2. Présentation de l'architecture 25
3. Matériel requis 26
4. Conception générale 27
a) Rôle de l'interface tun 27
b) Affectation d'adresse IP 28
c) Interception et demande d'accréditation 29
d) Méthode d'authentification 30
e) Transmission de paquets d'un client authentifié 34
f) Gestion d'une session authentifiée 37
g) Déconnexion d'une session authentifiée 39
h) Interface d'administration 39
i) Evolution de la solution 41
• CONCLUSION 42
• ANNEXES 43
RESUME
Aujourd'hui, la volonté de liberté de mouvements se fait de plus en plus

ressentir. Les publicités d'opérateur de téléphonie mobile en font leur principal
5
argument. Ce qui fait le succès de la téléphonie depuis des années, tend à se
répéter dans le milieu de l'informatique avec les réseaux sans-fil.
Il existe différentes technologies sans fils correspondant chacune à une
échelle d'utilisation différente que ce soit la technologie Bluetooth, Wifi ou
encore Wimax.
Aujourd'hui le Wifi semble prépondérant dans l'établissement de réseaux locaux
que ce soit en intérieur ou même en extérieur. On peut ainsi voir de plus en plus de
réseaux émerger dans les lieux publics à forte concentration comme les gares ou
les aéroports, ou même dans les entreprises.
De cette émergence est apparue l'idée de mettre en place un réseau sans-fil avec
authentification par portail captif afin d'offrir à toute personne ayant une
affiliation à l'IUT de Blagnac, un accès Internet.
ABSTRACT
Nowaday, people want to feel free to move anywhere and most mobile telephone
provider's advertising focuses on this wish which has become their new principal
selling point. What has made telephony a success for many years, will occur again
in the milieu of computer sciences with wireless networks.
There are different wireless technologies each corresponds to a different use
scale. You can find Bluetooth, Wifi or Wimax technologies. Today, Wifi technology
is the most popular technology in local networks inside as well as outside. We can
see more and more networks in public places with a high concentration of people,
such as railway stations, airports, or firms.
With this development, the idea of setting up a wireless network with
authentication by captive portal was developed to allow Internet access to anyone
to related to the IUT of Blagnac.
GLOSSAIRE
CGI : Un CGI (Common Gateway Interface) est un script classique (développé en

différents langages : C, C++, Perl...) permettant de générer des pages à partir de
6
données présentes sur un serveur donné.
IP forwarding : Technique consistant à retransmettre sur un autre port réseau les

paquets arrivant sur un premier port. Cela permet par exemple de faire d'une
machine avec deux cartes réseau un routeur.
Iptables : Firewall IP développé par l’équipe Netfilter pour GNU/Linux.
NAS : Network Access Server, surveille l’accès à une ressource (accès réseau par
exemple) et fait office d’intermédiaire entre le client et le serveur d’accès dont
dépend la décision d’accès.
UAM : Module d'une application qui invite l'utilisateur à entrer son identifiant et
le mot de passe associé nécessaire pour y accéder.
CHAP : Challenge Handshake Authentication Protocol est un protocole

d’authentification pour PPP à base de challenge, ce qui le rend bien plus discret que
son homologue pendant PAP. Ce protocole à l'avantage de "hasher" les mots de
passe avant de les transmettre. Il utilise aussi un système de défis (challenge-
response) et de clef secrète partagée (shared secret) afin d'authentifier les
clients distants. Ce système est donc bien plus sécurisé que le PAP. Il permet
d'authentifier le poste client (shared secret), ainsi que l'identité de l'utilisateur
(user/password). Ce protocole est défini dans la RFC 1994.
* une astérisque comme celle-ci désignera des définitions intégrées dans ce glossaire.
INTRODUCTION
De plus en plus de personnes disposent aujourd'hui d'un appareil mobile

(portable, PDA, ...) et souhaitent pouvoir accéder à l'Internet avec cet appareil
7
dans la majorité des lieux qu'ils fréquentent. Dans cette optique, l'expansion très
rapide des points d'accès sans-fil permet la connexion des appareils nomades.
Néanmoins chaque réseau possède sa politique d'accès et ne souhaite pas laisser
n'importe qui accéder aux ressources réseaux.
Ainsi il est nécessaire de mettre en place des systèmes d'authentification

sur ces réseaux qui doivent cumuler de multiples avantages comme une
compatibilité avec la majorité des appareils mobiles du marché, sécuriser les
échanges entre les clients et le réseau, offrir à l'utilisateur la plus grande
transparence aussi bien lors de la phase d'authentification que lors de l'utilisation
du réseau, réduire l'impact au niveau des ressources matérielles et de la bande
passante.
Devant ces enjeux, le portail captif s'est imposé comme une solution
fréquemment utilisée avec les points d'accès payants, mais elle peut se généraliser
à tous types de réseau (sans-fil ou filaire) nécessitant un contrôle d'accès. La
technique du portail captif consiste à forcer un client souhaitant accéder à un
service en http ou https sur un réseau à passer par une page web servant à
l'authentifier sur celui ci. Après authentification, la passerelle peut le laisser
passer ; le client a accès au réseau de façon classique.
Ainsi le système utilisé dans notre Université permettra d'authentifier les

utilisateurs désirant se connecter depuis n'importe quelle machine apportée à
l'intérieur des bâtiments ; la seule nécessité est de disposer d'un compte
utilisateur valide, d'un navigateur web gérant le https et dans le cas du portail
captif Chillispot d'autoriser l'ouverture du pop-up envoyé par Chillispot.
Chapitre 1: Présentation du projet
1. Description et usage
Un portail captif est une structure permettant un accès rapide à Internet.
8
Celui-ci agit sur le navigateur Web pour donner à un usager sans fil l'occasion de
présenter son accréditation pour l'ouverture d'une session de navigation. En
effet, lorsqu'un utilisateur nomade cherche à accéder à une page Web, le portail
captif intercepte la requête et demande l'authentification de l'utilisateur.
Il peut également être employé pour présenter à l'usager une certaine information
(telle qu'une Politique d'Utilisation Acceptable) avant d'accorder l'accès total au
réseau. Ceci permet donc à tout ordinateur équipé d'un navigateur HTML et d'un
accès Wifi de se voir proposer un accès à Internet sans qu'un programme
d'authentification personnalisé et précis ne soit requis.
Figure 1.1: L'usager veut aller sur une page Web et est redirigé
2. Fonctionnement général:
Lorsqu'un usager veut accéder à Internet, il va d'abord scanner* son

environnement sans-fil avec son terminal portatif et choisir le réseau offert. Son
terminal demande un bail DHCP*, délivré par l'interface sans-fil du point d'accès.
L'usager emploie alors son navigateur Web pour visiter n'importe quel site sur
Internet en envoyant une requête HTTP. Au lieu de recevoir la page demandée,
celui-ci arrive sur le portail du point d'accès.
Cette page peut exiger de celui-ci:
 qu'il entre directement un identifiant et un mot de passe

 qu'il clique simplement sur un bouton « d'acceptation au réseau »,
 qu'il entre toutes autres accréditations exigées par les administrateurs de
réseau.
L'usager entre alors son accréditation qui est vérifiée par un autre serveur
9
d'authentification sur le réseau. Tout autre accès au réseau est bloqué jusqu'à ce
que ses accréditations soient vérifiées.
Les identifiants de connexion (identifiant, mot de passe) de chaque utilisateur
sont stockés dans une base de données qui est hébergée localement ou sur un
serveur distant.
Figure 1.2: Les accréditations de l'usager sont vérifiées avant de lui permettre un accès
complet. Le serveur d'authentification peut être le point d'accès lui-même, un autre
ordinateur sur le réseau local ou un serveur n'importe où sur Internet.
Une fois authentifié, l'usager a accès à toutes les ressources du réseau puis il est
redirigé sur le site qu'il avait demandé au départ.
Figure 1.3:Une fois authentifié, l'usager peut avoir accès au reste du réseau.
Les portails captifs ne fournissent aucun chiffrement pour les usagers sans fil. Ils
comptent plutôt sur les adresses MAC et IP comme identification. Puisque ceci
n'est pas nécessairement très sécuritaire, on demandera à l'usager de
s'authentifier à nouveau périodiquement. Ceci peut se faire automatiquement en
réduisant au minimum une fenêtre flottante ou pop-up spéciale du navigateur
lorsque l'utilisateur entre pour la première fois.
3. Contexte d'installation:
10
Puisqu'ils ne fournissent pas de chiffrement fort, les portails captifs ne sont pas
un très bon choix pour les réseaux qui doivent être fermés pour ne permettre
l'accès qu'à des usagers fiables. Ils conviennent davantage aux cafés, aux hôtels
et autres endroits d'accès publics utilisés par des usagers occasionnels de réseau.
Dans des installations de réseau publiques ou semi-publiques, les techniques de

chiffrement comme le WEP et le WPA sont inutiles. Et pour cause, il n'y a
simplement aucune manière de distribuer des clefs publiques ou partagées aux
membres du grand public sans compromettre la sécurité de ces clefs. Dans ces
installations, une application plus simple tel qu'un portail captif fournit un niveau
de service qui se trouve entre un service complètement ouvert et un service
complètement fermé.
4. Résumé de la proposition
Résumé de la proposition:
Titre: Réalisation d'un portail captif basé sur Chillispot
Résumé du travail attendu:
 Etudier la technique du portail captif (Wifi-Hotspot)

 Présenter la solution logicielle Chillispot parmi ses concurrentes
 Mettre en œuvre cette solution dans un environnement virtualisé UBUNTU:
Installation – configuration MySQL, Freeradius, Chillispot...
 Tester la maquette et la mettre en conformité
 Rédiger des fiches de synthèse (Installation, Configuration, Utilisation,
Maintenance,...)
Chapitre 2: Etude des différentes propositions
1. Tableau comparatif et analyse
11
Les comparatifs que nous allons développer dans cette partie du chapitre sont
intégrés de manière à expliquer les différents choix probables que peuvent, lors
de la réponse à un cahier des charges, effectuer les responsables de projet.
Dans le milieu Open Source, il existe plusieurs solutions de portail captif. Notre
projet ayant pour but la mise en place d'un portail Wifi via la solution Chillispot,
nous n'avons pas eu à faire un choix, car celui-ci nous a été proposé pour plan de
départ. L’implémentation de Chillispot est écrite en C et en Perl (pour le
formulaire) et fonctionne sous la plateforme GNU/Linux avec comme couche basse
le pare feu Iptables*. Il est fourni avec plusieurs moyens d’authentification,
modifiable et débuggable facilement. C’est pour cela que la solution Chillispot nous
semble intéressante.
Or, nous avons décidé d'effectuer tout de même une étude complète du projet de
mise en place d'un portail Wifi global. C'est pourquoi nous avons cherché et
comparé les différentes solutions que nous aurions pu mettre en œuvre sans cette
contrainte.
Portails Captifs
NoCatSplash Talweg Wifidog Chillispot Public IP Monowall
Simplicité
d'installation
Infrastructure
nécessaire
Performances
réseau
Gestion
utilisateurs
Sécurité
authentification
Sécurité
communications
Protocoles
supportés
Crédit temps
Interface d’
administration
Légende:
Non disponible
Plus ou moins disponible
12
Voici en détail les différentes solutions en termes d'utilisation techniques
possibles :
a) NoCatSplash
Le logiciel NoCatSplash est un portail web captif destiné à sécuriser le
partage d’une connexion sans-fil en redirigeant les utilisateurs vers une page web
sur laquelle ils doivent s’authentifier via https avec un login/mot de passe. Pour
cela, NoCat modifie dynamiquement les règles Iptables* du firewall pour ouvrir
certains ports pour l’utilisateur (uniquement TCP avec NoCatAuth-0.82).
NoCatAuth nécessite les droits root pour manipuler les règles Iptables*.
NoCatSplash est une solution idéale pour les petites structures ou personnes
souhaitant partager facilement une partie de leur bande passante en offrant
notamment un contrôle sur les ports autorisés.
Figure 2.1: Architecture NoCat
Le logiciel NoCat fournit 2 modules : authserv (serveur web d’authentification) et

gateway (passerelle). La documentation conseille d’installer les deux modules sur
deux machines séparées car d’une part la gateway fonctionne avec les droits root
et d’autre part, cela permet de centraliser la gestion des droits d’accès.
Cependant, pour des contraintes matérielles, la passerelle et le serveur
d’authentification sont souvent installés sur une même machine.
Figure 2.2: portail d’authentification NoCat
13
Voici le portail d'identification de NoCat qui en premier temps demande les
login/mot de passe utilisateurs, qui confirme la véracité de ceux-ci puis la fenêtre
permettant de rester loguer sur le hotspot durant tout le long de l'utilisation de
celui-ci.
Néanmoins certains points nous ont interpellés comme les failles de sécurité
possibles avec cette solution :
- Possibilité de voler les droits d’accès d’un utilisateur (attaque), en spoofant le

couple @MAC/IP de l’utilisateur, déconnecter l’utilisateur et utiliser ses droits
jusqu’à expiration, ou attendre une déconnexion non explicite.
- Usurper l’identité du hotspot pour récupérer les login/mot de passe des

utilisateurs.
b) Talweg
Le logiciel talweg est un portail captif s'exécutant sur une plate-forme Linux.
Il utilise un serveur DNS, DHCP, Apache ainsi qu’Asp.Net et Iptables*.
On peut schématiser le principe de fonctionnement du portail captif de la

manière suivante :
Figure 2.3 : Principe du portail captif.
14
Une fois identifiés, les clients situés dans le réseau Wi-Fi transmettent leurs
requêtes à la passerelle en utilisant le protocole HTTPS. Les transmissions sont
donc sécurisées dans la partie la plus sensible du réseau où les écoutes des
communications sont facilitées en raison du médium de transmission Wi-Fi. La
passerelle s'occupe alors de contacter le site distant (HTTP ou HTTPS) et de
réceptionner la réponse du site. Elle retransmet ensuite l'information au client
Wi-Fi via la connexion HTTPS.
Le schéma de la figure 2.4 détaille le principe des redirections que subit la

requête.
Figure 2.4 : Principe des redirections.
On voit qu'un utilisateur authentifié cherchant à contacter directement un site

sur le port 80 ou 443 est bloqué par le firewall et redirigé vers un gestionnaire de
navigation qui va traiter la requête du client en contactant pour lui le site.
L'échange avec ce gestionnaire se fait via le protocole HTTPS et est donc
sécurisé grâce à SSL.
Ce fonctionnement n'est effectif que lorsque l'utilisateur est correctement
authentifié (présence du cookie TWG sur le client). Le principe de base de tous les
portails captifs, est qu'il soit redirigé vers une page de connexion, tant que
l'utilisateur n'a pas rentré un couple « nom d'utilisateur + mot de passe » valide.
Dès que l'authentification est validée, alors le portail dépose un cookie de session
(TWG ici). La navigation est alors possible tant que ce cookie reste présent sur le
navigateur (le temps de la session).
Différents modes d'identification sont disponibles pour la solution Talweg :

1. Authentification auprès d'un serveur CAS : principe de cookie.
2.Authentification auprès d'un serveur RADIUS : principe de vérification de
nom d'utilisateur et de mot de passe.
3.Authentification auprès d'un serveur LDAP : principe de serveur d'annuaire.
L'authentification auprès d'un serveur CAS est le suivant :
15
Figure 2.5 : Principe de l'authentification sur CAS.
Le navigateur contactant la passerelle mais n'étant pas authentifié (1) est redirigé
(2) vers le serveur d'authentification CAS (3). Alors l’utilisateur saisi via une
interface Web son login et mot de passe. Si ceux-ci sont corrects alors le serveur
CAS attribut un ticket de service ST (4) au navigateur qui contacte à nouveau la
passerelle talweg (5) en lui transmettant le ticket de service.
La passerelle contacte alors CAS (6) afin de vérifier la validité de
l'authentification. Si l'authentification est confirmée par CAS (7), alors la
passerelle sait que l'utilisateur est reconnu et correctement authentifié. Elle
dépose alors sur le navigateur un cookie de session TWG (8).
Une session est également créée et sera utilisée pour stocker les cookies et les
certificats transmis par les sites distants.
c) Wifidog
Wifidog est un logiciel libre fonctionnant à la fois sur des serveurs

d'authentification et, grâce à un logiciel de portail captif embarqué, sur une base
sans-fil. Cette architecture distribuée permet d'offrir un service de portail
captif gratuit tout en réduisant les coûts par nœuds installés au minimum. Chaque
nœud supplémentaire nécessitant un investissement juste de l'achat de
l'équipement. Le portail captif WifiDog est utilisé par les communautés sans fil de
New York, Paris, Québec, Berlin... Une dizaine d'autres endroits dans le monde
évaluent en ce moment le logiciel.
La consommation en ressource réseau est extrêmement faible, et la bande
passante demandée est donc très faible. La raison de ce faible coût en bande
16
passante est l'utilisation d'Iptables pour définir les règles de filtrages qui sont
contrôlées par Wifidog. Une fois la communication établie il y a beaucoup moins
d'informations qui circulent sur le réseau. Wifidog consomme également très peu
de ressources système.
Figure 2.6: portail d’authentification Wifidog

L'interface de connexion de Wifidog est le suivant. Il permet une identification
via login/mot de passe.
Figure 2.7 : portail d’accueil Wifidog

Voici l’interface, une fois connectée, qui stipule toutes les informations en ce qui
concerne la connexion.
d) Chillispot
Chillispot est un portail captif qui établit un tunnel HTTPS (HyperText

Transfert Protocol Secured). Il faut installer un serveur HTTPS (Apache), le
configurer pour qu'il soit à l'écoute du port 443/TCP. En effet, dès que le client
va vouloir se connecter à Internet, Chillispot enverra une redirection HTTP vers le
programme CGI* d'authentification sur le serveur sécurisé. Ce programme
récupère le login/mot de passe de l'utilisateur et demande au serveur Radius
central l'autorisation d'accès. Si celle-ci est fournie, Chillispot laisse passer la
connexion vers le site Internet demandé. Une fois authentifié, Chillispot laisse
passer tous les paquets réseau. Il est nécessaire de configurer le pare-feu du
portail captif pour qu'il ne laisse passer que ce que l'on veut. Ceci est possible
grâce à Netfilter, le composant du noyau Linux supportant les pare-feux. Très
puissant et assez facile à configurer, il permet de créer un pare-feu performant
17
avec état, dit à suivi de connexion.
Chillispot fonctionne entre deux réseaux : le réseau privé (où les ordinateurs se
retrouvent avant l'authentification) et le réseau public qui donne sur Internet. Le
programme s'appuie sur les fonctionnalités de routage de Linux pour faire
transiter les paquets. Il s'agit d'un routage avec une translation d'adresse ou
NAT (Network Address Translation) puisque la classe interne n'est pas routable.
Le principe de la translation NAT est que chaque paquet est corrigé à la volée en
fonction de son adresse IP source : la translation NAT remplace l'adresse source
à l'envoi du paquet par une adresse externe. Lorsque le retour de paquet arrive, la
translation NAT corrige l'adresse destination avant de renvoyer le paquet vers sa
finalité.
La validation de fonctionnement doit confirmer le passage du mot de passe en
mode crypté pendant l'authentification. Elle doit aussi confirmer qu'une
authentification est bien nécessaire pour accéder au réseau et qu'une fois la
connexion établie, les communications autorisées sont en clair.
Il est possible également par l'intermédiaire du firewall (iptables) de limiter
l'utilisation de certains ports.
Figure 2.8: Agencement des points d’accès
La bande passante est divisée par deux lors de l'utilisation de Chillispot, mais
reste tout à fait à un niveau acceptable avec un taux de transfert de 960 ko/s en
moyenne.
Il semble qu'une baisse de performances se ressent du fait de la consommation en
ressources matérielles de Chillispot sur le WRT54G. On constate donc que
Chillispot est grand utilisateur en temps CPU lors d'activité sur le réseau.
e) Public IP
Ce système est capable d’offrir, outre l’accès authentifié (ou non) à

l’Internet, un serveur proxy, un filtre de contenu et un serveur web/DHCP/cache
DNS. Seuls 128 Mo de mémoire vive sont requis pour l’installation et la gestion de
l’accès. C’est une interface web classique qui permet à l’administrateur de gérer
18
les accès à l’Internet après authentification sur le portail : création, suppression,
suspension et filtres pour le web (ce qui comprend par exemple le blocage de
certains ports, notamment ceux utilisés par les logiciels de messagerie
instantanée). L’interface d’accès peut être personnalisée, le hotspot peut donc
être par exemple multilingue.
f) MonoWall
MonoWall est un projet visant la création d'un système de firewall complet

qui peut-être utilisé sur un PC. Son important lot de paquetage lui procure une
sécurité accrue. Basé sur FreeBSD4, il intègre toutes les fonctionnalités des
firewalls professionnels vendus sur le marché.
Figure 2.9 : Architecture MonoWall
Voici l'architecture de MonoWall qui est celle d'un hotspot classique et qui est en
fait un logiciel que l'on peut décrire comme un pare-feu-routeur. Les avantages de
cette solution sont basés sur une administration autonome en local, de diverses
fonctionnalités et sur le fait que ce projet est toujours évolutif, car encore
développé.
g) Bilan
On peut voir sur ces comparatifs que chaque solution comporte des avantages
et des inconvénients. De manière à effectuer un choix, il faut définir un cahier
des charges bien précis et la spécificité de chacune des solutions sera mise en
œuvre en pesant le pour ou le contre selon les cas.
2. Pourquoi Chillispot?
Le portail captif choisi est Chillispot, disponible sur http://www.chillispot.info/. Ce

portail captif permet l'authentification/accounting auprès d'un serveur Radius en
19
natif, mais supporte surtout un tunnel HTTPS pour faire transiter les identifiants
de l'utilisateur. De cette façon, les pirates éventuels ne peuvent pas récupérer le
mot de passe de l'utilisateur en écoutant le réseau. Par contre, une fois
l'utilisateur connecté, la connexion sera non cryptée.
La plupart des portails captifs, comme NoCat, utilisent le protocole HTTP pour
transmettre le mot de passe. Ils ne sont plus acceptables dans un environnement
de sécurité.
Le serveur Web utilisé pour la communication HTTPS est Apache car c'est celui
qui est le plus massivement utilisé dans le monde, tout en supportant toutes les
technologies comme les CGI*, et le protocole HTTPS. Facile d'installation, les
fichiers de configuration sont très lisibles et les documentations sur le site Web
sont très bien écrites. Notre choix, même si ce projet nous l'impose, aurait donc
été tourné vers la solution de portail captif Chillispot.
3. Intégration de Chillispot en environnement universitaire
La procédure d'accès au réseau sans fil mis en place se fera de la manière

suivante:
Tout d'abord, le client choisira le SSID du hotspot wifi de l'IUT, et se

connectera à ce réseau via sa machine Windows, Linux ou Mac.
Figure 2.10 : Screenshot Wifi
L'utilisateur devra récupérer une adresse IP de manière dynamique. Celle-ci sera

donc fournie par le hotspot Chillispot.
20
Il faudra vérifier que l'IP soit bien donné de manière dynamique (comme sur la
figure au dessus).
L'utilisateur devra ensuite ouvrir un navigateur web, télécharger le certificat

fourni automatiquement et verra pour cela une fenêtre comme celle-ci apparaître :

Dans certains cas, il aura le message suivant et devra le passer pour se connecter
en cliquant sur OK:
21
Le client sera ensuite automatiquement redirigé vers la page html
d'authentification de Chillispot. Il devra alors entrer son login et son mot de passe
de manière à se connecter.
Figure 2.14 : Screenshot Chillispot
Si le login est bon, il pourra alors surfer sur Internet en gardant la pop-up de
Chillispot bien ouvert.
Figure 2.15 : Screenshot Google
22
Chapitre 3: Réalisation du Projet
1. Analyse du Cahier des Charges et de ses contraintes
Accès au web
On veut que les étudiants puissent accéder uniquement à du contenu Web. Il

est donc nécessaire d’effectuer un filtrage au niveau de la couche réseau.
Parallèlement, on veut que toute demande d’accès au web passe par le système
d’authentification du portail, d’où la dénomination “captif”.
23
Authentification
L’infrastructure Wifi sera répartie sur tout le périmètre de l'IUT de

Blagnac. Toute personne présentant une requête d'accès à Internet (professeur,
étudiant, conférencier) au service en charge du réseau informatique peut se voir
donner l'accès à Internet.
Restriction temporelle
On ne veut pas de connexions permanentes sans vérification régulière de

l’identité de celui qui est connecté, pour des raisons évidentes de sécurité et
d'utilisation à la ressource. Il faut donc avoir un système qui scrute chaque
connexion et demande une réauthentification si le temps imparti est écoulé.
Journalisation
On va devoir garder pendant un certain temps les informations de connexion

suivantes :
– qui accède à la ressource

– quand elle y a accédé
– la quantité de données reçue/émise
– destinataire de la connexion
– protocoles utilisés afin de pouvoir diagnostiquer de meilleure façon les
problèmes liés aux abus ou simplement les problèmes techniques.
2. Présentation de l'architecture
L'architecture physique initiale décidée avec M. MANSALIER c'est révélée être

la suivante:
Figure 3.1 : Architecture physique initiale
24
Nous avons donc réalisé une maquette dont l'architecture logique est la suivante:
Figure 3.2 : Architecture réseau logique
Afin de ne pas se heurter aux problèmes d'architecture du réseau de l'IUT,

nous avons décidé de simuler l'accès à internet par un serveur Apache installé
dans une machine virtuelle.
Comme demandé dans la proposition, nous avons aussi installé le portail captif
Chillispot dans un environnement virtualisé avec la distribution Ubuntu. Nous avons
donc installé la machine virtuelle dédiée à la simulation de ressource web et la
machine virtuelle intégrant le portail captif sur la même machine physique. Nous
avons opté pour que le dialogue entre les deux machines virtuelles s'effectue en
utilisant un réseau virtuel nommé VMNet4.
La liaison entre le portail et l'AP Aironet utilise l'autre interface Ethernet du
poste physique.
Une fois l'architecture logique décidée, nous avons établi l'adressage de la

maquette. Nous avons donc créé dans un premier temps un réseau local en
192.168.1.0/24 pour accueillir les postes clients sans-fil, puis dans un second
temps un réseau en 10.0.0.0/24 représentant la connexion à Internet.
25
Figure 3.3 : Adressage de la maquette
3. Matériel requis
La mise en place d’un portail captif Chillispot requiert un serveur possédant

deux cartes réseau. L’une d’entre elle se trouve du côté LAN IUT (le segment
réseau relié à Internet) et la deuxième du côté Wifi. Dans la mesure du possible,
et suivant le trafic prévu, il conviendra d’installer des cartes réseaux rapides
(10/100/1000Mbps) et de prévoir le câblage en conséquence (catégorie 5e, voire
catégorie 6). En effet, tout le trafic transitera par cette machine et cette
dernière constituera un goulot d’étranglement si le matériel n'est pas adapté aux
besoins.
D’un point de vue hardware, la machine ne nécessitera pas des ressources

importantes (Chillispot tourne sur des routeurs équipé de CPU cadencés à 200
MHz et très peu de RAM).
Dans notre situation, la machine physique au centre de l'architecture devra être
tout de même relativement puissante du fait que celle-ci doit héberger deux
machines virtuelles fonctionnant en simultanée. L'une d'elle nécessite le
fonctionnement d'un serveur Apache, un serveur d'authentification Radius ainsi
qu'un serveur de gestion de base de données, ce qui entraîne un besoin de
ressource matériel plus important. Ainsi cette machine virtuelle consommera au
minimum 256 Mo de mémoire vive pour assurer un bon fonctionnement du portail
captif. La deuxième machine n'étant destinée qu'à simuler une ressource Web,
celle-ci n'héberge qu'un serveur Apache et donc n'engendre qu'une faible
consommation en mémoire vive et puissance processeur.
Un poste d'une puissance de 3Ghz, équipé de 768 Mo de RAM avec comme

utilisation 8 Go de disque dur pour héberger les deux machines virtuelles nous a
suffit pour réaliser notre maquette.
26
Enfin, nous utiliserons un point d'accès Cisco Aironet 1130AG, pour desservir les
utilisateurs.
4. Conception générale
a) Rôle de l'interface tun
Avant toute chose, il est nécessaire d'expliquer comment s'intègre

Chillispot dans l'architecture logique de la maquette. Celui-ci est tout d'abord
composé d'un démon qui prend le contrôle de l'interface interne eth1 en utilisant
le module "vtun Kernel" pour mettre en place une interface virtuelle tun0. Dans les
faits, le module vtun kernel est utilisé pour déplacer les paquets de données du
mode kernel vers le mode usager de façon à ce que Chillispot puisse fonctionner
avec toutes sortes de modules hors normes. Sa première utilité est donc
d'intercepter tous les paquets arrivant sur Eth1 et de les soumettre à Chillispot.
On pourrait comparer son fonctionnement au mode "Promiscuous" qui est
généralement utilisé pour écouter le trafic réseau.
Figure 3.4 : Intégration de l'interface tun
b) Affectation d’adresse IP
Lorsqu'un client se connecte au réseau sans-fil celui-ci reçoit une adresse

Ip dynamique. Cela est possible du fait que Chillispot embarque un serveur DHCP
qui agit sur l'interface tun.
Ainsi tout client qui envoie une requête DHCP sur cette interface reçoit une
adresse IP allouée dynamiquement dans le réseau 192.168.182.0/24 (ce réseau
peut être changé dans le fichier de configuration de Chillispot "chilli.conf").
27
Figure 3.5 : Choix de capture des interfaces
Figure 3.6 : Capture sur Eth1
On voit ainsi que le serveur DHCP embarqué par Chillispot répond à la requête
faite par le client et lui affecte une adresse IP dans le réseau spécifié dans la
configuration de Chillispot.
Figure 3.7 : Attribution d'adresse par DHCP
c) Interception et demande d’accréditation
Une fois le client intégré au réseau, celui-ci peut se retrouver dans deux
états, « authentifié » et « non authentifié ». Un client « non authentifié »
28
essayant d'accéder à une page Internet va avoir sa connexion TCP interceptée par
le démon Chillispot. Ici cette page est simulée par le serveur Apache de la machine
simulant la ressource web accessible à l'adresse 10.0.0.1. Ayant intercepté la
connexion du client, Chillispot va usurper l'identité du destinataire du paquet et va
envoyer au poste client des paquets avec comme adresse source 10.0.0.1. Cela
permet ainsi à Chillispot de rediriger le client vers un script CGI* ou PHP hébergé
par un Serveur Apache sécurisé (SSL), où il lui est demandé un login et un mot de
passe.
Figure 3.8 : Interception et redirection vers le formulaire
Dans la figure précédente, le client fait sa requête d'accès et c'est l'interface

tun0 qui va répondre au client (1) en le redirigeant vers le poste 192.168.182.1 qui
va lui présenter le formulaire d'authentification (2).
Figure 3.9 : Formulaire d'authentification
29
d) Méthode d’authentification
L'architecture permettant l'authentification du client est constituée de quatre

acteurs qui effectuent des tâches complémentaires et indispensables entre elles.
Figure 3.10 : Architecture d'authentification
Après soumission des identifiants, ceux-ci sont cryptés et renvoyés à Chillispot en

utilisant la session SSL.
Figure 3.11 : Echange d'identifiant entre Chillispot et le client
Chillispot envoie un message "access-request" au serveur RADIUS en utilisant la

méthode "CHAP-Challenge" et "CHAP-Password" pour présenter les identifiants,
30
comme spécifié dans la RFC 2865.
Puis Chillispot adresse un message "accounting-request" au serveur RADIUS en
utilisant la même méthode (CHAP*) pour vérifier l'accounting du client (paramètre
de journalisation, respect du crédit, facturation).
Figure 3.12 : Requête envoyée par le démon Chillispot à FreeRadius
L'interface locale sert à faire transiter les informations d'authentification client

entre le démon Chillispot et le serveur Radius.
Figure 3.13 : Dialogue entre le démon Chillispot et Freeradius par l'interface de boucle
locale
Le serveur RADIUS reçoit ainsi les deux requêtes d'authentification et

d'accounting.
Figure 3.14 : Requête d'accès au réseau provenant de Chillispot
31
Figure 3.15 : Requête d'accounting provenant de Chillispot
Grâce à des requêtes SQL, FreeRadius extrait et compare les identifiants

reçus avec ceux contenus dans la base de données. Si l'authentification réussit
(comparaison positive), le serveur Radius retourne un message "accept-accept" et
une liste des ressources accessibles. L'état du client change en "authentifié" et
est autorisé à accéder aux ressources définies lors de l'acceptation. Le serveur
Radius va alors notifier quand la session débute ou se termine. Toutes les
informations de la session sont journalisées dans la base de données MySQL. C'est
l'accounting.
Figure3.16 : Session d'authentification à l'aide de requête SQL
Figure 3.17 : Session de journalisation à l'aide de requête SQL
32
e) Transmission de paquets d’un client authentifié
Une fois que le client est authentifié, Chillispot autorise le trafic provenant
du poste de celui-ci, réceptionné par l'interface tun0.
Figure 3.18 : Etat de tun0 après authentification
Pour router les paquets entre tun0 et eth0, la translation d'adresse IP ainsi que
l'Ip-forwarding* sont activés dans le noyau. Grâce à des règles du pare-feu
Iptables, on autorise seulement le trafic arrivant de l'interface contrôlée par
Chillispot à être redirigé vers eth0 et le trafic interne aux différents acteurs de
l'authentification à transiter par la boucle locale.
Nous allons maintenant étudier le contenu du fichier contenant les règles

Iptables:
#!/bin/sh
#
# Firewall script for Chillispot
On attribue à chaque variable l'interface associée. Les objectifs de ce script sont

les suivants:
 Toutes les connexions provenant de Chillispot sont autorisées
 Le protocole SSH est le seul protocole autorisé sur l'interface externe (eth0)
 Rien n'est autorisé sur l'interface interne (eth1)
 La redirection entre interface est autorisée pour les paquets provenant ou à
destination de l'interface externe, mais refusée pour les paquets ayant un
rapport avec l'interface interne.
 La translation d'adresse est activée sur l'interface externe.
IPTABLES="/sbin/iptables"
EXTIF="eth0"
INTIF="eth1"
33
Les politiques par défaut:
 On interdit tous les paquets en direction de la passerelle, destinés à celle-ci.
 On autorise toute sortie de paquets en sortie des interfaces de la machine. On
autorise toute redirection de paquets d'une interface à une autre
$IPTABLES -P INPUT DROP

$IPTABLES -P FORWARD ACCEPT
$IPTABLES -P OUTPUT ACCEPT
Autorise sur l'ensemble des interfaces tous les paquets dont la connexion a déjà
été établie.
$IPTABLES -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
Autorise sur l'interface externe, les paquets d'établissement de connexion dont

le protocole est TCP sur le port utilisé par SSH.
$IPTABLES -A INPUT -i $EXTIF -p tcp -m tcp --dport 22 --syn -j ACCEPT
On rejette tout autre paquet arrivant sur l'interface externe.

$IPTABLES -A INPUT -i $EXTIF -j REJECT
Le schéma ci-dessous résume l'ensemble des règles appliquées pour les

communications externes:
Figure 3.19 : Règles de communications externes
On rejette tout paquet arrivant sur l'interface interne à destination de celle-ci.
34
$IPTABLES -A INPUT -i $INTIF -j DROP

communications utilisant l'interface Eth1:
Figure 3.20 : Règles de communications utilisant l’eth1
Si la machine où tourne le démon Chillispot contient aussi le portail

d'authentification web (qu'il soit en http ou https) alors les deux règles suivantes
doivent être appliquées. Ces règles s'appliqueront alors à l'interface virtuelle
tun0.
$IPTABLES -A INPUT -p tcp -m tcp --dport 80 --syn -j ACCEPT
-9++++++++++++++++++Autorise les paquets arrivants sur tun0 utilisés pour

l'authentification sur la page web chillispot.
Le schéma ci-dessous résume l'ensemble des règles appliquées pour gérer les flux
nécessaires à l'affichage du portail web permettant l'identification de clients.
Figure 3.21 : Règles de gestion de flux du portail web d’authentification.
35
Autorise tout le trafic passant par la boucle locale utilisé pour le transit
d'informations entre les différents acteurs. Cette règle autorise dans notre cas
l'envoi des identifiants entre le démon Chillispot et le serveur Radius.
$IPTABLES -A INPUT -i lo -j ACCEPT
Rejette tous les paquets provenant ou à destination de l'interface interne (eth1)

destinés à être redirigés sur une autre interface que celle où ils sont arrivés. De
ce fait, tout transite entre l'interface eth0 et tun0.
$IPTABLES -A FORWARD -i $INTIF -j DROP
$IPTABLES -A FORWARD -o $INTIF -j DROP
Active le Source NAT sur l'interface externe eth0 pour pouvoir transmettre et
recevoir sur Internet.
$IPTABLES -t nat -A POSTROUTING -o $EXTIF -j MASQUERADE
f) Gestion d’une session authentifiée
Afin de pouvoir contrôler les clients ayant une accréditation ou non pour
accéder à Internet, un pop-up HTML muni d'un cookie de session est ouvert sur le
poste client et son navigateur est redirigé vers l'URL demandée initialement ou
inconditionnellement vers une autre URL paramétrable.
Figure 3.22 : Phase d'authentification, d'autorisation et d'utilisation
Le contenu du pop-up est rafraîchi à intervalle régulier attestant de la

présence et de l'activité de l'utilisateur. À chaque rafraîchissement, le cookie de
session est rejoué sur le portail captif et sa validité est vérifiée : le cookie
36
présenté est-il celui généré initialement pour ce poste ? (Test d'usurpation), le
cookie présenté correspond-il à une session en cours ? La présence du pop-up lors
de la phase d'utilisation normale est illustrée par la figure suivante :
Figure 3.23 : Pop-up d'authentification
Au moindre « défaut » de ce cookie de session, l'utilisateur est automatiquement

déconnecté et doit donc repasser par la phase de redirection initiale pour se
réauthentifier.
g) Déconnexion d’une session authentifiée
Une session utilisateur peut prendre fin par :
• la déconnexion explicite par l'utilisateur (bouton de logout dans le pop-up) ;
• la détection par le portail Chillispot de l'inactivité du pop-up (Idle-timeout) :

l'utilisateur a quitté son navigateur ou fermé le pop-up, le poste client s'est
déconnecté du réseau (portable fermé) ;
• une limite inconditionnelle qui déconnecte tout utilisateur, actif ou non, au delà
d'une certaine durée de connexion (Session-timeout), pour éviter les connexions «
infinies » ;
• Un défaut de vérification du cookie de session utilisateur (tentative

d'usurpation...).
Ces deux limites (Idle et Session timeout) sont renseignées à la création de
37
l'utilisateur dans la base de données MYSQL et sont donc fonction de chaque
utilisateur.
Pour toute requête web par un client ayant été déconnecté celui-ci verra sa
requête interceptée par tun0 et redirigé de nouveau vers la page du portail
d'authentification.
h) Interface d’administration
La solution Chillispot n'offre pas d'interface d'administration d'origine.

Nous avons dû rechercher une interface compatible avec le système d'information
employé par FreeRadius. Un module appelé FreeRadius-DialupAdmin est disponible
dans les dépôts de la distribution Ubuntu. Une fois testée, il s'est avéré que cette
interface était quelque peu limitée et très difficile à prendre en main. C'est
pourquoi, nous nous sommes penchés sur une interface beaucoup plus élaborée mais
qui a le défaut de ne plus être développée et demandant une installation pointue.
PhpRadmin offre une interface web aux administrateurs de l'établissement

leur permettant de visualiser les configurations et l'activité des utilisateurs sous
forme de graphiques, d'historiques et de compteurs.
Cette application écrite en php et utilisant divers scripts se base sur Dialup-
Admin pour offrir un contrôle complet sur la base de données MySQL. On peut de
ce fait, facilement gérer les opérations sur les profils des utilisateurs (ajout,
suppression, modification du profil,..), créer des groupes afin de gérer plus
facilement un ensemble de clients.
De plus, PhpRadmin utilise le protocole SNMP afin de remonter des statistiques
sur l'utilisation des ressources et RRDtool afin de tracer des graphiques.
38
Figure 3.24 : Graphiques sur l'utilisation du portail captif
Pour finir, cette dernière solution intègre des dictionnaires propres à chaque
solution de portail captif (Chillispot, WISP, Nocat) permettant l'ajout de
paramètres pour une utilisation plus approfondie (limite de réception, d'envoi,
limite par semaine, ...).
i) Evolution de la solution
En résumé, voici la liste synthétique des possibilités d'évolution du projet:
 Passage à l'échelle:
L'architecture choisie pour intégrer cette solution de portail captif permet une
extension facile de la zone de couverture Wifi. En effet, l'utilisation d'un
commutateur connecté sur la carte réseau locale de la passerelle captive autorise le
39
branchement de multiples points d'accès Aironet sans qu'aucune configuration sur ces
points d'accès ne soit nécessaire. Néanmoins cette architecture n'a pas été pensée
pour gérer la montant en charge des demandes d'accès aux ressources. Toutes les
requêtes des différents points d'accès sont gérées par une seule machine et de ce
fait, la montée en charge des demandes s'en retrouve vite limitée. Pour résoudre ce
problème, il est préférable d'employer des points d'accès embarquant la solution de
portail captif et de définir plusieurs serveurs d'authentification FreeRadius. En
faisant cela, on répartit la charge sur les différents serveurs rendant le système
hautement disponible et on créé de la redondance en évitant un point de
centralisation dans le système.
 Changement de système d'information:
La solution Chillispot peut s'adapter à plusieurs type de système d'information

pour effectuer des requêtes d'authentification. Dans notre cas, nous avons utilisé le
couple FreeRadius-MYSQL mais il est aussi possible de recourir à une
authentification par annuaire en utilisant FreeRadius-LDAP.
 Changement d'interface d'administration:
Comme nous l'avons abordé dans la partie précédente, la gestion des

utilisateurs est facilitée par l'emploi d'une interface d'administration. Le choix est
laissé à l'administrateur et dépend des nécessités et de l'utilisation du portail captif.
Pour une solution de portail captif à but commercial, celui-ci pourra se tourner vers
une interface telle que PhpMyPrepaid qui offre une ergonomie dans la gestion de
clients (notion de crédit). Si le portail captif reste un simple moyen d'allouer de la
ressource de manière authentifié, Dialup-Admin est l'interface privilégiée car celle-ci
est disponible dans les dépôts de la distribution Ubuntu et facile d'installation.
Après avoir testé ces deux interfaces, nous avons voulu pousser plus loin l'utilisation
de l'interface d'administration et nous sommes tombés sur un projet appelé
PhpRadmin qui se voulait être une interface très aboutie malgré son arrêt de
développement.
CONCLUSION
Alors que dans la plupart des études réalisées sur les portails captifs, chaque
solution est testée pour définir laquelle est la plus adaptée, nous avons fait le choix
d'effectuer une étude comparative théorique de l'existant en sachant déjà la solution
qui allait être adoptée. De cette étude, résulte un nombre important de solutions avec
des fonctionnalités spécifiques à chacune. Ces initiatives s'inscrivent en général dans
40
des projets du "monde libre" qui regroupent une communauté active. Ces solutions ne
sont pas figées et sont donc amenées à évoluer ce qui rend très certainement cette
étude comparative temporaire.
La réalisation d'un cahier des charges a permis de recenser les besoins de

l'IUT de Blagnac et d'élaborer une maquette, spécifiant ainsi les points à développer.
Du fait de sa modularité, chaque composant a pu être configuré de façon à rendre la
solution la plus souple possible. Différentes topologies pouvant être réalisées selon la
nécessité, cela implique une installation minutieuse et poussée. Une description
approfondie du mécanisme du portail captif permet de remédier à cette difficulté,
c'est pourquoi une partie importante du projet a été d'effectuer cette étude de
fonctionnement.
Une attention toute particulière a été portée sur la gestion du système

d'information. En effet, le fonctionnement général de la solution, et notamment la
sécurité, est entièrement dépendante des règles établies par l'administrateur réseau.
De ce fait, nous avons voulu rendre la plate-forme de gestion des utilisateurs la plus
ergonomique et la plus fonctionnelle possible. C'est pourquoi notre jugement de
prendre une interface offrant une prise en main facile et offrant une gestion des
utilisateurs la plus avancée qu'il nous a été donné de tester a prévalu sur le fait que
cette même interface n'était plus développée et qu'il nous a fallu la débugger pour la
rendre fonctionnelle.
Si le portail captif n'est pour l'instant pas intégré à l'architecture définitive,

son installation pourra être réalisée de façon succincte en réalisant quelques
modifications dans les règles de pare-feu et dans le fichier principal de Chillispot. Le
projet a aussi été porté dans le futur notamment sur une possible utilisation intensive
du portail et des solutions alternatives ont été envisagées. Par manque de temps, nous
n'avons pu tester la fonctionnalité de ces solutions alternatives et cela pourra faire
l'objet d'une suite à ce projet.
ANNEXES
41
TABLE DES MATIÈRES
1. Bibliographie
2. Tableau récapitulatif des installation
3. Installation de VMware Server
4. Création et configuration de la machine virtuelle
5. Installation d'Ubuntu virtualisé
42
6. Adressage et activation de l'ip forwarding*
7. Installation de PhpRadmin
8. Installation de MYSQL
9. Installation de FreeRadius
10. Test de l'authentification
11. Intégration MYSQL dans FreeRadius
12. Installation et configuration de Chillispot
13. Installation d'Apache sécurisé (SSL)
14. Configuration d'Iptables
15. Configuration de l'interface PhpRadmin
43
CREATION ET CONFIGURATION Durée : 20 min
Etape 2
DE LA MACHINE VIRTUELLE Difficulté : Intermédiaire
BIBLIOGRAPHIE
 Comparatif de portails captifs : http://www.gerthoffert.net/wiki/index.php?

title=Accueil
o Date de visite : 04/08
 Site officiel de Chillispot : http://chillispot.info/

o Date de visite : 12/07-03/08
 Installation de Chillispot sur Debian : http://www.pervasive-

network.org/SPIP/Installation-de-chillispot-sur-une
 Wiki FreeRadius : http://wiki.freeradius.org/Main_Page

 Projet d'application Wi-Fi : http://enseignement.ensi-

bourges.fr/projets/afficher_fichier.php?nom_fichier=279_PA-Wifi-Stalter-Sobesto.pdf
 Intégration de MYSQL dans FreeRadius : http://frontios.com/freeradius.html

44
Etape 2
Présentation :
Le logiciel Vmware est un système permettant sur une même machine physique
de créer des machines virtuelles afin de simuler des environnements de tests ou
construire des environnements de production. Il existe plusieurs types de systèmes
de virtualisation chez Vmware, qui remplissent des objectifs différents. Nous nous
attacherons ici à décrire uniquement les principes de fonctionnement du logiciel
gratuit Vmware Server.
Cette présentation est construit autour de la version Windows, et nécessite un
système d'exploitation de type XP pour être réalisé.
Afin d'obtenir cette version gratuite, il est nécessaire de se rendre sur la page de
téléchargement de VMware : http://www.vmware.com/download/server/
Lors de l'installation, une clé d'activation est demandée. Pour cela, il est nécessaire
de s'enregistrer sur la page : http://register.vmware.com/content/registration.html
afin de récupérer une clé d'activation.
Une fois cette clé récupérée, il ne reste plus qu'à lancer l'installation :
En choisissant l'installation complète, un module appelé « Vmware Management
Interface » va être installé et nécessite IIS pour fonctionner correctement.
VMware Management Interface est une interface Web de gestion qui permet de
visualiser l’état des machines virtuelles. Il est aussi possible de démarrer, arrêter ou
mettre en pause les machines. Enfin une vue détaillée de chaque machine permet de
voir l’état mémoire ou CPU, le nombre d’utilisateurs connectés.
45
Etape 2
N'ayant nullement besoin de cette fonction par la suite, nous choisirons de n'installer
ni IIS, ni le module « Vmware Management Interface ».
Après avoir choisi le répertoire d'installation, l'interface nous avertit que l' « auto-
run » peut avoir des effets inattendus sur le fonctionnement des machines virtuelles.
Nous choisirons donc de désactiver l'auto-run pour plus de sûreté.
L'installation terminée nous pouvons commencer à créer et configurer la machine

virtuelle qui accueillera le portail captif Chillispot.
Nous décidons donc de créer une nouvelle machine virtuelle avec une configuration
basique car dans notre cas une configuration avancée n'a pas d'utilité et peut être
configurée par la suite si besoin.
46
Etape 2
Afin que la machine virtuelle puisse

accueillir le système d'exploitation et l'installer, nous devons renseigner quel type de
système d'exploitation il s'agit ainsi que sa version (ici, nous prendrons une
distribution Ubuntu) afin de pouvoir simuler le système de fichier qui correspondrait
le mieux (ext3 dans notre cas).
Puis il est primordiale d'indiquer le nom de la machine virtuelle de façon à ce qu'on

puisse connaître sa fonction principale (serveur, client, test,...). Il est aussi possible
de modifier le chemin du dossier où seront stocker les fichiers de la machine
virtuelle.
Nous choisirons de ne pas configurer l'interface réseau tout de suite car les
possibilités de l'assistant sont trop restrictives. Nous choisirons donc l'option "Do
not use a network connexion" et nous configurerons la partie réseau de la machine
virtuelle ultérieurement.
Afin de garantir une stabilité du système virtualisé ainsi que de bonnes performances,
nous déciderons de laisser la taille de l'image du système virtualisé à 8 go.
Après avoir cliqué sur "Terminer" la

machine virtuelle est créée.
Il faut maintenant configurer les paramètres de réseaux virtuels en allant dans

Host>Virtual Network Settings. Dans l'onglet "Host Virtual Network Mapping", nous
définirons que pour atteindre le réseau Vmnet 2(reliant la machine virtuelle à
Internet), toute machine virtuelle utilisera la première carte réseau "Intel(R)
47
Etape 2
PRO/1000 MT Network Connection". Pour atteindre le réseau Vmnet 3 (le réseau de

desserte WiFi), ces mêmes machines virtuelles devront utiliser la carte "Generic
Marvell Yukon Chipset base"
Il faut maintenant configurer plus en détails la machine virtuelle sur les ressources à
utiliser pour son fonctionnement. Pour ce faire, il faut cliquer sur "Edit this virtual
machine". Notre portail captif ne demande pas plus de 256 Mo de RAM, ce qui est la
valeur que nous lui attribuerons.
La deuxième étape consiste à ajouter deux cartes réseaux virtuelles qui pointeront
chacune soit vers Vmnet2 ou Vmnet4 (donc soit en utilisant la carte réseau Intel ou
soit en utilisant une carte virtuelle présente sur le réseau virtuel 4 pour faire la
liaison avec la machine virtuelle simulant Internet).
48
Etape 2
Puis on réeffectue cette étape en choisissant le Vmnet 1 pour la deuxième carte

réseau.
Le résumé de la machine doit être similaire à cette configuration :
49
Etape 2
Après avoir inséré le cédérom d'Ubuntu, il ne reste plus qu'à lancer la machine
virtuelle en cliquant sur la commande « Power on this virtual machine ».
50
INSTALLATION D’UBUNTU Durée : 20 min
Etape 3
VIRTUALISE Difficulté : Débutant
Le cédérom se lance automatiquement et le « boot menu » s'affiche. On changera la

langue (par la touche F2) en « français » pour une meilleure compréhension des
questions posées et on lancera Ubuntu en sélectionnant la première instruction.
Ubuntu ayant finis de charger ses principaux modules dans la mémoire vive, nous nous
occupons de l'installation à proprement dit. Les trois premières étapes concernent le
paramétrage linguistique. Ainsi, nous laisserons les paramètres tels quels concernant
la langue et le fuseau horaire.
L'assistant nous invite ensuite à lui indiquer sur quelle partition le système devra être
installé. Nous choisirons donc d'installer le système sur la partition virtuelle SCSI3
qui est la partition créée par Vmware.
Après cela, nous devons renseigner différentes informations nécessaires à

l'identification du principal utilisateur ainsi qu'à l'identité du poste.
51
INSTALLATION D’UBUNTU Durée : 20 min
Etape 3
VIRTUALISE Difficulté : Débutant
Enfin, une fenêtre récapitulative nous informe des principaux choix qui ont été
effectués lors du paramétrage de l'installation.
Le bouton « Installer » lance donc la procédure d'installation du système virtualisé.
Lors de l'installation, le système cherche un accès internet pour télécharger la

version la plus récente des paquets. Si l'accès internet n'est pas possible, il est
conseillé de continuer l'installation car la mise à jour du système peut être faite
ultérieurement. Lorsque l'installation est achevée, l'assistant propose un redémarrage
de la machine, ce que nous acceptons.
Après redémarrage, il est préférable de configurer le mot de passe administrateur
pour pouvoir effectuer les manipulations d'installation et de configuration en toute
liberté.
52
ADRESSAGE IP ET ACTIVATION DE L'IP Durée : 10 min
Etape 4
FORWARDING Difficulté : Débutant
La première étape avant toute installation de logiciel est de configurer les

interfaces de la passerelle qui retransmettra les requêtes web des clients vers
Internet. Dans notre cas, la carte de marque Intel (appartenant au Vmnet2)
correspond à l'interface eth0 dans la machine virtuelle. Cette carte ethernet est
reliée au modem de l'IUT sur le réseau 10.0.0.0/24 utilisé pour rejoindre Internet.
Nous décidons d'adresser l'IP 10.0.0.2/24 à cette interface eth0. La carte Broadcom
est alors représentée par l'interface eth1. Cette carte, reliée au point d'accès WiFi,
est censée desservir le trafique pour les utilisateurs. Nous lui adresserons l'IP
192.168.0.2 .Nous obtenons ainsi le schéma de configuration suivant :
Pour configurer les interfaces réseaux de façon permanente, il faut éditer le fichier
/etc/network/interfaces comme ci-dessous:
Après avoir vérifié que la passerelle arrive bien à communiquer avec les équipements
auquel elle est connectée, il faut mettre en place le mécanisme d'IP Forwarding. Ce
mécanisme, désactivé par défaut sur Ubuntu, permet à la passerelle de transmettre
les requêtes des clients vers le routeur internet.
Pour activer ce mécanisme il suffit de changer l'état du bit du module réseau

ip_forward par la commande:
echo 1 > /proc/sys/net/ipv4/ip_forward
53
ADRESSAGE IP ET ACTIVATION DE L'IP Durée : 10 min
Etape 4
FORWARDING Difficulté : Débutant
En effectuant ce changement de bit, cela active l'IP_fowarding uniquement durant la

session réseau actuelle. Cela implique que si un redémarrage du réseau a lieu, le
mécanisme sera de nouveau désactivé.
Pour empêcher cela, il faut indiquer dans le fichier "sysctl.conf" qui est lu par le
système avec le chargement des modules réseaux d'activer le mécanisme. La
commande est déjà présente dans le fichier mais elle est commentée. Il suffit donc
de la décommenter :
Pour être assuré de la continuité du trafic, il est préférable d'effectuer un test à

partir du poste client.
54
Durée : 5 min
Etape 5 INSTALLATION DE PHPRADMIN Difficulté : Débutant
Avant d'installer FreeRadius et MYSQL qui sont les acteurs principaux dans
l'authentification d'utilisateurs, nous allons récupérer et installer PhpRadmin qui
contient la structure de la future base de données.
PhpRadmin est téléchargeable sur le site officiel (www.phpradmin.org) et directement

sur le lien (http://prdownloads.sourceforge.net/phpradmin/phpradmin-0.01-pre-
alpha1.tar.gz?download)
Une fois téléchargé, nous allons installer le package :
55
Durée : 5 min
Etape 6 INSTALLATION DE MYSQL Difficulté : Débutant
Dans un premier temps, il convient d'installer MYSQL (server et client) qui

servira à stocker la base de données utilisateurs.
root@chillispot-server:/home/chillispot# apt-get install mysql-server mysql-client
Durant l'installation, il nous est demandé de spécifier le mot de passe administrateur

pour accéder à MYSQL en utilisant le compte "root".
Nous prendrons le mot de passe "chillispot" pour le compte root.
56
Durée : 5 min
Etape 7 INSTALLATION DE FREERADIUS Difficulté : Débutant
Présentation :
Radius (Remote Authentication Dial-In User Service) est un système qui fait de
« l'AAA » (Authentication, Authorization and Accounting). Utilisé depuis longtemps
par bon nombre de fournisseurs d'accès à l'internet pour authentifier leurs clients et
leur communiquer une configuration IP, RADIUS va être utilisé dans notre cas pour
gérer l'accès des utilisateurs au portail captif.
Dans ce sous-chapitre chapitre, nous verrons comment installer et configurer

un serveur RADIUS libre. FreeRadius fonctionne initialement en s'appuyant
uniquement sur des fichiers texte. Ce n'est pas forcément ce qu'il y a de plus simple à
gérer, si l'on doit manipuler un grand nombre de clients. Ici, nous utiliserons MySQL
pour stocker les éléments d'authentification ainsi que les informations sur chaque
profil utilisateur. Outre la souplesse qu'apportent des outils comme PhpMyAdmin pour
gérer la liste des clients, cette solution offre l'avantage de ne pas nécessiter de
redémarrage de FreeRADIUS à chaque modification de la base.
Il faut tout d'abord installer Freeradius ainsi que le module additionnel freeradius-
mysql permettant qui permet l'utilisation d'une base de données MYSQL comme
source d'authentification:
root@chillispot-server:/home/chillispot# apt-get install freeradius freeradius-mysql
57
Durée : 15 min
Etape 8 TEST DE L’AUTHENTIFICATION Difficulté : Intermédiaire
Avant de configurer Freeradius pour qu'il utilise MYSQL, il est judicieux de le tester
dans sa configuration initiale. Pour cela, nous allons créer un utilisateur qui
s'authentifiera localement, que nous allons déclarer à la fin du fichier
/etc/freeradius/users:
testuser1 Auth-Type := Local, User-Password == "testsecret"
Nous avons créé un utilisateur "testuser1" avec le mot de passe "testsecret".

Nous décidons aussi de changer le mot de passe utilisé pour chiffrer les données
d'authentification entre le NAS et le serveur Radius. Cela s'effectue dans le
fichier /etc/freeradius/clients.conf:
Pour tester l'authentification de l'utilisateur testuser1 nous allons utiliser le module

de test de Freeradius mais il est au préalable nécessaire de désactiver le daemon
Freeradius qui est lancé, puis de lancer FreeRadius en mode "debug":
58
Durée : 15 min
Etape 8 TEST DE L’AUTHENTIFICATION Difficulté : Intermédiaire
On remarque que le serveur radius écoute les demandes d'authentification sur le port
1812 et les demandes d’accounting sur le port 1813.
On lance le test d'authentification du côté client :
Celui-ci est accepté.
Et du côté serveur on assiste à l'envoie du message d'acceptation de l'utilisateur:
S'étant assurés que l'authentification FreeRadius par fichier de données fonctionne

correctement nous allons maintenant créer la base de données MYSQL qui va contenir
toute la structure de gestion des futurs clients WiFi.
59
INTEGRATION MYSQL DANS Durée : 25 min
Etape 9
FREERADIUS Difficulté : Intermédiaire
La première étape consiste à créer une base de données que nous nommerons
"phpradmin":
Puis nous allons construire la structure de la base grâce à un fichier contenant toutes
les requêtes SQL. Pour cela nous allons afficher le contenu du fichier et rediriger la
sortie directement vers MYSQL:
Pour que Freeradius puisse accéder à la base de données dont il va se servir pour
authentifier les clients nous allons créer un compte utilisateur MYSQL.
60
Etape 9
Nous devons indiquer à Freeradius d'utiliser une source MYSQL pour

l'authentification et la gestion des comptes. Pour cela, il faut décommenter le terme
"sql" des parties "authorize", "accounting", "session" et commenter le terme "file" de
ces mêmes parties du fichier /etc/freeradius/radiusd.conf:
authorize {
preprocess
chap
mschap
suffix
eap
#files
sql
}
authenticate {
Auth-Type PAP {
pap
}
Auth-Type CHAP {
chap
}
Auth-Type MSCHAP {
mschap
}
eap
}
accounting {
detail
unix
radutmp
sql
}
session {
sql
}
Par ces modifications, on indique à Freeradius d'utiliser MYSQL et non plus des
fichiers comme source.
Il faut maintenant lui indiquer le profil qu'il va utiliser pour accéder à la base
61
Etape 9
"radius". Cela est configuré dans le fichier /etc/freeradius/sql.conf:
Afin de tester que les paramètres précédents ont bien été pris en compte, nous allons
créer un utilisateur dans la base "radius" (en utilisant le profil MYSQL de
Freeradius).
Puis on réeffectue la procédure d'authentification en utilisant le module "radtest".
Démarrage du serveur d'authentification :
On remarque que du côté du serveur celui-ci s'appuie maintenant sur la base

"phpradmin"
62
Etape 9
L'authentification se fera en présentant l'utilisateur "mysqltest" qui aura comme mot

de passe "testsecret" sur le serveur hébergé localement en utilisant un chiffrement
dont la clé est "radiussecret".
On voit que le serveur radius a bien accepté l'utilisateur:
La configuration du serveur d'authentification FreeRadius est enfin terminée.
63
INSTALLATION ET Durée : 10 min
Etape 11
CONFIGURATION DE CHILLISPOT Difficulté : Débutant
Le logiciel Chillispot se compose de deux modules : hotspotlogin.cgi (un formulaire web

d'authentification) et du daemon chillispot qui joue le rôle de serveur DHCP en plus
d'intercepter les requêtes web des clients.
L'installation va demander les informations minimums pour le fonctionnement de

chillispot.
Nous informons ensuite la clé partagée pour le chiffrement des informations entre le
serveur radius et le démon chillispot. C'est le même mot de passe que nous avions
défini dans la partie locale du fichier clients.conf. Le mot de passe à spécifié est donc
"radiussecret".
L'interface eth1 est l'interface reliée au point d'accès WiFi en relation avec les
clients.
Il faut maintenant indiquer l'adresse de la page d'authentification à envoyer aux

clients pour qu'ils puissent s'identifier (appelé aussi uam).
64
Etape 11
On laissera le champ suivant vide. Ce champ prendra alors la valeur de l'adresse du

serveur UAM spécifiée précédemment.
On spécifie la clé partagée qui va être utilisé pour chiffrer la transmission de données
entre la page CGI chargé par le client et le démon chillispot qui va réceptionner les
informations. Nous utiliserons la clé "uamsecret".
65
Etape 11
On note que le portail captif est désactivé au démarrage du poste par défaut car une
mauvaise configuration de Chillispot lancé en daemon peut bloquer la console.
Il nous est aussi indiqué qu'un serveur radius doit être actif ainsi qu'un serveur UAM.
La configuration de Chillispot se fait dans son unique fichier de configuration :

/etc/chilli.conf
Le premier paramètre à modifier concerne la valeur du réseau sur lequel nous

accueillerons les clients WiFi. Ce réseau doit être différent de celui d'eth1 du fait
que ce réseau sera entretenu par l'interface tun0 gérée par Chillispot.
net 192.168.182.0/24
Il faut ensuite spécifier l'adresse du serveur DNS de l'IUT

dns1 192.168.100.2
Puis l'adresse du serveur radius que chillispot doit écouter :

radiuslisten 127.0.0.1
Le paramètre suivant concerne l'adresse du serveur radius auquel chillispot doit

envoyer les informations qu'il reçoit des clients Wi-Fi
radiusserver1 127.0.0.1
On ne spécifie pas les ports sur lequel chillispot envoie les requêtes
d'authentification car par défaut ce seront les ports 1812 et 1813 qui seront pris.
Spécifiez le secret partagé entre le serveur Radius et le daemon Chillispot. Ce secret

doit être le même que celui qui figure dans le fichier clients.conf du serveur Radius
radiussecret radiussecret
66
Etape 11
Donner l'interface à partir de laquelle le daemon Chillispot doit attribuer des

adresses IP. Cette interface est celle présente du côté du réseau WiFi.
dhcpif eth1
Indiquer ici, l'adresse sur laquelle les clients seront redirigés pour la demande
d'authentification. L'adresse IP ci-dessous correspond à l'adresse IP du serveur
UAM accessible depuis l'interface tun0. 192.168.182.1 est l'adresse par défaut que
Chillispot donne à l'interface virtuelle tun0.
uamserver https://192.168.182.1/cgi-bin/hotspotlogin.cgi
Préciser le secret partagé entre le daemon Chillispot et la page hotspotlogin.cgi

uamsecret chillispotsecret
Définisser l'adresse IP sur laquelle le daemon Chillispot écoute (interface tun)

uamlisten 192.168.182.1
Déclarer ici les adresses qui n'auront pas besoin d'authentification pour être
consultables. Ce sont les adresses en libres accès. Parmi elles, doit figurer
obligatoirement, l'adresse de la page d'authentification chillispot
uamallowed 192.168.182.1/24, 192.168.100.2
Lors de l'installation du paquet chillispot, la CGI propre à chillispot à été installée

dans /usr/lib/cgi-bin/. Cette CGI nommée hotspotlogin.cgi permet de générer
l'affichage du formulaire au client WiFi. La seule option à configurer dans ce script
est le secret partagé entre la CGI et le démon chillispot.
$uamsecret = "chillispotsecret"
67
INSTALLATION D'APACHE Durée : 20 min
Etape 12
SECURISE (SSL) Difficulté : Avancé
Pour sécuriser les données d'identification transitant entre le client et chillispot,

celui-ci demande obligatoirement l'utilisation d'une connexion chiffrée (https) pour
fonctionner. Nous devons donc dans un premier temps installer Apache2:
Nous allons renseigner que le serveur tourne localement sur la machine. Pour cela il
faut ajouter la ligne "ServerName 127.0.0.1" dans le fichier /etc/apache2/httpd.conf
Pour que le protocole SSL puisse fonctionner avec le Serveur HTTP Apache2, il faut
activer le module SSL avec la commande:
La commande "apache2-ssl-certificate" n'existe plus sous Feisty Fawn. Nous allons

donc générer le certificat SSL grâce à OpenSSL.
sudo openssl req -x509 -nodes -days 365 -newkey rsa:1024 -out
/etc/apache2/server.crt -keyout /etc/apache2/server.key
Explications :
 -x509 -nodes donne le type de certificat voulu
 -days 365 indique la durée de validité (en jours) de votre certificat
 -newkey rsa:1024 demande une clé RSA de 1024 bits - d'après la doc apache, il
est déconseillé de créer une clé plus grosse pour des histoires de compatibilité
 -out /etc/apache2/server.crt est le chemin de votre certificat
 -keyout /etc/apache2/server.key est le chemin de la clé privée
68
Etape 12
Une fois le certificat généré, on vérifie bien dans le fichier /etc/apache2/ports

qu'Apache2 écoute bien sur le port 443:
Afin d'héberger le CGI nous allons créer un "VirtualHost" en lui indiquant le

certificat afin de permettre la sécurisation de la communication avec le client.
Pour configurer notre hôte virtuel, nous allons créer un fichier de configuration
nommé "chillispot" dans le répertoire /etc/apache2/sites-enabled/
Il faut ensuite importer cette configuration d'hôte virtuel dans la configuration

Apache2 par la commande a2ensite:
69
Etape 12
Dans notre cas, dès la création du fichier Chillispo,t celui-ci a été intégré à la
configuration d'Apache2.
Pour finir il faut supprimer le fichier 000-default du même dossier pour ne pas qu'il
n'y ait pas de conflits dans la configuration. Enfin, l'application de toutes ces
manipulations demande le redémarrage d'Apache2 :
Enfin pour vérifier que le serveur Apache2 fonctionne correctement on peut exécuter
la commande suivante:
70
Durée : 10 min
Etape 13 CONFIGURATION D'IPTABLES Difficulté : Débutant
Il est indispensable pour le bon fonctionnement du portail captif de disposer

d’un certain nombre de règles IPTABLES, notamment des règles de translations mais
également des règles bloquantes.
Dans toute configuration de firewall, la règle absolue est de bloquer tout, puis
d’autoriser seulement ce que l’on souhaite. C’est ce qui est fait dans le fichier
"firewall.iptables" que l'on peut trouver dans le répertoire de documentation
/usr/share/doc/chillispot/.
Nous allons tout d'abord copier cet ensemble de règles dans le dossier
"/etc/network/if-pre-up.d/" qui est un dossier où les scripts contenus à l'intérieur
sont lancés automatiquement avant chaque démarrage d'une interface réseau. Mais
pour que les scripts fonctionnement, il faut respecter quelques règles :
- Ils doivent être exécutables (chmod +x)

- Ils doivent Indiquer l’interpréteur de commande sur la première ligne (ex :
# !/bin/sh)
- Le nom ne doit contenir que des caractères, chiffres, ’_’ et ’-’ (Pas de points)
Nous devons donc rendre le fichier exécutable et le renommé car le nom par défaut
comprend un point.
Nous allons maintenant étudier le contenu du fichier :
#!/bin/sh
#
# Firewall script for ChilliSpot
# A Wireless LAN Access Point Controller
On attribue à chaque variable l'interface associée. Les objectifs de ce script sont les
suivants :
 Toutes les connexions provenant de chillispot sont autorisées
 Le protocole SSH est le seul protocole autorisé sur l'interface externe (eth0)
 Rien n'est autorisée sur l'interface interne (eth1)
 La redirection entre interface est autorisée pour les paquets provenant ou à
destination de l'interface externe, mais refusée pour les paquets ayant un rapport
avec l'interface interne.
 La translation d'adresse est activée sur l'interface externe.
# Uses $EXTIF (eth0) as the external interface (Internet or intranet) and

# $INTIF (eth1) as the internal interface (access points).
#
71
Durée : 10 min
#
# SUMMARY
# * All connections originating from chilli are allowed.
# * Only ssh is allowed in on external interface.
# * Nothing is allowed in on internal interface.
# * Forwarding is allowed to and from the external interface, but disallowed
# to and from the internal interface.
# * NAT is enabled on the external interface.
IPTABLES="/sbin/iptables"
EXTIF="eth0"
INTIF="eth1"
Les politiques par défaut:

 On interdit tous les paquets en direction de la passerelle, destinés à celle-ci.
 On autorise toute sortie de paquets en sortie des interfaces de la machine.On
autorise toute redirection de paquets d'une interface à une autre
$IPTABLES -P INPUT DROP

$IPTABLES -P FORWARD ACCEPT
$IPTABLES -P OUTPUT ACCEPT
Autorise sur l'ensemble des interfaces tous les paquets dont la connexion a déjà été
établie.
#Allow related and established on all interfaces (input)
$IPTABLES -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
Autorise sur l'interface externe, les paquets d'établissement de connexion dont le

protocole est tcp sur le port utilisé par SSH.
#Allow releated, established and ssh on $EXTIF. Reject everything else.

$IPTABLES -A INPUT -i $EXTIF -p tcp -m tcp --dport 22 --syn -j ACCEPT
On rejette tout autre paquet arrivant sur l'interface externe.
$IPTABLES -A INPUT -i $EXTIF -j REJECT

communications externes :
72
Durée : 10 min
#Allow related and established from $INTIF. Drop everything else.

$IPTABLES -A INPUT -i $INTIF -j DROP

communications utilisant l'interface Eth1:
Si la machine où tourne le daemon chillispot contient aussi le portail

d'authentification web (qu'il soit en http ou https) alors les deux règles suivantes
doivent être appliquées. Ces règles s'appliqueront alors à l'interface virtuelle tun0
#Allow http and https on other interfaces (input).

#This is only needed if authentication server is on same server as chilli
Autorise les paquets arrivants sur tun0 utilisés pour l'authentification sur la page
web chillispot.
#Allow 3990 on other interfaces (input).
73
Durée : 10 min
Le schéma ci-dessous résume l'ensemble des règles appliquées pour gérer les flux
nécessaires à l'affichage du portail web permettant l'identification de clients.
Autorise tout le trafique passant par la boucle locale utilisé pour le transite
d'informations entre les différents acteurs. Cette règle autorise dans notre cas
l'envoi des identifiants entre le démon Chillispot et le serveur RADIUS.
#Allow everything on loopback interface.
$IPTABLES -A INPUT -i lo -j ACCEPT
Rejette tous les paquets provenant ou à destination de l'interface interne (eth1)

destinés à être redirigés sur une autre interface que celle où ils sont arrivés. De ce
fait, tout transite entre l'interface eth0 et tun0.
# Drop everything to and from $INTIF (forward)

# This means that access points can only be managed from ChilliSpot
$IPTABLES -A FORWARD -i $INTIF -j DROP
$IPTABLES -A FORWARD -o $INTIF -j DROP
Active le Source NAT sur l'interface externe pour pouvoir transmettre la requête
sur locale sur Internet.
#Enable NAT on output device

$IPTABLES -t nat -A POSTROUTING -o $EXTIF -j MASQUERADE
74
Afin de pouvoir gérer les comptes des utilisateurs utilisant l'accès Wi-Fi, nous utiliserons
la solution PhpRadmin qui est l'interface php, que nous avons précédemment extraite dans
le dossier /usr/local/phpradmin/. Cette interface permet d'administrer les différentes
tables de la base de données utilisées par le serveur FREERADIUS, afin d'obtenir des
statistiques concernant les connexions utilisateurs ainsi que leur état. Elle donne aussi la
possibilité d'appliquer des règles pour certains profils (limitation, interdictions de certains
protocoles,...).
L'interface PhpRadmin est écrite en php4, donc il faut en premier lieu installer php dans sa
version la plus récente (php5) dans une optique d'utilisation avec MYSQL.
Il faut de plus, installer les programmes qui vont permettre la réalisation de graphique
ainsi que la réception de statistiques sur le réseau. Pour cela, nous allons récupérer
RRDtool et SNMP dans les dépôts de la distribution et les installer :
Durée : 10 min
L'interface PhpRadmin intègre un assistant d'installation, mais il est nécessaire

d'effectuer quelques opérations au préalable du fait que cette interface a été développée
pour PHP4 et donc que certaines opérations de l'assistant ne pourront être exécutées.
Il faut tout d'abord créer un profil permettant à l'interface d'interagir avec la base de
données utilisateurs :
Lors de l'installation par l'assistant une erreur apparaît lors de l'attribution des privilèges
au profil phpradmin car l'assistant a été réalisé sous php4, c'est pourquoi on supprimera
une partie du script, les opérations étant faites postérieurement.
Nous éditerons donc le fichier /usr/local/phpradmin/www/install/setup.php vers les lignes

523:
76
Durée : 10 min
Il faut maintenant configurer Apache pour que celui-ci prenne en compte l'interface. Pour
cela, il suffit d'effectuer la manipulation suivante:
Il est nécessaire de relancer Apache2 par la commande "/etc/init.d/apache2 reload"
On configure ensuite le fichier général de dialupAdmin concernant l'accès à la base de

données ainsi que certains paramètres annexes.
general_prefered_lang: en
general_prefered_lang_name: English
general_charset: iso-8859-1
general_base_dir: /usr/local/phpradmin/www/include/dialup_admin
general_radiusd_base_dir: /usr/sbin/
general_domain: phpradmin.org
general_use_session: no
general_most_recent_fl: 50
general_strip_realms: no
general_realm_delimiter: @
general_realm_format: suffix
general_show_user_password: yes
general_raddb_dir: /etc/freeradius
general_ldap_attrmap: /etc/freeradius/ldap.attrmap
general_clients_conf: /etc/freeradius/clients.conf
general_sql_attrmap: /usr/local/phpradmin/conf/dialup_admin/conf/sql.attrmap
general_accounting_attrs_file: /usr/local/phpradmin/conf/dialup_admin/conf/accounting.attrs
77
Durée : 10 min
general_extra_ldap_attrmap: /usr/local/phpradmin/www/include/dialup_admin/conf/extra.ldap-attrmap
general_lib_type: sql
general_user_edit_attrs_file: /usr/local/phpradmin/conf/dialup_admin/conf/user_edit.attrs
general_sql_attrs_file: /usr/local/phpradmin/conf/dialup_admin/conf/sql.attrs
general_default_file: /usr/local/phpradmin/conf/dialup_admin/conf/default.vals
general_finger_type:
general_nas_type: other
general_snmpfinger_bin: /usr/local/phpradmin/conf/dialup_admin/bin/snmpfinger
general_radclient_bin: /usr/bin/radclient
general_test_account_login: test
general_test_account_password: testpass
general_radius_server: localhost
general_radius_server_port: 1812
general_radius_server_auth_proto: chap
general_radius_server_secret: radiussecret
general_auth_request_file: /usr/local/phpradmin/www/include/dialup_admin/conf/auth.request
general_encryption_method: clear
general_accounting_info_order: desc
general_stats_use_totacct: no
general_restrict_badusers_access: no
general_caption_finger_free_lines: free lines
ldap_server:
ldap_write_server:
ldap_base:
ldap_binddn:
ldap_bindpw:
ldap_default_new_entry_suffix:
ldap_default_dn:
ldap_regular_profile_attr:
ldap_use_http_credentials:
ldap_directory_manager:
ldap_map_to_directory_manager:
ldap_debug:
ldap_filter:
ldap_userdn:
sql_type: mysql
sql_server: localhost
sql_port: 3306
sql_username: phpradmin
sql_password: passwordpra
sql_database: phpradmin
sql_accounting_table: radacct
sql_badusers_table: badusers
sql_check_table: radcheck
sql_reply_table: radreply
sql_user_info_table: userinfo
sql_groupcheck_table: radgroupcheck
sql_groupreply_table: radgroupreply
sql_usergroup_table: usergroup
sql_total_accounting_table: totacct
78
Durée : 10 min
sql_nas_table: nas
sql_command: /usr/bin/mysql
general_snmp_type: net
general_snmpwalk_command: /usr/bin/snmpwalk
general_snmpget_command: /usr/bin/snmpget
sql_debug: false
sql_use_user_info_table: true
sql_use_operators: true
sql_password_attribute: User-Password
sql_date_format: Y-m-d
sql_full_date_format: Y-m-d H:i:s
sql_row_limit: 50
sql_connect_timeout: 3
sql_extra_servers:
counter_default_daily: none
counter_default_weekly: none
counter_default_monthly: none
counter_monthly_calculate_usage: false
INCLUDE: /usr/local/phpradmin/conf/dialup_admin/conf/naslist.conf
INCLUDE: /usr/local/phpradmin/conf/dialup_admin/conf/captions.conf
Les paramètres encadrés en rouge sont ceux qui doivent être changés dans le fichier
d'origine pour que l'interaction en FreeRadius et DialupAdmin soit possible.
On peut dès lors se rendre sur la page contenant l'assistant d'installation de PhpRadmin à
savoir, http://localhost/phpradmin .
Après avoir accepté le contrat de licence, il faut remplir le formulaire décrivant les
chemins des différents éléments logiciels que va utiliser PhpRadmin:
79
Durée : 10 min
Pour poursuivre l'assistant, il est nécessaire d'affecter certains droits sur des dossiers
afin que l'interface puisse écrire dans le journal et puisse configurer les fichiers de
configuration en respectant les paramètres entrés précédemment dans le formulaire.
Pour résoudre ces problèmes de droit :
80
Durée : 10 min
On peut ainsi continuer vers la prochaine étape qui est la configuration à l'accès à la base
de données utilisateurs.
Mot de passe:
passwordpra
Pour l'étape suivante, le choix est laissé à l'administrateur concernant ses identifiants.
Un récapitulatif des opérations s'affiche alors:
81
Durée : 10 min
La dernière page de l'assistant indique les dernières manoeuvres à suivre afin de pouvoir
bénéficier de toutes les fonctionnalités de l'interface.
82
Durée : 10 min
Il faut savoir que les conseils de commandes ci-dessus ont été écrits pour une distribution
Fedora et sont pour la plupart, différentes sur Ubuntu:
83
Durée : 10 min
1.
2. La première ligne de déclaration des scripts est à changer comme ci-dessous:
Il faut rendre ces scripts exécutables:
3. Certains scripts doivent être lancés au démarrage de la machine tel que le script
"log_badlogins". Pour cela on applique la manipulation suivante:
4. Pour permettre à PhpRadmin d'écrire dans le journal principal afin de créer un

historique des actions, il faut déclarer le propriétaire du dossier contenant les logs pour
que l'interface puisse écrire dans les logs:
En cliquant sur le lien "interface" de la page, on arrive sur la page d'authentification de
84
Durée : 10 min
PhpRadmin.
Il faut donc suivre les instructions du portail afin de garantir la sécurité de l'interface.
Une fois authentifié, on a accès à l'interface pour gérer le portail captif et les
utilisateurs.
Néanmoins, lors de création d'un profil utilisateur, le script utilisé pour la création de
celui-ci dans la base de données utilise un opérateur ":=", alors que quand FreeRadius
effectue son test d'authentification il effectue sa requête avec un opérateur "==". Afin de
pallier ce problème il faut éditer le fichier
/usr/local/phpradmin/www/include/dialup_admin/lib/sql/create_user.php3 :
85
Durée : 10 min
On peut ainsi créer des profils utilisateur grâce à l'interface de PhpRadmin
De nombreux paramètres sont disponibles alors qu'ils n'étaient pas présents dans Dialup-
86
Durée : 10 min
Admin. Les paramètres les moins explicites sont détaillés lorsque l'on clique dessus.
Nous avons aussi décelé un défaut de programmation dans la rubrique Options>"Radius
Server". Malgré la spécification de l'emplacement où est installé FreeRadius, aucun fichier
de configuration propre à FreeRadius n'est recueilli.
Pour rétablir ce bug, il faut éditer le fichier

/usr/local/phpradmin/www/include/phpconfig-freeradius/cls_phpconfig.php:
Enfin, il faut rendre le dossier /etc/freeradius/ lisible par l'interface PhpRadmin par
87
Durée : 10 min
l'instruction:
chmod o+r /etc/freeradius
De plus, nous avons remarqué que le passage de php4 vers php5 posait problème dans
l'affichage de la rubrique "Global Stats"
.
Nous avons retouché le code en particulier la composition de la variable $timest afin que le
serveur Apache puisse afficher la valeur résultante.
Extrait du code du fichier functions.php3 posant problème. :
88
Durée : 10 min
Extrait du code après modification:
Il faut relancer le serveur Apache2 pour que les modifications de l'interface soient prises
en comptes:
89
Durée : 10 min
root@chillispot-server:/# /etc/init.d/apache2 restart
On observe que le formulaire permettant de spécifier la période des statistiques ainsi que
d'autres paramètres s'affiche convenablement grâce aux modifications des fonctions php.
Ajout du paramètre de limite de téléchargement
Par défaut, PhpRadmin ne permet pas la gestion d’une limite de téléchargement en entrée
ou en sortie. Cette option est très intéressante pour limiter les utilisateurs utilisant le
hotspot pour du téléchargement massif. Pour cela, il est nécessaire de configurer les
options de dialup-admin afin d’ajouter ce paramètre.
La première chose à faire est de rendre le dictionnaire des paramètres pouvant être
ajoutés lisible pour l’interface PhpRadmin :
On va maintenant pouvoir ajouter ces paramètres de limite dans le formulaire de création

et d'édition de profil utilisateur.
90

Langue

Rapport Final Chillispot

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Rapport Final Chillispot

Titre original :

Transféré par

Droits d'auteur :

Formats disponibles

Institut Universitaire de

Mise en place d'un portail

Mise en place d'un portail

Luc MAYERHOFFER à l’attention de M.Gaël MANSALIER.

Aujourd'hui, la volonté de liberté de mouvements se fait de plus en plus

CGI : Un CGI (Common Gateway Interface) est un script classique (développé en

IP forwarding : Technique consistant à retransmettre sur un autre port réseau les

Iptables : Firewall IP développé par l’équipe Netfilter pour GNU/Linux.

CHAP : Challenge Handshake Authentication Protocol est un protocole

De plus en plus de personnes disposent aujourd'hui d'un appareil mobile

Ainsi il est nécessaire de mettre en place des systèmes d'authentification

Ainsi le système utilisé dans notre Université permettra d'authentifier les

Chapitre 1: Présentation du projet

Un portail captif est une structure permettant un accès rapide à Internet.

Lorsqu'un usager veut accéder à Internet, il va d'abord scanner* son

Cette page peut exiger de celui-ci:

 qu'il entre directement un identifiant et un mot de passe

Dans des installations de réseau publiques ou semi-publiques, les techniques de

Titre: Réalisation d'un portail captif basé sur Chillispot

Résumé du travail attendu:

 Etudier la technique du portail captif (Wifi-Hotspot)

Chapitre 2: Etude des différentes propositions

1. Tableau comparatif et analyse

Figure 2.1: Architecture NoCat

Le logiciel NoCat fournit 2 modules : authserv (serveur web d’authentification) et

Figure 2.2: portail d’authentification NoCat

- Possibilité de voler les droits d’accès d’un utilisateur (attaque), en spoofant le

- Usurper l’identité du hotspot pour récupérer les login/mot de passe des

On peut schématiser le principe de fonctionnement du portail captif de la

Figure 2.3 : Principe du portail captif.

Le schéma de la figure 2.4 détaille le principe des redirections que subit la

Figure 2.4 : Principe des redirections.

On voit qu'un utilisateur authentifié cherchant à contacter directement un site

Différents modes d'identification sont disponibles pour la solution Talweg :

L'authentification auprès d'un serveur CAS est le suivant :

Wifidog est un logiciel libre fonctionnant à la fois sur des serveurs

Figure 2.6: portail d’authentification Wifidog

Figure 2.7 : portail d’accueil Wifidog

Chillispot est un portail captif qui établit un tunnel HTTPS (HyperText

Figure 2.8: Agencement des points d’accès

Ce système est capable d’offrir, outre l’accès authentifié (ou non) à

MonoWall est un projet visant la création d'un système de firewall complet

Figure 2.9 : Architecture MonoWall

Le portail captif choisi est Chillispot, disponible sur http://www.chillispot.info/. Ce

3. Intégration de Chillispot en environnement universitaire

La procédure d'accès au réseau sans fil mis en place se fera de la manière

Tout d'abord, le client choisira le SSID du hotspot wifi de l'IUT, et se

Figure 2.10 : Screenshot Wifi

L'utilisateur devra récupérer une adresse IP de manière dynamique. Celle-ci sera

L'utilisateur devra ensuite ouvrir un navigateur web, télécharger le certificat

Figure 2.12 : Screenshot Wifi

Figure 2.14 : Screenshot Chillispot

Figure 2.15 : Screenshot Google

1. Analyse du Cahier des Charges et de ses contraintes

On veut que les étudiants puissent accéder uniquement à du contenu Web. Il

L’infrastructure Wifi sera répartie sur tout le périmètre de l'IUT de

On ne veut pas de connexions permanentes sans vérification régulière de

On va devoir garder pendant un certain temps les informations de connexion

– qui accède à la ressource

L'architecture physique initiale décidée avec M. MANSALIER c'est révélée être

Figure 3.1 : Architecture physique initiale