PFEbouabid PDF

République Tunisienne
Ministère de l’Enseignement Supérieur

et de la Recherche Scientifique
Université de Tunis El Manar
Institut Supérieur d’Informatique d’El Manar
Rapport de Projet de Fin d’Études
Présenté en vue de l’obtention du
Diplôme National de Licence Appliquée en Sciences Technologies

Spécialité : Administration des réseaux et services
Par
Talel BOUZAYENI et Maryem ABID
Mise en place d’un portail captif PfSense
Encadrant professionnel : Monsieur El Baldi FERID Ingénieur R&D

Encadrant académique : Monsieur Ben Gouissem BECHIR Maître Assistant
Réalisé au sein de Topnet
Année Universitaire 2018 - 2019

République Tunisienne
Ministère de l’Enseignement Supérieur

et de la Recherche Scientifique
Université de Tunis El Manar
Institut Supérieur d’Informatique d’El Manar
Rapport de Projet de Fin d’Études
Présenté en vue de l’obtention du
Diplôme National de Licence Appliquée en Sciences Technologies

Spécialité : Administration des réseaux et services
Par
Talel BOUZAYENI et Maryem ABID
Mise en place d’un portail captif PfSense
Encadrant professionnel : Monsieur El Baldi FERID Ingénieur R&D

Encadrant académique : Monsieur Ben Gouissem BECHIR Maître Assistant
Année Universitaire 2018 - 2019

J’autorise l’étudiant à faire le dépôt de son rapport de stage en vue d’une soutenance.
Encadrant professionnel, Monsieur El Baldi FERID
Signature et cachet
J’autorise l’étudiant à faire le dépôt de son rapport de stage en vue d’une soutenance.
Encadrant académique, Monsieur Ben Gouissem BECHIR
Signature
Dédicaces
A ma chére mére
A mon cher pére,

Qui n’ont jamais ceccé de formuler des priéres à mon égard et de me soutenir
pour que je puisse atteindres mes objectifs, que ce travail traduit ma gratitude
et mon affection
A mes soeurs YASMINE , RAJE , MALEK
Pour ses soutiens morales tout au long de mes études, que dieu les protége et
leurs offre la chance et le bonheur
A mon cher SLIM

Qui m’a aidé et supporté dans les moments difficiles,
A mon cher binome

Pour son indéfectibles soutiens et son patience infinie tout au long de ce projet
A mes chéres amies HAJER et HAFFAR

Pour leurs amours et leurs encouragements.
A toute ma famille ,
A tous mes autres ami(e)s ,
A tous ceux que j’aime et ceux qui m’aiment.
MARYEM Abid
ii
TALEL
Bouzayeni
iii
Remerciements
Je remercie
Je suis reconnaissant
J’exprime ma gratitude
iv
Table des matières
Introduction générale 1
1 Présentation du projet et Spécification des besoins : 2

1.1 Présentation de l’organisme d’accueil : . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.1 Organisme d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.2 Óbjectifs de l’entreprise : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Présentation du cadre du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.1 Description du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.2 Solution proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Spécification des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3.1 Sécurisation des accès Internet avec un portail captif . . . . . . . . . . . . . . 5
1.3.2 Authentification des utilisateurs . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3.3 Filtrage de trafic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2 Géneralités sur les portails captifs 7

2.1 Définition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2 Fonctionnement général des portails captifs . . . . . . . . . . . . . . . . . . . . . . . 9
2.3 Aperçu des principales solutions portails captifs . . . . . . . . . . . . . . . . . . . . 10
2.3.1 ALCAZAR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3.2 ZeroShell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3.3 ChilliSpot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3.4 PFsense . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.4 Comparaison des portails captifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.5 Choix de la solution de portail captif : PfSense . . . . . . . . . . . . . . . . . . . . . 13
2.6 Définition de PfSense : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.7 Aperçu des fonctionnalités et services de PFsense . . . . . . . . . . . . . . . . . . . . 14
2.7.1 Services complexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.7.2 Services simples : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
v
2.7.3 Surveillance du système ( Monitoring) : . . . . . . . . . . . . . . . . . . . . . 16
2.7.4 Portail captif : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.7.5 Les packages : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.8 Authentification des utilisateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.8.1 Définition du serveur FreeRadius : . . . . . . . . . . . . . . . . . . . . . . . . 19
2.9 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3 Réalisation 20
3.1 Architecture proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.2 Matériel et architecture réseau requis : . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.3 Configuration du Serveur DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.3.1 La configuration de l’interface WAN . . . . . . . . . . . . . . . . . . . . . . . 23
3.3.2 La configuration des interfaces LAN, OPT1, OPT2 . . . . . . . . . . . . . . 23
3.4 Configuration du FireWall (Rules) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.5 Installation et configuration de la solution Portail Captif . . . . . . . . . . . . . . . 25
3.5.1 Installation et configuration de FreeRadius : . . . . . . . . . . . . . . . . . . . 27
3.5.2 La Liaison de FreeRadius à la base de données MYSQL : . . . . . . . . . . . . 29
3.5.3 Configuration du portail captif : . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.5.4 Liaison du portail captif avec FreeRadius . . . . . . . . . . . . . . . . . . . . 31
3.5.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.6 Configuration de la base de donnée de type MYSQL : . . . . . . . . . . . . . . . . . 33
3.7 Conception et mise en place de l’interface d’inscription et d’authentification . . . . . 34
3.7.1 Analyse de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.7.2 Spécification des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.7.3 Les solutions trouvés et choisies . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.7.4 Conception de l’interface web ; . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.7.5 Développement de la solution : . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Bibliographie 48
Annexes 49
Annexe 1. Exemple d’annexe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
vi
4.1 Configuration de la base de donnée . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
vii
Table des figures
1.1 logoentreprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1 Procédure d’authentification par portail captif . . . . . . . . . . . . . . . . . . . . . 9
3.1 Architecture détaillée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.2 La spécification d’intervalle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.3 Le temps par défaut/maximale de Bail . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.4 Au niveau de l’interface LAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.5 Création de l’interface Authentification . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.6 Association des port à chaque serveur . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.7 Schéma explicative de fonctionnement du NAS . . . . . . . . . . . . . . . . . . . . . 28
3.8 Configuration du client NAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.9 La configuration de liaison entre le FreeRadius et la BD . . . . . . . . . . . . . . . . 29
3.10 Configuration du Idle/HARD timeout . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.11 Configuration de la bande passante . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.12 Autorisation du protocole HTTPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.13 Configuration du protocole PAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.14 Diagramme de séquence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.15 Capture du trafic au cours d’authentification ( Le portail utilise le port 8003 ) . . . . 32
3.16 Capture sur la table des utilisateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.18 Création de l’interface Accounting (1) . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.19 Création de l’interface Accounting (2) . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.20 Capture de l’ancienne interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.21 Schéma Explicatif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.22 Scénario d’exécution normale sans exceptions . . . . . . . . . . . . . . . . . . . . . . 38
3.23 Compatibilité de l’interface développé avec toute les types des terminaux . . . . . . 39
3.24 Aperçu complète de la nouvel interface . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.25 Schéma explicatif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.26 Aperçu du script JQuery AJAX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
viii
Table des figures
3.27 Schéma explicatif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

3.28 Structure des tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.29 L’envoie du numéro vérifié . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.30 la création du TOKEN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.31 Le code d’enchaînement de l’inscription . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.32 Extrait du code de la fonction resendToken () . . . . . . . . . . . . . . . . . . . . . 46
4.1 Télechargement de l’image ISO de GNS3 . . . . . . . . . . . . . . . . . . . . . . . . . 49

4.2 Lancement de l’installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.3 choix des logiciels a installer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.4 installation de WinPcap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.5 Fin de l’installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.6 Télechargement de l’image ISO de PfSense . . . . . . . . . . . . . . . . . . . . . . . . 52
4.7 Configuration de la RAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.8 Configuration des cartes réseaux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.9 Installation de PfSense . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.10 Affectation des interfaces réseaux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.11 Affectation d’une adresse IP à l’interface OPT1 . . . . . . . . . . . . . . . . . . . . . 55
4.12 L’interface de PfSense . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.13 Configuration de l’interface WAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.14 Configuration de l’interface LAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.15 Configuration de l’interface OPT1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.16 Configuration de l’interface OPT2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.17 Au niveau de l’interface WAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.18 Au niveau de l’interface LAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.19 Activation du service SSH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.20 Autorisation du protocole TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.21 Autorisation d’accès par le commentaire . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.22 Création d’un utilisateur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.23 Installation du packages FreeRadius . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.24 Installation réussite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
ix
4.26 Création de l’interface Accounting . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
4.27 Création de l’interface status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.28 Configuration du NAS Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.29 Liste des NAS Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.30 Récupération du fichier.sql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.31 Exécution du fichier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
4.32 Intégration freeRadius avec MySql (1) . . . . . . . . . . . . . . . . . . . . . . . . . . 66
4.33 Intégration freeRadius avec MySql (2) . . . . . . . . . . . . . . . . . . . . . . . . . . 67
4.34 Choix de l’interface a exploité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
4.35 Choix du mode d’authentification . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
4.36 Installation du paquet PDO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
4.37 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
x
Liste des tableaux
Tableau 1.1 Comparaison des solutions de portails captifs . . . . . . . . . . . . . . . . . 13
xi
Liste des abréviations
— GISI = Génie Informatique des Systèmes Industriels
— GLSI = Génie Logiciel et Systèmes d’Information
— GTR = Génie des Télécommunications et Réseaux
xii
Introduction générale
Selon les statistiques [1], le nombre d’internautes est en augmentation successive qui atteint 4
142 276 en (2011) .Ce qui impose une augmentation de l’offre des services Internet. En effet, la plupart
d’eux disposent d’un appareil mobile (Portable, Smartphone, ...) et souhaitent pouvoir accéder à
Internet 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 et plus
particulièrement les ressources Internet qui sont très limitées. Ainsi, il est nécessaire de mettre en
place des systèmes d’authentification sur ces réseaux qui doivent cumuler de multiples avantages.
Ces avantages sont entre autres : une compatibilité avec la majorité des appareils mobiles du marché,
une sécurité des échanges entre les clients et le reste du réseau, une plus grande transparence offerte
à l’utilisateur aussi bien lors de la phase d’authentification que lors de l’utilisation du réseau, une
réduction de l’impact au niveau des ressources matérielles et de la bande passante, etc. Face à ces
enjeux, le portail captif s’est imposé comme une solution fréquemment utilisée dans les points d’accès
payants ou non. Il peut se généraliser à tous les modes d’accès (sans-fil ou filaire) nécessitant un
contrôle d’accès.
Dans ce cadre ,Topnet dispose d’un réseau informatique dont la gestion se complique avec la
diversité et le nombre croissant des invités d’où la nécessité de mettre en place un portail captif. Ce
document synthétise nos travaux menés dans ce cadre et est organisé en trois chapitres. Le premier
chapitre de ce document présente la structure d’accueil, le thème d’étude ainsi que le contexte dans
lequel s’inscrit le stage. Le deuxième chapitre est consacré à l’étude générale des portails captifs
ainsi que l’étude technique de la solution choisie, et le troisième détaille la mise en œuvre pratique
et technique de notre solution.
1
Chapitre 1
Présentation du projet et
Spécification des besoins :
Plan
1 Présentation de l’organisme d’accueil : . . . . . . . . . . . . . . . . . . . 3
2 Présentation du cadre du projet . . . . . . . . . . . . . . . . . . . . . . . 4
3 Spécification des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Chapitre 1. Présentation du projet et Spécification des besoins :
Introduction
Ce chapitre a pour objectif la présentation de l’organisme d’accueil «TOPNET» et ses

différentes particularités , à savoir l’idée du projet et ses principales fonctionnalités ainsi que les
objectifs à atteindre. En plus, dans ce chapitre nous allons préciser tous les besoins rigoureux pour
sécuriser le réseau.
1.1 Présentation de l’organisme d’accueil :
1.1.1 Organisme d’accueil[2]
Figure 1.1: logoentreprise
TOPNET est une entreprise tunisienne qui offre l’accès internet en Tunisie au grand public
ainsi qu’au marché professionnel et ceci est garanti par un réseau d’agence commerciale pareillement
via un réseau possédant plusieurs distributeurs et un réseau de vente en ligne .
TOPNET fournit une vaste gamme de produits et de services :
• Des modes d’accès à internet ( mobile , ADSL ..) ;
• la permission de mise en place des serveurs à configuration personnalisée en plus des différentes
services et options tels que : pack sécurité, datacenter, cloud, parrainage etc . . . ;
• un bilan professionnel qui indique clairement les objectifs annoncés dans l’introduction et en
particulier ceux qui n’ont pu être atteints. Il présente et synthétise les conclusions partielles ;
1.1.2 Óbjectifs de l’entreprise :
En outre , l’entreprise TOPNET s’engage à accentuer sa place dans le marché en utilisant

une méthodologie précise et en adoptant certain objectifs . Elle cherche à assurer la satisfaction du
client en étant à son écoute et en répondant à ses espérances avec une rentabilité garantie, et ce,
à travers l’amélioration incessant de son fonctionnement interne. En plus elle offre constamment de
nouveaux produits et services qui obéissent aux demandes évolutifs de la clientèle.
3
1.2 Présentation du cadre du projet
Notre étude est réalisée dans le cadre d’un stage de fin d’étude en administration de réseau
informatique et services au sein de l’entreprise TOPNET. Elle consiste à dégager une solution de
portail captif Pfsense dans le but de sécuriser le réseau informatique de l’organisme et pour proposer
aux invités un sondage, une publicité, ou pour mettre en avant les promotions en cours .
1.2.1 Description du projet
Pour permettre aux usagers de profiter d’une connectivité à internet dans son sièges et
agences, TOPNET décide de mettre en place un service d’accès WiFi gratuit pour les invités afin
d’améliorer leur confort dans l’agence d’où la nécessité de l’utilisation du portail captif comme une
solution pour des buts de marketing ( proposer des sondages une publicité, ou pour mettre en avant
les promotions en cours.. ) et principalement pour la sécurité du réseau que l’accès libre ne le garantie
pas.
Le projet consiste à implémenter une architecture réseau basée sur :
• Points d’accès reliés à un réseau IP .
• Un ou plusieurs sites centraux pour la gestion des points d’accès et la concentration du trafic
(Wireless LAN Controllers)
• Un système d’authentification avec portail captif qui sera contrôlée par un administrateur
réseau dont ses fondamentales exigences sont :
— La solution fournie doit gérer les connexions des utilisateurs via différents terminaux
(Smartphone, tablette, ordinateur portable. . . ), en effet :
Un utilisateur se connecte autant de fois qu’il veut, mais la durée d’une connexion ne doit
pas dépasser 30 mn.
Elle doit assurer au moins cent (100) connexions à la fois avec un débit minimal de 4
Mbps.
— Cette solution doit être capable d’identifier chaque visiteur venant se connecter à son
réseau sans fil, d’enregistrer et de stocker ses données de connexion (compte de connexion,
Numéro de téléphone, adresse IP Publique, dates et heure , et durées des communications)
4
pour une durée d’un an. Cette obligation se traduit par la mise en place d’un système
d’archivage et de sauvegarde des fichiers journaux (logs).
1.2.2 Solution proposée
Le service proposé, devra permettre à toute personne équipée d’un appareil mobile (Smartphone,
tablette, ordinateur portable. . . ) d’accéder à Internet via un réseau sans fil. La prestation demandée
comprend :
• Un service de données permettant l’accès à internet avec un débit moyen par utilisateur exigé.
• La Couverture d’une zone urbaine par le service internet doit être assurée par la technologie
WiFi Outdoor d’où :
o La fourniture des équipements nécessaires (routeur, points d’accès, solution de stockage des
logs, etc.)
o La configuration et la mise en place des points d’accès.
1.3 Spécification des besoins
Dans cette partie, nous allons énumérer les besoins auxquels doit répondre à la topologies
pour sécuriser le réseau de l’entreprise.
1.3.1 Sécurisation des accès Internet avec un portail captif
Un portail captif est une application qui permet de contrôler l’authentification des utilisateurs
dans un réseau local qui souhaitent d’accéder à un réseau externe ( INTERNET). Quand un
utilisateur cherche à accéder à Internet pour la première fois, le portail captif l’impose de s’authentifier
pour recevoir son accès à l’aide d’une page web enregistrer localement sur le portail captif via un
serveur HTTP. Dès que l’utilisateur est authentifié, il utiliser son accès Internet pour une durée
déterminée par l’administrateur et à la fin de cette durée l’utilisateur va redemander ses identifiants
de connexions pour une autre session. Le but de l’implémentation de ce système est la limitation
des intrusions dans le réseau de l’entreprise. [3]
5
1.3.2 Authentification des utilisateurs
L’authentification est l’opération par laquelle le destinataire et /ou l’émetteur d’un message
s’assure de l’identité de son interlocuteur. l’authentification est une phases cruciale pour la sécurisation
de la communication. Les utilisateurs doivent pouvoir prouver leur identité à leurs partenaires de
communication et doivent également pouvoir vérifier l’identité des autres utilisateurs. L’authentification
de l’identité sur un réseau est une opération complexe, car les parties qui communiquent ne se
rencontrent pas physiquement lors de la communication. Un utilisateur malveillant peut ainsi intercepter
des messages ou emprunter l’identité d’une autre personne ou entité.
1.3.3 Filtrage de trafic
Le réseau informatique des entreprises est une entité importante qui offre des services diversifiés
et contient un nombre très grand d’équipements de type différent. Donc, pour mieux sécuriser ce
réseau, on a besoin d’utiliser des outils et mécanisme de filtrage de réseau comme les firewalls pour
limiter l’accès à des certains équipements. [4]
1.4 Conclusion
Dans ce chapitre nous avons présenté l’entreprise d’accueil ensuite nous avons procédé par
établir une étude du projet et une description sur notre solution ainsi que la spécification des besoins
de l’entreprise. Dans le prochain chapitre, nous allons présenter l’étude préalable des différentes
solutions à implémenter dans ta topologie .
6
Chapitre 2
Géneralités sur les portails captifs
Plan
1 Définition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2 Fonctionnement général des portails captifs . . . . . . . . . . . . . . . . 9
3 Aperçu des principales solutions portails captifs . . . . . . . . . . . . . 10
4 Comparaison des portails captifs . . . . . . . . . . . . . . . . . . . . . . . 12
5 Choix de la solution de portail captif : PfSense . . . . . . . . . . . . . . 13
6 Définition de PfSense : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
7 Aperçu des fonctionnalités et services de PFsense . . . . . . . . . . . . 14
8 Authentification des utilisateurs . . . . . . . . . . . . . . . . . . . . . . . 18
9 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Chapitre 2. Géneralités sur les portails captifs
Introduction
Aprés définir les besoins et le contexte du système .Il s’agit de choisir les meilleures solutions
dans le réseau de l’entreprise, les fonctionnalités les plus pertinentes et les différents mécanismes de
sécurité valables qu’on peut implémenter dans le réseau de l’organisme. Enplus, dans ce chapitre
nous allons préciser tous les besoins rigoureux pour sécuriser le réseau passant ensuite à l’étude
primitifs des solutions de sécurité offertes. Nous passons par la suite à l’étude de PFsense et ses
principaux services offertes.
2.1 Définition
Un portail captif est une application qui permet de gérer l’authentification des utilisateurs
d’un réseau local qui souhaitent accéder à un réseau externe (généralement Internet). Il oblige les
utilisateurs du réseau local à s’authentifier avant d’accéder au réseau externe. Lorsqu’un utilisateur
cherche à accéder à Internet pour la première fois, le portail capte sa demande de connexion grâce
à un routage interne et lui propose de s’identifier afin de pouvoir recevoir son accès. Cette demande
d’authentification se fait via une page web stockée localement sur le portail captif grâce au serveur
HTTP. Ceci permet à tout ordinateur équipé d’un navigateur web et d’un accès Wifi de se voir
proposer un accès à Internet.
Au-delà de l’authentification, les portails captifs permettent d’offrir différentes classes de

services et tarifications associées pour l’accès Internet (Par exemple : Wifi gratuit, filaire payant,
1 heure gratuite,...). Cela est obtenu en interceptant tous les paquets quelles que soient leurs
destinations jusqu’à ce que l’utilisateur ouvre son navigateur web et essaie d’accéder à Internet.
Lors de l’établissement de la connexion, aucune sécurité n’est activée. Cette sécurité ne sera active
que lorsque l’ordinateur connecté tentera d’accéder à Internet avec son navigateur web. Le portail
captif va, dès la première requête HTTP, rediriger le navigateur web afin d’authentifier l’utilisateur,
sans quoi aucune demande ne passera au-delà du serveur captif. Une fois l’utilisateur authentifié, les
règles de firewall le concernant sont modifiées et celui-ci se voit autorisé à utiliser son accès Internet
pour une durée fixée par l’administrateur. A la fin de la durée fixée, l’utilisateur se verra redemander
ses identifiants de connexions afin d’ouvrir une nouvelle sesdon.
8
Ce système offre donc une sécurité du réseau mis à disposition, il permet de respecter la
politique de filtrage web de l’entreprise grâce à un module proxy et permet aussi grâce à un firewall
intégré d’interdire l’accès aux protocoles souhaités.[4]
2.2 Fonctionnement général des portails captifs
Figure 2.1: Procédure d’authentification par portail captif
Le client se connecte au réseau par l’intermédiaire d’une connexion filaire ou au point d’accès
sans fil pour du wifi. Ensuite un serveur DHCP lui fournit une adresse IP ainsi que les paramètres de
la configuration du réseau. A ce moment-là, le client a juste accès au réseau entI lui et la passerelle,
cette dernière lui interdisant, pour l’instant, l’accès au reste du réseau. Lorsque le client va effectuer
sa première requête de type web en HTTP ou HTTPS, la passerelle le redirige vers une page web
d’authentification qui lui permet de s’authentifier grâce à un login et un mot de passe. Cette page
est cryptée à l’aide du protocole SSL pour sécuriser le transfert du login et du mot de passe. Le
système d’authentification va alors contacter une base de données contenant la liste des utilisateurs
autorisés à accéder au réseau.[5]
9
Enfin le système d’authentification indique, plus ou moins directement selon les portails
captifs, à la passerelle que le couple MAC/IP du client est authentifié sur le réseau. Finalement le
client est redirigé vers la page Web qu’il a demandé initialement ; le réseau derrière la passerelle lui
est dorénavant accessible. Le portail captif, grâce à divers mécanismes comme une fenêtre pop- up
sur le client rafraîchie à intervalles réguliers ou des requêtes ping vers le client, est en mesure de
savoir si l’utilisateur est toujours connecté au réseau. Au bout d’un délai d’absence sur le réseau, le
portail captif va couper l’accès à cet utilisateur.
2.3 Aperçu des principales solutions portails captifs
2.3.1 ALCAZAR
ALCASAR (Application Libre pour le Contrôle d’Accès Sécurisé et Authentifié au Réseau)

est un projet français essentiellement consacré aux fonctions de portail captif. Cet applicatif s’installe
via un script supporté par la distribution Linux Mandriva, les configurations se font via une ’interface
de gestion sécurisée (HTTPS) ou bien en mode console sur le Serveur Mandriva. Une sauvegarde
de la configuration est prise en charge via la création d’un ghost système (fichier système) dans le
panneau d’administration. Les mises à jour régulières assurent la durabilité de la solution.
L’authentification au portail est sécurisée par HTTPS et un couple utilisateur / mot de

passe. Une documentation assez complète est disponible pour l’installation et la configuration et
la communauté est active. Tout comme PFsense, ALCASAR est compatible avec de nombreuses
plates-formes, la personnalisation des pages utilisateurs et la simplicité d’utilisation sont présentes.
2.3.2 ZeroShell
ZeroShell est une distribution Linux conçue pour mettre en place une sécurité globale au
sein d’un réseau (Pare-Feu, VPN, portail captif...). Son installation est simple via une distribution
dédiée. Elle présente une interface de gestion web simple d’utilisation qui permet entre autres de
sauvegarder la configuration du portail captif ou de personnaliser les pages de connexion .
Comme les deux autres portails la page d’authentification est sécurisée et la connexion se fait
via un couple utilisateur/mot de passe. On retrouve assez peu de documentation pour la gestion du
système. Son utilisation reste identique aux autres solutions présentées.
10
2.3.3 ChilliSpot
ChilliSpot est un applicatif désigné pour la gestion de l’authentification sur les réseaux, son
installation est assez simple via un package applicatif accessible sur les distributions Red Hat et
Fedora. La sauvegarde de la configuration est disponible mais elle implique de copier les fichiers de
configuration et donc de les connaître. La page de connexion est disponible en HTTPS à condition
d’avoir configuré le serveur web (Apache) au préalable en écoute sur le port 443.
On retrouve une documentation complète et une communauté assez active, mais le projet est
en abaissement, la dernière version stable date d’octobre 2006 et le projet est interrompu depuis le
départ du développeur principal. L’utilisation est la même que les autres solutions proposées, page
de connexion avec champs utilisateur et mot de passe.
2.3.4 PFsense
PFsense est une distribution FreeBSD développée en 2004. L’objectif de départ est d’assurer
les fonctions de pare-feu et de routeur mais l’engouement généré par cet applicatif lui a permis
d’étendre ses fonctionnalités et présente d’autres fonctions de portail captif, serveur proxy, DHCP
... Son installation se fait aisément par une distribution dédiée et toutes les configurations peuvent
se faire soit en ligne de commande (SSH) ou via l’interface web (HTTPS). La restauration de
configuration est disponible à travers l’interface web et permet de générer un simple fichier d’une
taille acceptable.
Le portail garantit une évolution stable grâce à des mises à jour quotidienne dont l’installation
est gérée automatiquement dans une partie du panneau d’administration. Cette solution assure une
authentification sécurisée via le protocole HTTPS et un couple utilisateur / mot de passe.
La documentation est très complète et disponible sur Internet, un support commercial est
désormais présent en cas de gros problèmes. PFsense dispose aussi d’une communauté très résolutif.
PFsense assure une compatibilité multi-plateformes, une personnalisation complète des pages disponibles
aux utilisateurs ainsi qu’une accessibilité d’utilisation grâce à une page de connexion simple : deux
champs (utilisateur / mot de passe).[6]
11
2.4 Comparaison des portails captifs
Dans l’étude comparative des solutions nous avons dégagé les critères importants que doivent
tenir compte les différentes solutions :
• Sécurité des échanges lors de l’authentification : afin d’éviter la récupération de mot de passe
sur le réseau ;
• Existance d’une documentation complète : pour consolider la rapidité de mise en place de la

solution ;
• Facilité d’administration : pour mettre le logiciel accessible a administer ;
• Simplicité d’utilisation : pour permettre à tous les visiteurs de se connecter au réseau Wi-Fi ;
• Compatibilité multiplate-formes : pour permettre la connexion depuis les Smartphones, n’importe

navigateurs web et différents système d’exploitation ;
• Présence de sauvegarde et restauration de configuration : pour assurer un redémarrage du

système très rapidement en cas de problèmes ;
• Pérennité de la solution : pour pallier les failles de sécurité et augmenter les fonctionnalités de
la solution via des mises à jour ;
• Possibilité de personnaliser la page de connexion : pour adapter le logiciel à la charte graphique

de l’entreprise et ainsi le rendre plus convivial.
Critéres Alcasar PfSense ZeroShell ChilliSpot
Sécurité HTTPS HTTPS HTTPS HTTPS

d’authentification
Plates-forme clients Toutes Toutes Toutes Toutes

supportées
Facilité d’administration installation via installation installation via installation via

distribution via script distribution .rpm sur Red
dédiée automatisé dédiée Hat et Fedora
Personnalisation ++ ++ + ++
Facilité d’utilisationn + ++ ++ ++
12
Sauvegarde et ++ ++ + +
restauration de
configuration
Pérennité de la solution ++ ++ + -
Tableau 1.1 : Comparaison des solutions de portails captifs [7]
2.5 Choix de la solution de portail captif : PfSense
Bien que nous n’ayons pas mis en pratique toutes ces solutions pour les comparer, l’étude
théorique permet de retenir les deux premières solutions à savoir PFsense et ALCASAR car elles
répondent toutes deux à nos besoins : solutions libres, peuvent s’installer sur un serveur comme
sur un poste de travail, authentification des utilisateurs par login et mot de passe, contrôle de
la bande passante, facilité d’administration, d’installation et de configuration, facilité d’utilisation,
documentation très détaillée et disponible, disponibilité de mises à jour,etc.
Les deux solutions répondent tout à fait au cas étudié mais ALCASAR s’installe uniquement
via une distribution Mandriva. Aussi ALCASAR s’installe via un script automatisé, par contre
PFsense s’installe via une distribution dédiée ; ce qui rend impératif le choix de PFsense. De plus
PFsense présente une interface plus conviviale et une page principale en tableau de bord où l’on
retrouve toutes les informations essentielles et que l’on peut modifier en fonction des besoins. Ce
produit présente aussi une plus grande assurance car la communauté des utilisateurs est très active.
Une fois qu’on choisi le firewall Pfsense comme portail captif et le serveurRADIUS comme
serveur d’authentification de notre solution. nous passons par la suite à l’étude de PFsense et ses
principaux services offertes.
2.6 Définition de PfSense :
Développé par Chris Buechler et Scott UlIrich, PFsense ou « Packet Filter Sense » est un
applicatif qui fait office de routeur/firewall open source basé sur le système d’exploitation FreeBSD
et Monowall. Il est une reprise du projet Monowall auquel il rajoute ses propres fonctionnalités.
PFsense est basé sur PF (packet filter), comme iptables sur GNU/Linux et il est réputé pour sa
13
fiabilité [4]. C’est une distribution dédiée qui peut être installée sur un simple poste de travail, un
serveur ou même sur un boîtier en version embarquée.
Ce qui séduit chez PFsense est sa facilité d’installation et de configuration des outils d’administration
réseau. En effet, après une installation en mode console, il s’administre ensuite simplement depuis
une interface web et gère nativement les VLAN (802.1q).
La distribution PFsense met ainsi à la disposition de l’administrateur réseau une multitude

d’outils open source et de services permettant d’optimiser ses tâches. Parmi ces services, figure
Captive Portail (portail captif) qui fait l’objet de ce projet. [8]
2.7 Aperçu des fonctionnalités et services de PFsense
2.7.1 Services complexes
pfSense peut fournir aux clients une variété de services pour améliorer leur expérience de
différentes manières. Plusieurs d’entre elles sont complexes et justifient leurs propres sections de la
documentation, tandis que d’autres sont plus simples à configurer.[9]
2.7.1.1 DHCP :
Le protocole DHCP (Dynamic Host Configuration Protocol) permet à un périphérique tel

que pfSense d’attribuer de manière dynamique les adresses IP aux clients à partir d’un pool d’adresses
prédéfini. DHCP envoie également des informations de configuration aux clients tels qu’une passerelle,
des serveurs DNS, un nom de domaine et d’autres paramètres utiles.
Ce service est nécessaire dans notre solution à fin de fournir des adresses IP pour les interfaces
LAN et d’autres interfaces facultatifs.
2.7.1.2 DNS :
DNS, ou Domain Name System, est le mécanisme par lequel un périphérique réseau convertit
un nom tel que www.TOPNET.com en une adresse IP telle que 198.50.100.91, ou inversement. Les
clients doivent disposer d’un DNS fonctionnel s’ils veulent atteindre d’autres périphériques, tels que
des serveurs, avec leur nom d’hôte ou leur nom de domaine complet.
14
Ces rubriques traitent de l’utilisation de pfSense en tant que résolveur ou transitaire DNS de
mise en cache, qui gère les demandes DNS provenant de clients locaux. Lorsqu’il agit en tant que
résolveur ou transitaire, pfSense exécute une résolution DNS ou transmet des requêtes à un serveur
de transfert DNS en amont.
D’où la nécessité de l’utilisation d’au moins un serveur DNS ( résolveur ou transitaire ) pour
que les clients peuvent accédé aisément à l’internet.
2.7.1.3 Équilibrage de la charge du serveur (Server Load Balancing) :
L’équilibrage de la charge entrante est utile pour prendre en charge plusieurs serveurs, mais
apparaît en externe en tant que système unique. Cela permet de répartir la charge d’un site Web
sur plusieurs serveurs physiques, de manière semi-intelligente, en reconnaissant la défaillance d’un
serveur, etc. Mais, il n’est pas utiles dans notre cas.
2.7.2 Services simples :
pfSense propose également plusieurs services non couverts dans leurs propres sections de la
documentation.
2.7.2.1 NTP Server :
Le démon NTP (ntpd), permet à pfSense de jouer le rôle de serveur Network Time Protocol
pour un réseau et de synchroniser l’horloge avec les serveurs NTP distants en tant que client NTP.
c’est un service facultatif par rapport à notre besoins .
2.7.2.2 SNMP :
Le démon SNMP (Simple Network Management Protocol), permet d’interroger certaines

informations d’état à partir de pfSense avec un client SNMP, telles que celles des systèmes de
surveillance réseau. ce qui n’est pas nécessaire dans notre solution .
2.7.2.3 UPnP et NAT-PMP :
UPnP et NAT-PMP permettent aux périphériques et aux programmes qui les prennent en
charge d’ajouter automatiquement des redirection de port dynamique et des entrées de pare-feu.
Les utilisations les plus courantes concernent les systèmes de jeu (XBox, Playstation, etc.) et les
15
programmes BitTorrent tels que uTorrent, qui reposent tous deux sur l’autorisation de connexions
entrantes vers un service local.
2.7.2.4 Logs :
Les Logs sur pfSense contiennent les événements récents et les messages des démons. Ces
messages peuvent être stockés localement sur une base limitée ou transférés vers un serveur de
journalisation central pour un stockage à long terme, de meilleurs rapports, des alertes, etc. C’est
un service d’enregistrement des données de navigation des invités qui est indiqué dans le cahier des
charges .
2.7.2.5 Le proxy IGMP :
Le proxy IGMP, comme son nom l’indique, proxy le trafic IGMP entre les segments de réseau.
Les interfaces actuellement définies sont répertoriées sur la page principale et les entrées peuvent
être gérées à partir de celle-ci . Sont utilisation n’est pas nécessaire dans notre solution.
2.7.3 Surveillance du système ( Monitoring) :
Surveillance du système pfSense fournit une mise d’informations sur l’état du pare-feu, ses
services, le trafic traversant le pare-feu et les données de journal, et il est par défaut activé au niveau
de PfSense.
2.7.4 Portail captif :
La fonction de portail captif dans pfSense permet de sécuriser un réseau en demandant un

nom d’utilisateur et un mot de passe (ou seulement un clic), saisis sur une page de portail.
Si l’authentification est utilisée, elle peut être effectuée à l’aide de la gestion intégrée des
utilisateurs de pfSense ou d’un serveur d’authentification externe tel qu’un serveur RADIUS.
Étant donné que l’authentification des utilisateurs du portail captif avec FreeRADIUS répond
à notre besoin , on l’adopte pour notre solution pour assurer :
— Utilisation simultanée et désactivation des connexions simultanées : Cela garantira qu’il ne

peut y avoir qu’une seule connexion avec ce nom d’utilisateur / mot de passe.
16
— Réauthentifiez les utilisateurs toutes les minutes : Activez cette option sur le CP afin que les
utilisateurs soient déconnectés si leur temps ou leur trafic est atteint.
— Il est possible de donner à un utilisateur une certaine quantité de trafic (le chargement et le
téléchargement sont résumés) : ce là nous fourni un gain au niveau de la bande passante.
— FreeRADIUS et Captive Portal peuvent être utilisés pour authentifier les utilisateurs par nom
d’utilisateur et mot de passe. Il est possible qu’un hôte du portail captif ne soit authentifié
qu’avec une adresse MAC. Cela peut être réalisé avec Plain-MAC-Auth activé ou avec 802.1X.
Or que ce services n’est pas sécurisé dans notre cas .
— Quantité de temps : Il est possible de donner à un utilisateur donné un temps d’utilisation. Cela
peut être fait dans un délai donné. Par exemple, un utilisateur devrait pouvoir se connecter
à Internet au maximum 60 minutes par jour, mais il peut utiliser 20 minutes le matin, 30
minutes le midi et les 10 minutes restantes l’après-midi. Si l’utilisateur le souhaite, il peut
utiliser toutes les 60 minutes.
2.7.5 Les packages :
Les packages étendent les fonctionnalités du logiciel PfSense. Ils fournissent des services et
des utilitaires supplémentaires introuvables dans l’installation de base. Celles-ci sont entièrement
facultatives et ne sont pas nécessaires pour la plupart des déploiements. Par contre et en liaison avec
nos besoins, on a trouvé que le package Squid et SquidGuard sont nécessaire pour notre solution.
2.7.5.1 Squid :
Squid est un serveur mandataire, en anglais un proxy, entièrement libre et très performant.
Squid est capable de gérer les protocoles FTP, HTTP, HTTPS et Gopher. Il est généralement utilisé
pour des fonctions de filtrage d’URL ou en tant que tampon. Les pages Internet sont stockées
localement ce qui évite d’aller les recharger plusieurs fois et permet d’économiser la bande passante
Internet.
17
2.7.5.2 SquidGuard :
SquidGuard est un filtre, un redirecteur et un plugin de contrôle d’accès pour Squid. Il va

notamment permettre d’appliquer sur un proxy une liste noire de sites ou mots clés interdits. Il est
nécessaire de tracer toutes les communications vers l’internet au sein des établissements .
La mise en place d’un proxy transparent Squid avec filtrage d’URL SquidGuard permettant
de filtrer les accès à Internet de l’ensemble des utilisateurs connectés au réseau interne, de bloquer
l’accès aux sites à caractère indésirables ou offensant.[10]
2.8 Authentification des utilisateurs
L’authentification est un point essentiel du portail captif puisqu’elle définit l’autorisation

d’accès vers l’extérieur. Ainsi trois méthodes d’authentification sont offertes :
— Sans authentification (No authentification) : les clients sont libres ; ils verront le portail mais il
ne leur sera pas demandé de s’authentifier, or que cette solution ne répond pas à notre besoin
( sécurité ) donc elle est rejeté.
— Authentification via un fichier local (Local User manager) : les paramètres des comptes utilisateur
sont stockés dans une base de données locale au format XML .
— Authentification via un serveur RADUIS (RADIUS Authentification) : à ce niveau, nous avons

le choix entre utiliser un serveur embarqué FreeRADIUS et utiliser un serveur RADIUS distant
du serveur PFsense.
Pour ce projet nous avons retenu l’authentification RADIUS car non seulement cela permet de gérer
un grand nombre d’utilisateurs, mais aussi pour des raisons de sécurité.
A ce stade, le portail est déjà accessible, c’est-à-dire que pour un utilisateur qui se connecte
au réseau local et à partir de son navigateur, demande une page web, il sera redirigé vers la page
captive qui lui demandera de s’authentifier avant d’avoir accès à la page demandée initialement.
18
2.8.1 Définition du serveur FreeRadius :
RADUIS (Remote Authentification Dial-In User Service) est un protocole client-serveur

permettant de centraliser des données d’authentifications [’8]. Le client RADIUS appelé NAS (Network
Access Server) fait office d’intermédiaire entre l’utilisateur final et le serveur. C’est le standard utilisé
aujourd’hui surtout par les fournisseurs d’accès à Internet car il est très malléable et très sécurisé.
PfSense intègre un paquet radius libre (FreeRadius) couplé avec une base de données pour
stocker les informations des utilisateurs. Mais on peut aussi utiliser une base de données externe
pour y stocker ses données d’utilisateurs. De même, on peut utiliser un serveur RADIUS distant
pour authentifier les utilisateurs. Ainsi le CNFP utilise une base de données MYSQL sur un autre
serveur pour enregistrer ses utilisateurs. Dans ce cas nous pouvons soit installer un serveur RADIUS
sur le serveur MySQL pour stocker les données d’identification dam la base MySQL, soit installer le
serveur RADIUS sur le serveur PFsense pour y stocker localement les données d’identification.
Dans tous les cas le serveur d’authentification (RADIUS) sera l’intermédiaire entre le portail
captif et la base de données (locale ou distante). Pour la phase de test, nous avons exploité le second
cas c’est-à-dire installer un serveur embarqué FreeRadius sur le serveur PFsense. [11]
2.9 Conclusion
Dans ce chapitre, nous avons choisi le serveur Pfsense comme portail captif et le serveur
RADIUS comme serveur d’authentification.En plus, nous avons détaillé les services et les fonctionnalités
de Pfsense ainsi que les les matériels nécessaire pour son implémentation. Nous passons par la suite
à l’étude technique de notre solution.
19
Chapitre 3
Réalisation
Plan
1 Architecture proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2 Matériel et architecture réseau requis : . . . . . . . . . . . . . . . . . . . 22
3 Configuration du Serveur DHCP . . . . . . . . . . . . . . . . . . . . . . 23
4 Configuration du FireWall (Rules) . . . . . . . . . . . . . . . . . . . . . . 24
5 Installation et configuration de la solution Portail Captif . . . . . . . . 25
6 Configuration de la base de donnée de type MYSQL : . . . . . . . . . . 33
7 Conception et mise en place de l’interface d’inscription et d’authentification 34

Chapitre 3. Réalisation
Introduction
Dans ce chapitre nous allons implémenter les différentes technologies et services décris dans
les chapitres précèdents . Ce chapitre fera l’objet d’une présentation des étapes les plus importantes
réalisées durant la période du stage.
3.1 Architecture proposée
Afin d’assurer la meilleure couverture WiFi possible au niveau du siège TOPNET, nous
adaptons l’infrastructure déployée à l’établissement et son architecture. Au début, l’installation de
plusieurs répéteur WIFI sont nécessaires afin de couvrir des zones de plus grande densité, d’où
l’utilisation de 3 switchs niveau 2 qui sont connecté à quelques machines clients "firefox" pour le
test.
Pour cette mise en pratique, nous utiliserons le firewall PfSense . C’est un firewall qui va
protéger notre LAN. Le but étant de rendre l’accès à l’internet accessible, tout en le protégeant.
On commence par placer ses composants dans notre maquette GNS3 :
— un interface WAN liée à l’internet.
— Un firewall pfSense qui posséde 4 ports, 2 Gigabit pour les interfaces et 2 FastEthernet.
— L’interface OPT1 est lié à une machine virtuelle d’administration ( pour accéder au firewall
via l’interface WEB "GUI" d’où la facilité de la configuration et tester ).
— L’interface OPT2 est lié à une base de donnée (séparé de PfSense) de type MYSQL pour éviter
la charge sur PfSense et pour faire l’inscription via une interface web, en plus parmi les besoins
de Topnet c’est la journalisation des informations des utilisateurs qui sert à la traçabilité en
cas d’un attaque ou intrusion à partir du portail.
21
Figure 3.1: Architecture détaillée
3.2 Matériel et architecture réseau requis :
Pour le matériel sur lequel PFsense doit s’installer, on a besoin d’un minimum qui soit
composé d’une machine dotée d’au moins deux cartes réseau et dont les caractéristiques sont :
— Au moins 4 Go de disque dur.
— Au moins 512 Mo de RAM.
— Un CPU cadencé à au moins 600 MHZ. Mais dans notre cas nous avons utilisé une machine
virtuelle avec les caractéristiques suivantes :
- 4 Go de disque dur ;
- Un CPU cadencé à au 2GHZ "4 threads" ;
- 1GB de RAM ;
22
3.3 Configuration du Serveur DHCP
Notre serveur DHCP est configuré au niveau du serveur Pare-feu « 13 pfSence », nous allons
donc activer et configurer ce service en donnant la plage d’adressage comme le montre les figures
ci-dessous.
NB : Toutes les configurations d’adressage dans ce projet vont être sous le protocole IPV4
(pas d’IPV6).
3.3.1 La configuration de l’interface WAN
L’interface WAN est la passerelle par défaut (GATEWAY) vers le réseau internet. Toute les
requêtes destiné hors de ce réseau sera véhiculer a cette point de sortie. Comme la majorité des cas
la passerelle récupère une adresse IP d’après le fournisseur d’internet. Donc notre interface WAN
sera configurée comme un client DHCP.
3.3.2 La configuration des interfaces LAN, OPT1, OPT2
La configuration d’adressage IP pour ces trois interfaces du firewall (LAN, OPT1, OPT2)
sera être statique avec un serveur DHCP activé.
• Pour l’interface LAN on va utiliser une plage d’adresse 192.168.1.1/24 puis on active le
serveur DHCP avec une plage 192.168.1.100 - 192.168.1.199 pour atteindre jusqu’à 100 clients qui
peuvent se connecté simultanément. En plus, on vérifie le temps par défaut/maximale de Bail, ils
doivent être supérieur à la « Hard Timeout » du portail captif, sinon on provoque la déconnexion
des clients authentifié qui ont déjà des sessions actifs au portail.
Figure 3.2: La spécification d’intervalle
23
Figure 3.3: Le temps par défaut/maximale de Bail
Default lease est configuré sur 2 Heures par défaut. Maximum lease est configuré sur 24
Heures par défaut. Puisque le Hard timeout sur le portail captif va être configuré sur une durée
d’une seul heure alors on laisse les deux champs vide.
• Pour l’interface OPT1 qui est dédié au réseau d’administration, on va utiliser la plage
d’adresse 192.168.2.1/24, puis on active le serveur DHCP avec une seul adresse 192.168.2.2 puisque
on a une seul machine d’administration, mais on peut élargir la plage des adresses si il y a plusieurs
machines d’administration.
• Pour l’interface OPT2 qui est dédié à la liaison de la base de donnée, on va utiliser la plage
d’adresse 192.168.3.1/24, puis on active le serveur DHCP avec une seul adresse aussi 192.168.3.2
puisque on est connecté avec une seul BD pour faciliter la configuration, mais on peut faire une
configuration statique au lieu de DHCP si on plusieurs BD ou des autres serveurs.
3.4 Configuration du FireWall (Rules)
Une fois les interfaces sont tous configurées, une étape de sécurité primordiale est celle
d’appliquer les autorisations d’accès entre les interfaces selon notre besoin.
• Pour l’interface WAN on laisse les deux règles prédéfini ( Block private networks/ Block
bogon networks ), c’est deux règles sont utilisée dans la majorité de firewall ou routeur pour bloquer
l’accès aux réseaux local d’après le réseau internet ( incoming traffic ).
24
• Pour l’interface LAN on a mis des règles pour bloquer l’accès aux services d’administration
qui peut provoquer des problèmes de sécurité au niveau du Pare-feu.
Figure 3.4: Au niveau de l’interface LAN
Comme indiqué dans les règles on a bloqué l’accès aux ports 80, 443, 22 pour restreindre
l’interface WEB du Pfsense et le service SSH. On a bloqué l’accès à les trois autres interfaces «
OPT1/OPT2/WAN » pour qu’un pirate ne peut pas contourner la restriction d’accès aux services
critiques depuis c’est trois dernier. Et aussi l’accès aux deux réseaux OPT1 et OPT2 pour éviter un
attaque sur le réseau d’administration ou à la base de donnée.
• Pour les deux interfaces OPT1 et OPT2 on créer des règles d’autorisation complète vers
toute les interfaces et les réseaux de Pare-feu puisque les deux sont accessible seulement par l’administrateur
de ce réseau.
3.5 Installation et configuration de la solution Portail Captif
Pour authentifié les utilisateurs qui vont se connecté sur le réseau WIFI, on doit utiliser un
portail captif, le rôle de ce dernier et de redirigé les utilisateurs vers un page web d’authentification
lorsque ils demandent n’importe qu’elle page web.
Le Pfsense propose une solution de portail captif basé sur un serveur Radius préinstallé avec
des différentes fonctionnalités et options, parmi ses options, il propose trois méthodes d’authentification :
• Authentification basé sur adresse MAC.
• « None method» sans authentification, une page web affiché pour l’utilisateur, il valide en
cliquant sur submit.
25
• Authentification basé sur une backend.
Cette dernière permet d’utiliser un serveur d’authentification « utilisateur/mot de passe »

pour garantir l’accès ou le nié, et cette méthode répond à la besoin de notre projet partiellement.
Le portail propose le serveur local de Pfsense comme backend lié à une interface Web pour
authentifier les utilisateurs.
Figure 3.5: Création de l’interface Authentification
Les comptes d’utilisateurs sont créés par l’administrateur du firewall manuellement. Alors
cette solution manque la possibilité de création des comptes par utilisateurs sur le portail.
Pour répondre à la besoin de notre projet on doit changer le serveur d’authentification proposé
par le portail vers un serveur qui propose la possibilité d’authentifié les utilisateurs à partir d’une
base de donnée pour qu’on puisse développer une solution d’enregistrement des utilisateurs à travers
l’interface web du portail captif.
Notre choix était le serveur FreeRadius comme une backend du portail captif.
26
3.5.1 Installation et configuration de FreeRadius :
FreeRadius est un serveur Radius libre offre une alternative aux autres versions d’entreprise
Radius, et est un des serveurs Radius les plus modulaires et riches en fonctionnalités disponibles.
L’installer de FreeRadius est très simple sous Pfsense, il suffit d’aller au « Package Manager
» à partir de l’interface WEB et l’installer.
Par la suite en passe à la configuration en commençant par la création des trois interfaces
principale de Radius :
• Authentification : l’interface qui gère le processus d’authentification « vérification des

informations d’identification »
• Accounting : l’interface qui journalise l’accès des clients « date d’authentification, adresse
IP associer . . . », on va utiliser ce service pour le Logs et la traçabilité.
• Status : l’interface qui sert à surveiller l’état du serveur. . .
Figure 3.6: Association des port à chaque serveur
Et comment une dernière étape on a besoin de créer un client NAS, le rôle de ce dernier et
de acheminer les demandes des clients au serveur et fournir des réponses.
27
Figure 3.7: Schéma explicative de fonctionnement du NAS
On a configuré le client NAS sur l’interface 192.168.1.1 « la point du contact entre les
utilisateurs et le Pfsense »
Figure 3.8: Configuration du client NAS
28
3.5.2 La Liaison de FreeRadius à la base de données MYSQL :
Dans cette partie nous allons faire la configuration nécessaires pour lier notre serveur d’authentification
à la base de données qu’on va l’utiliser.
Figure 3.9: La configuration de liaison entre le FreeRadius et la BD
Le serveur FreeRadius propose d’autres fonctionnalités autres que l’authentification « Authorization

», il propose :
• Accounting
• Post-Auth
Ces deux fonctionnalités permettent de garder des informations de journalisation à la base
de données, alors nous allons l’utiliser aussi pour le Log.
3.5.3 Configuration du portail captif :
En activant le portail captif on peut voir plusieurs options quand peut ajouter :
• Le Hard timeout est le temps maximal dans lequel les utilisateurs restent connectés, après
cette durée ils seront déconnectés, avec la possibilité de reauthentifié. Le portail mentionne que le
paramètre « Hard timeout » doit être inférieure à la Bail par défaut/maximum du serveur DHCP,
on a choisi 60 minutes comme une durée maximale.
29
• Idle timeout est le temps maximal lequel les utilisateurs peuvent rester inactive, après cette
durée ils seront déconnectés, avec la possibilité de reauthentifié. Cette option est efficace pour éviter
que les utilisateurs inactive sature la portail sans utilisé le service internet. On a choisi une durée de
15 minutes.
Figure 3.10: Configuration du Idle/HARD timeout
C’est deux autres options sert à limiter la bande passante pour chaque utilisateur et garantir
un débit minimale pour chaque utilisateur du portail. Aussi c’est deux options répond au besoin de
notre projet de garantir un débit minimale de 4Mbit/s pour chaque utilisateur.
Figure 3.11: Configuration de la bande passante
Le portail nous donne aussi la possibilité d’utilisé le protocole HTTPS sur l’interface WEB
d’authentification pour éviter l’interception les identifiants, cette option est nécessaire pour garantir
l’un de notre besoin principale du projet la sécurité de l’utilisateur et le portail.
Figure 3.12: Autorisation du protocole HTTPS
30
3.5.4 Liaison du portail captif avec FreeRadius
Pour utiliser le serveur FreeRadius comme une backend d’authentification on doit ajouter un
nouveau serveur d’authentification au niveau Pfsense pour l’utiliser au lieu du serveur local de ce
dernier.
Figure 3.13: Configuration du protocole PAP
En ajoutant le serveur FreeRadius, on s’étant arrêté au choix du protocole d’échange entre

le client et le Client-NAS.
Le Pfsense propose quatre choix de protocole :

• PAP
• MD5-CHAP
• MSCHAPv1
• MSCHAPv2
Le protocole PAP transmet les mots de passe d’une façon « obsfucated », très facile à décrypté,
mais au contraire si on veut stocker les mots de passe dans une base de données ce protocole donnera
la possibilité de stocker les mots de passe dans les formes de hachage la plus robuste dans le monde.
Les autres protocoles (CHAP, MSCHAPv1, MSCHAPv2) utilisent des méthodes de hachage
pour garantir l’identité des clients lors de transmission sur le canal réseau, mais au contraire si on
est dans le cas d’utilisation d’une BD pour l’authentification, les mots de passe doit être stocké dans
la base en claire.
Donc on est dans un problématique, on doit transmettre les donnée d’authentification crypté
éviter que les donnée être compromis, ainsi qu’on doit stocker les mots de passe dans la base d’une
manière haché pour éviter l’exposition de donnée des clients dans un cas d’intrusion.
31
Pour mieux comprendre le scénario on a fait un diagramme qui décrit d’authentification d’un
utilisateur.
Figure 3.14: Diagramme de séquence
Comme indiqué dans le diagramme l’échange des informations d’authentification entre l’utilisateur
et le serveur WEB se fait à partir de protocole HTTPS. D’autre part, les échanges entre les différentes
services ( Serveur Web, NAS-Client, Serveur d’authentification ) se fait localement dans Pfsense et
non exposé sur le réseau.
3.5.5 Conclusion
On peut utiliser le protocole PAP afin de stocker les mots de passe en forme haché dans la
base et sans risque que les données soient être compromis sur le réseau.
Figure 3.15: Capture du trafic au cours d’authentification ( Le portail utilise le port 8003 )
32
Figure 3.16: Capture sur la table des utilisateurs
3.6 Configuration de la base de donnée de type MYSQL :
Après avoir terminé les étapes de mise en place de l’architecture et terminer les configurations
de réseau et du portail captif, on nous reste que configuré la base donnée pour être utilisé pour
l’authentification et la journalisation. On a utilisé une VM «Virtual Machine » préconfiguré de
Bitnami basé sur la distribution Linux Debian, qui contient les packages nécessaires au fonctionnement
normale d’une machine serveur ainsi que le serveur MYSQL. Tout d’abord on va autoriser l’accès à
distance via SSH pour qu’elle soit être configurable depuis le réseau d’administration en supprimant
le fichier de blocage et réactivant le service. Puis on va autoriser l’accès au serveur MYSQL pour
qu’il soit accessible par le serveur Radius et l’administrateur en ajoutant une exception au Pare-feu
du système et en autorisant l’accès à distance dans les fichiers de configuration de la BD. Par la suite
on va créer une base de données radius et un compte utilisateur lui associé. Et comme une dernière
étape importé le fichier « schema.sql » à la base avant qu’elle sera opérationnel avec le serveur
FreeRadius, ce fichier contient les tables qui sont utilisés par les différentes services de Radius «
authentification, accounting, statuts ».
33
Les principales tables sont :

• radcheck : est la table qui contient les informations d’authentification des utilisateurs,
utiliser par le serveur FreeRadius pour authentifier les utilisateurs.
• radacct : cette table est utilisée pour garder un historique des sessions établie . . . «
Accounting » , l’importance de cette table dans le cadre de ce projet est qu’elle nous offre la traçabilité
des utilisateurs.
Figure 3.18: Création de l’interface Accounting (1)
Figure 3.19: Création de l’interface Accounting (2)
Pour l’utilisateur « 55000004 » par exemple on peut voir plusieurs informations sur comme la
date de début et fin de la session et l’adresse IP local associer à cet client « colonne framedipaddress
». Donc un cas d’une intrusion à partir de ce réseau on peut combiner le log de Pare-feu avec le log
enregistré dans cette table pour déterminer l’utilisateur responsable à cette action.
• radpostauth : est la table qui log l’historique des opérations d’authentification des utilisateurs
« authentification avec succès / échoué ».
3.7 Conception et mise en place de l’interface d’inscription et

d’authentification
Les étapes de mise en place et configuration des serveurs est terminer, maintenant on va
passer à la dernière étape fondamentale du projet : la conception et développement de la solution
d’authentification Web.
3.7.1 Analyse de l’existant
Le portail existant de Pfsense est très basique il manque la fonctionnalité d’inscription et

manque aussi de design.
34
Figure 3.20: Capture de l’ancienne interface
Pour c’est besoin on a choisi de développer une nouvel solution qui prend en charge l’ajout
de l’option d’inscription et renouveler le design du portail captif.
3.7.2 Spécification des besoins
Pour que les utilisateurs puissent s’authentifié sur le portail captif, ils doivent s’enregistrer
tout d’abord pour prouver leurs identités.
Mais pour le cas d’un portail captif, des différentes conditions s’appliquent.
• La connexion internet est restreinte avant l’authentification.

• Les utilisateurs doivent utiliser des informations à l’inscription qui garantir la traçabilité
des utilisateurs en cas d’intrusion ou cyberattaque d’après le portail.
• Les utilisateurs doivent fournir des informations qui satisfait le besoin de marketing du
l’entreprise.
35
3.7.3 Les solutions trouvés et choisies
Selon les besoins spécifié on peut proposer ces différentes méthodes d’inscription :
• Inscription par API « Google/Facebook/Twitter ...»
• Inscription normale par email
• Inscription par Numéro Mobile
La solution d’inscription par API facilite la phase d’authentification énormément pour les utilisateurs
et elle offre aussi un aspect de marketing en retournant des adresses email, mais théoriquement cette
solution n’est pas réalisable puisque l’authentification par API se passe au niveau de client Web
de l’utilisateur suite à la restriction d’accès internet. L’inscription par email offre aussi l’aspect de
marketing, mais comme l’inscription par API elle est non réalisable puisque l’utilisateur ne peut pas
vérifier son email suite à la restriction d’accès internet. Les deux dernières méthodes aussi n’offre
pas un aspect de sécurité, un email ou identifiant d’un API n’offre pas de la traçabilité. La meilleure
solution pour solution qui répond à tous nos besoins est l’inscription par Numéro Mobile, cette
solution offre la traçabilité, la méthode d’inscription est très simple, aucune connexion à internet
requis et la vérification se fait à travers un code de confirmation sur un SMS.
36
Figure 3.21: Schéma Explicatif
3.7.4 Conception de l’interface web ;
Selon l’étude des choix de solution pour l’enregistrement, on a pris l’inscription par Numéro
Mobile comme une meilleure solution qui répond à tous les besoins de notre projet.
La création et validation d’un compte utilisateur à travers son Numéro Mobile se fait dans
ce scénario « scénario d’exécution normale sans exceptions » :
37
Figure 3.22: Scénario d’exécution normale sans exceptions
Description :
1. Demande d’inscription par l’utilisateur « Numéro de Tel / Mot de passe ».
2. Insertion de « Numéro de Tel / Mot de passe » + Token à la BD.
3. Demande d’envoyer de SMS contenant le Token au « Numéro de Tel ».
4. Réception du SMS contenant le Token de validation sur le terminal mobile de l’utilisateur.
Pour appliquer ce scenario on a besoin de :

• Front-end : La page d’inscription
• Back-end : pour gérer toute le processus de d’inscription :
o Validation des entrés des utilisateurs.
o Interrogation de la base de données et l’insertion des utilisateurs.
o Génération des Token et l’envoie à travers OTP SMS.
• SMS Token (Serveur SMS OTP) : pour la validation et certification d’un numéro mobile.
38
3.7.4.1 Conception du Front-end :
Pour la front-end on a choisi de refaire un nouveau design plus riche et ergonomique, compatible
avec tous les types des terminal mobile « Notebooks, smartphones, tablettes . . . ».
On va créer une Template codé en Html5, CSS3, Jquery, Bootstrap. . .
Figure 3.23: Compatibilité de l’interface développé avec toute les types des terminaux
Figure 3.24: Aperçu complète de la nouvel interface
39
3.7.4.2 Conception du Back-end
Pour la back-end on va développer un code PHP pour acheminer les trois acteurs principaux
( redaction non terminer )
Figure 3.25: Schéma explicatif
3.7.4.3 Proposition de solution OTP :
Pour le serveur OTP «One Time Password» on peut loueur un serveur d’après un fournisseur
de service de messagerie en ligne ou un opérateur, on peut aussi utiliser une API en ligne qui fournit
ce type service avec une facturation par nombre des SMS envoyé.
Dans notre projet on va utiliser la deuxième solution, les API en ligne offre une simplicité
d’intégration de la solution dans des nombreux type des Back-end, et dans notre cas nous allons
l’intégré au niveau du Back-end PHP de notre solution.
3.7.5 Développement de la solution :
A cette phase, on commencer à enchainé toute les différentes composantes pour donner la
solution finale tout le long du projet.
40
3.7.5.1 Développement du Front-end
Pour la Front-end on a créé une interface une interface unifié pour l’authentification et
l’inscription, afin de faciliter la tâche « Inscri/Auth » pour l’utilisateur pour obtenir l’interface
à la figure 3.24.
Et pour optimiser le temps de ce processus au maximum on a développé un script JQuery

AJAX pour éviter de quitter la page d’index au processus d’inscription ou le rechargement de la
page complètement à chaque demande.
Figure 3.26: Aperçu du script JQuery AJAX
Cette fonction envoie la demande d’inscription « Numéro / Mot de passe » d’utilisateur au

back-end, retour la réponse et l’insert à la balise de réponse sans besoin de rafraichir toute la page.
41
Figure 3.27: Schéma explicatif
On a créé trois fonctions JQuery AJAX pour trois scénarios
• La première fonction sert à créer un compte utilisateur

• La deuxième fonction sert à renvoyer un Token de confirmation si le compte n’est pas encore
actif ou la Token n’est pas reçu.
• La troisième fonction sert à valider la Token reçu pour vérifier la propriété du numéro.
3.7.5.2 Développement du Back-end :
Notre back-end tourne sur un serveur PHP 7, pour quelle peut se communiquer avec la BD
de type MYSQL, on doit installer un driver (Mysqli ou PDO).
On a choisi de d’installer l’extension PDO puisque elle offre les requetés préparé qui nous
aide à éviter les Injection SQL au niveau de la base.
Aussi, on a besoin d’installer la bibliothèque de l’API quand va utiliser pour envoyer des
SMS de vérification. On a choisi une API hébergé en ligne, pour sa simplicité d’implementation, et
diversité des bibliothèques qui offre « Java, PHP, NodeJS, Python, .NET . . . ». Pour note back-end,
la bibliothèque est installable depuis COMPOSER et il suffit de l’appelé depuis le code PHP pour
qu’elle soit être opérationnel.
42
Après que les besoins du back-end sont satisfaits on commence par création de table nécessaire
pour la partie d’inscription.
Figure 3.28: Structure des tables
Cette table contient les numéros mobiles à vérifier à la phase d’inscription.
La structure de table :
• mobile-number : Numéro mobile d’utilisateur.
• verification-code : Token de vérification généré et envoyé.
• verified : la statue de vérification « 1 » si le numéro est vérifié et « 0 » si le numéro n’est
pas encore vérifié.
• password : mot de passe haché en SHA256.
• Timecode : la date d’envoi du « verification-code », utilisé pour éviter l’envoi successive du
Token.
Et une fois la vérification est términée, le back-end s’intervient une autre fois pour renvoyer
le numéro vérifié à la table d’authentification de pfsense :
Figure 3.29: L’envoie du numéro vérifié
On a utilisé deux tables séparé pour éviter la modification du fonctionnement normale de

serveur FreeRadius.
Après la préparation de la table de la base de données, on a poursuivi vers la création de la

fonction d’envoie des code de confirmation « Token » :
Description :
Dans cette fonction on a importé la bibliothèque du l’API, si l’importation et l’envoie est
terminer par succès alors la fonction va retourner la valeur « TRUE » sinon en cas d’erreur ou
d’exception elle va retourner « FALSE ».
43
Figure 3.30: la création du TOKEN
Et finalement, on a codé le script principale du back-end qui enchaine toute l’opération

d’inscription :
Figure 3.31: Le code d’enchaînement de l’inscription
44
Ce script est constitué principalement de quatre fonctions :
• La fonction verif () : est la fonction principale qui s’exécute à chaque fois quand la back-end
reçoive une demande d’après la front-end afin d’exécuter un série de test et de validation sur les entrés
de l’utilisateur et déterminer la prochaine fonction à exécuter.
• La fonction register () : est la fonction qui s’exécute si l’utilisateur demande l’enregistrement,
cette fonction vérifie premièrement si l’utilisateur est enregistrer sur la BD sinon il retour un
message qui indique que le numéro est enregistré ». La deuxième étape elle vérifie si l’utilisateur
est déjà enregistrer et non validé, alors elle retour un message qui offre la possible d’envoyer un
code de confirmation « en utilisant la fonction resendToken () ». Sinon en troisième étape elle insert
l’utilisateur à la base avec une Token généré et envoyé aussi à l’utilisateur en par le script d’API
SMS.
• La fonction resendToken () : cette fonction est utilisé si l’utilisateur demande le renvoie de
Token.
• La fonction submit () : cette fonction est appelé pour insérer l’utilisateur à la table
d’authentification du serveur FreeRadius par les deux fonctions « register() et resendToken() »
si l’utilisateur à terminer l’étape de vérification du numéro mobile.
45
Figure 3.32: Extrait du code de la fonction resendToken ()
En appelant cette fonction :

• Elle fait appelle au script de connexion à la base « en utilisant le moteur PDO »
• Génère une Token de verification.
• Interroge la base pour obtient la date du dernier Token envoyé, pour vérifier si on a passé
5 minutes.
• Si 5 minutes est passé alors elle appelle le script qui contient la bibliothèque et la fonction
d’envoi du Token par SMS.
• Prépare une transaction, et envoie une requête de mise à jour de la Token à la base.
• Exécute la fonction TokenSend() pour envoyer la Token au Numéro mobile , si la fonction
a été exécuter avec succès elle commit la requête et créer des champs d’écriture du Token au niveau
du Front-end , sinon fait un rollback et afficher un message d’erreur.
Conclusion
Ce chapitre fait l’objet d’une démarche structurée pour aboutir à un portail captif fiable.
Ainsi que le choix des outils choisis se base sur les critères de l’extensibilité, l’externalisation et de
la sureté. En premier lieu, nous avons mise en place de l’architecture réseaux. En second lieu nous
avons déployé les services proposés et augmenté le niveau de sécurité de notre architecture, ainsi
que nous avons utilisé plusieurs méthodes pour authentifier les utilisateurs de notre infrastructure
et services. Dans le chapitre suivant nous allons faire tous les tests nécessaires pour valider le bon
fonctionnement de tous les services.
46
Conclusion générale
Pour authentifier les utilisateurs de son réseau afin de partager la connexion Internet de façon
sécurisée, TOPNET s’est orientée vers une solution de portail captif.
Après une présentation de l’organisme la d’accueil, la démarche suivie pour cette étude a
permis d’analyser les besoins. Ensuite une étude comparative de portail captif a permis de choisir
une solution à implanter. C’est la solution PfSense a été retenue ainsi que le serveur d’authentification
RADIUS pour sécuriser le réseau. Cet applicatif libre a été ensuite étudié de façon technique et sa
fonction captive a été implantée de façon effective. Nous pensons que le but de ce projet est atteint
car, il nous aura permis de savoir d’abord l’existence de solutions libres de portail captif, ensuite de
mener une étude comparative et de faire enfin l’implémentation de la solution libre PFsense.
Pour finir, l’outil PFsense tel que conçu, propose d’autres services réseau qui peuvent être
mis à profit en fonction des besoins.
47
Bibliographie
[1] (), adresse : http://www.journaldunet.com/web-tech/chiffres-internet/tunisie/pays-

tun.
[2] (), adresse : https://www.topnet.tn.
[3] (), adresse : http://www.beep.ird.fr/collect/upb/index/assoc/ESI-2013-KON-ETU/ESI-

2013-KON-ETU.pdf.
[4] (), adresse : ESI-2013-KON-ETU_2.pdf.
[5] (), adresse : https : / / www . memoireonline . com / 03 / 12 / 5546 / m _ Authentification - et -

protocole-PPPOE-le-cas-de-laccessibilite--linternet-via-ringodialere8.html.
[6] (), adresse : http://www.lolokai.com/blog/2011/06/21/pfsense- la- distribution-

freebsd-dediee-au-routage-et-au-firewalling/.
[7] (), adresse : https://www.supinfo.com/articles/single/2064-portail-captif.
[8] (), adresse : https : / / www . osnet . eu / fr / content / tutoriels / d % C3 % A9tail - des -
fonctionnalit%C3%A9s-de-pfsense.
[9] (), adresse : https : / / docs . netgate . com / pfsense / en / latest / services / index . html ?
fbclid=IwAR3Ya5HmHb6szAYzeJcjxiM5OUh- RhPFpTyaRWNchlJfcG6FfLtn3f_TuEg#complex-
services.
[10] (), adresse : https://docs.netgate.com/pfsense/en/latest/packages/index.html.
[11] (), adresse : http://reseaux85.fr/index.php?title=Reseau:pfsense.
48
Annexes
Annexe 1.
Dans cette deuxième annexe, nous allons décrire les étapes d’installation de GNS3 et la
configuration nécessaire .
Installation du Logiciel GNS3
— Etape 1 : Dans un premier temps, on va télécharger la dernière version du logiciel gns3 depuis
son site officiel.
Figure 4.1: Télechargement de l’image ISO de GNS3
— Etape 2 : Exécuter le fichier téléchargé.
Figure 4.2: Lancement de l’installation
49
Annexes
— Étape 3 : Ensuite, nous allons choisir les logiciels qu’on doit les installer avec GNS3.
Figure 4.3: choix des logiciels a installer
— Étape 4 : Dans cette étape , nous allons installer WinPcap
Figure 4.4: installation de WinPcap
50
Annexes
— Étape 5 : Enfin, on termine l’installation de GNS3
Figure 4.5: Fin de l’installation
51
Annexes
Annexe 2.
Dans ce premier annexe, nous allons décrire les étapes d’installation et de le configuration de
PfSense.
Installation de PfSense :
— Etape 1 : Dans un premier temps, il faut télécharger la version ISO de PfSense à partir du son
site offieciel www.pfsense.org .
Figure 4.6: Télechargement de l’image ISO de PfSense
— Étape 2 : Ensuite, on doit créer une nouvelle machine virtuelle et choisir le système à virtualisé
avec les nécessaires configurations :
-taille de la RAM
-taille du disque dur
-nombre de processeur
52
Annexes
Figure 4.7: Configuration de la RAM
— Étape 3 : Dans cette étape, nous allons configurer les quatre cartes réseaux qu’on va utiliser
pour établir la liaison de notre serveur PfSense dans notre architecture.
Figure 4.8: Configuration des cartes réseaux
53
Annexes
— Étape 4 : Par la suite, il est nécessaire de confirmer que vous voulez réellement installer PfSense
Figure 4.9: Installation de PfSense
— Étape 5 : Dans cette étape, nous allons affecter les interfaces réseaux : EM0 pour le réseau
WAN, EM1 pour le réseau LAN, EM2 pour le réseau OPT1 et EM3 pour le réseau OPT2.
Figure 4.10: Affectation des interfaces réseaux
54
Annexes
— Étape 6 : Maintenant, on doit affecter une adresse IP pour l’interface OPT1 .
Figure 4.11: Affectation d’une adresse IP à l’interface OPT1
— Étape 7 : En dernier lieu, notre serveur PfSense est prêt pour la configuration.
Figure 4.12: L’interface de PfSense
55
Annexes
Configuration du PfSense :
— Étape 1 : L’interface WAN sera configuré entant qu’un client DHCP .
Figure 4.13: Configuration de l’interface WAN
— Étape2 : On a choisi l’interface sur laquelle nous souhaitons activer le serveur DHCP ( La
configuration d’adresse IP (IPV4) sera statique ). Dans notre cas, les interfaces sont "LAN" ,
"OPT1" , "OPT2" .
Figure 4.14: Configuration de l’interface LAN
56
Annexes
Figure 4.15: Configuration de l’interface OPT1
Figure 4.16: Configuration de l’interface OPT2
Configuration du FireWall (Rules) :
Une fois les interfaces sont tous crées, une étape de sécurité primordiale est celle d’appliquer
les autorisations d’accès entre les interfaces selon notre besoin. La figure 4.5 présente la liste
des contrôles d’accès appliqués à l’interface WAN et la figure 4.6 présente la liste des contrôles
de l’interface LAN.
57
Annexes
— Étape 1 : les régles de l’interface WAN sont par défaut.
Figure 4.17: Au niveau de l’interface WAN
— Étape 2 : les régles de l’interface LAN sont créer selon les besoins du TOPNET ( Autorisation
du port 443 et 80)
Figure 4.18: Au niveau de l’interface LAN
58
Annexes
Annexe 3.
Dans ce troixiéme annexe, nous allons décrire les étapes d’installation de MYSQL server et sa
configuration nécessaire.
4.1 Configuration de la base de donnée
— Étape 1 : Puisque le service SSH est bloqué par défaut au niveau de la VM du Bitnami "BD",
on a supprimé le fichier du blocage puis on a réactivé le service.
Figure 4.19: Activation du service SSH
— Étape 2 : Maintenant, on peut accéder à la base de donnée en tant qu’administrateur, mais la

connexion à distance au service MySql est bloquée par défaut (Firewall/Serveur MYSQL).
Pour résolu ce problème, on doit :
59
Annexes
* Ouvrir le port 3306 (TCP) dans le pare-feu du serveur
Figure 4.20: Autorisation du protocole TCP
* Mettre cette ligne en commentaire
Figure 4.21: Autorisation d’accès par le commentaire
60
Annexes
* Création d’une base de donné nommé ’RADIUS’ puis la création d’un compte utilisateur
Radius avec l’association des privilèges
Figure 4.22: Création d’un utilisateur
61
Annexes
Annexe 4.
Dans cet annexe, nous allons décrire les étapes d’installation et de le configuration du package
FreeRADIUS.
Installation du FreeRadius :
— Le package freeRadius est installé à partir de gestionnaire des packages. Donc nous allons le
télécharger et l’installer comme suit.
Figure 4.23: Installation du packages FreeRadius
— Installation réussite
Figure 4.24: Installation réussite
62
Annexes
Configuration du FreeRadius :
— Création des interfaces :
Pour que freeRadius soit bien fonctionnel, nous allons créer les trois interfaces « Authentification
», « Accounting » et « status » . Ces trois interfaces contiennent la configuration des ports
nécessaires.
Figure 4.26: Création de l’interface Accounting
63
Annexes
Figure 4.27: Création de l’interface status
— Configuration du NAS/Clients :
NAS/Client est le système à travers lequel s’effectuer l’authentification. Dans la zone de texte
« Client IP Address » Nous allons taper l’adresse de l’interface LAN du pare-feu car nous
voulons authentifier tous les utilisateurs du réseau.
Figure 4.28: Configuration du NAS Clients
Figure 4.29: Liste des NAS Clients
64
Annexes
Annexe 5.
Dans cet annexe, nous allons décrire les étapes de Intégration de la de FreeRadius avec la Base
de donnée et le portail captif :
Intégration de la Base de donnée avec le FreeRadius :
— Étape 1 :On récupére le fichier schéma.sql du FreeRadius pour la création des tables.
Figure 4.30: Récupération du fichier.sql
65
Annexes
— Étape 2 :On exécute le fichier d’où la création des tables.
Figure 4.31: Exécution du fichier
— Étape 3 :Lors de l’authentification les informations de l’utilisateur qui demande l’accès serons
récupérés de la base de donnée de type MySql.
Figure 4.32: Intégration freeRadius avec MySql (1)
66
Annexes
Figure 4.33: Intégration freeRadius avec MySql (2)
L’intégration du portail captif avec le FreeRadius
Figure 4.34: Choix de l’interface a exploité
Encore un peu plus bas dans la fenêtre, nous accédons à une rubrique « Authentification« .
C’est dans cette partie qu’il faut choisir le mode d’authentification de nos clients .
Figure 4.35: Choix du mode d’authentification
67
Annexes
— Pour installer le module pdo-mysql, on a tapeé ceci dans la console du shell.
Figure 4.36: Installation du paquet PDO
Figure 4.37:
68
PÌl
Rw§ ...An¡ Tyr` TlA Plm Rw§ ...An¡ Tyr` TlA Plm Rw§ ...An¡ Tyr` TlA Plm Rw§
Rw§ ...rWF rK` ¤d ¨ wk§ ºAr ...An¡ Tyr` TlA Plm Rw§ ...An¡ Tyr` TlA Plm
ºAr ...An¡ Tyr` TlA Plm Rw§ ...rWF rK` ¤d ¨ wk§ ºAr ...An¡ Tyr` TlA Plm
Rw§ ...rWF rK` ¤d ¨ wk§ ºAr ...An¡ Tyr` TlA Plm Rw§ ...rWF rK` ¤d ¨ wk§
ºAr ...An¡ Tyr` TlA Plm Rw§ ...rWF rK` ¤d ¨ wk§ ºAr ...An¡ Tyr` TlA Plm
nkm§ ...rWF rK` ¤d ¨ wk§ ºAr ...An¡ Tyr` TlA Plm Rw§ ...rWF rK` ¤d ¨ wk§
...An¡ Tyr` TlA Plm Rw§ Exemple ici A Plm XF¤ ¨ Tyny¯ ¤r Aml tk
Aml Hm E¤A d ºAr : yAf Aml
Résumé
Mettez le resumé en français ici... Mettez le resumé en français ici... Mettez le resumé en français
ici... Mettez le resumé en français ici... Merci de ne pas dépasser les dix lignes. Mettez le resumé
en français ici, merci de ne pas dépasser les dix lignes. Mettez le resumé en français ici, merci de
ne pas dépasser les dix lignes. Mettez le resumé en français ici, merci de ne pas dépasser les dix
lignes. Mettez le resumé en français ici, merci de ne pas dépasser les dix lignes. Mettez le resumé
en français ici, merci de ne pas dépasser les dix lignes. Mettez le resumé en français ici, merci de
ne pas dépasser les dix lignes. Mettez le resumé en français ici, merci de ne pas dépasser les dix
lignes. Mettez le resumé en français ici, merci de ne pas dépasser les dix lignes.
Mots clés : Merci de ne pas dépasser les cinq mots
Abstract
Put the English abstract here, put the English abstract here, put the English abstract here, put
the English abstract here, put the English abstract here, put the English abstract here... Please
don’t exceed ten lines, Please don’t exceed ten lines, Please don’t exceed ten lines, Please don’t
exceed ten lines. Put the English abstract here, please don’t exceed ten lines. Put the English
abstract here, please don’t exceed ten lines. Put the English abstract here, please don’t exceed
ten lines. Put the English abstract here, please don’t exceed ten lines. Put the English abstract
here, please don’t exceed ten lines. Put the English abstract here, please don’t exceed ten lines.
Put the English abstract here, please don’t exceed ten lines. Put the English abstract here,
please don’t exceed ten lines.
Keywords : Please don’t use more than five keywords
[email protected] : ¨¤rtk¯ d§rb 71 222 222 : HAf 71 111 111 : Ah Hw - ryb AfR - C® ry h
Rue du Lac Malaren, Les Berges du Lac 1053 Tunis Tél : 71 111 111 Fax : 71 222 222 Email : [email protected]
[email protected] : ¨¤rtk¯ d§rb 71 706 698 : HAf 71 706 164 : Ah TA§C 2080 ¨¤CAb A§r w h 2
2, Abou Raihane Bayrouni 2080 l’Ariana Tél : 71 706 164 Fax : 71 706 698 Email : [email protected]

PFEbouabid PDF

Transféré par

Droits d'auteur :

Formats disponibles

PFEbouabid PDF

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

PFEbouabid PDF

Transféré par

Droits d'auteur :

Formats disponibles

République Tunisienne

Ministère de l’Enseignement Supérieur

Université de Tunis El Manar

Institut Supérieur d’Informatique d’El Manar

Rapport de Projet de Fin d’Études

Présenté en vue de l’obtention du

Diplôme National de Licence Appliquée en Sciences Technologies

Talel BOUZAYENI et Maryem ABID

Mise en place d’un portail captif PfSense

Encadrant professionnel : Monsieur El Baldi FERID Ingénieur R&D

Réalisé au sein de Topnet

Année Universitaire 2018 - 2019

Ministère de l’Enseignement Supérieur

Université de Tunis El Manar

Institut Supérieur d’Informatique d’El Manar

Rapport de Projet de Fin d’Études

Présenté en vue de l’obtention du

Diplôme National de Licence Appliquée en Sciences Technologies

Talel BOUZAYENI et Maryem ABID

Mise en place d’un portail captif PfSense

Encadrant professionnel : Monsieur El Baldi FERID Ingénieur R&D

Année Universitaire 2018 - 2019

Encadrant professionnel, Monsieur El Baldi FERID

Encadrant académique, Monsieur Ben Gouissem BECHIR

A mon cher pére,

A mes soeurs YASMINE , RAJE , MALEK

A mon cher SLIM

A mon cher binome

A mes chéres amies HAJER et HAFFAR

A tous ceux que j’aime et ceux qui m’aiment.

1 Présentation du projet et Spécification des besoins : 2

2 Géneralités sur les portails captifs 7

2.1 Procédure d’authentification par portail captif . . . . . . . . . . . . . . . . . . . . . 9

3.1 Architecture détaillée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.27 Schéma explicatif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4.1 Télechargement de l’image ISO de GNS3 . . . . . . . . . . . . . . . . . . . . . . . . . 49

Tableau 1.1 Comparaison des solutions de portails captifs . . . . . . . . . . . . . . . . . 13

— GISI = Génie Informatique des Systèmes Industriels

— GLSI = Génie Logiciel et Systèmes d’Information

— GTR = Génie des Télécommunications et Réseaux

2 Présentation du cadre du projet . . . . . . . . . . . . . . . . . . . . . . . 4

3 Spécification des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Ce chapitre a pour objectif la présentation de l’organisme d’accueil «TOPNET» et ses

1.1 Présentation de l’organisme d’accueil :

1.1.1 Organisme d’accueil[2]

Figure 1.1: logoentreprise

TOPNET fournit une vaste gamme de produits et de services :

• Des modes d’accès à internet ( mobile , ADSL ..) ;

1.1.2 Óbjectifs de l’entreprise :

En outre , l’entreprise TOPNET s’engage à accentuer sa place dans le marché en utilisant

1.2 Présentation du cadre du projet

1.2.1 Description du projet

• Points d’accès reliés à un réseau IP .

1.2.2 Solution proposée

o La configuration et la mise en place des points d’accès.

1.3 Spécification des besoins

1.3.1 Sécurisation des accès Internet avec un portail captif

1.3.2 Authentification des utilisateurs

1.3.3 Filtrage de trafic