Docstoc

Authentification

Document Sample
Authentification Powered By Docstoc
					       AUTHENTIFICATION




 Mise en œuvre et configuration d’une architecture d’authentification,

                     Introduction au protocole RADIUS




Robert GUIRAUDET et Daddy KABASELE WA KABASELE          TSRIT 2009 - 2010
                                       Sommaire
I. L’authentification                                                                  4
   A. Définition                                                                       4
   B. L’authentification sur la machine locale                                         4
   C. L’authentification Centralisée                                                   4
     1. Le besoin d’authentification                                                   4
     2. Les acteurs de l’authentification                                              4
     3. Le théâtre de l’authentification                                               5
   D. Notions introductives à l’authentification                                       6
     1. La cryptographie, qu’est-ce que c’est ?                                        6
     2. La fonction de hachage                                                         6
     3. Les certificats                                                                7
   E. Standards et protocoles de liaison liés à l’authentification                     8
     1. 802.1x                                                                         8
     2. PPP                                                                            9
   F. Les protocoles d’authentification                                               10
      1. Les protocoles d’authentification liés à la trame PPP                        10
      2. EAP (Extensible Authentication Protocol)                                     10
   G. RADIUS                                                                          11
     1. Le protocole RADIUS                                                           11
     2. Le serveur RADIUS                                                             13
II. Le Projet Authentification                                                        14
   A. La Problématique                                                                14
   B. Propositions                                                                    14
III. Mise en œuvre locale                                                             16
   A. CONFIGURATION DE TEST                                                           16
   B. OUTILS DE GESTION ET D'ANALYSE                                                  16
     1. Accès console :                                                               16
     2. Webmin                                                                        17
     3. WireShark                                                                     18
     4. Tcpdump                                                                       19
   C. PROBLÈMES RENCONTRÉS                                                            20
   D. MISE EN PRODUCTION                                                              20
   E. ANNEXES A LA MISE EN OEUVRE LOCALE                                              21
     1. DOMAINES VIRTUALISES XEN                                                      21
   F. SECURISATION SSL DE FREERADIUS                                                  22
      1. Clés publiques easy-rsa :                                                    22
      2. Paramètres du certificat :                                                   22
      3. création des clés (clé publique + clé privée = biclé) :                      23



Authentification : Robert GUIRAUDET et Daddy KABASELE WA KABASELE TSRIT 2009 – 2010    2
      4. création d'un certificat pour le serveur freeradius :                         23
      5. Paramètres Diffie-Hellman (côté serveur d'une connexion ssl/tls)              23
      6. Création des certificats clients (un par personne autorisée à se connecter)   24
      7. Copie des certificats                                                         24
   G. INSTALLER LE SERVEUR FREERADIUS ET LA BASE DE DONNÉES
   MYSQL                                                                               24
     1. Configuration de mysql :                                                       24
     2. Configuration de freeradius :                                                  25
     3. Test freeradius en local :                                                     26
   H. SUPPLICANT DEBIAN                                                                27
     1. Créer un fichier /etc/wired.conf avec :                                        27
     2. Tester le client en mode debug :                                               27
     3. Lancer wpa_supplicant à chaque démarrage et en tâche de fond:                  28
   I. SUPPLICANT WINDOWS XP                                                            29
   J. PARAMETRAGE DU CLIENT RADIUS DANS UN SWITCH HP PROCURVE
   3400CL                                                     30
      1. Commandes CLI :                                      30
      2. Déroulement de l'authentification :                  31
   K. DEBUG RADIUS D'UNE AUTHENTIFICATION ACCEPTÉE                                     31
   L. AFFECTER PLUSIEURS ADRESSES IP À UNE INTERFACE RESEAU                            32
   M. COMPILATION DE PAQUETS SOURCES                                                   33
   N. DEBUGGER UN PROBLEME DNS/PROXY/ROUTAGE                                           33
   O. INSTALLATION DE WEBMIN                                                           34
   P. INSTALLER UN ANALYSEUR DE TRAME DANS UN DOMAINE INVITÉ                           34
IV. Mise en œuvre distante                                                             35
   A. Les choix                                                                        35
     1. Généralité                                                                     35
     2. L’addition s’il vous plait… : le logiciel serveur                              35
     3. …est toujours Roi : le logiciel client                                         35
     4. Le choix du protocole                                                          36
   B. Installation et configuration du serveur                                         37
     1. Installation                                                                   37
     2. Les fichiers de configuration du serveur                                       37
     3. XCA et certificats                                                             39
   C. Configuration du client RADIUS s/ Windows 2003 serveur                           45
   D. Configuration d’un supplicant sous Windows XP                                    50
   E. Analyse                                                                          54
     1. Place à la mise en place                                                       54
     2. Les dents de la mer : captures de trames                                       55
   F. Conclusion                                                                       57
V. Conclusion du projet                                                                58




Authentification : Robert GUIRAUDET et Daddy KABASELE WA KABASELE TSRIT 2009 – 2010     3
I. L’authentification
     A. Définition
En informatique, l’authentification est le procédé permettant de vérifier l’identité d’une
personne ou d’une machine qui voudrait se joindre à un réseau informatique privé dans le but
d’utiliser des ressources partagées par ce réseau.
Il existe plusieurs procédés d’authentification dont les plus connus consistent à recueillir
auprès du demandeur de l’authentification un identifiant et un mot de passe, ou encore par
l’analyse des informations propres à une machine, envoyées par le demandeur
d’authentification.
De ce fait, bien que n’étant pas le seul, les procédés d’authentification jouent un rôle
prépondérant dans la sécurisation d’un réseau informatique privé.

     B. L’authentification sur la machine locale
Dans les réseaux informatiques de très petite taille, les solutions d’authentification des
personnes peuvent se faire en local, cela veut dire que les utilisateurs s’authentifient
directement sur le poste de travail informatique auquel ils veulent avoir accès. Quant aux
restrictions d’accès physique des machines sur le réseau informatique, elle est quasi
inexistante. Ce qui peut être acceptable sur un réseau de petite taille ne l’est pas forcément sur
des réseaux de plus grandes envergures ou les personnes ou machines essayant de se joindre à
un réseau ne sont pas forcément connues et l’accès aux ressources sensibles partagées sur le
réseau informatique n’est pas contrôlé.

     C. L’authentification Centralisée

1. Le besoin d’authentification
Le processus d’authentification centralisé est une scène assez classique en quatre actes avec
pour rôle principale un besoin d’authentification. Le besoin d’authentification vient de la
volonté d’accéder à des ressources se trouvant sur un réseau privée protégé par une méthode
d’authentification quelconque. Le besoin d’authentification, pour être comblé, s’adjoindra
alors les services de plusieurs éléments constitutifs du réseau.

2. Les acteurs de l’authentification
Dans la mise en place d’une solution d’authentification centralisée dans un parc informatique
composé de personnes ou de machines utilisant des techniques d’authentifications différentes,
il y’a besoin d’une structure permettant l’authentification de tous. Le besoin d’authentification
se composera alors de trois adjuvants :
   Le demandeur d’authentification, c’est l’initiateur de l’authentification, il parle un
    langage compréhensible par l’agent relais d’authentification et dans la généralité il n’a que
    lui pour seul interlocuteur dans le processus d’authentification.




Authentification : Robert GUIRAUDET et Daddy KABASELE WA KABASELE TSRIT 2009 – 2010             4
   L’agent relais, c’est l’agent chargé de recueillir les demandes d’authentifications
    provenant du demandeur d’authentification, de les analyser puis de les interpréter afin de
    pouvoir les transmettre à l’agent authentificateur.
   L’agent authentificateur, au bout de la chaîne du processus d’authentification, il est
    chargé de vérifier et de valider les informations qui lui sont transmises. De ce fait, il est
    dans le processus d’authentification le seul à avoir accès au registre des personnes ou des
    machines habilitées à se joindre au réseau informatique.




                                                        Agent
                   demandeur                                                                Agent
                d’authentification                       relais                       d’authentification

                                      Identification
                                     et demande de
                                        connexion
                                                                    Interprétation et
                                                             envoi des info. d’identification



                                                                      Confrontation
                                                                  positive et acceptation
                                      autorisation
                                     de connexion




                   Processus d’authentification d’un poste de travail à un réseau privé.



3. Le théâtre de l’authentification
   Acte 1, la demande : Le demandeur d’authentification déclare ses identifiants auprès de
    l’agent relais, la demande est analysée et traitée par ce dernier, qui le soumet ensuite à
    l’agent d’authentification.
   Acte 2, soumission : L’agent relais d’authentification soumet à l’agent authentificateur la
    demande d’authentification émise par le demandeur d’authentification après l’avoir
    interprétée dans un format compréhensible par celui-ci.
   Acte 3, authentification : après avoir recueilli les données d’authentification qui lui sont
    soumises par l’agent relais, l’agent authentificateur fait une concordance entre les
    informations contenues dans la base données utilisateur et celles que lui soumet l’agent
    relais.
   Acte 4, la réponse : une fois la demande d’authentification soumise, analysée et traitée, le
    résultat de ce processus est renvoyé à l’agent relais qui autorise ou pas le demandeur
    d’authentification à se joindre au réseau privé.
Le nombre d’actes que comporte un processus d’authentification diffère selon la solution
d’authentification utilisée, mais en règle générale, la négociation comporte au minimum
quatre actes.




Authentification : Robert GUIRAUDET et Daddy KABASELE WA KABASELE TSRIT 2009 – 2010                        5
                                                                                         Réseau XYZ




                                                                    6
                            5
                                                     4
                            1                                       2
                                                           Agent
             demandeur                                                                   3
          d’authentification                               relais



                                                                                               Agent
                                                                                         d’authentification


                                Modem d’accès internet avec authentification préalable



     D. Notions introductives à l’authentification

1. La cryptographie, qu’est-ce que c’est ?
La cryptographie est une science de la cryptologie, du grec : cruptos (étymologiquement la
science du secret), elle s’attache à protéger et à assurer la confidentialité, l’authenticité et
l’intégrité des messages.
En informatique on utilise essentiellement deux modes de cryptographie :

  a) La cryptographie symétrique
Dite à clé secrète, la « clé » est une information permettant de chiffrer et de déchiffrer un
message et sur laquelle repose toute la sécurité du message.

  b) La cryptographie asymétrique
Dite cryptographie à clé publique, elle repose sur l’utilisation de deux clés, l’une publique qui
est diffusé et connue de tous, elle permet le codage du message et l’autre privée qui est gardé
secrète et permet le décodage du message.
La connaissance du fonctionnement des procédés cryptographique est un préalable quant au
choix final de la méthode d’authentification.

2. La fonction de hachage

  a) Définition
On nomme fonction de hachage une fonction particulière qui, à partir d’une donnée fournie en
entrée, calcule une empreinte servant à identifier rapidement, la donnée initiale. Les
algorithmes de hachage les plus utilisés sont :

  b) L’algorithme MD5
(Message-Digest algorithm 5) est un algorithme de hachage qui fournit l’empreinte
numérique d’une donnée en entré sur 128 bits (soit 32 caractères en notation hexadécimale).


Authentification : Robert GUIRAUDET et Daddy KABASELE WA KABASELE TSRIT 2009 – 2010                           6
En 1996 est découvert une faille qualifiée de grave compromettant la fiabilité de l’algorithme,
en effet avec une bonne puissance de calcule il était devenu possible de produire une donnée
ayant la même empreinte numérique qu’une autre. Aujourd’hui MD5 est essentiellement
utilisé dans le contrôle d’intégrité de fichiers numériques.

  c) L’algorithme SHA-1
(Secure Hash Algorithm 1) est un algorithme de hachage conçu par la NSA (Agence
National de Sécurité) des Etats-Unis. Elle produit l’empreinte numérique d’une donnée en
entré sur 160 bits (soit 40 caractères en notation hexadécimale).

3. Les certificats

 a) Définition
Un certificat numérique est une carte d’identité numérique dont l’objet est d’identifier une
            entité physique ou non. Le certificat numérique est un lien entre l’entité physique
            et l’entité numérique, l’autorité de certification chargée de l’enregistrement et du
            recensement des certificats numérique, fait loi de tiers de confiance et atteste du
            lien entre l’identité physique et l’entité numérique.

  b) La norme X.509
X.509 est une norme de cryptographie asymétrique qui établit un format standard de certificat
numérique et un algorithme pour la validation de chemin de certification, c’est la norme la
plus utilisée.
Dans le système X.509 une autorité de certification attribue un certificat liant une clé publique
à un nom distinct (Distinguish Name), une adresse électronique ou un enregistrement DNS
(Domain Name System). Un certificat émis par une autorité de certifications est appelé
certificat racine.

  c) L’algorithme RSA
RSA du sigle de ses concepteur Ron Rivest, Adi Shamir et Len Adleman est un algorithme
de chiffrement très utilisé dans les échanges sur le réseau public Internet, en 2002 il servait
encore à protéger les codes nucléaires des armées américaines et russe. Utilisée en
cryptographie asymétrique, elle produit une clé numérique appelé clé RSA et peut comporter
jusqu'à 4096 bits (soit 1024 caractères en notation hexadécimale).

   d) Principe de fonctionnement
Concrètement un utilisateurs A télécharge un certificat publiques émis par un autre utilisateur
B l’ordinateur de A va contrôler la validité et les paramètres de codage en se référant au
certificat public émis par une autorité de certification C, l’utilisateur B effectue la même
manipulation que l’utilisateur A, dans le cas ou les certificats de deux utilisateurs sont
concordantes avec les paramètres de l’autorité de certification C, alors la communication entre
les machines des deux utilisateurs peut avoir lieu.




Authentification : Robert GUIRAUDET et Daddy KABASELE WA KABASELE TSRIT 2009 – 2010            7
                 Certificat racine                     Utilisateur                         Serveur
                         C                                  A                                 B

                                                                      Téléchargement
                                                                     Certificat public B
                               Confrontation B et C


                                     Hachage positif

                                                                     Etablissement de la
                                                                         connexion




              Schéma simplifié de la validation d’un certificat serveur à l’aide d’un certificat racine




     E. Standards et protocoles de liaison liés à l’authentification

1. 802.1x
Le standard 802.1x mis au point en 2001, permet de contrôler l'accès physique aux
équipements d'infrastructure réseaux et par ce biais, de relayer les informations liées aux
dispositifs d'identification en s'appuyant sur des mécanismes d'authentification existant. Cette
authentification intervient avant tout mécanisme d'auto configuration (DHCP, PXE,...).
Dans ce modèle trois entités interagissent, le système à authentifier ou Supplicant, le relais
d’authentification ou Authenticator et un serveur d'authentification ou authentication server.
L’Authenticator se comporte comme un mandataire (proxy) entre le système à authentifier et
le serveur d'authentification, si l'authentification réussit, l’Authenticator donne l'accès à la
ressource qu'il contrôle.




Authentification : Robert GUIRAUDET et Daddy KABASELE WA KABASELE TSRIT 2009 – 2010                       8
Le standard 802.1x s'appuie sur d'autres standards existants. Le dialogue utilise le protocole
EAP (PPP Extensible Authentication Protocol). Entre le système à authentifier et
l'Authenticator on utilise des trames Ethernet spécifiques EAPOL (EAP Over Lan =
encapsulation directe de EAP dans Ethernet). Le dialogue entre l'Authenticator et le serveur
d'authentification se fait par une simple « ré-encapsulation » des paquets EAP dans un format
qui convient au serveur d'authentification, sans modification de son contenu.

2. PPP
Le protocole PPP (Point-to-Point Protocol) est un protocole de transmission pour l’Internet,
il permet d’établir une connexion entre deux hôtes sur une liaison point à point, il fait partie
des protocoles de la couche de liaison (couche 2) du modèle OSI.
PPP s’appuie sur trois composants :
   L’encapsulation des datagrammes des protocoles supérieurs,
   Des protocoles de contrôle NCP (Network Contorl Protocols) qui ont pour rôle de lancer
    et configurer plusieurs protocoles de la couche réseau (couche 3) du modèle OSI.
   Le control de liaison avec LCP (link Control Protocol), qui a pour rôle d’établir, de
    configurer, de tester et de fermer la liaison de données
La trame du protocole PPP ressemble à celle du protocole HDLC avec un champ déterminant
le protocole de niveau supérieur transporté et qui vient s’ajouter derrière le champ de
supervision.

       Drapeau
           Supervision                                         Paquet                 Drapeau




         Adresse              Protocole                                               FCS

                                              Format d’une trame PPP


Les valeurs les plus classiques du champ de protocole sont les suivantes :
   0x0021 : IPv4
   0x002B : IPX (Internetwork Packet eXchange)
   0x002D : TCP/IP en-tête compressé
   0x800F : IPv6
Aujourd’hui, le protocole PPP est encapsulé dans IP à l’aide de protocoles de tunneling tel
que PPTP à des fins de fin de mise en place de réseau privé virtuel.


Authentification : Robert GUIRAUDET et Daddy KABASELE WA KABASELE TSRIT 2009 – 2010             9
     F. Les protocoles d’authentification
Il existe plusieurs protocoles d’authentification selon le type de connexion utilisée.

1. Les protocoles d’authentification liés à la trame PPP
   PAP (Password Authentication Protocol) Authentification par mot de passe, le
    protocole PAP est un protocole très simple a implémenter mais sa principale faiblesse et
    non pas des moindres est qu’il transmet en clair les données d’authentification sur le
    réseau. Le dialogue d’authentification avec PAP comporte trois éléments, la requête
    d’authentification, l’acquittement positif, l’acquittement négatif.
   CHAP (Challenge-Handshake Authentication Protocol) est un protocole
    d’authentification par challenge son objectif est que le poste utilisateur s’identifie auprès
    du serveur d’authentification sans échange de mot de passe en clair sur le réseau, le
    processus d’identification avec CHAP se déroule en 5 étapes :
     Demande de connexion d’un poste utilisateur.
     Après établissement de la connexion, l’Authenticator envoi une valeur de hachage
      d’au plus 255 octets (challenge) générée aléatoirement à l’aide de l’algorithme de
      hachage MD5.
     Le poste utilisateur lui répond avec une valeur de hachage calculée sur la base du
      challenge et du mot de passe.
     L’Authenticator effectue la même opération (ce qui nécessite la connaissance du mot
      de passe) et compare avec le résultat reçu.
     L’Authenticator accepte ou refuse l’accès en le notifiant au poste utilisateur. Dans le
      cas d’une notification positive, à intervalle régulier, l’Authenticator renvoi un nouveau
      défi au poste utilisateur.
   MS-CHAP ce protocole est la version Microsoft du protocole CHAP, elle existe en deux
    versions MS-CHAP v1 le challenge et utilise une valeur de hachage de 8 octets tandis que
    MS-CHAP v2 utilise une valeur de hachage de 16 octets
Bien que le protocole CHAP contrairement à PAP assure un certain niveau de cryptage du
mot de passe, l’identifiant et transmis en clair du Supplicant vers l’Authenticator et de
l’Authenticator vers le serveur RADIUS ce qui peut constituer une faiblesse de sécurité.

2. EAP (Extensible Authentication Protocol)
EAP plus qu’un protocole est un ensemble de bibliothèques et de conventions
d’authentification. EAP implémente des fonctions communes aux mécanismes
d’authentifications dont la principale est l’authentification réciproque du Supplicant et du
serveur, ces mécanismes sont appelés méthodes EAP et on en compte aujourd’hui environ une
quarantaine dont :
   EAP-MD5 : standard ouvert, cette méthode EAP utilise la fonction de hachage MD5 et
    s’apparente dans son mode de fonctionnement au protocole CHAP à l’exception du fait
    que le processus d’authentification est accompli entre le Supplicant et le serveur
    d’authentification sans intervention de l’authenticator.




Authentification : Robert GUIRAUDET et Daddy KABASELE WA KABASELE TSRIT 2009 – 2010           10
             demandeur                                 Agent                                Agent
          d’authentification                           relais                         d’authentification


                           Connexion physique

                                    Ouverture d’un canal d’authentification

                                              Envoi d’un challenge

                                              Réponse au challenge

                                                                  Autorisation d’accès

                           Autorisation d’accès


                               Schéma d’authentification de la méthode EAP-MD5


   EAP-TLS : un autre standard ouvert, EAP-TLS offre un très bon niveau de sécurité, il
    utilise le certificat numérique SSL/TLS pour l'établissement d’une communication
    sécurisée entre le serveur et le Supplicant qui permettra ensuite l’identification.
    L’obligation de disposer de certificat numérique coté client pour l’authentification rend
    cette méthode très contraignante à déployer sur un parc de postes utilisateurs conséquent.
   EAP-TTLS : également un standard ouvert, il se démarque d’EAP-TLS par l’utilisation
    d’un certificat numérique mais uniquement du côté du serveur d’authentification. PEAP
    est une autre implémentation de ce protocole, il a été développé conjointement par
    Microsoft, RSA Security et Cisco Systems.
   Autres méthodes EAP : d’autres méthodes EAP ont été développés pour
    l’authentification d’autres types de matériels tels que les téléphones cellulaires, ou les
    matériels se connectant au réseau UMTS (Universal Mobile Télécommunications
    Systems)
Le mode de fonctionnement des méthodes EAP diffère de celui que l’on a avec les protocoles
PAP ou CHAP. EAP implique une communication indirecte entre le Supplicant et le serveur
d’authentification. Cette communication s’établit d’abord entre le Supplicant et
l’Authenticator en s’appuyant sur EAP, puis entre l’Authenticator et le serveur
d’authentification par encapsulation en s’appuyant sur le protocole RADIUS. On dit que
l’Authenticator est transparent.

     G. RADIUS

1. Le protocole RADIUS
La communication entre un client et un serveur est comme tous processus de communication,
encadré par un protocole. Au début des années 1990 en plein balbutiement de la connexion
internet par modem RTC (Réseau Téléphonique Commuté), il y’a eu un besoin d’authentifier
des usagers internet a partir de multiples serveurs en utilisant une seule et même base


Authentification : Robert GUIRAUDET et Daddy KABASELE WA KABASELE TSRIT 2009 – 2010                        11
utilisateur. Il alors été mis au point le protocole RADIUSqui est l’acronyme de Remote
Authentication Dial-In User ou Authentification des usagers téléphonique distant en français.
Le protocole RADIUS, permet d’assurer le transport des informations d’authentification de
façon normalisé, l’opération d’authentification est initié par un client du protocole RADIUS
que l’on nomme Authenticator, c’est le relais de connexion, dans la pratique l’Authenticator
peut être un boitier d’accès distant, un commutateur réseau ou un autre système serveur sur le
réseau.

                   Code          Longueur                           Attributs et valeurs




                            ID           Authentificateur

                                 Format général d’un paquet du protocole RADIUS




Le format général d’un paquet (constituant d’une trame Ethernet) du protocole RADIUS
comporte cinq champs :
   Le champ Code, ce champ d’un seul octet contient une valeur identifiant le type de
    paquet il s’agit de :
     Access-Request (code = 1),                       Paquet de demande d’accès
     Access-Accept (code = 2),                        Paquet de réponse à un identifiant valide
     Access-Reject (code = 3),                        Paquet de réponse à un identifiant non valide
     Access-Challenge (code = 11),                    paquet d’envoie d’une empreinte numérique à concaténer
                                                       avec le secret partager.

   Le champ ID, ce champ d’un seul octet contient une valeur permettent au client RADIUS
    d’associer les requêtes et les réponses.
   Le champ longueur, champ de seize octets contenant la longueur totale du paquet.
   Le champ Authentificateur, également de seize octet a pour but de vérifier l’intégrité
    des paquets. On distingue deux types d’authentificateur :
     Authentificateur de requête, inclus dans les paquets de type Access-Request et
      envoyé par le client RADIUS, sa valeur et calculer aléatoirement.
     Authentificateur de réponse, inclus dans les paquets de type Access-(Accept, Reject,
      Challenge), sa valeur est calculée par le serveur d’authentification RADIUS à partir de
      l’algorithme de hachage MD5 sur une chaîne de caractère composé de la
      concaténation des champs code, ID, longueur, Authentificateur de requête, attributs et
      du secret partagé entre l’Authenticator et Le serveur d’authentification.




Authentification : Robert GUIRAUDET et Daddy KABASELE WA KABASELE TSRIT 2009 – 2010                       12
   Le champ Attribut, de valeur variable, ce champ contient l’ensemble des attributs et
    valeurs envoyées soit par l’Authenticator en requête, soit par le serveur en réponse.
    Chaque attribut possède un numéro d’attribut auquel est associé un nom. La valeur d’un
    attribut peut correspondre à l’un des types suivant :
     Adresse IP (‘4 octets)
     Date (4 octets)
     Chaine de caractères (jusqu'à 255 octets)
    Dans la terminologie RADIUS ces attributs sont appelés AVP (Attributes Value-Pair). Il
    existe un grand nombre d’attributs dans le protocole RADIUS, mais peu d’entre eux sont
    utile pour l’authentification par réseau non RTC.
            N°
         d’attribut
                                                     Champ Attributs et
             Valeur
                       Longueur                          Valeurs




                  AVP                                AVP                              AVP
                      Format général du champ attribut d’un paquet du protocole RADIUS


La principale faiblesse du protocole RADIUS compte tenu du rôle prépondérant qu’il occupe
dans le processus d’authentification est qu’il assure les échanges en clair entre l’Authenticator
et le serveur seul le mot de passe peut être crypté par hachage, ce qui impose une sécurisation
physique de ceux-ci.

2. Le serveur RADIUS
Les services d’authentification sont assurés par le service serveur appelé serveur RADIUS
dont la fonction première est d’assurer l’identification de poste utilisateur (Supplicant), ce
serveur pour traiter une requête d’authentification peut se connecter si nécessaire à une base
externe (base de données SQL, annuaire LDAP, comptes d'utilisateur de machine ou de
domaine).
La seconde fonction principale d’un serveur RADIUS est L’accounting (comptabilisation),
assurant la journalisation des connexions de postes utilisateurs, après connexion effective lors
d’un processus d’authentification réussie, l’Authenticator envoie au serveur RADIUS un
paquet « accounting-start » et lors de la déconnexion de celui-ci un paquet « accounting-
stop ».




Authentification : Robert GUIRAUDET et Daddy KABASELE WA KABASELE TSRIT 2009 – 2010           13
II. Le Projet Authentification
     A. La Problématique
Une entreprise possédant deux agences distantes l'une de l'autre souhaite que ses utilisateurs
site et nomades aient accès aux ressources réseau présentes dans les deux agences au travers
d'un réseau public non sécurisé.
Il est impératif pour des raisons évidentes de confidentialité que seules les personnes
authentifiées, puissent avoir accès aux ressources réseau de l'entreprise.
Il nous est demandé de proposer des solutions permettant de sécuriser l'accès de chaque
utilisateur aux ressources des deux agences.

     B. Propositions
Il est possible d'utiliser une solution d'authentification centralisée ou bien répartie entre les
deux agences. Dans ce cas là, en cas d'échec d'authentification locale, une authentification
distante sera demandée. Nous choisissons la solution décentralisée qui facilitera la
maintenance locale de la base de données des utilisateurs du réseau.




Pour les clients locaux et nomades, le dispositif d'authentification doit pouvoir fonctionner sur
plateforme linux ou Windows.




Authentification : Robert GUIRAUDET et Daddy KABASELE WA KABASELE TSRIT 2009 – 2010           14
Ce projet mettra en pratique le standard 802.1x afin d'authentifier les utilisateurs site et le
protocole point à point PPP (et dérivées) pour les utilisateurs nomades.
Un serveur RADIUS relié a une base de donnée (fichier texte, SQL ou LDAP) et à des clients
d'authentification RADIUS NAS (Network Access Server) sera mis en place au niveau de
chaque agence. RADIUS est un service présent dans Windows 2003 Server. Nous choisissons
plutôt d'utiliser la version libre FreeRADIUS afin de garder la main sur tous les paramétrages
nécessaires.
Le serveur RADIUS à besoin de connaître les éléments d'authentification de chaque
utilisateur. Pour cela il est possible d'utiliser un simple fichier texte, une base de donnée SQL
ou un service d'annuaire LDAP. Nous choisissons d'installer MySQL, un système de base
donnée open source très répandue et donc aisée à maintenir.
Il sera nécessaire également d'installer OpenSSL (certificats X509). Ceci est nécessaire pour
mettre en œuvre EAP-TLS (Extensible Authentication Protocol-Transport Layer Security),
méthode la plus sûre pour que serveurs et clients s'authentifient mutuellement.
Nous choisissons de virtualiser les serveurs car ceci facilite leur administration. Une machine
serveur sera installée dans chaque agence pour héberger FreeRADIUS et MySQL.




Authentification : Robert GUIRAUDET et Daddy KABASELE WA KABASELE TSRIT 2009 – 2010           15
III. Mise en œuvre locale
     A. CONFIGURATION DE TEST
Avant la mise en production, une version de test doit valider le projet.
 Sur une machine physique vierge, est installée une distribution DEBIAN dont on modifiera le
noyau à l'aide de paquets XEN.
En mode paravirtuel les performances des domaines virtualisés sont très proches d'un système
réel. De plus il est possible :
        d'attribuer des disques supplémentaires à chaud au système invité,
        d'augmenter la mémoire RAM à chaud,
        d'attribuer de la cpu supplémentaire,
        d'attribuer une nouvelle interface réseau à la volée,
        de migrer à chaud (sans arrêt du service).
Le domaine virtualisé hébergera un serveur FreeRadius ainsi qu'une une base de donnée
mysql.
L'accès au serveur RADIUS sera sécurisé par SSL
Un modèle de switch à été sélectionné pour sa capacité à implémenter le protocole 802.1x. Il
s'agit du HP ProCurve 3400.
Une machine cliente en multiboot Linux/Windows sera chargée de valider l'authentification
pour les deux systèmes d'exploitation les plus couramment utilisés par les utilisateurs finaux.
En annexes se trouvent les détails de l'installation, de la configuration et du débogage de
l'installation.

     B. OUTILS DE GESTION ET D'ANALYSE

1. Accès console :
Pour intervenir dans le domaine invité depuis le domaine 0 (le domaine 0 est le système qui
accueille les domaines virtualisés ) nous utiliserons la console tty1. On peut ainsi ouvrir une
session comme si on était au clavier de la machine virtuelle.
tsrit32:/home/ethern# xm console rad.tsrit.fr
Debian GNU/Linux 5.0 rad.tsrit.fr hvc0
rad.tsrit.fr login: root
Password:
Last login: Thu Jan 28 08:35:10 UTC 2010 on hvc0
Linux rad.tsrit.fr 2.6.26-2-xen-686 #1 SMP Wed Aug 19 08:47:57 UTC 2009 i686




Authentification : Robert GUIRAUDET et Daddy KABASELE WA KABASELE TSRIT 2009 – 2010               16
2. Webmin
WebMin est une interface web avec accès sécurisé par le protocole https qui nous permettra
de surveiller en un clin d'oeil la charge du disque dur, de la mémoire vive et du processeur du
domaine invité. Bien que Webmin s'emploie par le biais d'une interface web, il ne neécessite
pas pour autant d'avoir Apache installé : en effet ce logiciel dispose d'un mini-serveur web
dédié. Webmin nous sera très utile aussi pour intervenir sur la base de données MySql dans
laquelle sont stockés les paramètres d'authentification de chaque utilisateur.




Authentification : Robert GUIRAUDET et Daddy KABASELE WA KABASELE TSRIT 2009 – 2010          17
3. WireShark
Il arrive que l'on ait besoin de voir ce qui se passe réellement sur le réseau, paquet par paquet.
On utilise dans ce cas un « analyseur de trame ». Cet outil scrute tous les paquets qui
atteignent une interface réseau, et les affiche de manière plus lisible à l'utilisateur. Avec l'outil
WireShark disponible dans le système Linux et dans le système Windows, la représentation
graphique des paquets est organisée par couches successives, ce qui permet de visualiser
chacun des protocoles impliqués dans un paquet. Dans cet exemple seuls les paquets en
provenance ou à destination du switch HP ProCurve sont visibles grâce au filtre sur l'adresse
IP du switch. On voit de manière séparée les informations correspondant à la couche
physique, puis la couche ethernet 2, les informations du paquet IP, puis celles de la
communication UDP, puis enfin le résultat de la requête radius en tant que telle.




Authentification : Robert GUIRAUDET et Daddy KABASELE WA KABASELE TSRIT 2009 – 2010               18
Dans cet autre copie d'écran nous voyons le dialogue qui s'instaure lors d'une session
d'authentification 802.1x au moment de la connexion. La trame choisie transporte une
empreinte MD5 en guise de challenge :




4. Tcpdump
Tcpdump est l'ancêtre de WireShark. Son intérêt réside dans le fait qu'il fonctionnera en mode
console dans les domaines virtualisés dépourvus d'interface graphique. Dans l'exemple qui
suit, nous avons sélectionné le dialogue avec le switch HP ProCurve dont l'adresse est
10.2.245.131. Nous assistons ici à une authentification réussie (Access Accept).

rad:~# tcpdump host 10.2.245.131
[ 5120.358822] device eth0 entered promiscuous mode
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
09:42:26.651937 arp who-has rad.tsrit.fr tell 10.2.245.131
09:42:26.655937 arp reply rad.tsrit.fr is-at 00:16:3e:ea:2b:09 (oui Unknown)
09:42:26.651937 IP 10.2.245.131.1024 > rad.tsrit.fr.radius: RADIUS, Access Request (1), id: 0x98 length: 198
09:42:26.651937 IP rad.tsrit.fr.radius > 10.2.245.131.1024: RADIUS, Access Challenge (11), id: 0x98 length:
80
09:42:26.655937 IP 10.2.245.131.1024 > rad.tsrit.fr.radius: RADIUS, Access Request (1), id: 0x99 length: 227
09:42:26.655937 IP rad.tsrit.fr.radius > 10.2.245.131.1024: RADIUS, Access Accept (2), id: 0x99 length: 52




Authentification : Robert GUIRAUDET et Daddy KABASELE WA KABASELE TSRIT 2009 – 2010                       19
     C. PROBLÈMES RENCONTRÉS
J'ai souhaité valider également une solution avec un client RADIUS embarqué dans une
machine hôte plutôt que dans un switch. Malheureusement tous les outils développés que j'ai
essayé étaient conçus pour un usage sans-fil alors que l'usage souhaité était filaire. J'ai ainsi
testé, CoovaChilli, ChilliSpot, RadiusClient, PAM-RADIUS-AUTH et PYRAD sans succès.
La solution du switch s'est donc naturellement imposée.

     D. MISE EN PRODUCTION
La mise en situation réelle consiste d'abord à mettre en concordance la configuration des
machines et des programmes avec le plan d'adressage de l'entreprise.

Il faudra utiliser l'autorité de certification déjà en place dans l'entreprise pour la gestion des
certificats X.509 et redistribuer les nouvelles clés publiques et privées au niveau des serveurs
ainsi que chez tous les utilisateurs de TLS.

Il est nécessaire également de mettre à jour les paramètres de sécurité. Mots de passe de
sécurité utilisés par MySQL, FreeRadius, SSL, les clients RADIUS des switches.

Il faut aussi remplir la base de donnée MySQL avec les login et les mots de passe des
utilisateurs de l'entreprise.




Authentification : Robert GUIRAUDET et Daddy KABASELE WA KABASELE TSRIT 2009 – 2010             20
     E. ANNEXES A LA MISE EN OEUVRE LOCALE

1. DOMAINES VIRTUALISES XEN
La dernière version stable de Debian est installée depuis un miroir local grâce au mode PXE
de prise en main par le réseau.

  a) Nous installons l'hyperviseur xen et ses outils :
              # aptitude install xen-linux-system-2.6.26-2-xen-686
                  # aptitude install xen-tools
                  # reboot

  b) Modification du fichier de configuration de xen :
             # nano /etc/xen/xend-config.sxp
         On dé-commente la ligne suivante afin de parametrer :
                  (network-script network-bridge)
         On met en commentaire la ligne :
                  # (network-script network-dummy)
         On redémarre xen :
                  # /etc/init.d/xend restart

  c) Création des domaines invités :
       On créé un répertoire pour héberger les systèmes de fichier des domaines invités.
                  # mkdir -p /var/xen-vm
         On modifie le fichier de configuration des systèmes virtualisés :
                  # nano /etc/xen-tools/xen-tools.conf
                           dir= /var/xen-vm
                           gateway = 196.168.12.254
                           netmask = 255.255.255.0
                           broadcast = 196.168.12.255
                           dist = lenny
                           mirror = ftp://robert.tsrit2k.edu/debian/
                           serial_device = hvc0
                           disk_device = xvda
         On créé les domaines invités :
                  xen-create-image -- hostname=rad.tsrit.fr --ip 196.168.12.11 --role udev –force
                  xen-create-image -- hostname=sql.tsrit.fr --ip 196.168.12.12 --role udev --force
         On démarre le domaine invité :
                  xm create rad.tsrit.fr.cfg


Authentification : Robert GUIRAUDET et Daddy KABASELE WA KABASELE TSRIT 2009 – 2010            21
                  xm create sql.tsrit.fr.cfg
         Accès console :
                  xm console rad.tsrit.fr (CTRL + ] pour quitter).

   d) Synchronisation horloge des domaines invités :
Après un arrêt accidentel du serveur le domaine invité se désynchronise par rapport à
l’horloge fournie par Xen. Pour éviter ce problème, on va contraindre le domaine invité à
utiliser sa propre horloge.
Au niveau du domaine invité (domU), nous ajoutons dans /etc/sysctl.conf :
         xen.independent_wallclock=1
Au niveau de la machine hôte (dom0), dans /etc/xen/rad.tsrit.fr.cfg) nous ajoutons :
         extra="clocksource=jiffies"
Redémarrer le domaine invité




     F. SECURISATION SSL DE FREERADIUS
l'installation d'OpenVpn nous permet d'obtenir des scripts SSL qui vont nous simplifier la
tâche.
         # aptitude install openvpn



1. Clés publiques easy-rsa :
Copie des scripts exploitant openssl
         # mkdir -p pki-tsrit
         # cp /usr/share/doc/openvpn/examples/easy-rsa/2.0 pki-tsrit
         # cd pki-tsrit



2. Paramètres du certificat :
         # nano vars
                  export KEY_COUNTRY="FR"
                  export KEY_PROVINCE="Midi-Pyrénées"
                  export KEY_CITY="Toulouse"
                  export KEY_ORG="Tsrit"
                  export KEY_EMAIL="admin@tsrit.fr"
         # . ./vars



Authentification : Robert GUIRAUDET et Daddy KABASELE WA KABASELE TSRIT 2009 – 2010          22
         # ./clean-all

3. création des clés (clé publique + clé privée = biclé) :
         # ./build-ca
Generating a 1024 bit RSA private key
......++++++
.................++++++
writing new private key to 'ca.key'
Country Name (2 letter code) [FR]:
State or Province Name (full name) [Midi-Pyrénées]:
Locality Name (eg, city) [Toulouse]:
Organization Name (eg, company) [Tsrit]:
Organizational Unit Name (eg, section) []:
Common Name (eg, your name or your server's hostname) [Tsrit CA]:
Email Address [admin@tsrit.fr]:

4. création d'un certificat pour le serveur freeradius :
# ./build-key-server rad.tsrit.fr
Generating a 1024 bit RSA private key
writing new private key to 'rad.tsrit.fr.key'
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
Using configuration from /home/ethern/pki-tsrit/openssl.cnf
Check that the request matches the signature
Signature ok
Certificate is to be certified until Jan 12 09:22:23 2020 GMT (3650 days)
Sign the certificate? [y/n]:y
1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated

5. Paramètres Diffie-Hellman (côté serveur d'une connexion ssl/tls)
         # ./build-dh
Generating DH parameters, 1024 bit long safe prime, generator 2



Authentification : Robert GUIRAUDET et Daddy KABASELE WA KABASELE TSRIT 2009 – 2010   23
This is going to take a long time



6. Création des certificats clients (un par personne autorisée à se connecter)
         # ./build-key RobertGuiraudet



7. Copie des certificats
Maintenant que tous les certificats ont étés créés, il reste à les copier là où ils sont nécessaires.
   la clé publique du certificat racine (keys/ca.crt) sera copiée sur toutes les machines
    (serveur et clients) dans /etc/ssl/certs/tsrit_CA.crt
         /home/ethern/pki-tsrit/keys# cp ca.crt /etc/ssl/certs/tsrit_CA.crt
         /home/ethern/pki-tsrit/keys# rcp ca.crt 196.168.12.11:/etc/ssl/certs/tsrit_CA.crt
         root@196.168.12.11's password:
         ca.crt                                100% 1220         1.2KB/s 00:00
   le certificat serveur s'installe uniquement sur le serveur. keys/rad.tsrit.fr.crt dans
    /etc/ssl/rad.tsrit.fr.crt, keys/rad.tsrit.fr.key dans /etc/ssl/private/rad.tsrit.fr.key ainsi que les
    paramètres Diffie-Hellman keys/dh1024.pem dans /etc/freeradius/dh1024.pem
         /home/ethern/pki-tsrit/keys# rcp rad.tsrit.fr.crt 196.168.12.11:/etc/ssl/rad.tsrit.fr.crt
      /home/ethern/pki-tsrit/keys# rcp rad.tsrit.fr.key
196.168.12.11:/etc/ssl/private/rad.tsrit.fr.key
      /home/ethern/pki-tsrit/keys# rcp dh1024.pem
196.168.12.11:/etc/freeradius/dh1024.pem

     G. INSTALLER LE SERVEUR FREERADIUS ET LA BASE
      DE DONNÉES MYSQL
         aptitude install freeradius
         aptitude install freeradius-mysql
         aptitude install mysql-server
         aptitude install mysql-client

1. Configuration de mysql :
         mysql -p
                  create database radius;
                  quit
         cat /etc/freeradius/sql/mysql/shema.sql | mysql -u root -p radius
         mysql -p radius
                  mysql> INSERT INTO radcheck (UserName,Attribute,op,Value) VALUES


Authentification : Robert GUIRAUDET et Daddy KABASELE WA KABASELE TSRIT 2009 – 2010                    24
                              ('robert','User-Password','==','ethern');
                       Query OK, 1 row affected (0.00 sec)

2. Configuration de freeradius :
         dans /etc/freeradius/sites-enabled/default modifier :
                            # Read the 'users' file
                       #    files
                              # Look in an SQL database. The schema of the database
                              # is meant to mirror the "users" file.
                              # See "Authorization Queries" in sql.conf
                              sql


         dans /etc/freeradius/sql.conf :
                       # Connection info:
                       server = "localhost"
                       login = "radius"
                       password = "ethern"


         dans /etc/freeradius/radiusd.conf :
                 $INCLUDE sql.conf
         authorize {
             preprocess
             chap
             suffix
             eap
             #files
             sql
         }
         authenticate {
             Auth-Type PAP {
                 pap
             }
             Auth-Type CHAP {
                 chap
             }
             eap
         }
         accounting {
             detail




Authentification : Robert GUIRAUDET et Daddy KABASELE WA KABASELE TSRIT 2009 – 2010   25
             radutmp
             sql
         }
         session {
             sql
         }

         pour autoriser un nouveau client NAS, modifier le fichier /etc/freeradius/clients.conf :
                     # HP Procurve 3400cl
                     client 10.2.245.131 {
                              secret       = ethern
                              shortname       = HP Procurve 3400CL
                              nastype       = other
                     }

3. Test freeradius en local :
         lancer freeradius en mode console pour voir les messages de debug
                     /etc/init.d/freeradius stop
                     freeradius -X
                     ctrl-c
      utiliser l'outil de test en local radtset sous la forme radtest user motdepasse 127.0.0.1
portNAS secretpartagé
                     radtest robert ethern 127.0.0.1 1645 ethern
         si tout est bien configuré on doit obtenir une réponse Access-Accept :
                     Sending Access-Request of id 125 to 127.0.0.1 port 1812
                              User-Name = "robert"
                              User-Password = "ethern"
                              NAS-IP-Address = 196.168.12.11
                              NAS-Port = 0
         radclient: no response from server for ID 125 socket 3
         Loupé.
        Après avoir corrigé les fichiers clients.conf et users, il est important de redémarrer
freeradius par la commande /etc/init.d/freeradius restart pour que les modifications soient
prises en compte.
         Sending Access-Request of id 236 to 127.0.0.1 port 1812
                     User-Name = "robert"
                     User-Password = "ethern"
                     NAS-IP-Address = 196.168.12.11
                     NAS-Port = 1645


Authentification : Robert GUIRAUDET et Daddy KABASELE WA KABASELE TSRIT 2009 – 2010               26
         rad_recv: Access-Accept packet from host 127.0.0.1 port 1812, id=236, length=71
         OK




      H. SUPPLICANT DEBIAN
         aptitude install wpasupplicant

1. Créer un fichier /etc/wired.conf avec :
         ctrl_interface=/var/run/wpa_supplicant
         ctrl_interface_group=0
         ap_scan=0
         network={
                 key_mgmt=IEEE8021X
                 identity="robert"
                 password="ethern"
         }

2. Tester le client en mode debug :
         wpa_supplicant -i eth0 -dd -Dwired -c/etc/wired.conf

Initializing interface 'eth0' conf '/etc/wired.conf' driver 'wired' ctrl_interface 'N/A' bridge 'N/A'
Configuration file '/etc/wired.conf' -> '/etc/wired.conf'
Reading configuration file '/etc/wired.conf'
ctrl_interface='/var/run/wpa_supplicant'
ctrl_interface_group='0' (DEPRECATED)
ap_scan=0
Line: 4 - start of a new network block
key_mgmt: 0x8
identity - hexdump_ascii(len=6):
   72 6f 62 65 72 74                        robert
password - hexdump_ascii(len=6):
   65 74 68 65 72 6e                        ethern
Priority group 0
  id=0 ssid=''
Initializing interface (2) 'eth0'
wpa_driver_wired_init: Added multicast membership with packet socket
Own MAC address: 00:0c:f1:a0:84:5d



Authentification : Robert GUIRAUDET et Daddy KABASELE WA KABASELE TSRIT 2009 – 2010                     27
RSN: flushing PMKID list in the driver
Setting scan request: 0 sec 100000 usec
EAPOL: SUPP_PAE entering state DISCONNECTED
EAPOL: KEY_RX entering state NO_KEY_RECEIVE
EAPOL: SUPP_BE entering state INITIALIZE
EAP: EAP entering state DISABLED
RX EAPOL - hexdump(len=46): 01 00 00 04 03 05 00 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
EAPOL: Received EAP-Packet frame
EAPOL: SUPP_BE entering state REQUEST
EAPOL: getSuppRsp
EAP: EAP entering state RECEIVED
EAP: Received EAP-Success
EAP: EAP entering state SUCCESS
CTRL-EVENT-EAP-SUCCESS EAP authentication completed successfully
EAPOL: IEEE 802.1X for plaintext connection; no EAPOL-Key frames required
WPA: EAPOL processing complete
Cancelling authentication timeout
State: ASSOCIATED -> COMPLETED
CTRL-EVENT-CONNECTED - Connection to 01:80:c2:00:00:03 completed (auth) [id=0 id_str=]
EAPOL: SUPP_PAE entering state AUTHENTICATED
EAPOL: SUPP_BE entering state RECEIVE
EAPOL: SUPP_BE entering state SUCCESS
EAPOL: SUPP_BE entering state IDLE
EAPOL authentication completed successfully




3. Lancer wpa_supplicant à chaque démarrage et en tâche de fond:
créer un script de démarrage :
         echo «wpa_supplicant -i eth0 -Dwired -c/etc/wired.conf -B» >> /etc/init.d/supplicant
rendre le script exécutable
         chmod +x /etc/init.d/supplicant
créer un lien dans dans le niveau d'exécution 2 :
         ln -s /etc/init.d/supplicant /etc/rc2.d/S99supplicant
le script s'est-il bien lancé ? :
         ps aux | grep wpa




Authentification : Robert GUIRAUDET et Daddy KABASELE WA KABASELE TSRIT 2009 – 2010                  28
     I. SUPPLICANT WINDOWS XP




Authentification : Robert GUIRAUDET et Daddy KABASELE WA KABASELE TSRIT 2009 – 2010   29
     J. PARAMETRAGE DU CLIENT RADIUS DANS UN
       SWITCH HP PROCURVE 3400CL
         aptitude install gtkterm

1. Commandes CLI :
         show authentication


         radius-server host 10.2.245.35 key ethern
         write mem
         show radius


Authentification : Robert GUIRAUDET et Daddy KABASELE WA KABASELE TSRIT 2009 – 2010   30
                  Server IP         Addr Port         Port Encryption Key
                  10.2.245.35            1812                      1813
         aaa authentication port-access eap-radius
         show auth
                  Access Task | Primary Secondary Primary Secondary
                  Console       | Local       None        Local       None
                  Telnet       | Local      None        Local        None
                  Port-Access | EapRadius
                  Webui         | Local      None        Local       None
                  SSH          | Local      None         Local       None
                  Web-Auth        | ChapRadius
                  MAC-Auth          | ChapRadius
         aaa port-access authenticator 17 control auto
         aaa port-access authenticator active
         show port-access authenticator config

2. Déroulement de l'authentification :
                  show port-access authenticator


         Port Status State           Backend State VLAN ID Port COS                   Limit Inbound
         17 Closed Disconnected Idle                      1        No-override No-override
         17 Closed Connecting              Idle          1         No-override No-override
         17 Closed Authenticating Response                     1       No-override No-override
         17 Open Authenticated Idle                       1        No-override No-override



     K. DEBUG RADIUS D'UNE AUTHENTIFICATION
      ACCEPTÉE

rad_recv: Access-Request packet from host 10.2.245.131 port 1024, id=143, length=233
         Framed-MTU = 1480
         NAS-IP-Address = 10.2.245.131
         NAS-Identifier = "switch"
         User-Name = "robert"
         Service-Type = Administrative-User
         Framed-Protocol = PPP




Authentification : Robert GUIRAUDET et Daddy KABASELE WA KABASELE TSRIT 2009 – 2010                   31
         NAS-Port = 17
         NAS-Port-Type = Ethernet
         NAS-Port-Id = "17"
         Called-Station-Id = "00-16-35-b2-f2-8f"
         Calling-Station-Id = "00-0c-f1-a0-84-5d"
         Connect-Info = "CONNECT Ethernet 100Mbps Full duplex"
         Tunnel-Type:0 = VLAN
         Tunnel-Medium-Type:0 = IEEE-802
         Tunnel-Private-Group-Id:0 = "1"
         State = 0x031d21ea031e251496cf6cc18f2d97da
         EAP-Message = 0x0203001c04101145cdd07c699bca55f981e065f520e7726f62657274
         Message-Authenticator = 0xe353daf8b3a10f14fc0288559c689aa8
Thu Jan 28 20:24:34 2010 : Debug: modsingle[authorize]: calling chap (rlm_chap) for request 1
Thu Jan 28 20:24:34 2010 : Debug: modsingle[authorize]: returned from chap (rlm_chap) for request 1
Thu Jan 28 20:24:34 2010 : Debug: ++[chap] returns noop
Thu Jan 28 20:24:34 2010 : Debug: modsingle[authorize]: calling mschap (rlm_mschap) for request 1
Thu Jan 28 20:24:34 2010 : Debug: modsingle[authorize]: returned from mschap (rlm_mschap) for request 1
Thu Jan 28 20:24:34 2010 : Debug: ++[mschap] returns noop
Thu Jan 28 20:24:34 2010 : Debug: modsingle[authorize]: calling suffix (rlm_realm) for request 1
Thu Jan 28 20:24:34 2010 : Debug:       rlm_realm: No '@' in User-Name = "robert", looking up realm NULL
Sending Access-Accept of id 143 to 10.2.245.131 port 1024
         EAP-Message = 0x03030004
         Message-Authenticator = 0x00000000000000000000000000000000
         User-Name = "robert"
Thu Jan 28 20:24:34 2010 : Debug: Finished request 1.
Thu Jan 28 20:24:34 2010 : Debug: Going to the next request
Thu Jan 28 20:24:34 2010 : Debug: Waking up in 4.7 seconds.
Thu Jan 28 20:24:39 2010 : Debug: Cleaning up request 0 ID 142 with timestamp +53
Thu Jan 28 20:24:39 2010 : Debug: Waking up in 0.2 seconds.
Thu Jan 28 20:24:39 2010 : Debug: Cleaning up request 1 ID 143 with timestamp +53
Thu Jan 28 20:24:39 2010 : Debug: Ready to process requests.


     L. AFFECTER PLUSIEURS ADRESSES IP À UNE
       INTERFACE RESEAU
Dans /etc/network/interfaces ajouter les lignes suivantes :
         auto eth0:1
         iface eth0:1 inet static
         address 172.16.0.250
         netmask 255.255.0.0
         network 172.16.0.0


Authentification : Robert GUIRAUDET et Daddy KABASELE WA KABASELE TSRIT 2009 – 2010                        32
     M. COMPILATION DE PAQUETS SOURCES
         mkdir src
         mv coova-chilli-1.2.0.tar.gz src
         cd src
         tar -xvzf coova-chilli-1.2.0.tar.gz
         cd coova-chilli-1.2.0
         ./configure –help
         apt-get install gcc
         apt-get install libssl-dev
          apt-get install make
         ./configure --enable-chilliproxy --with-openssl
         make
         make install



     N. DEBUGGER UN PROBLEME DNS/PROXY/ROUTAGE
test résolution de nom :
         aptitude install dsnutils

         nslookup www.google.fr

« pinguer » le serveur DNS :
         cat /etc/resolv.conf
         ping -c2 ip_du_dns

vérifier les routes, l'IP du DNS etc, la route par défaut :
         /sbin/route -n

vérifier les variables d'environnement :
         env | grep proxy

modifier la variable proxy (on peut l'ajouter dans /etc/profile) :
         export http_proxy="http://10.1.245.254:80/"
ajouter une passerelle par défault (on doit le fixer dans /etc/network/interfaces) :
         route add default gw 10.2.245.254
suppression de network-manager (indispensable pour maîtriser l'adressage ip fixe dans


Authentification : Robert GUIRAUDET et Daddy KABASELE WA KABASELE TSRIT 2009 – 2010    33
/etc/network/interfaces) :
         aptitude remove network-manager
voir les services en fonctionnement (et les ports ouverts)
         nmap 10.2.245.35
arrêter un service :
         ps aux | grep radius
         killall freeradius
         freeradius -XX (lancer radius en mode debug)



     O. INSTALLATION DE WEBMIN
Il s'agit de pouvoir administrer à distance les serveurs situés dans les domaines XEN
Télécharger webmin_1.500_all.deb
Le copier dans chaque domaine
         rad# passwd root
         rcp ./webmin_1.500_all.deb 196.168.12.11:/home/
       aptitude install libnet-ssleay-perl libauthen-pam-perl libio-pty-perl          libmd5-perl
openssl
         dpkg -i ./webmin_1.500_all.deb
Dans un navigateur web, entrer https://rad.tsrit.fr:10000/



     P. INSTALLER UN ANALYSEUR DE TRAME DANS UN
       DOMAINE INVITÉ
Dans les domaines créés avec XEN nous n'avons virtualisé que le noyau de la distribution
Debian (sans l'interface graphique). On pourra quand même utiliser un analyseur de protocole
en ligne de commande : TCPDUMP.
         aptitude install tcpdump
         tcpdump -i eth0




Authentification : Robert GUIRAUDET et Daddy KABASELE WA KABASELE TSRIT 2009 – 2010           34
IV. Mise en œuvre distante
     A. Les choix

1. Généralité
Dans une structure possédant un parc informatique composée de multiples stations de travail
nomades et souhaitant que ces postes puissent accéder à des ressources locales, on aura besoin
de mettre en place des solutions d'accès distant, mais aussi et surtout, une architecture
d'authentification sure, fiable, facile à déployer et qui garantissent la sécurité et la
confidentialité des usagers.
Le choix d'une architecture d'authentification basé sur RADIUS (serveur et protocole)
s'impose à nous. En effet, en plus d'offrir une large palette de méthodes d'authentification, la
solution RADIUS à pour lui l'avantage d'être supporté par la quasi totalité des équipements
réseaux actuel mais aussi par les systèmes d'exploitation les plus utilisé aujourd'hui.
La mise en place d'une solution d'authentification basée sur RADIUS nécessite trois outils
pour fonctionner, un logiciel serveur d'authentification RADIUS, un logiciel client qui servira
d'agent intermédiaire à l'authentification et enfin des logiciels d'authentification (supplicant)
installer sur les postes nomades.

2. L’addition s’il vous plait… : le logiciel serveur
Nous avons fait le choix pour notre serveur d'utiliser une implémentation libre de serveur
RADIUS qui est FreeRADIUS, ce logiciel serveur est présent dans la majorité des
distributions linux actuelles, ce qui nous donne le choix quant à la distribution à utiliser.
Nous prenons parti d’intégrer notre serveur RADIUS sur la distribution linux openSUSE dans
sa version 11.2. Le choix de cette distribution est des plus logiques compte tenu de sa
maturité, sa stabilité et des ses outils qui facilitent la configuration de l'ensemble du système.
La version 11.2 de cette distribution offre dans ces dépôts freeRADIUS dans sa version 2 qui
corrige plusieurs « bug » dont ceux liés aux méthodes EAP. Ce qui nous conforte dans le
choix de cette distribution.

3. …est toujours Roi : le logiciel client
Le choix d'un logiciel client du protocole RADIUS est plus délicat, en effet, le client est la
passerelle entre le serveur d'authentification et les supplicants, il doit non seulement recueillir
les demandes d'accès venant des usagers distant mais aussi leurs requêtes d'authentification.
Ce qui veut dire que notre client doit supporter au moins un protocole de réseau privé virtuel
(VPN) sécurisé en plus du protocole radius et de la méthode EAP-TTLS/PEAP.
Notre choix se porte sur Microsoft Windows 2003 serveur, cette version du système
d'exploitation de Microsoft dédié au machine serveur offre tout les prés requis dont nous
avons besoin pour notre client de protocole RADIUS, c'est à dire le support du VPN, avec le
protocole PPTP et L2TP, et le support de la méthode d'authentification PEAP qui créé un
tunnel sécuriser pour l'authentification du serveur auprès du supplicant.




Authentification : Robert GUIRAUDET et Daddy KABASELE WA KABASELE TSRIT 2009 – 2010             35
4. Le choix du protocole
Nativement, RADIUS supporte plusieurs méthodes d'authentification offrant selon le cas
sécurité ou flexibilité. S’agissant d'un serveur et des clients distants les uns des autres, le
choix de l'authentification de chaque protagoniste semble la plus évidente, mais pour des
raisons de flexibilité seul le serveur d'authentification pourra s'authentifier à l'aide de
certificats, les usagers distants eux s'authentifieront à l'aide d'un identifiant et d'un mot de
passe.
Le choix de la méthode d'authentification EAP-TTLS/PEAP parait alors tout indiquée, cette
méthode a l'avantage d'être supporté par les systèmes d'exploitation de type Unix/Linux ainsi
que Microsoft Windows qui implémente en natif des logiciels supplicant supportant la
méthode.




Authentification : Robert GUIRAUDET et Daddy KABASELE WA KABASELE TSRIT 2009 – 2010          36
     B. Installation et configuration du serveur

1. Installation
L’installation et la configuration du serveur RADIUS sous la distribution openSUSE nécessite
l’utilisation du terminal de commande. FreeRADIUS étant un logiciel sans interface
graphique, sa configuration se fait à l’aide de ses fichiers de configuration situés dans son
répertoire de configuration qui est par défaut « etc/raddb ».
Precision syntaxique : les lignes commençant par le symbole « # » sont des commandes à
entrer dans le terminal de comande sans le symbole lui-même.
Commençons premièrement par rajouter le dépôt de logiciels qui va nous permettre d’installer
le serveur RADIUS avec la commande suivante :
# zypper addrepo http://download.opensuse.org/distribution/11.2/repo/oss/ web-oss
Cette formalité accomplie nous pouvons passer à l’installation du serveur lui même
# zypper install freeradius-server
Zypper l’outil de gestion des paquets de la distribution openSUSE fait l’inventaire des fichiers
et dépendances à installer. Acquiesçait positivement, l’installation se termine.
Nous aurons également besoin pour l’authentification de notre serveur du support de SSL
installons donc les paquets openssl et ses dépendances
# zypper install openssl
Notre serveur aura également besoin d’une empreinte numérique de type diffie-hellman nous
n’en aurons pas besoin ici mais cette empreinte est un pré requis exigé par le serveur
# openssl dhparam –check –text -5 512 –out /etc/raddb/certs/dh
Un fichier de type « contenu aléatoire » est également requis par notre serveur RADIUS pour
pouvoir se lancer
# dd if=/dev/urandom of=/etc/raddb/certs/random count=2

2. Les fichiers de configuration du serveur
L’installation finie, nous pouvons maintenant passer à la configuration de notre serveur
d’authentification.
Pour la configuration de notre serveur, nous n’avons besoin que de cinq fichiers dans le
répertoire « /etc/raddb » et ses sous répertoires:
./radius.conf : fichier de configuration générale du serveur, dans ce fichier nous allons activer
la prise en charge EAP en dé commentant (enlever le symbole « # ») la ligne du module dans
la section module si ce n’est déjà fait.

…
modules {
      …
      $INCLUDE ${confdir}/modules/
      …
…


Authentification : Robert GUIRAUDET et Daddy KABASELE WA KABASELE TSRIT 2009 – 2010           37
./sites-available/default nous devons également dé commenter dans ce fichier aux sections
authorize et authenticate les méthodes EAP.

…
authorize {
       eap {
                  ok = return
       }
…
authenticate {
       eap
…

./clients.conf : fichier référençant l’ensemble des clients du protocole RADIUS habilités à
interroger notre serveur RADIUS. Voici son contenu,

client 10.192.0.1 {                                    # adresse ou nom DNS du client
        secret      = radius                           # secret partager entre le client et le serveur
        shortname = w2003srv                           # nom court définissant le client
        nastype     = other                            # le type de client (cisco, computone.., other)
}
…
client …                                               # client suivant

./users : ce fichier ne sera utilisé dans notre mise en œuvre qu’à des fins de test, en l’absence
de base de données de type SQL ou LDAP, users.conf référence l’ensemble des supplicants
authentifiable par notre serveur.

DEFAULT        Auth-Type := EAP           # méthode d’authentification par défaut
               Reply-Message = "Salut, %{User-Name}" # message d’accueil par défault
# insérons un utilisateur nommer kalamar avec pour mot de passe k@l@m@r
"kalamar"      Cleartext-Password := "k@l@m@r"

./eap.conf : ce fichier sert à configurer les méthodes EAP que peut utiliser notre serveur pour
authentifier des utilisateurs, à noter que, toujours dans le même fichier, la méthode EAP-TLS
doit être configuré afin d’utiliser EAP-TTLS/PEAP.
NB : la création des clés est décrite dans la section suivante

         eap {
                  default_eap_type = peap

                  tls {
                           certdir = ${confdir}/certs
                           cadir = ${confdir}/certs

                           private_key_password = mot_de_pass_de_laclé
                           private_key_file = ${certdir}/structure_serveur_radius.pem

                           certificate_file = ${certdir}/structure_serveur.crt



Authentification : Robert GUIRAUDET et Daddy KABASELE WA KABASELE TSRIT 2009 – 2010                      38
                           CA_file = ${cadir}/structure_root.crt

                           dh_file = ${certdir}/dh
                           random_file = ${certdir}/random

                           fragment_size = 1024
                           cipher_list = "DEFAULT"

                           cache {
                              enable = yes
                              lifetime = 24 # hours
                              max_entries = 255
                           }
                  }

                  ttls {
                           default_eap_type = md5
                           copy_request_to_tunnel = yes
                           use_tunneled_reply = yes
                           virtual_server = "inner-tunnel"
                  }

                  peap {
                           default_eap_type = mschapv2
                           copy_request_to_tunnel = yes
                           use_tunneled_reply = yes
                           virtual_server = "inner-tunnel"
                  }

                  mschapv2 {
                  }
         }


3. XCA et certificats
La mise en place de la méthode EAP-TTLS/PEAP nécessite la possession de certificats au
format X.509 signés par une autorité de certification valide.
Notre serveur ayant pour but de n’authentifier que des utilisateurs interne à notre structure,
nous allons nous établir comme autorité de certification.
C’est là que le logiciel XCA va nous aider, tournant sur plateforme Windows, ce logiciel est
un moyen très simple de créer des certificats au format X.509
Voici la marche à suivre :
Lançons le logiciel XCA après l’avoir téléchargé et installé, dans le menu « file », on créé une
nouvelle base de certificat et on l’enregistre dans le répertoire de notre choix ;




Authentification : Robert GUIRAUDET et Daddy KABASELE WA KABASELE TSRIT 2009 – 2010          39
Le logiciel nous demande un mot de passe qui servira à protéger notre base de certificat ainsi
que toutes nos clés RSA




Une fois notre base de certificat créé, dans l’onglet « Private Keys » et dans la colonne de
droite de notre logiciel, on créer une nouvelle clé à l’aide du bouton « New Key » ce sera la
clé privé de notre autorité de certification.



Authentification : Robert GUIRAUDET et Daddy KABASELE WA KABASELE TSRIT 2009 – 2010        40
Répétons l’opération précédente et créons une seconde clé qui sera la clé privé de notre
serveur




Rendons nous maintenant dans l’onglet certificat et créons notre premier certificat qui sera
notre certificat racine qui servira à signer tous les certificats de notre structure, dans la fenêtre




Authentification : Robert GUIRAUDET et Daddy KABASELE WA KABASELE TSRIT 2009 – 2010               41
qui s’ouvre à nous et dans la section Template on sélectionne le Template « CA » et on
« apply » c’est important;




Dans l’onglet subject de notre fenêtre de création de certificat on remplit les champs
d’information de notre certificat et on pense à sélectionner la clé privé de notre autorité de
certification puis on valide par « OK » ;




Authentification : Robert GUIRAUDET et Daddy KABASELE WA KABASELE TSRIT 2009 – 2010        42
Nous répétons l’opération précédente cette fois en sélectionnant la Template
« HTTPS_server » et la clé privée de notre serveur voila nous avons nos certificats ;




Authentification : Robert GUIRAUDET et Daddy KABASELE WA KABASELE TSRIT 2009 – 2010   43
A l’aide du bouton « export » de notre logiciel on exporte la clé privé de notre serveur et nos
deux certificats, CA et Serveur au format de fichier « PEM » transférons les ensuite sur la
machine hébergeant notre serveur RADIUS dans le répertoire « /etc/raddb/certs ».
La configuration de notre serveur radius est terminée.




Authentification : Robert GUIRAUDET et Daddy KABASELE WA KABASELE TSRIT 2009 – 2010         44
     C. Configuration du client RADIUS s/ Windows 2003 serveur
La mise en place de notre serveur VPN, client RADIUS et des plus simples, il faut installer le
service routage et accès distant puis le configurer pour authentifier nos usagers distants à
partir de notre serveur RADIUS.
Commençons par installer le service routage et accès distant, ouvrons l’outil Gérer votre
serveur puis on ajoute un nouveau rôle a notre machine serveur




Nous allons choisir de configurer notre serveur avec les options personnalisés puis à la page
rôle du serveur, on ajoute le rôle « Serveur VPN/Accès Distant » :




Authentification : Robert GUIRAUDET et Daddy KABASELE WA KABASELE TSRIT 2009 – 2010        45
Aux fenêtres suivantes on prendra soin de choisir l’option accès VPN et NAT, remplissez les
étapes suivantes selon votre configuration




Puis à la fenêtre gestion des serveurs d’accès distant multiple, on choisi de configurer notre
serveur pour travailler avec un serveur RADIUS



Authentification : Robert GUIRAUDET et Daddy KABASELE WA KABASELE TSRIT 2009 – 2010        46
A la fenêtre suivante on entre l’adresse IP ou le nom DNS de notre serveur RADIUS et voila,
terminez ensuite l’installation du serveur d’accès distant.




Authentification : Robert GUIRAUDET et Daddy KABASELE WA KABASELE TSRIT 2009 – 2010     47
L’installation de notre serveur d’accès achevée, nous allons le configurer pour n’accepter que
les requêtes EAP. Pour ce faire, lançons la console de management de notre service Routage
et accès distant en passant par le menu démarrer.




Dans la console plaçons nous sur l’icône représentant notre serveur d’accès distant dans le
menu contextuel de notre serveur VPN, sélectionnons propriété




A l’onglet sécurité, on sélectionne le bouton « méthodes d’authentification »



Authentification : Robert GUIRAUDET et Daddy KABASELE WA KABASELE TSRIT 2009 – 2010        48
A la fenêtre qui suit nous décochons toutes les méthodes d’authentification à l’exception du
protocole EAP.




Voila la configuration de notre Client de protocole RADIUS terminée.



Authentification : Robert GUIRAUDET et Daddy KABASELE WA KABASELE TSRIT 2009 – 2010      49
     D. Configuration d’un supplicant sous Windows XP
Avant toute chose, nous devons installer le certificat public de notre autorité de certification
rien de plus simple, il suffit dans le menu contextuel de l’icône de notre certificat de choisir
de l’installer, laissons les paramètres par défaut de l’installation.




Nous allons à présent créer une interface virtuelle de connexion d’accès distant, pour ce faire
rendons nous dans le panneau de configuration puis connexions réseau. Dans le menu fichier,
nous choisissons de créer une nouvelle connexion et la connexion à créer sera une connexion
au réseau d’entreprise.




Authentification : Robert GUIRAUDET et Daddy KABASELE WA KABASELE TSRIT 2009 – 2010          50
A la fenêtre suivante nous choisissons de créer une connexion réseau privé virtuel, il va nous
être demandé par la suite l’adresse IP ou le nom DNS de l’interface public de notre serveur
d’accès distant, nous le renseignons et terminons.




Configurons maintenant notre nouvelle interface afin qu’il s’authentifie par l’intermédiaire du
protocole EAP. Toujours dans connexion réseau, dans le menu contextuel de notre connexion
réseau, faisons apparaitre les propriétés de notre connexion d’accès distant, dans l’onglet
sécurité, nous sélectionnerons les options avancées.




Authentification : Robert GUIRAUDET et Daddy KABASELE WA KABASELE TSRIT 2009 – 2010         51
Puis dans les propriétés des options avancées, nous allons utiliser la méthode
d’authentification EAP protégé.




Dans les propriétés du mode EAP, nous allons choisir de valider le certificat du serveur,
ensuite, nous sélectionnons le certificat de notre autorité de certification que nous avons
installer au préalable, et nous prenons pour méthode d’authentification le protocole EAP-
MSCHAP-V2.




Authentification : Robert GUIRAUDET et Daddy KABASELE WA KABASELE TSRIT 2009 – 2010     52
Voila nous avons finit la configuration de notre supplicant pour une connexion authentifié par
serveur radius à notre serveur d’accès distant.




Authentification : Robert GUIRAUDET et Daddy KABASELE WA KABASELE TSRIT 2009 – 2010        53
     E. Analyse

1. Place à la mise en place
A l’aide de l’outil de capture de trame WIRESHARK, nous allons capturer les paquets
transitant d’une part entre notre serveur radius et notre serveur d’accès distant, d’autre part
entre notre serveur d’accès distant et notre poste de travail distant windows XP.
Pour notre analyse nous configurons un réseau simple simulant une connexion d’accès
distant.


                               10.192.0.1                              10.80.0.1




                                                                         Réseau Public XYZ




    Serveur de fichiers                          Serveur d’accès                              Client d’accès
          Local                                      distant                                      distant
                                                                                 10.80.0.20




                   Serveurs d’authentification
                           RADIUS
                                                               10.192.0.45
          10.192.0.10



                          Réseau Local                                                        Réseau Distant
                          Gw 10.192.0.1




Authentification : Robert GUIRAUDET et Daddy KABASELE WA KABASELE TSRIT 2009 – 2010                            54
2. Les dents de la mer : captures de trames

  a) EAP
Lançons notre client de connexion d’accès distant, voici ce que nous donne la capture de
paquets transitant sur le réseau public entre le client et le serveur d’accès distant




Bien que très intéressante nous ne pouvons décemment pas faire une analyse détaillée et en
profondeur du protocole EAP dans cette exposé, malgré tout la capture que nous avons sous
les yeux est très parlante, tout d’abord nous remarquons que notre serveur d’accès distant
initie une connexion de protocole EAP sous la forme d’une demande d’identification de notre
supplicant Windows XP, de plus il y’a demande de challenge de type MD5 ce qui nous
indique que nous sommes en présence d’un protocole de type CHAP. par la suite, le reste de
la communication se poursuit en TLS ce qui veut dire qu’elle est cryptée, puisqu’il y’a eu
requête d’identité au préalable en EAP, il nous est permis de supposer, avec des très grosses
pincette, que la communication du mot de passe de l’usager se fait sur un mode sécurisé.




Authentification : Robert GUIRAUDET et Daddy KABASELE WA KABASELE TSRIT 2009 – 2010       55
  b) RADIUS
Lançons-nous maintenant dans l’analyse des trames transitant entre client et serveur du
protocole RADIUS.




Cette capture confirme ce que nous savons du protocole EAP à savoir que l’envoi du
challenge au supplicant n’est plus dévolue au client du protocole RADIUS mais au serveur
lui-même. Nous avons également une confirmation flagrante sur la sécurité du mot de passe
de l’usager qui n’est aucunement crypté.




Authentification : Robert GUIRAUDET et Daddy KABASELE WA KABASELE TSRIT 2009 – 2010   56
     F. Conclusion
En conclusion, le serveur feeRADIUS associé au service routage et accès distant de Windows
2003 serveur s’est montré être un doublé gagnant pour l’authentification des usagers nomades
avec un bon niveau de journalisation des connections. Associé à une base de données de type
SQL, nul doute que cette solution est incontournable.
Malgré tout, bien que le protocole RADIUS associé à EAP-TTLS/PEAP apporte une couche
de sécurité en plus en traversant un réseau public tel que l’internet, certaines données
transitent encore en clair, pour y remédier, il nous faudra mettre en place des solutions de
tunneling autorisant la sécurité des échanges sur le réseau public.




Authentification : Robert GUIRAUDET et Daddy KABASELE WA KABASELE TSRIT 2009 – 2010      57
V. Conclusion du projet
La sécurité d'un système informatique ne sera jamais parfaite. Même si on empêche la
connexion sur le réseau d'utilisateurs non sûrs, grâce à un système d'authentification basé sur
un serveur RADIUS, il faudra aussi veiller à surveiller l'usage que feront du réseau ces mêmes
utilisateurs effectivement identifiés et authentifiés. Un employé en instance de licenciement
qui télécharge des dossiers sur les projets les plus importants et qui les propose à la
concurrence, un commercial négligent qui reste connecté pendant qu'il s'absente alors qu'il
reçoit un nouveau prospect, un utilisateur maladroit qui a supprimé le mauvais répertoire par
erreur, etc.
La réponse à ces problématiques passe parfois par de la technique : il ne faut pas donner plus
que les accès nécessaires, et il convient d'avoir des sauvegardes régulières. Mais dans la
plupart des cas, il s'agit avant tout de prévention en formant les utilisateurs afin qu'ils puissent
mieux éviter les risques.
Comparée à l'absence de contrôle d'accès, ou à un contrôle d'accès basé uniquement basé sur
la valeur de l'adresse MAC/Ethernet, l'activation de l'authentification 802.1x est un réel
progrès. Ce progrès se mesure aussi par la facilité d'ingénierie que procure le recours à un
serveur d'authentification externe. Compte-tenu de la présence quasi-systématique de serveurs
RADIUS sur un site, on peut considérer que l'activation de l'authentification 802.1x ne rajoute
pas de complexité dans l'administration réseau d'un site.




Authentification : Robert GUIRAUDET et Daddy KABASELE WA KABASELE TSRIT 2009 – 2010              58

				
DOCUMENT INFO
Categories:
Tags:
Stats:
views:179
posted:1/5/2012
language:Latin
pages:58