ˆ · 2017-05-30 · technologiques censées y répondre pour finir par une quatrième partie où...

� �

��

��

��

�

�

��

�

��

� �� ! �� "��"��

�

�

�

�

��

�

�

�

�

�

�

�

�

�

�

�

�

�

#�$��%�� !��

&��'��(��%�"��#$��%��&�'�� !�� (� ��

)��%��)��%��

��%�� %��*++,�

*��%��-��

# ��%��.�� .��#��/��!�##0��1 " ��23��&�

�

�

� �

�

�

�

�

+��

�

4�� .�# ��5� �.!��#��

��..�� .� .�6��

�� #� 5� � #��#�� !�� "��#$� ��%��&�'�� .��

��#/�� (� �� #��7 ��#��

��#�� #��8��

�

4�� .�� .�# ��!��##� ��

�� 4��9�#� %��'��)%�� #�� !�� .!�(� �� . �

�! �� 8� �� .�# .�� (�� .�� !�5� ��

� ��.��&&� ��!�� (� ��8��

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

� �

� � � � � � � ��

��#� ��8888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888 :�

�8�3�� !�� ;��&�<��=8888888888888888888888888888888888888888888888888888888888888888888888888888888888888888 *�

:8��&88888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888 *�

*8�9!��8888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888 *�

*8:8�3�� 8888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888 *�

*8*8�&�. ��888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888 *�

��8�3��-��.�� 5��.�� .��&888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888 ,�

:8��;��88888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888 ,�

*8�9��.�� .8888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888 >�

*8:8�%##0��#��88888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888 ?�

*8*8�%##0�� 88888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888 @�

��8��#�� 88888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888 :+�

:8�%##0�� 7 �� 7 ��(#�A+*8:B 8888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888 :+�

:8:8�3�� A+*8:B 88888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888 :+�

:8*8�� C�� D��%3�9888888888888888888888888888888888888888888888888888888888888888888888888 ::�

:8E8�� C�� (��C�� 7 #�� <�%3� ��%��&=8888888888888888888888888888888888 :*�

:8,8�� 77��.��C�� 7 #�� %38888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888 :*�

:8>8��#�� 78888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888 :E�

*8�9��#� ��##0��7 �888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888 :,�

*8:8�9!��# ��F��1�38888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888 :,�

*8*8�13%8888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888 :,�

*8E8�A+*8:: 888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888 :G�

*8,8�9�29%��7 �8888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888 :?�

*8>8��#�� 78888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888 :A�

E8�%##0�� (#��;�� (��( �� 888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888 :A�

E8:8��;�� (��( ��3#8888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888 :A�

E8*8��;�� (��( ��&&988888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888 *:�

�28�� .��8888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888 *,�

:8��/��!�##0��(#�A+*8:B888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888 *,�

:8:8�9��(��C�� 7 #�� 888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888 *,�

:8*8�%�� #�� C�##0�7 �� 88888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888 *G�

:8E8�%�� #�� C�##0��7 �888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888 *A�

:8,8��7 �� #� �� 88888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888 *@�

:8>8�) ��8888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888 EA�

*8�%##0� �� #��(#��23��&&98888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888 E@�

*8:8�� .��. � �� H�0.8888888888888888888888888888888888888888888888888888888888888888888888888888 ,:�

*8*8�"��#� ��C�##0��;��#88888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888 ,*�

*8E8�&H�0.��!�� 7 #�� ##0 8888888888888888888888888888888888888888888888888888888888888888888888888888888888888888 ,,�

*8,8�) ��8888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888 ,G�

��#�� 888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888 ,?�

%��;�8888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888 ,A�

�� 88888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888 >>�

) -� �� I�1-�� 88888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888 >G�

�

� �

� :� �

Introduction

�

Le développement rapide des technologies et des services mobiles est issu des récentes innovations techniques et de la demande grandissante des utilisateurs. Ce rapide décollage est vérifié par l’intégration massive de technologie communicante par défaut dans les équipements, par l’intensification et l’accélération de la circulation des personnes et des informations. Les frontières physiques de l’organisation sont estompées et le développement des réseaux va dans le sens de la répartition des tâches entre centres géographiquement distants et dans l’externalisation d’un nombre croissant de fonctions. Dans une organisation comme le CNRS, cette émergence des technologies de la mobilité autorise le personnel à exercer ses fonctions dans des espaces autres que celui du laboratoire et dans des plages horaires différentes de la normale, nous parlerons alors de nomadisme qui représente le fait de pouvoir travailler sans contrainte d’espace ni de temps de manière aussi efficace que sur le lieu de travail habituel. Cette étude porte sur les solutions technologiques existantes et à venir que j’ai pu étudier durant mon stage de quatre mois au sein de l’Unité des Réseaux du CNRS (UREC), elle prendra notamment en compte le caractère spécifique d’un environnement de laboratoire et surtout les problèmes de sécurité soulevés par le nomadisme. Nous verrons dans une première partie une présentation de l’UREC, nous poserons ensuite la problématique du nomadisme dans un environnement de laboratoire puis les solutions technologiques censées y répondre pour finir par une quatrième partie où sera examiné en détail le déploiement des technologies retenues.�

� *� �

I. Présentation de l’Unité des Réseaux du CNRS (UREC)

1. CNRS Le Centre National de la Recherche Scientifique est un organisme public de recherche fondamentale (Etablissement public à caractère scientifique et technologique, placé sous la tutelle du Ministre chargé de la Recherche). Il produit du savoir et met ce savoir au service de la société. Avec 26 000 personnes (dont 11 600 chercheurs et 14 400 ingénieurs, techniciens et administratifs), un budget qui s'élève à 214 millions d'euros HT pour l'année 2004, une implantation sur l'ensemble du territoire national, le CNRS exerce son activité dans tous les champs de la connaissance, en s'appuyant sur 1300 unités de recherche et de service.

2. L’UREC

2.1. Présentation Créée en 1990, l’UREC (www.urec.cnrs.fr), l'unité réseaux du CNRS, est une unité de service du CNRS (Unité Propre de Services UPS836). Ses missions sont définies par le Comité d'Orientation des Moyens Informatiques du CNRS (COMI) qui lui donne ses moyens, elle est rattachée au département STIC du CNRS (Sciences et Technologies de l’Information et de la Communication). L’UREC emploie 15 personnes dont 11 sont ingénieurs, lesquels sont pour la majorité répartis entre l’UREC Grenoble et l’UREC Paris. Ses missions d'origine sont de promouvoir, de développer et d'organiser les services réseaux, tant au niveau des infrastructures que des applications, et d'aider les utilisateurs à s'en servir. Celles-ci ont évolué, pour suivre les nouveaux besoins des laboratoires (services Internet, calcul distribué, certificats électroniques) et faire face aux nouvelles problématiques (sécurité). Elle travaille en collaboration avec tous les départements scientifiques du CNRS et fait appel aux différentes compétences des ingénieurs dans les laboratoires. Elle a des liens étroits avec la Direction des Systèmes d'Information du CNRS (DSI), l'équipe du GIP Renater et la cellule technique réseau des universités, le CRU.

2.2. Ses missions �

L’UREC a plusieurs missions :

+��

L'unité apporte une expertise pour la définition de la politique réseau du CNRS et veille à ce que le meilleur service réseau soit rendu de bout en bout, du laboratoire à Renater en passant par les réseaux de campus, métropolitains, régionaux. Outre les compétences techniques qu'elle doit maintenir, elle suit et s'implique parfois fortement dans l'évolution des différentes composantes du réseau enseignement-recherche. Elle joue un rôle de consultant pour la conception et la réalisation des réseaux de campus et de laboratoires CNRS. Elle administre certains services nationaux comme le serveur de noms cnrs.fr.

� E� �

��

L'UREC définit et assure certains éléments de la politique de sécurité CNRS. Elle construit, forme et anime une organisation humaine de coordinateurs et de correspondants sécurité. Elle apporte une expertise technique pour aider les laboratoires à améliorer leur sécurité et à résoudre leurs problèmes d'intrusion. Elle diffuse un ensemble d'informations et de solutions techniques validées pour les laboratoires.

�� ,��"� � ��

L'UREC est impliquée dans plusieurs projets technologiques où elle apporte ses compétences en matière de réseaux et de sécurité. On peut citer : • IPv6 : formation des administrateurs, choix et tests d'outils, déploiement en France et dans le monde, mise en place de réseaux de tests et maintenant de service. Cette activité est assurée dans Renater par un ingénieur UREC. • Multicast : avec les mêmes axes d'activité que IPv6, et aussi dans Renater. • Grilles de calcul : mise en place de grilles et développement de logiciel dans des projets comme Datagrid et e-Toile par le passé, EGEE de nos jours. • Les réseaux optiques à travers la définition de l'architecture et la mise en place du réseau RAP (Réseau Académique Parisien).

�� ,�� -&��

Dans ces projets, l'UREC monte des plates-formes de test et assure une phase pilote (le déploiement est ensuite assuré par un autre service) ou joue un rôle de coordinateur des différents acteurs. On peut citer comme projets : • Autorité de certification CNRS : développement du logiciel IGC pour créer des certificats électroniques, définition de l'organisation pour diffuser ces certificats, coordination des phases pilotes de déploiement. • Intranet STIC : construction d'un Intranet dans le département STIC. • Annuaire CNRS : projet pour créer et/ou fédérer un ensemble d'annuaires électroniques au CNRS.

)��

L'UREC anime un certain nombre de listes de diffusion et de groupes de travail et organise régulièrement des formations, des séminaires, des journées techniques pour les administrateurs systèmes et réseaux du CNRS, souvent en coopération avec d'autres organismes de recherche. C'est évidemment une activité transversale aux différentes thématiques techniques. �

� ,� �

II. Problématique du nomadisme au CNRS �

On peut définir le nomadisme comme le fait de permettre aux acteurs de l’organisation d’accéder à leurs données personnelles et aux ressources collectives sans contrainte de localisation et de temps. Le nomadisme au CNRS s’intègre dans un environnement bien spécifique. Nous aborderons dans cette partie la problématique générale soulevée par le nomadisme, en commençant par une rapide description du contexte informatique au CNRS (d’après le « Rapport de la SSI au CNRS, Joseph Illand »). Nous verrons dans la partie suivante les technologies permettant de répondre à cette problématique.�

1. Contexte général �

Les Directions du CNRS successives ont constamment insisté sur le caractère stratégique des systèmes d’information et la nécessité de les protéger. Tout cela dans un contexte unique et complexe du fait : • De l’imbrication des organismes et des statuts : un laboratoire du CNRS peut être universitaire, INSERM, INRA, etc., il peut être composé de personnels attachés à différents organismes, certains titulaires d’autres pas, certains permanents, d’autres stagiaires, visiteurs ou thésards ; les catégories d’utilisateurs et leurs droits associés sont complexes à définir. • D’une dispersion géographique : 1 300 laboratoires répartis sur l’ensemble du territoire. • D’une grande hétérogénéité des environnements : la sécurité des systèmes d’information ne s’appréhende pas de la même façon, suivant qu’il s’agit d’un grand laboratoire possédant des moyens financiers et humains importants, une culture et un savoir-faire en système et réseau, ou d’une petite unité de recherche qui a constitué son informatique par accumulations successives, sans plan, sans connaissance préalable et sans personnel technique associé. Le panorama est vaste et présente une grande variété de structures et de cultures qui se côtoient. Les solutions proposées doivent être adaptives ou spécifiques à un type d’environnement. • De la difficulté à définir précisément « un périmètre » pour les systèmes d’information : les unités du CNRS entretiennent de nombreuses relations avec le monde extérieur et partagent une partie de leur système d’information dans le cadre de projets communs de recherche, de collaboration internationale et de contrats industriels ou européens. Les chercheurs se déplacent beaucoup, 20% de l’effectif du CNRS est en permanence en déplacement, et ont besoin de communiquer quotidiennement avec leur laboratoire, ne serait-ce que pour consulter leur messagerie électronique. De plus ces mêmes chercheurs se déplacent de laboratoire en laboratoire. La SSI (Sécurité des Systèmes d’Information) n’est pas au centre des préoccupations des personnels des laboratoires.

� >� �

2. Le nomadisme �

Les utilisateurs expriment le besoin d’accéder à leurs ressources usuelles durant leur déplacement. Des besoins plus spécifiques et plus compliqués à satisfaire vont se greffer, en plus de la messagerie et de l’accès aux fichiers personnels, tel que l’accès à des applications client-serveur spéciales, à des calculateurs ; globalement avoir accès aux ressources de leur intranet habituel.

Figure [1] : Les besoins du nomade ( ref. « %##0�� #�� F�� - �� -��J��

�� K��&L��)

� G� �

Les acteurs (utilisateurs) déterminent les usages, c'est-à-dire ce qu’ils attendent en terme de possibilités de la part du nomadisme. Les usages définissent alors à leur tour l’architecture du Système d’Information (SI) et le choix des équipements. �

Figure [2] : Envisager le nomadisme

Non spécifiques au CNRS, le nomadisme et les technologies associées soulèvent une nouvelle problématique dans la Sécurité des Systèmes Informatiques (SSI). On retrouve d’ailleurs parmi les orientations prioritaires pour 2004 énumérés dans le rapport officiel de la SSI au CNRS de 2003 : • L’élaboration de recommandations pour l’administration et la connexion de postes nomades • La maîtrise de l’utilisation de la technologie sans fil dans les laboratoires • La sécurisation des accès à distance avec les nouveaux modes d’accès haut débit Le nomadisme va soulever de nouveaux problèmes en terme de sécurité et reposer certains existant déjà sur les réseaux classiques.

� ?� �

Figure [3] : Sécurité et nomadisme (source France Telecom)

Deux catégories de nomadisme vont être définies, chacune influant sur l’architecture du SI et le choix des équipements : l’accès local qui regroupe les accès filaire et sans fil, et l’accès distant lorsque la connexion se fait en passant par un prestataire extérieur (par exemple un Fournisseur d’Accès Internet - FAI). Dans chaque cas le besoin est le même, pouvoir travailler sans contraintes géographiques généralement avec son propre ordinateur, ce qui va imposer des choix technologiques en vue de satisfaire ces besoins.

2.1. Accès local �

Nous parlerons d’accès local lorsque l’utilisateur se connecte au réseau interne en étant physiquement sur site, c'est-à-dire dans les locaux ou à l’extérieur immédiat (cas de l’accès sans fil). Dans tous les cas, la ou les ressource(s) qu’il veut atteindre est ou sont située(s) sur le réseau local sur lequel il va directement se brancher. La connexion peut se faire de façon classique en utilisant une prise réseau libre dans un bureau ou en utilisant une carte réseau sans fil. Du fait des équipements et des problèmes différents posés par ces deux méthodes de connexion nous allons les traiter séparément : d’une part l’accès filaire, d’autre part l’accès sans fil. Ces deux catégories vont poser chacune une problématique propre, la catégorie sans fil étant la plus difficile à maîtriser. Le principal problème posé par l’accès local est la présence de postes non maîtrisés dans le réseau interne de l’organisation. En effet, il s’agit la plupart du temps de portables personnels, utilisés indifféremment pour les loisirs et le travail, parfois par plusieurs utilisateurs ; l’administrateur n’a aucun contrôle sur ces postes (potentiellement compromis) mais reste responsable du réseau dont il a la charge. L’introduction de postes nomades dans le réseau interne peut devenir une menace pour ce dernier ; leur introduction directe dans le réseau interne fait qu’ils court-circuitent les mécanismes de sécurité vis-à-vis de l’extérieur.

� A� �

2.1.1. Accès filaire �

Le scénario classique consiste en un utilisateur se trouvant physiquement dans les locaux et branchant son portable sur une prise libre du réseau (ou en débranchant une machine pour y mettre la sienne…). Les locaux des laboratoires sont considérés comme sûrs, il faut généralement un badge pour rentrer. Il est donc peu probable qu’un utilisateur rentre dans un laboratoire pour se connecter au réseau à des fins malveillantes. Le principal problème est l’hétérogénéité dans la classe d’utilisateurs potentiels (cf. partie II, 1. Contexte général de la SSI au CNRS) induisant un processus d’authentification forcément complexe. Par exemple un invité n’aura pas les mêmes droits et n’aura pas accès aux mêmes ressources qu’un chercheur permanent. Ce problème était résolu sur les postes « fixes », dont l’administrateur a la charge, via les identifiants fournis par l’utilisateur lorsqu’il se « logue » sur la machine, une fois identifié/authentifié il bénéficie des droits adéquats dans le sous-réseau approprié. Sur son poste nomade, l’utilisateur a les droits d’administrateur, il peut installer le système d’exploitation de son choix, s’affecter une adresse IP, bref s’affranchir de tous les droits sur le réseau et usurper la place d’un utilisateur autorisé. Le réseau devra être préparé à accueillir et gérer ces postes nomades afin qu’une telle situation ne se produise pas. Le deuxième problème, commun à l’accès sans fil, vient encore du caractère non maîtrisé du poste et du risque d’introduction de virus et autres codes malicieux. L’utilisateur peut s’il le désire ne pas utiliser d’antivirus, peut décider de ne pas mettre à jour son système d’exploitation et l’administrateur ne peut le forcer à changer de comportement et ne peut pas inspecter chaque poste nomade avant qu’il ne soit connecté (d’une part ce n’est pas son rôle, il a déjà un parc de machines à surveiller et d’autre part il s’agit souvent de la propriété de l’utilisateur).

2.1.2. Accès sans fil �

Récemment apparue dans le monde des réseaux, la connexion sans fil reçoit un accueil très positif du public. Quasiment tous les portables récents sont pourvus de série d’une carte sans fil intégrée, et le prix des cartes sans fil a chuté. Le prix des points d’accès a suivi cette tendance et il n’est maintenant pas rare de voir des utilisateurs déployer leur propre réseau sans fil en connectant leur borne au réseau local, au mépris de la politique de sécurité locale. Ce type de connexion, la plus difficile à maîtriser coté administrateur, doit bénéficier d’une attention particulière, notamment en terme de confidentialité des communications et d’authentification. Tout d’abord la couverture du point d’accès - la zone ou l’accès est possible - est rarement confinée aux locaux, et « déborde » souvent au dehors du bâtiment. Ainsi, contrairement à l’accès filaire, on ne sait pas qui va essayer de se connecter, ni quand et où. Les possibilités d’accès devront être strictement réglementées. Ensuite du fait du médium utilisé (l’air) pour transmettre les communications, il va falloir utiliser des technologies garantissant la confidentialité des échanges. Autant il est peu probable qu’une personne ayant accès aux locaux décide d’écouter les communications transitant sur les câbles réseau (ce type d’opération est de plus difficile à mettre en œuvre de manière efficace – réseau commuté, VLAN, etc.), autant cette opération est plus simple sur

� @� �

un réseau sans fil insuffisamment protégé, du fait du caractère partagé du médium et des failles de sécurité dans les premiers mécanismes de sécurité disponibles. De plus, le caractère récent de cette technologie fait qu’il coexiste plusieurs standards, certains peu fiables en terme de sécurité, moins performants et en fin de vie, d’autres récents et plus robustes. Un choix va s’imposer, faut-il utiliser les dernières technologies, plus sûres, mais incompatibles avec les équipements moins récents, au risque d’écarter des utilisateurs du service, ou bien réaliser un compromis ? Quoi qu’il en soit, le déploiement du sans fil doit permettre, comme pour le filaire, l’authentification sûre de l’utilisateur (cf. Charte Renater).

2.2. Accès distant �

Un accès distant est l’opération d’accéder aux ressources du réseau interne de « l’extérieur », c'est-à-dire qu’il y a au moins un réseau étranger entre les deux parties (le nomade et le réseau interne à atteindre) qui sert de réseau de transport. Les différents scénarios sont : • Accès depuis le domicile en passant par son propre FAI • Accès depuis un laboratoire externe (ex. un chercheur accède au réseau de son laboratoire depuis un autre laboratoire) • Accès depuis un hot spot (gare, aéroport, certains cafés ou restaurants) • Accès depuis un cybercafé Dans les trois premiers scénarios, l’utilisateur utilise son ordinateur personnel, dans le dernier cas il utilise un ordinateur mis à sa disposition. La problématique va être différente, par exemple dans le cas du cybercafé l’utilisateur devra faire attention à ne pas laisser d’identifiant sur le poste (dans certaines configurations le navigateur les mémorise automatiquement). Dans le cas d’un accès depuis un autre laboratoire, l’utilisateur est dépendant de la politique de sécurité locale qui peut lui poser des problèmes pour atteindre son réseau (le filtrage des ports notamment) ; nous apporterons une attention particulière à ce point, car ce scénario, fréquent, montre le coté asymétrique du nomadisme, en terme d’équipement et de paramétrage du SI : d’un côté le réseau du laboratoire doit recevoir et satisfaire les connexions de ses chercheurs en déplacement et de l’autre il doit permettre à des chercheurs externes de se connecter à leur laboratoire. Encore une fois il faudra accorder les solutions en fonction des moyens et des besoins, la meilleure solution au niveau des laboratoires étant une homogénéisation des méthodes d’authentification pour une facilité accrue de connexion pour les personnels de laboratoire en déplacement. La problématique du côté non maîtrisé du poste est la même pour ce type d’accès, et les solutions devront permettre de protéger les ressources locales contre un poste nomade compromis. Tout scénario confondu, il faudra veiller à utiliser des solutions indépendantes du système d’exploitation, limiter les contraintes technologiques en écartant le plus possible les solutions propriétaires et minimiser les manipulations à effectuer côté client afin de ne pas rebuter le personnel non-informaticien, majoritaire dans le panel d’utilisateurs.

� :+� �

III. Technologie �

Nous verrons dans cette partie des solutions technologiques au nomadisme. Dans un premier temps nous aborderons les solutions dédiées aux accès filaire et sans fil, puis nous finirons avec les solutions pour les accès distants.

1. Accès sur site en filaire et sans fil avec 802.1X �

La norme IEEE 802.1X répond à un manque dans le domaine de la sécurité en permettant au réseau d'authentifier l'utilisateur ou l'équipement dès que la connexion au niveau physique est réalisée. En effet les réseaux locaux (LAN) utilisant les normes 802 sont souvent déployés dans des environnements permettant à des équipements non autorisés de se rattacher physiquement au réseau, ou à des utilisateurs non autorisés de tenter d'accéder au LAN via un équipement déjà raccordé. Ce genre d'environnement inclut les réseaux d'organisation dont les locaux sont accessibles au public ou aux personnes invitées, ou encore les réseaux sans fil dont le rayonnement des points d'accès déborde sur l'extérieur du bâtiment. Dans ce genre d'environnement il est désirable de restreindre l'accès aux services fournis par le LAN aux utilisateurs et équipements autorisés à y accéder. Le standard 802.1X permet de contrôler l'accès au LAN au niveau de la couche 2 – couche liaison – du modèle OSI (annexe [1]) avant que les protocoles des couches supérieures soient montés. Le terme port dans ce document se référera à un point d'accès physique ou logique au LAN, décrivant par exemple un port sur un commutateur ou une association station - point d'accès pour le sans fil. Les ports sont des points vulnérables du réseau, il n'est en effet pas compliqué de rattacher son ordinateur à une prise réseau, elle-même reliée à un port, et encore plus simple de se raccorder à un point d'accès sans fil. Il est par contre compliqué pour l'administrateur de configurer pour chaque port qui a le droit et qui n'a pas le droit de s'y raccorder (équipement et utilisateurs compris), une solution serait de désactiver tous les ports non utilisés mais il faudrait alors l'intervention directe de l'administrateur en cas de nouvelle demande d'accès, ce qui peut tourner au cauchemar en cas d'utilisateurs mobiles dans l'organisation, de plus cette solution n'empêche personne de débrancher une machine d'un port et d'y raccorder la sienne. Une autre solution serait d'établir une politique de sécurité sur chaque port, en enregistrant l'adresse physique (MAC) de la machine autorisée et qui fermerait le port en cas d'adresse inconnue. Ceci implique d'associer tous les ports des commutateurs avec une adresse MAC unique, ce qui représente déjà une tâche considérable en fonction de la taille de l'organisation, et qui n'est pas viable encore une fois dans le cas d'utilisateurs mobiles, sans parler du fait que les adresses MAC des interfaces réseaux sont modifiables par logiciel, donc usurpables.

1.1. Présentation du standard 802.1X �

Le standard 802.1X (approuvé en tant que standard à l'été 2001) apporte une solution commercialement indépendante au problème de l'accès physique au réseau, là ou les autres solutions ont échoué. Cette solution permet d’identifier et authentifier le client avant son accès physique au réseau, en s'appuyant sur sa capacité à fournir des informations pour l'authentification. A la différence de la solution basée sur les adresses physiques, ces informations peuvent être soit une combinaison Login/Mot de passe soit un certificat électronique. Ces informations ne sont pas vérifiées au niveau du commutateur (alors que

� ::� �

c'était le cas pour la solution basée sur les adresses mac) mais sont envoyées par relais à un serveur d'authentification (un serveur RADIUS [x]) qui utilise une base d'information d'authentification. Le mécanisme de l'authentification peut donc être centralisé et n'a pas à être déployé port par port. De plus le serveur RADIUS peut attaquer une base de données d'authentification existante (LDAP, Active Directory).

Figure [4] : Acteurs d’une authentification 802.1X

Le déroulement d'une authentification 802.1X met en jeu trois acteurs désignés par les termes suivants : �

• Authenticator : Le port du commutateur (compatible 802.1X) configuré pour le contrôle d'accès. Dans le cas du sans fil, l'authenticator est le point d'accès. • Supplicant : L'équipement qui tente d'accéder au réseau, c'est lui qui fournit les informations d'authentification lorsque l'authenticator le demande. • Serveur d'authentification : Un serveur RADIUS qui examine les informations fournies par le supplicant à l'authenticator. Le serveur RADIUS prend la décision d'autoriser ou non l'accès du supplicant au réseau et en informe l'authenticator qui en fonction ouvrira ou fermera son port (ou refusera l'association dans le cas du sans fil).

1.2. Dialogue entre le supplicant et l'authenticator – EAPOL �

Le standard 802.1X spécifie un format de trame Ethernet spécial utilisant pour le champ « type » la valeur hexadécimale 0x888e. Le port du commutateur qui est en mode 802.1X n'acceptera que ce type de trame tant que l'authentification n'est pas accomplie, empêchant tout autre type de trame de passer. Dans le cas d'une topologie où l'adresse MAC d'un des deux acteurs ne peut être connue de l'autre, l'adresse destination utilisée est une adresse de diffusion spéciale (dont la valeur est 01:80:C2:00:00:03) qui ne sera jamais retransmise par un commutateur ou un pont de niveau 2. Ces trames transportent dans leur charge utile (payload) le protocole EAP (Extensible Authentication Protocol) décrit ci-dessous. On parle de EAPOL pour « EAP Over LAN », utilisé pour le dialogue entre le Supplicant et l'Authenticator. Le format d'une trame Ethernet EAPOL est décrit en détail en annexe [2].

� :*� �

1.3. Dialogue entre l'authenticator et le serveur d'authentification (EAP in RADIUS) �

L'authenticator est responsable du relayage des trames EAP entre le supplicant et le serveur d'authentification. Ce relayage prend en compte les transformations nécessaires de ces paquets pour une transmission dans le format approprié. Dans cette étude le serveur d'authentification est un serveur RADIUS, l'authenticator communique alors en EAPOL avec le supplicant et en EAP in RADIUS (RFC 2865, 2866, 2869) avec le serveur d'authentification. L'authenticator est client du serveur RADIUS et peut attribuer les informations qu'il reçoit au supplicant (VLAN, temps de session, etc.). Les trames EAPOL-Start et EAPOL-Logoff sont à l'usage exclusif du supplicant qui les envoie à l'authenticator, les trames EAP-Request/identity sont à l'usage exclusif de l'authenticator qui les envoie au supplicant, les trames EAPOL-Key sont utilisées par le supplicant et l'authenticator. Ces derniers types de trames ne seront pas relayés vers le serveur d'authentification. Dans la configuration de cette étude, toutes les autres trames EAP arrivant du supplicant sont converties du format EAPOL en EAP in RADIUS et inversement, à noter que le standard 802.1X n'impose pas l'utilisation de RADIUS. Lorsque l'authenticator reçoit un message EAPOL de la part du supplicant qu'il doit faire parvenir au serveur d'authentification, il le transforme en un paquet RADIUS ayant un attribut de code 79 indiquant qu’il encapsule un paquet EAP. Une étude précise et détaillée de EAP in RADIUS est fournit en annexe [3].

1.4. Différentes méthodes d'authentification EAP �

Le protocole EAP est destiné à encapsuler des protocoles d’authentification et les informations de contrôles relatives, il ne spécifie pas le type d'authentification à utiliser et en supporte une grande variété. Le serveur Freeradius utilisé pendant cette étude supporte : �

• EAP-MD5 : basée sur mot de passe, jugée non sécurisée et inapte pour le sans fil (pas d'attribution de clé WEP) • LEAP (propriété Cisco) : basée sur mot de passe, jugée non sécurisée, des outils librement disponibles (asleap par exemple) permettent de récupérer les mots de passe échangés • Generic Token Card – EAP-GTC : authentification basée sur les informations contenues dans une carte à puce • EAP-TLS : l'authentification est réalisée via l'utilisation de certificats. Cette authentification, symétrique, est réalisée chez le supplicant, qui vérifie le certificat serveur, et chez le serveur d'authentification qui vérifie le certificat client. A noter que TLS [RFC 2716] est la version standardisée de SSL, EAP utilise le tunnel TLS, assurant ainsi une grande sécurité pour les échanges • EAP-TTLS : utilise un tunnel TLS pour procéder à une authentification via une autre méthode EAP qui bénéficiera donc de la protection du tunnel. Seul le serveur doit obligatoirement disposer d'un certificat • PEAP (Protected EAP, Microsoft) : similaire à EAP-TTLS, par défaut la méthode d'authentification est MS-CHAPv2 (basée sur mot de passe transmis dans un tunnel de chiffrement)

� :E� �

1.5. Récapitulatif �

Le schéma ci-dessous représente les échanges EAP entre les trois acteurs de la négociation :

�Figure [5] : Echanges EAP

� �

� :,� �

Le tableau ci-dessous montre l’empilement protocolaire mis en jeu dans l’utilisation de 802.1X : � � � �

Supplicant Authenticator Serveur d'Authentification

EAP-Méthode d'Authentification

EAP

RADIUS

UDP

EAPOL IP

802.3 (Ethernet) - 802.11

�Figure [6] : Pile des protocoles utilisés pour le contrôle d’accès 802.1X

2. La protection des accès sans fil �

Les accès sans fil représentent un problème supplémentaire par rapport au filaire en terme de confidentialité des échanges. Les standards ont beaucoup évolué dans ce domaine et proposent maintenant des solutions que l’on peut raisonnablement qualifier de fiables. Nous allons étudier dans l’ordre chronologique d’apparition ces standards.

2.1. L’ancien : le WEP �

Le WEP, pour Wired Equivalent Privacy, est la première réponse apportée aux problèmes de confidentialité qu’apporte le sans fil. Cette solution s’est malheureusement révélée très vite inefficace. Elle propose de chiffrer intégralement les données transmises entre les équipements en utilisant une clé commune aux deux participants de l’échange. Deux gros problèmes dans ce mécanisme ont rapidement été découverts. D’une part le poste utilisateur (que nous appellerons client) n’authentifie pas le point d’accès dont un attaquant peut alors usurper l’identité et mettre en place une redirection de niveau 1 (au niveau physique, ici les ondes hertziennes), l’attaquant a alors accès aux échanges entre le client et le point d’accès légitime sans que l’utilisateur ne s’en rende compte. Le deuxième problème réside dans le fait qu’une écoute passive permet de déduire la clé de chiffrement (qui est commune à toutes les stations du réseau). De plus un mécanisme de contrôle d’intégrité défaillant fait qu’un attaquant peut modifier une trame sans que ce contrôle donne un résultat négatif. On peut conclure que le WEP ne remplit pas son rôle, pire il induit un faux sentiment de sécurité chez les utilisateurs (du moins à sa sortie, lorsque les failles n’étaient connues que des initiés).

2.2. WPA �

Devant un constat aussi négatif, les constructeurs ont dû réagir. Le standard 802.11i n’étant pas encore finalisé (il a été approuvé par l’IEEE fin juin 2004), il fallait trouver une solution rapidement et compatible avec les équipements existants. Le WiFi Protected Access (WPA) a alors vu le jour. Son but est de combler une à une les failles du WEP en utilisant dans le

� :>� �

futur standard 802.11i les solutions transposables aux équipements existants. On peut le voir comme un ensemble de rustines logicielles se superposant au matériel. �

Authentification �

Pour l’authentification WPA propose un mécanisme basé soit sur 802.1X, soit sur secret partagé (afin de conserver un mode simple à mettre en œuvre). En plus de permettre la validation de l’accès des clients aux réseaux, la phase d’authentification sert de point de départ à un mécanisme de générations des clés de chiffrement en fournissant au client et au point d’accès une clé maîtresse d’une longueur de 256 bits, la PMK (pour Pairwise Master Key). Lorsque l’authentification se fait via 802.1X, la PMK est calculée simultanément par le client (le supplicant) et par le serveur d’authentification (le serveur RADIUS) puis ce dernier la fournit au point d’accès (l’authenticator) afin qu’il puisse générer les clés de chiffrement à utiliser avec le client. Le mécanisme de génération des clés de chiffrement et de contrôle d’intégrité sera par la suite initialisé par la PMK. L’authentification par secret partagé (PSK pour PreShared Key) dérive la PMK du secret. A noter que le secret peut être soit directement la PMK, une clé de 256 bits, soit une phrase de 8 à 63 caractères de laquelle sera dérivée la PMK ; il faudra bien choisir le secret car n’importe qui le connaissant devient capable de déduire la PMK et, à partir d’elle, de recalculer toutes les clés qui seront utilisées pendant la session. �

Chiffrement des données et contrôle d’intégrité �

Pour rester compatible avec les équipements existants, le mécanisme de chiffrement est basé sur le WEP. L’amélioration vient d’une méthode de gestion des clés différente, appelée TKIP (Temporal Key Integrity Protocol) qui permet un renouvellement des clés de chiffrement plus robuste dans le temps. En annexe [4] se trouve une description détaillée du processus de génération de toutes les clés nécessaires à une session WiFi en mode WPA. �

Ainsi contrairement à l’ancien WEP, la gestion des clés de chiffrement ne se fait plus à partir d’éléments uniques et communs à toutes les stations du réseau, mais grâce à une clé de session qui change à chaque association. De plus l’intervention des adresses MAC dans le processus fait qu’il n’est pas possible d’avoir sur le même réseau deux associations utilisant la même clé de session. Avec le WEP, une attaque réussie permettait l’accès au dialogue de toutes les stations, dorénavant une attaque ne peut porter que sur une seule station. Enfin il est quasiment impossible qu’une clé serve deux fois (à chiffrer une trame) car il faudrait épuiser les 2^48 valeurs possibles dans la même session, ceci est dû à la taille du vecteur d’initialisation de 48 bits. L’accès d’un intrus sur le réseau supposera donc qu’il obtienne une PMK valide qui est la base de tout le mécanisme. Ceci implique qu’il parvienne à voler des informations d’authentification (certificats, mot de passe pour 802.1X ou bien le secret partagé). Le contrôle d’intégrité se fait maintenant sur la trame entière (contrairement au WEP ou il ne concernait que les données utiles de la trame). Une somme cryptographique est calculée via l’algorithme Michael qui va permettre au destinataire de s’assurer de l’authenticité de la trame reçue. Cette somme, appelée MIC (Message Integrity Control) est calculée à l’aide d’une des deux clés temporelles de 64 bits qui ont été extraites auparavant des 512 bits de la PTK. Le MIC est alors placé à la suite des données incluses dans la trame et c’est l’ensemble « données + MIC » qui est fourni au moteur WEP. Le destinataire, une fois la trame déchiffrée, calcule à son tour un MIC dessus et le compare à celui reçu avec la trame.

� :G� �

A noter qu’en ce qui concerne les trafics multicast et broadcast, le procédé est le même à la différence que l’on utilise la clé de groupe à la place de la clé de session. Pour conclure sur le WPA, on peut dire que le niveau de sécurité apporté est satisfaisant en attendant la prochaine norme 802.11i (à laquelle il emprunte certains éléments) et on peut résumer le WPA par cette équation : WPA = 802.1X/EAP + TKIP + MIC + WEP Le seul point noir au tableau est que WPA ne s’intéresse pas au trafic de contrôle, ce qui fait qu’il ne protége pas le réseau des attaques de déni de service (DoS – Denial of Service), qui vise à rendre inutilisable le réseau pour l’utilisateur, par exemple en envoyant massivement des trames de désassociation, mais ne compromet pas la confidentialité des échanges.

2.3. 802.11i �

La norme 802.11i, qui a pour appellation commerciale WPA2, doit apporter un niveau de sécurité optimal aux réseaux WiFi. Nous ne reviendrons pas sur les éléments empruntés par le WPA qui sont : • Utilisation de 802.1X ou du secret partagé pour l’authentification • Système de génération des clés • TKIP et contrôle d’intégrité cryptographique devraient être optionnels afin de rendre compatible un équipement WPA2 avec WPA. �

La norme va plus loin en intégrant notamment deux concepts majeurs : la pré-authentification et l’utilisation de l’algorithme AES pour le chiffrement et le contrôle d’intégrité. �

Pré-authentification �

Ce concept est censé répondre au manque de protection du trafic de contrôle, rendant vulnérable le réseau au déni de service (à noter qu’un intrus peut provoquer de tels dénis de service afin de forcer les stations à se ré-authentifier et obtenir ainsi de précieuses informations d’authentification). La méthode est de faire intervenir l’authentification de la station avant l’association au point d’accès. Ainsi des clés pourraient être dérivées pour protéger le trafic de contrôle et éviter son usurpation, un intrus ne pourrait alors plus injecter des trames de contrôles qui seraient prises en compte par les équipements. Chiffrement des données et contrôle d’intégrité avec AES �

Le chiffrement et le contrôle d’intégrité seront gérés par des algorithmes se basant sur le standard AES (Advanced Encryption Standard), l’ensemble s’appelant CCMP (Counter Mode CBC-MAC Protocol). A noter qu’un autre mécanisme de chiffrement basé également sur AES avait d’abord été proposé, appelé WRAP (Wireless Robust Authenticated Protocol) il a été abandonné au profit de CCMP jugé plus sûr mais restera optionnel car certains constructeurs l’avaient déjà implémenté. Quoi qu’il en soit un matériel n’est « 802.11i compliant » que s’il implémente CCMP. Le moteur WEP est complètement supprimé et sera remplacé par un moteur AES, d’où le changement nécessaire de matériel. �

�

� :?� �

Fonctionnalité supplémentaire �

Le mode de fonctionnement Ad-hoc ou IBSS (Independent Basic Service Set), permettant à deux stations de communiquer directement, sera sécurisé ; ce mode n’était pas couvert par WPA. Les mécanismes seront les mêmes qu’en mode Infrastructure ou BSS qui est le mode de fonctionnement classique.

2.4. Les VLAN sur réseau sans fil Il est compliqué de concevoir comme possible la création de VLAN sur un réseau à médium partagé comme le sont les réseaux sans fil. Certains constructeurs ont pourtant apporté cette fonctionnalité sur leurs produits haut de gamme. Ces produits supportent la création de VLAN grâce à une interface Ethernet compatible 802.1Q et en gérant coté sans fil plusieurs réseaux (ESSID). Une correspondance ESSID – N° de VLAN est alors effectuée par le point d’accès qui marquera en conséquence les trames émises par son interface ethernet. Le gros avantage de ce procédé est qu’il n’oblige pas à déployer une borne par VLAN. Il est donc envisageable d’avoir par exemple un VLAN ouvert pour l’accès internet seulement, un VLAN avec WEP statique pour l’accès à quelques ressources internes non critiques et un VLAN avec WPA/802.1X pour un accès complet aux ressources internes. Sur ce même type de produit il sera possible avec l’authentification 802.1X d’affecter un VLAN à une station en fonction des éléments d’authentification (méthode utilisée, utilisateurs, etc. ; ce type d’affectation est abordé dans la partie IV. Déploiement). On pourra alors placer les utilisateurs non authentifiés dans le VLAN restreint à l’accès internet, et ceux authentifiés dans un VLAN approprié (permanent, temporaire, etc.). L’intérêt étant de pouvoir accueillir des systèmes divers et des profils d’utilisateurs variés sans mettre en péril la sécurité du réseau. �

�Figure [7] : VLAN sur réseau sans fil

� :A� �

2.5. Récapitulatif �

Le WEP avec clé statique ne doit être utilisé que si le matériel ne supporte pas le WPA. A réserver pour un usage domestique et migrer dès que possible. Il faut impérativement maîtriser la couverture hertzienne des points d’accès. Le WEP avec 802.1X apporte un niveau de sécurité moyen, il est possible de l’augmenter en configurant l’expiration des sessions EAP sur le serveur d’authentification pour forcer le renouvellement régulier de la clé de chiffrement (on peut descendre jusqu’au quart d’heure si le réseau est très peu chargé). Si le matériel supporte ce mode, il est fort probable qu’une mise à jour permettra le support de WPA (ce fut le cas avec la borne utilisée durant l’étude). Le WPA avec secret partagé convient parfaitement à l’usage domestique, il est conseillé d’utiliser un secret unique par station si le matériel le supporte. Le WPA avec 802.1X représente la configuration professionnelle pour une sécurité optimale. Penser à bien choisir la méthode d’authentification EAP afin qu’elle n’introduise pas un maillon faible (cf. III. 1.4. Différentes méthodes d'authentification EAP).

3. Accès Distant avec les réseaux privés virtuels �

Les réseaux privés virtuels (VPN) permettent à l’utilisateur de se connecter à distance aux ressources internes du réseau du laboratoire de manière sécurisée. Il en existe plusieurs types, nous étudierons les VPN basés sur le protocole IPsec (Internet Protocol security) puis ceux basés sur le protocole SSL (Secure Sockets Layer). Le protocole IPsec fut pendant un moment la seule option pour les VPN, maintenant des produits se basent également sur SSL qui a déjà sécurisé le monde du commerce électronique.

3.1. Réseaux privés virtuels sur IPsec �

Le protocole IPsec (qui est intégré dans IPv6) répond aux besoins de confidentialité et d’authentification des communications sensibles transitant sur les réseaux IP. En intervenant dans les couches basses (niveau 3, cf. figure [8]), il permet de sécuriser de façon transparente toutes les applications basées sur TCP-UDP/IP.

3.1.1. Principe �

Le protocole IPsec propose deux modes de fonctionnement : le mode tunnel et le mode transport. Le texte qui suit est notamment tiré de « Utilisateurs nomades et IPsec » par François Morris du Laboratoire de Minéralogie-Cristallographie (cf. webographie�) �

� Mode tunnel : Dans ce mode les communications entre deux machines A et B transitent par deux passerelles G et H. On a donc le schéma suivant : A �� G �� H �� B Les liaisons entre A et G ainsi que H et B ne sont pas sécurisées, tandis que celles entre G et H le sont. A peut être éventuellement confondu avec G, de même que H avec B.

� :@� �

On peut donc avoir trois types de tunnels : - Sous-réseau à sous-réseau - Machine à sous-réseau. C’est le cas du poste nomade connecté au réseau interne. - Machine à machine L’en-tête d’un paquet IPsec contient les adresses IP des extrémités du tunnel (G et H), le protocole ESP (50) ou AH (51), il n’y a pas de numéro de port. Le contenu du paquet IPsec est sécurisé (authentifié et éventuellement chiffré). Outre les informations servant à sécuriser, il comprend le paquet IP original et donc les adresses IP et les ports des machines source et destination (A et B). � Mode transport : Dans ce mode on a une liaison directe entre deux machines. On a donc le schéma suivant : A �� B L’en-tête du paquet IPsec est celui du paquet IP original. Le contenu du paquet IP original est sécurisé par IPsec. �

Deux niveaux de sécurité sont proposés par IPsec. L’un assure la confidentialité (par chiffrement) du paquet transmis ainsi que l’authentification, il est appelé ESP (Encapsulating Security Payload). L’autre n’assure que l’authentification et est appelé AH (Authentication Header). Les paramètres de la connexion incluant entre autres l’échange des clés de chiffrement, les algorithmes utilisés, les durées de vies du matériel cryptographique sont assurées par la méthode IKE (Internet Key Exchange). Ce trafic repose sur le protocole UDP à destination du port 500. Plusieurs méthodes pour crypter les données sont possibles, notamment à base de secret partagé ou de certificats X.509.

�Figure [8] : Empilement protocolaire incluant IPsec

� *+� �

3.1.2. Applications �

IPsec peut être utilisé pour interconnecter deux réseaux géographiquement distants en utilisant internet. �

Figure [9] : Connexion site à site avec IPsec �

IPsec permet également la sécurisation des accès distants à faible coût. Il fut un temps les clients IPsec étaient sources de problèmes car payants et spécifiques à un matériel donné. Désormais IPsec est disponible par défaut sous Windows 2000/XP et il existe une solution libre pour Linux.�

�Figure [10] : Nomadisme avec IPsec

�

Une fois le tunnel établi, le poste nomade se voit attribuer une adresse IP du réseau interne et peut donc accéder directement aux ressources comme s’il était connecté directement sur le réseau local. Cela peut représenter un inconvénient car en fonction du profil de l’utilisateur on désire généralement autoriser ou non l’accès à certaines ressources. Les pare-feux posent également problème aux utilisateurs d’IPsec car en fonction de leur lieu de connexion (un réseau de campus, un laboratoire, etc.) les politiques de sécurité peuvent varier et les ports utilisés (50 et 51) ne seront pas nécessairement ouverts. La situation peut également être rendue complexe lorsque l’utilisateur se connecte sur un réseau effectuant de la

� *:� �

translation d’adresse (NAT, Network Address Translation). C’est le cas de la plupart des hot-spots et cela va nécessiter que l’utilisateur modifie la configuration de son poste, ce qui peut être problématique avec du personnel non-informaticien.

3.2. Réseaux privés virtuels sur SSL �

Ce type de VPN repose sur une approche différente du type vu précédemment. Le protocole SSL est situé au dessus du niveau 4 (TCP/UDP) et permet de sécuriser les protocoles de niveau applicatif s’appuyant sur TCP. Il fournit pour cela les services d’authentification, de confidentialité et d’intégrité. Dans notre cas le protocole visé est HTTP qui devient HTTPS (SSL est directement implémenté dans le code des navigateurs et des serveurs web). En 2001 l’IETF (Internet Engineering Task Force) a racheté le brevet SSL qui appartenait à Netscape et l’a rebaptisé TLS (Transport Layer Security). TLS correspond à SSL version 3 avec des différences notamment au niveau des algorithmes cryptographiques qui font que ces deux protocoles ne sont pas inter-opérables. TLS, qui devrait rapidement supplanter SSL, inclut néanmoins un mécanisme de compatibilité ascendante avec SSL.

3.2.1. Principe �

Le protocole SSL est composé de deux couches. La plus basse, appelée « SSL Record Layer », se situe juste au-dessus d’un protocole de transport en mode connecté (TCP la plupart du temps) et a pour rôle d’encapsuler les données de niveau supérieur et de les transmettre cryptées à la couche transport, en plus des fonctions de fragmentation et de compression. La deuxième couche est constituée de trois blocs principaux : « SSL handshake protocol » qui permet au serveur et au client (éventuellement) de s’authentifier via des clés asymétriques (publique/privée) et de se mettre d’accord sur une clé secrète (identique aux deux parties) qui servira à crypter et décrypter les données échangées, « SSL change cipher » qui est chargé de synchroniser les stratégies de chiffrement et « SSL Alert » qui transmet les messages d’alerte et d’interruption de session en cas de problème.

� **� �

�

Figure [11] : Empilement protocolaire incluant SSL

3.2.2. Applications Les produits VPN SSL sont arrivés récemment sur le marché. Le principal argument de vente qu’avancent les constructeurs est qu’ils sont dits « client-less », c'est-à-dire que l’utilisateur n’a pas besoin d’installer un client spécial sur son poste et qu’un navigateur web suffit pour se connecter aux ressources du réseau interne. Il s’agit en réalité d’un abus de langage car toutes les solutions SSL installent au moment de la connexion sur le concentrateur VPN une applet JAVA ou un composant ActiveX sur le poste client via le navigateur, qui permettra de réaliser entre autres de la redirection de port afin de tunneliser les applications traditionnelles. Le procédé est généralement le suivant : l’utilisateur est connecté à internet, avec son navigateur il se connecte sur le concentrateur VPN SSL. Après authentification, apparaît un portail avec des liens sur les différentes ressources du réseau interne auxquelles il a accès. Imaginons qu’il désire se connecter à une machine de l’intranet (non accessible de l’extérieur donc) via ssh. En cliquant sur le lien correspondant à cette ressource, l’applet JAVA est automatiquement téléchargée et va intercepter le trafic de son client ssh, le rediriger dans le tunnel SSL. A l’arrivée le concentrateur va sortir du tunnel le trafic SSH et le diriger vers la machine ciblée. L’exemple de SSH peut paraître étrange du fait qu’il s’agit déjà de communication sécurisée mais l’intérêt ici est de pouvoir atteindre une machine non accessible de l’extérieur. Les autres arguments en faveur des VPN SSL sont que l’utilisateur ne sera pas bloqué par les pare-feux, le port 443 étant un port largement utilisé, et que ce type de VPN est insensible au réseau faisant de la translation d’adresse. De plus l’authentification via l’interface web permet de n’afficher sur celle-ci que les ressources accessibles en fonction du

� *E� �

profil d’utilisateur ; la granularité de l’accès est bien meilleure comparée aux produits basés sur IPsec. �

�Figure [12] : Empilement protocolaire incluant SSL & la redirection de port

�

Le déploiement d’un VPN SSL permet à l’utilisateur de se connecter à ses ressources depuis n’importe quel endroit. Il lui suffit d’avoir à sa disposition un ordinateur muni d’une connexion internet et d’un navigateur compatible JAVA. Il peut donc se connecter d’un ordinateur autre que le sien sans avoir à installer de client spécifique.

�Figure [13] : Nomadisme avec SSL

� *,� �

IV. Déploiement �

La durée de mon stage ne m’a pas permis de tester toutes les solutions technologiques devant répondre au problème du nomadisme, notamment un VPN de type IPsec (que j’ai étudié durant mon année de DESS, dans le cadre du projet professionnel) et surtout les différentes méthodes de test d‘intégrité (virus, mise à jour du système d’exploitation, ports ouverts...) des postes nomades avec notamment celle proposé par Microsoft dans son serveur Windows 2003 et sa fonction « Quarantine » qui semble prometteuse lorsqu’elle est déployée sur un parc « tout-Windows ». Nous verrons d’abord l’étude concrète du contrôle d’accès avec 802.1X, qui intègre pour sa partie sans fil la confidentialité des échanges. Puis nous étudierons le déploiement d’un VPN SSL qui doit répondre aux problèmes des accès distants.

1. Contrôler l’accès au réseau avec 802.1X Le but de l'étude est de tester le contrôle d'accès et l'authentification via 802.1X en filaire et en sans fil, ces tests incluent l'authentification par certificat (l’infrastructure de gestion de clé (IGC) CNRS-Test a été utilisée) et par login/mot-de-passe. Le matériel choisi dans le rôle d’authenticator est pour l'accès filaire un commutateur HP2626, que nous avons choisi pour sa compatibilité à la norme 802.1X et sa capacité à gérer plusieurs VLAN sur un même port. Il est de plus facilement administrable et une interface Web offre des fonctions de supervision avancées. Pour le sans fil une borne était déjà présente, il s’agit d’une D-Link AP 2000+ qui possède les capacités requises pour cette étude, à savoir une compatibilité 802.1X et une possibilité de fonctionnement en WPA (après mise à jour de la borne). Malheureusement elle ne gère pas les VLAN. Nous allons voir la configuration des différents éléments, en commençant par le serveur d'authentification, puis les authenticators et enfin la configuration des clients (supplicant) Linux et Windows.

1.1. Le serveur d'authentification �

Le serveur d'authentification utilise le serveur RADIUS « Open Source » Freeradius (freeradius.sourceforge.net) dans sa version 1.0.0-pre3. Nous avons retenu cette solution du fait, en plus de sa gratuité, de la bonne réputation dont elle dispose. Ce serveur RADIUS est capable d’authentifier selon les méthodes que nous avons choisi d’étudier. L’absence de service après vente et d’aide technique est largement compensée par une grande communauté d’utilisateurs s’échangeant facilement les informations ainsi qu’une liste de diffusion très active (cf. pour les adresses « Bibliographie & Webographie » en fin de rapport). Le système d'exploitation est basé sur une distribution RedHat 9 avec un noyau 2.4.20-31.9. Il est nécessaire d'installer OpenSSL avant Freeradius. En utilisant la procédure classique (cf. annexe [5]), le fichier exécutable du démon du serveur (radiusd) est placé dans « /usr/local/bin/ ». Les fichiers de configuration sont dans le répertoire « /usr/local/etc/raddb/ », ils sont très bien commentés et constituent la documentation de Freeradius.

� *>� �

Les fichiers à modifier sont : • radiusd.conf pour la configuration globale du serveur Ce fichier est découpé en deux grandes parties, d’abord les paramètres propres au démon (interfaces d’écoute, port, etc.), puis une partie définition des modules (définition et configuration des modules d’authentification disponibles hormis ceux du type EAP qui sont traités séparément, des modules de journalisation, de relayage des requêtes, etc.). C’est par exemple dans ce fichier que seront configurés les paramètres (adresses IP, mot de passe, etc.) d’une éventuelle base de données LDAP contenant les noms d’utilisateur et leur mot de passe associé. • eap.conf pour la configuration des méthodes EAP d'authentification Le contenu de ce fichier était au départ inclus dans la partie module du fichier RADIUS.conf mais les développeurs ont préféré le séparer pour des raisons de lisibilité car il devenait de plus en plus volumineux du fait du nombre de méthodes d’authentification EAP différentes. En fonction des méthodes EAP que le serveur devra supporter dans son environnement de production il y aura éventuellement certains paramètres à configurer. Par exemple dans le cas d’une authentification via EAP-TLS, il faudra indiquer le répertoire contenant le certificat du serveur (qu’il enverra au supplicant) et la clé privée avec le mot de passe associé, celui contenant le certificat de l’autorité (qui permettra de vérifier le certificat fourni par le supplicant), indiquer si le serveur doit vérifier un fichier contenant les certificats révoqués ou encore s’il faut vérifier que le nom de l’utilisateur correspond au nom du propriétaire du certificat fourni. • clients.conf pour définir et paramétrer le dialogue avec les authenticators Ici sont recensés les authenticators via un nom, une adresse IP et un secret partagé. D’autres informations optionnelles peuvent être ajoutées pour éviter les connexions simultanées d’un même utilisateur. • users qui est le fichier des utilisateurs Un utilisateur est défini par son nom et sa méthode d’authentification (en fonction des méthodes, ce fichier peut contenir des mots de passe). On peut aussi y mettre des directives post-authentification, comme une attribution de VLAN. Exemple de déclaration d’un utilisateur : "Pierre Dupont" Auth-Type := EAP Reply-Message = "Authentification reussie : VLAN ID 3 - permanent", Tunnel-Type = 13, Tunnel-Medium-Type = 6, Tunnel-Private-Group-Id = 3 ��

Ici l’utilisateur Pierre Dupont doit s’authentifier via une méthode EAP, en fonction de ce que le supplicant lui fournit, le serveur décide de la méthode EAP adéquate ; ce fichier peut contenir le mot de passe associé à l’utilisateur dans le cas ou le serveur RADIUS n’est pas interfacé avec une base de données ou avec le fichier de mot de passe Unix (/etc/passwd). Si Pierre Dupont arrive à s’authentifier alors il recevra le message "Authentification reussie : VLAN ID 3 - permanent" et le port de l’authenticator où sa machine est connectée sera affectée au VLAN n°3.

� *G� �

A noter qu’il est possible de créer un script relançant le démon radiusd à chaque modification du fichier users afin que le serveur Freeradius prenne en compte les ajouts ou suppressions d’utilisateurs. �

Le serveur accueillant Freeradius doit être dédié à cette tâche, il ne doit pas proposer d’autres services car en répondant aux requêtes d’authentification des utilisateurs il prend une place critique dans l’architecture du réseau. Il devra être redondant afin de ne pas bloquer l’accès au réseau en cas de panne et son accès devra être strictement limité aux authenticators. Les commutateurs et points d’accès compatibles 802.1X proposent toujours d’interroger un deuxième serveur RADIUS en cas de non réponse du premier. Le coté « Open Source » de Freeradius fait qu’une grande communauté s’est créée autour de lui et une recherche dans les archives de la liste de diffusion des utilisateurs apporte une réponse à quasiment toutes les questions.

1.2. Application à l'accès filaire �

L'authenticator utilisé est un switch 24 ports HP-2626. Trois VLAN ont été définis dans sa configuration, le VLAN 1 est le VLAN « invité », c’est là qu’atterrissent les utilisateurs sans client 802.1X (incapables donc de répondre aux requêtes d’identification du switch) ou n’ayant pas réussi à s’authentifier, ils trouveront dans ce VLAN cloisonné – sans sortie sur l’extérieur – un serveur web expliquant leur situation et comment s’en sortir, un serveur FTP contenant des clients 802.1X. Ils pourront accéder à ces ressources grâce à l’adresse IP que leur aura fournie le serveur DHCP, à noter que pour des raisons de sécurité il est possible d’interdire aux utilisateurs de ce VLAN de dialoguer entre eux. Les VLAN 2 et 3, respectivement appelés « permanent » et « temporaire » sont là pour tester l’attribution de VLAN en fonction de la méthode EAP d’authentification (d’une part via certificat, d’autre part via login/mot de passe), dans tous les cas ils auront, pour ces tests, accès aux mêmes ressources. Le schéma du déploiement est le suivant (chaque couleur représente un VLAN différent, à l’exception du trait rouge car le poste de travail se verra attribuer dynamiquement un VLAN) :

� *?� �

�Figure [14] : Application à l’accès filaire

�

Plusieurs scénarios ont été envisagés : �

• L’utilisateur du poste de travail dispose d’un client 802.1X (intégré dans Windows XP, pour Linux la solution Xsupplicant a été utilisée), répond à la demande d’identification réclamée par le switch, qui relaie les informations fournies au serveur Freeradius. Ce dernier authentifie l’utilisateur et dit au switch de le placer dans le VLAN 2 si l’utilisateur s’est authentifié avec un certificat (EAP-TLS) et dans le VLAN 3 si il s’est authentifié via un couple login/mot de passe (EAP-TTLS & PEAP), le serveur DHCP lui attribue une adresse IP adéquate. • L’utilisateur n’a pas de client, il atterrit donc automatiquement dans le VLAN 1, obtient un client grâce au serveur FTP, lit les instructions sur le site web et se reconnecte. A noter qu’il devra généralement posséder les droits d’administrateur sur sa machine pour pouvoir installer ou configurer le client 802.1X. �

La configuration du switch est relativement aisée, elle se fait de façon classique par le port console ou par Telnet (via une interface de commande) ou de façon graphique via un serveur web intégré au switch utilisant SSL (HTTPS). Pour chaque port du switch on peut activer 802.1X, attribuer un VLAN statique (celui qui sera utilisé si le serveur RADIUS n’en attribue pas) qui correspond pour l’étude au VLAN « invité », ce mode de fonctionnement est appelé « OpenVLAN mode » par HP.

� *A� �

1.3. Application à l'accès sans fil �

L’authenticator est maintenant un point d’accès sans fil D-Link DWL-2000AP+. En attendant la nouvelle norme 802.11i qui devrait apporter son lot de nouveautés en termes de sécurité, nous utiliserons le mode WPA (WiFi Protected Access) qui utilise 802.1X pour l’authentification et réalise de la rotation de clés WEP. Contrairement à l’accès filaire, nous ne pourrons utiliser le VLAN « invité », car l’utilisation de VLAN en sans fil est problématique et repose sur des solutions propriétaires (Cisco notamment) que notre borne ne supporte pas. Une borne sera donc rattachée à un VLAN, nous avons choisi de rattacher le VLAN 2 qui est le VLAN des utilisateurs permanents. Deux solutions s’offrent à nous pour les utilisateurs n’ayant pas de client 802.1X, soit ils se connectent en filaire (cf. ci-dessus), soit nous déployons un second point d’accès sans fil sur un réseau disposant d’un serveur analogue à celui du VLAN « invité ». Ne disposant que d’un point d’accès, nous avons utilisé la première solution. Le schéma du déploiement est le suivant : �

�Figure [15] : Application à l’accès sans fil

�

Là encore deux scénarios sont envisagés : • L’utilisateur du portable a un client 802.1X, il s’authentifie à la borne en lui fournissant les informations demandées (certificat ou login / mot de passe), la borne relaie ces informations au serveur Freeradius qui en retour envoie un message de connexion acceptée.

� *@� �

La borne génère alors les premières clés WEP et finalise l’association. La borne étant sur le VLAN permanent, l’utilisateur reçoit une adresse IP adéquate de la part du serveur DHCP de ce VLAN. �

• L’utilisateur n’a pas de client 802.1X, il doit donc se brancher au préalable en filaire, sur le VLAN « invité » (pointillés verts sur la figure [15]). �

La configuration de la borne sans fil se fait via une interface web (HTTPS), nous avons été limités par le fait qu’elle ne supporte pas la gestion de VLAN (seuls quelques rares produits haut de gamme en sont capables). En résumé, en ce qui concerne les VLAN en sans fil, soit la borne supporte la norme 802.1Q sur son interface Ethernet et dispose d’un mécanisme pour attribuer des numéros de VLAN à ses clients, soit on multiplie le nombre de bornes en fonction du nombre de VLAN à déployer. Hormis ce fait, du côté utilisateur il n’y a pas beaucoup de différence par rapport à l’accès filaire, la durée de la phase d’authentification est la même et l’utilisation du WPA est transparente.

1.4. Configuration des clients �

Une fois que l’authenticator est prêt à relayer les requêtes d’authentification au serveur Freeradius et que ce dernier peut y répondre, il reste à configurer les postes utilisateur (les supplicants). Dans cette étude nous verrons la configuration d’un poste Windows XP puis celle d’un poste Linux. Une solution pour Macintosh n’a pas été étudiée mais Mac OS X intègre un client 802.1X (avec support notamment de EAP-TTLS).

./0/./�1 �� 2��3��

�

Un client 802.1X est intégré à Windows XP et il n’est pas nécessaire d’en installer un à moins d’utiliser la méthode d’authentification EAP-TTLS qui n’est pas prise en charge par le client intégré. Le client gratuit SecureW2 de Alfa & Ariss (librement disponible sur http://www.securew2.com) permet de combler ce manque. Nous avons testé les méthodes EAP-TLS, EAP-TTLS et EAP-PEAP, utilisant respectivement un certificat et pour les deux dernières un login/mot de passe (tous deux directement inclues dans le fichier « users » du serveur Freeradius), en filaire et en sans fil. De manière plus spécifique nous verrons la configuration d’une connexion WPA. La révision de la carte sans fil utilisée (trop récente) ne nous a malheureusement pas permis de tester ce mode sous Linux faute de pilotes disponibles. �

� Méthode EAP-TLS : �

Le certificat du serveur Freeradius, comme celui de l’utilisateur, est signé par l’autorité de certification CNRS-Test qui est elle-même autosignée. Pour indiquer au client 802.1X d’utiliser EAP-TLS, il faut sélectionner « Carte à puce ou autre certificat » dans l’onglet « Authentification » des propriétés de la connexion Ethernet (cf figure [16]).

� E+� �

�Figure [16] : Sélection de EAP-TLS

�

Puis en cliquant sur « Propriétés » on peut préciser le certificat à utiliser et paramétrer quelques options, par exemple nous avons du décocher la case « Valider le certificat du serveur » car les certificats que nous utilisions n’intégraient pas les extensions « X509v3 Extended Key Usage » (ceci est désormais corrigé sur l’IGC CNRS Standard). �

� E:� �

�Figure [17] : paramétrage de l’utilisation de certificat.

�

Une fois le client correctement paramétré et le certificat utilisateur installé, le fait de se brancher au réseau force l’authentification. Si plusieurs certificats utilisateur sont disponibles, Windows demande lequel utiliser sinon la procédure est automatique et l’authentification se fait sans l’intervention de l’utilisateur. La figure [18] montre une authentification réussie.

�Figure [18] : Authentification via certificat réussie

� E*� �

� Méthode EAP-PEAP : �

Cette méthode est directement implémentée dans le client 802.1X intégré à Windows. Elle est similaire à la méthode EAP-TTLS dans le fait qu’elle utilise un tunnel TLS pour protéger l’intégrité des messages d’authentification EAP. On sélectionne cette méthode de la même façon que pour EAP-TLS (cf figure [19]).

�Figure [19] : Sélection de EAP-PEAP

�

Nous devons ensuite sélectionner la méthode EAP qui sera utilisée dans le tunnel créé par PEAP, nous avons choisi MSCHAP-v2. �

� EE� �

�Figure [20] : Sélection de MSCHAP v2

�

Il est possible d’utiliser les identifiants fournis à l’ouverture de session Windows comme login/mot de passe, ainsi l’utilisateur n’a pas à intervenir. Nous avons choisi d’utiliser un couple login/mot de passe différent de celui de l’ouverture de session. �

�Figure [21] : Demande du client de rentrer le login/mot de passe

�

Lorsque la connexion au réseau est réalisée, Windows va demander à l’utilisateur de rentrer ces informations (cf. figure [21]), ce qui se fait en cliquant sur le témoin de connexion réseau dans la zone de notification.

� E,� �

�Figure [22] : Saisie des identifiants

�

L’authentification réussie est notifiée de la même façon qu’en utilisant la méthode EAP-TLS (cf Figure [22] : Authentification via certificat réussie). �

� Méthode EAP-TTLS : Cette méthode est identique à la précédente, à la différence qu’elle n’est pas supportée par Microsoft. Il faut donc utiliser un client EAP-TTLS qui se greffe au client 802.1X intégré.

� E>� �

�Figure [23] : Sélection du client EAP-TTLS

�

Puis à l’instar de PEAP, il faut sélectionner à nouveau une méthode d’authentification (qui utilisera donc le tunnel TLS pré-établi).

�Figure [24] : Sélection d’une méthode d’authentification

�

� EG� �

Nous avons réalisé nos tests avec MSCHAP v2, à noter que l’utilisation du client d’Alfa & Ariss permet de sélectionner une méthode basée sur l’algorithme MD5, ce qui peut être maintenant considéré comme sûr grâce à l’utilisation du tunnel TLS. �

� Méthode WPA pour une connexion WiFi : �

Comme nous l’avons vu au chapitre III, le WPA est pour l’instant le plus abouti en terme de sécurité des connexions sans fil et de compatibilité matérielle. Son utilisation côté client n’est pas plus compliquée que les méthodes vues précédemment, ce qui est un bon point vu les avancées majeures qu’elle propose en termes de sécurité.

�Figure [25] : Sélection du WPA

�

Il faut donc sélectionner pour l’ « Authentification réseau » WPA (à noter que WPA-PSK correspond à utiliser WPA avec un secret partagé par le client et le point d’accès, cf. partie III, dans notre cas nous utilisons nos certificats). Puis une méthode de « Cryptage des données », dans notre cas ce sera TKIP (notre matériel ne supportant pas AES). �

� E?� �

�Figure [26] : Sélection de TKIP

�

La configuration de l’utilisation des certificats (onglet « Authentification ») est analogue à celle qui a été faite pour EAP-TLS et si le poste ne dispose que d’un seul certificat utilisateur, la connexion est établie en WPA sans aucune intervention.

./0/4/�*��

�

Nous avons étudié 802.1X sur une distribution Fedora Core 2 (noyau 2.6.6). Le client « OpenSource » implémentant 802.1X est « Xsupplicant » dans sa version 1.0pre2 (www.open1x.org). Ce client supporte tous les types d’authentification EAP actuellement existants (EAP-PEAP inclus). Après une installation classique, le fichier exécutable xsupplicant se trouve dans « /usr/local/sbin », le fichier de configuration xsupplicant.conf dans « /etc/ ». C’est dans ce fichier de configuration qu’il faut indiquer le répertoire contenant les certificats (ceux de l’utilisateur et de l’autorité), indiquer son nom d’utilisateur et son mot de passe en fonction de la méthode EAP choisie. Dans sa version actuelle Xsupplicant ne propose pas d’interface graphique pour sa configuration, tout doit se faire « à la main », les auteurs précisent qu’une telle interface devrait apparaître dans une prochaine version. Par défaut le fichier de configuration doit contenir les mots de passe, le processus d’authentification se fait alors sans l’intervention de l’utilisateur, mais il est possible d’utiliser l’exécutable « xsup_monitor » fourni avec Xsupplicant, qui demande de saisir le mot de passe au cours de l’authentification dans un terminal, ceci permet d’éviter de laisser son mot de passe dans un fichier non crypté.

� EA� �

Afin de lancer l’authentification à chaque démarrage de la machine, nous avons modifié le fichier « /etc/rc.local », pour qu’il lance Xsupplicant automatiquement :

#!/bin/sh # # This script will be executed *after* all the other init scripts. # You can put your own initialization stuff in here if you don't # want to do the full Sys V style init stuff.

touch /var/lock/subsys/local /etc/sysconfig/network-scripts/ifdown eth0 /usr/local/sbin/xsupplicant -i eth0 -d 5& /sbin/ifconfig eth0 allmulti up

�

�

Le paramétrage de ce client est relativement austère, mais une fois correctement effectué il n’y a plus à y toucher. On peut définir plusieurs profils dans le fichier de configuration afin de pouvoir s’authentifier avec la même machine sur des réseaux différents sans avoir à modifier quoi que ce soit. En annexe [6] se trouve un extrait du journal de xsupplicant montrant une authentification 802.1X réussie.

1.5. Bilan �

Le déploiement de la solution 802.1X apparaît comme prometteuse pour les accès filaire et sans fil. Une fois le serveur d’authentification mis en place, les équipements réseau et les postes clients configurés, la migration vers cette solution est quasiment transparente pour l’utilisateur. L’utilisation d’une méthode d’authentification basée sur certificat ne demande aucune intervention de la part de l’utilisateur - il n’a pas à fournir à nouveau un login/mot de passe - et la durée de la phase d’authentification, une dizaine de secondes au maximum, ne représente pas une contrainte. L’utilisation de certificat évite également à l’administrateur d’avoir à gérer des comptes à mot de passe qui peuvent être source de tracas (mot de passe de l’utilisateur oublié, sécurité cruciale du fichier de mots de passe et de la machine l’abritant, etc.). Nous avons par contre constaté un souci avec les ordinateurs portables qui en sortant d’une mise en veille nécessitent de débrancher et rebrancher le câble réseau afin de forcer la ré-authentification. Des trois méthodes EAP testées (-TLS, -TTLS, -PEAP), c’est la méthode TLS, avec une IGC déployée, qui nous est apparue la plus simple d’emploi pour l’utilisateur. D’une part elle est disponible par défaut sous les Windows récents (2000, XP, en ce qui concerne 98 et NT l’utilisation d’un client tiers est indispensable) et dans le client 802.1X « Open Source » pour Linux, « Xsupplicant ». D’autre part grâce au fait que le certificat personnel de l’utilisateur lui suffit pour se connecter. La méthode PEAP, associée à MSCHAP-v2, est réservée au monde Windows et n’est donc recommandable que sur un parc « tout Windows ». La méthode TTLS, plus adaptive, permet de gérer un parc hétérogène en déployant un client 802.1X compatible. Il manque à cette étude l’utilisation d’une liste de révocation au niveau du serveur RADIUS, permettant d’écarter les utilisateurs tentant de se connecter avec des certificats révoqués, qui n’a pas pu être sérieusement étudiée dans les délais impartis. Ainsi que des essais avec d’autres systèmes d’exploitation, notamment Macintosh et les anciens Windows (98 essentiellement). Globalement avec le renforcement de la sécurité qu’elle apporte, cette solution semble viable pour être déployée dans un cadre de travail malgré les quelques changements d’habitude qu’elle imposera aux utilisateurs. A terme si elle est

� E@� �

déployée dans de nombreux laboratoires, il faudra penser à interfacer les serveurs RADIUS entre eux afin qu’ils puissent relayer les demandes d’authentification, ainsi un chercheur en déplacement dans un laboratoire serait authentifié par rebond par le serveur RADIUS de son propre laboratoire. L’administrateur devra tout même rajouter à ses machines d’importance critique le serveur RADIUS qui, rappelons-le, devra obligatoirement être redondant ; sans ce dernier c’est l’accès au réseau qui sera refusé. Il devra également prévoir un scénario de crise dans le cas où les deux serveurs RADIUS tomberaient en panne. Il serait préférable de déployer cette solution petit à petit, en soumettant d’abord un groupe restreint d’utilisateurs pendant plusieurs semaines ou de la limiter au WiFi, afin de minimiser les problèmes inhérents à l’utilisation d’une nouvelle technologie réseau dans un environnement de production. Quoi qu’il en soit, le laboratoire qui déploiera cette solution devra disposer de ressources humaines dédiées à l’informatique.

2. Accès à distance au réseau avec un VPN SSL �

L'Unité Réseaux du CNRS a bénéficié pendant trois semaines du prêt d’un concentrateur VPN SSL (http://www.nokia.com/nokia/0,,43098,00.html) de la société NOKIA ; prêt effectué par l'intermédiaire de la société Retis (http://www.retis.fr/). Ce type de produit, nouveau sur le marché, permet de garantir la sécurité des accès aux ressources du réseau interne en utilisant un tunnel SSL entre le client (connecté à un réseau public) et le boîtier VPN. Aucune configuration sur le poste de l’utilisateur n’est nécessaire, à la différence des solutions basées sur IPsec qui requièrent l’utilisation d’un client (parfois de la même marque que le concentrateur VPN). Ici tout se fait via un navigateur supportant HTTPS affichant un portail où sont présentées les ressources accessibles du réseau interne.

� ,+� �

�Figure [27] : Portail de connexion

� � �

Le VPN SSL peut effectuer un test d’intégrité du poste utilisateur (avant ou après son identification) si le plug-in Java (Java version 1.4 et plus) est installé pour le navigateur de l’utilisateur. Ce plug-in permet également d’effectuer de la redirection de port permettant à l’utilisateur d’accéder à des serveurs de son réseau interne d’une manière sécurisée (et en passant les pare-feux) grâce à l’encapsulation du trafic dans le tunnel SSL (port 443). Le VPN SSL est ainsi accessible à quasiment tous les postes connectés à Internet, toutes plateformes confondues. Durant ce prêt il a été testé avec succès sous Linux (Fedora Core 2) et Windows XP, avec les navigateurs Internet Explorer 6, Mozilla Firefox 0.9.2 et Netscape 7.1. Le concentrateur VPN a été installé sur le réseau de l’UREC dans le VLAN Test, avec une adresse IP publique d’une part (pour le test cette partie du réseau représente l’extérieur) et d’autre part sur un réseau privé (avec des adresses IP non routées) qui représente l’intranet avec des ressources typiques (comme ftp, smtp, ssh, un serveur web …) qui devront être accessibles de l’extérieur uniquement en passant par le VPN. �

� ,:� �

��

Figure [28] : Déploiement du concentrateur VPN SSL

2.1. Installation, paramétrage et administration du système �

Configuration initiale �

Le concentrateur possède un port console et trois ports Ethernet 10/100. La configuration initiale s’est faite via un terminal relié au port console pour attribuer un nom au boîtier et configurer une interface réseau pour l’intranet ainsi que pour effacer l’ancienne configuration. Ensuite toute la configuration s’est faite via un navigateur. Paramétrage général supplémentaire Via l’interface web de configuration (appelée Voyager) a été configurée la deuxième interface Ethernet pour le réseau public, puis le NSAS (Nokia Secure Access System) a été installé. Le NSAS est le serveur Web qui permet à l’administrateur d’administrer le concentrateur, il peut à travers elle ajouter/enlever/modifier des utilisateurs, des accès aux ressources internes et différents moyens d’authentification (login/mot de passe et certificat). C’est également ce serveur que les utilisateurs utilisent pour s’authentifier et accéder aux ressources (c’est lui qui installe l’applet java chez le client, qui affiche le portail, etc.). Le fait qu’il y ait deux interfaces web séparées pour la configuration matérielle du concentrateur et pour l’administration permet de ne pas noyer l’administrateur sous une avalanche de menus et d’options.

� ,*� �

Mise à jour Nous avons reçu, la dernière semaine de prêt, une nouvelle version du NSAS (V2). La mise à jour se fait facilement via l’interface web Voyager, en ayant préalablement copié le fichier compressé (.tgz) de la nouvelle version dans le répertoire « /opt/packages » sur le concentrateur VPN. A noter que l’ancienne version est juste désactivée pour y revenir rapidement en cas de problème, et toute la configuration est portée automatiquement sur la nouvelle version. Nous avons également installé le pack « language » qui permet de traduire en français l’interface NSAS. Problèmes rencontrés lors de l’installation De gros problèmes de latence ont été perçus en accédant au concentrateur VPN sur l’interface publique avec parfois des pertes de connexions. Pour remédier à cela nous avons dû désactiver l'auto-négociation des paramètres de la connexion Ethernet (10/100Mbits, full/half duplex) sur le concentrateur VPN et le port du switch sur lequel il était raccordé.

2.2. Fonctions d'accès aux ressources �

Le boîtier offre différentes méthodes d’accès aux ressources, méthodes décrites ci-dessous. A l’administrateur de choisir celles à appliquer dans son environnement. Navigation Web �

Un serveur web a été créé dans le réseau interne (inaccessible de l’extérieur) et l’accès à ce serveur de l’extérieur en passant par le concentrateur a été testé avec succès. A noter que dans ces tests, nous avons consacré très peu de temps à l’examen de cette fonction, qui ne semble pas d’une grande utilité dans notre environnement où nous utilisons des serveurs HTTPS où l’utilisateur se connecte et s’authentifie grâce à son certificat. �

Accès aux partages de fichiers &%�)%�F�

Le système permet d’accéder à des fichiers partagés « Windows » par l’intermédiaire de l’interface Web. Cette fonctionnalité a été testée avec succès avec un serveur Samba. Mais l'interface ne permet pas de travailler directement sur les fichiers (c’est à dire de façon transparente pour l'utilisateur) ; par exemple si l'utilisateur clique sur un document Word, ce dernier s’ouvre mais l'enregistrement (après modification) ne peut se faire qu’en local ; l'utilisateur devra le redéposer via l'interface web sur son compte samba. Le « glisser déposer » de fichier n'est pas possible. "�3�F�

Le système permet d’accéder aux ressources par l’intermédiaire d’un serveur FTP. Le rendu et les fonctionnalités sont analogues à celles offertes par l’intermédiaire du serveur samba. Un test concluant a été réalisé avec le produit vsftp. �

�

�

�

� ,E� �

Redirection de port Une autre possibilité nous est offerte pour accéder aux ressources internes ; il s’agit de la redirection de port. Cette fonctionnalité peut être mise en place de deux façons comme nous allons le voir sur l’exemple de SSH ; le service a été installé sur un serveur du réseau interne, là encore non accessible de l’extérieur. Le concentrateur a été configuré de façon à ce que l’applet java (qui se charge sur le poste utilisateur) intercepte les connexions sur 127.0.0.1 port 22, les envoie via le tunnel au concentrateur qui les redirige à son tour vers le serveur SSH. Dans cette configuration, l’utilisateur utilise son client habituel et rentre l’adresse 127.0.0.1 ; le reste de la connexion se passe comme s’il était physiquement sur le réseau interne. Cette fonctionnalité marche très bien et lorsque la redirection de port est lancée, une fenêtre affichée par l’applet indique l’état de la communication. A noter que dans cette configuration, la commande à passer (ssh 127.0.0.1) n’est pas la même que celle à faire si on est directement sur le réseau (par exemple ssh nom_du_serveur). Il est possible si l’utilisateur possède des droits suffisants (droits administrateur) de rendre la connexion transparente (quel que soit l’endroit, l’utilisateur saisit ssh nom_du_serveur). Pour cela, il faut cocher une option qui autorise l’applet à modifier le fichier hosts sur le poste client, afin que ce dernier utilise à la place de l’IP 127.0.0.1 le nom du serveur qu'il utilise sur son réseau interne. Pour ce faire l’applet rajoute dans le fichier hosts une correspondance « Nom du serveur de la ressource » <-> 127.0.0.1. Le nom du serveur doit être « fully qualified » (ie : un DNS accessible doit pouvoir associer le nom du serveur à son adresse IP) pour que la modification du fichier hosts soit possible, sinon l’association « Nom du serveur de la ressource » <-> 127.0.0.1 ne fonctionne pas. En plus du service SSH, nous avons testé avec succès la redirection IMAP et SMTP, qui permet d'utiliser son client habituel et d'atteindre son serveur mail quelque soit le point de connexion. Les essais avec FTP se sont soldés par un échec (cela n'a pas marché, nous arrivons à nous loguer mais le transfert de fichier n’a pas fonctionné – sans doute à cause des ports dynamiques). Ce problème a été contourné en utilisant le protocole SSH pour le transfert de fichier (SFTP, WinSCP). La redirection de port permet aussi d’affecter une lettre de lecteur à un disque partagé (« drive mapping »). Ainsi l’espace de fichiers (situé dans l’intranet) apparaît comme un simple dossier dans le voisinage réseau.

� ,,� �

Messagerie (proxy) Le boîtier possède aussi une fonctionnalité de « proxy mail » - dans ce cas, le client de messagerie interroge le concentrateur et non son serveur de messagerie habituel. A noter que dans ce cas, il faut laisser des ports supplémentaires ouverts (25, 143) au niveau du concentrateur. La figure [29] ci-dessous montre l’apparence du portail une fois l’utilisateur (ici « test1 ») authentifié, les ressources accessibles apparaissent sous forme de liens :

�Figure [29] : Portail affiché une fois authentifié

2.3. Systèmes d’authentification, gestion des accès �

Méthodes d’authentification Deux modes d’authentification sont possibles avec le boîtier : par couple « utilisateur / mot de passe » ou par certificat. Ces informations peuvent être stockées en local (c'est-à-dire que le concentrateur stocke dans sa mémoire ces informations) ou en externe (serveur d’authentification externe, via RADIUS, Active directory, LDAP, NTLM, Unix-NIS, …). Si l’authentification se fait par certificat, on fournit au concentrateur les CA (Autorité de Certification en français) pour qu'il puisse reconnaître les certificats issus de ces CA. Durant ces tests ont été testées avec succès la méthode locale (utilisateur / mot de passe) et celle, externe, via les certificats. La méthode par utilisateur / mot de passe ne présente pas de difficulté majeure.

� ,>� �

�

La méthode via certificat s'est révélée plus complexe à déployer. Cela pour deux raisons principales : la volonté d’utiliser un certificat de l’autorité de certification CNRS-Standard (qui n’est pas autosignée mais dépend d’une autorité supérieure, d’où le besoin de faire gérer par le boîtier la chaîne de certification CNRS -> CNRS-Standard) et la volonté de faire un contrôle d’accès personnalisé, d’ou la nécessité de réaliser une correspondance (simple, portant sur un champs (OID) du certificat, ou explicite, portant sur l’ensemble des champs) entre un certificat et un utilisateur. Tout a fonctionné, sauf la correspondance simple en fonction de l’adresse « email » (à cause de l’OID « E » que cherche le boîtier et l’OID « emailAddress » qu’utilisent les certificats issus de l’IGC CNRS-Standard). Il est ressorti des tests une fonctionnalité intéressante, qui semble exister uniquement avec les certificats : le basculement d’un utilisateur « non reconnu » par son certificat (la correspondance n’a pas fonctionné) dans un groupe par défaut, qui pourrait être par exemple le groupe des utilisateurs externes. �

Des tests sur les certificats, il ressort que ce produit a l’air assez jeune sur ce sujet (par exemple, absence de prise en compte des listes de révocation, faiblesse au niveau de la correspondance simple à cause d’OID fixé par défaut, à noter que ce problème est contourné par la correspondance explicite, menu complexe, ….), mais il semble prometteur. Gestion des utilisateurs Un utilisateur est défini par son nom, sa ou ses méthode(s) d’authentification et son groupe d’appartenance, on peut en plus définir, indépendamment des paramètres de son groupe, ce qu’il y aura affiché sur sa page d’accueil (liens vers les ressources accessibles) et certains paramètres de connexion comme la durée du time-out en cas d’inactivité. Sur ce produit on n’ajoute pas les ressources accessibles pour un groupe donné mais on ajoute les groupes autorisés pour une ressource donnée (à partir de l’écran de configuration de cette dernière). Le concentrateur peut importer une liste d’utilisateurs sous forme de fichier texte. La gestion des utilisateurs et des groupes est simple et efficace. Contrôle d’accès Un grand atout dont dispose ce produit est sa granularité dans le contrôle d’accès. Ainsi il va être possible d’autoriser/interdire l’accès à des ressources en fonction de nombreux paramètres en plus du nom d'utilisateur et du groupe d'appartenance tels que l’heure, la date, la validité de son test d’intégrité, sa méthode d’authentification (mot de passe ou certificat), la taille de la clé SSL utilisée pour le cryptage, etc. Tests d'intégrité Le concentrateur est livré avec quatre scripts testant l'intégrité du poste utilisateur, ils testent la présence de fichiers (permettant de savoir si un antivirus est installé), la présence de programmes en mémoire (pour savoir si l'antivirus est lancé), la présence de « mauvais fichiers » (indiquant la présence d'un virus/ver/trojan) et enfin la présence de ports ouverts (indiquant qu'un ver ou trojan est activé sur la machine – utilisation de la commande « netstat »). Seul ce dernier test est possible aux machines Linux, tous les autres sont spécifiques aux plateformes Windows. Ces scripts sont lancés par l’applet Java (ils nécessitent la présence du plug-in Java pour leur exécution) ; il est possible d’écrire des scripts personnels.

� ,G� �

Pour faire prendre en compte ces scripts, des règles sont à définir ; par exemple, la règle suivante pourrait être définie : « exécuter le script de vérification des fichiers mauvais uniquement si l’adresse IP de connexion n’appartient pas à un réseau de confiance ». Une fois définie cette règle s’applique à tous ceux qui remplissent la condition d’exécution du script. Ensuite, c’est à l’administrateur de décider ce qu’il veut faire des résultats de l’exécution des règles ; il peut décider d’en informer simplement l’utilisateur (c’est-à-dire ne rien bloquer) ou il peut décider d’affecter des accès différents en fonction du résultat, c'est-à-dire autoriser ou non l’accès à certaines ressources.

2.4. Bilan �

Ce produit possède des fonctionnalités intéressantes et originales au niveau des contrôles d’accès et des tests d’intégrité. De plus la granularité très poussée convient parfaitement à l’environnement de type laboratoire où se côtoient de multiples catégories d’utilisateurs aux droits et besoins différents. Dans un environnement comme le CNRS ou l’on tend à généraliser l’utilisation de certificat, il est regrettable que cette fonction se soit révélée fastidieuse à déployer. Enfin un avantage indéniable de ce type de produit est qu’il permet de limiter le nombre de services de la zone démilitarisée (DMZ) du réseau de l’organisation, permettant ainsi de réduire le nombre de maillons faibles dans la chaîne de sécurité. Quoi qu’il en soit, la mise en place d’un VPN doit se faire en fonction de l’existant, par exemple si un réseau propose déjà à ses utilisateurs en déplacement un serveur IMAPS permettant de récupérer de façon sécurisée ses messages, un serveur SSH accessible de l’extérieur pour travailler et accéder à ses fichiers, l’intérêt d’ajouter un concentrateur VPN est faible, en revanche si le réseau du laboratoire doit se plier à des règles de filtrage strictes imposées par le réseau de niveau supérieur (de campus par exemple) et que très peu de ports sont ouverts sur l’extérieur, alors un concentrateur VPN est une bonne solution pour proposer ces services en s’affranchissant des règles de filtrage. De plus sur ce type de VPN SSL, la granularité permise au niveau des droits d’accès aux ressources permet d’améliorer la sécurité des accès distants. Enfin il aurait été intéressant d’étudier en parallèle une solution VPN IPsec pour comparer à l’utilisation les avantages et inconvénients de chaque solution.

� ,?� �

Conclusion �

Les laboratoires doivent fournir de la connectivité à leurs personnels et invités, nous avons vu la solution 802.1X et comment protéger les accès sans fil, et doivent permettre à ce personnel de rentrer sur leur réseau lorsqu’ils sont en déplacement, pour ce cas nous avons vu les solutions de type VPN. Ceci représente l’aspect non symétrique du nomadisme et implique donc dans chaque cas l’utilisation de technologies différentes. Les solutions proposées dans ce rapport ne sont pas figées et continuent d’évoluer de concert avec les besoins des utilisateurs et avec les avancées technologiques. De plus il n’existe pas une solution unique pour tous les accès nomades, et certaines sont viables pour différents types d’accès, par exemple une solution de type VPN est utilisable pour les accès distant et sans fil. Les meilleures solutions se révéleront après des essais approfondis et plus longs dans le temps avant de pouvoir être déployées dans un environnement de production. Après quatre mois d’étude et vu l’étendue du domaine du travail, Il reste encore beaucoup à étudier, notamment les tests d’intégrité des postes avant leur accès aux ressources ainsi qu’un comparatif VPN IPsec/SSL basé sur une utilisation dans le temps, et c’est pourquoi mon stage se prolonge en un CDD de quatre mois supplémentaires au sein de l’UREC. De plus il faut garder à l’esprit que les possibilités techniques des solutions mobiles et les freins liés à leur mise en place ne doivent pas occulter les freins déjà présents dans les applications qu’elles supportent, ainsi les problèmes liés à l’utilisation d’applications en local ne disparaîtront pas avec l’ajout de solutions mobiles. Ce stage a été pour moi une expérience extrêmement enrichissante au niveau technique et sur le monde du travail, il me permet de plus de rentrer dans la vie professionnelle.

� ,A� �

Annexes : �

)��5.6�%�# ��7��

�

��

)��546�%�8 ��(��"��)�7*� ��

Le premier champ apparaissant dans la trame est en haut, le dernier en bas : �

��H��

3��#��2� ��

3�#$��H��

3�#$��)��H�9��

3�#$��)��H�

� � �

" ��ME+N�D�"��.��C��.��%3�9��

�

Ethernet Type : Codé sur deux octets, pour un réseau Ethernet la valeur est 0x888e Protocol Version : Codé sur un octet, contient pour le moment la valeur 1 Packet Type : Contient une valeur codée sur un octet définissant le type de paquet

transmis, pour le moment il en existe cinq différents : � 0000 0000 indique que la trame transporte un paquet EAP (décrit ci-dessous) � 0000 0001 indique qu'il s'agit d'une trame EAPOL-Start, utilisée par le supplicant

pour initier avec l'authenticator une phase d'authentification. � 0000 0010 indique qu'il s'agit d'une trame EAPOL-Logoff, utilisée par le supplicant

lorsqu'il se déconnecte.

� ,@� �

� 0000 0011 indique une trame EAPOL-Key, utilisée pour la gestion des clés de chiffrement

� 0000 0100 indique une trame EAPOL-Encapsulated-ASF-Alert utilisée pour les messages SNMP [x]

�

Packet Body Length : Codé sur deux octets cette valeur indique la longueur du champ suivant (la taille des données qui y sont transportées), une valeur égale à zéro indique que le champs Packet body n'existe pas (pas de données).

Packet Body : ce champ est présent si le type du paquet (indiqué par le champ

Packet-type) est EAP-Packet, EAPOL-Key ou EAPOL-Encapsulated-ASF-Alert. Pour tous les autres types ce champ est absent. Dans le cas d'un type EAP-Packet, exactement un paquet EAP est encapsulé dans cette trame. Dans le cas d'un type EAPOL-Key, ce champ contient exactement un descripteur de clé (Key Descriptor, décrit ci-dessous).

�

�

�

�#� ��H��

OH�9��

��H��

OH��2�

OH��;�

OH�& ��

OH�

�

" ��ME:N�F�OH��#� ��

�

Le Key Descriptor permet de gérer l'échange de clé de chiffrement (permettant l'attribution dynamique de clé WEP dans le cas de réseau sans fil 802.11, où le média est partagé par plusieurs équipements). Il est utilisé pour attribuer les clés unicast, broadcast et multicast, la protection contre le rejeu est assurée par le champ Counter Replay.

�

�

�

�

�

�

�

�

�

� >+� �

�

�

�

Le champ Packet Body d’une trame EAPoL de type EAP-Packet contient un paquet : �

��

�� 7 ��

9��

��

" ��ME*N�F�3�5��%3�

�

Code : c'est le type du paquet, quatre valeurs possibles : � 1 pour Request � 2 pour Response � 3 pour Success � 4 pour Failure

�

Identifiant : Un nombre codé sur un octet permettant d'associer les requêtes et les réponses. Lorsque l'Authenticator émet un paquet Request/Identity, il utilise un numéro identifiant qui sera retrouvé dans tous les échanges suivants.

Longueur : Représente sur deux octets la taille totale du paquet, la fragmentation des

paquets EAP n'étant pas permise, la longueur maximale dépendra de la taille maximale d'une trame Ethernet (MTU).

Données : Leur taille varie de zéro (pour les paquets de type Success et Failure) à

plusieurs octets (pour les paquets Request et Response).

� >:� �

)��596�%��)��+)��

�Le protocole RADIUS utilise UDP, le serveur écoute pour les besoins d'authentification

sur le port 1812. �

��

�� 7 ��

9��

%�� #��

%�� -��

" ��MEEN�F�"��.��C��5��%��&�

�

Code : Donne la fonction du paquet, ici sont définis les codes relatifs à l'authentification :

� 1 pour Access-Request : Emis par l'authenticator vers le serveur RADIUS pour l'authentification d'une connexion.

� 2 pour Access-Accept : Emis par le serveur en cas d'authentification réussie. � 3 pour Access-Reject : Emis par le serveur en cas d'authentification non réussie. � 11 pour Access-Chalenge : Réponse du serveur à un Access-Request pour

authentifier le supplicant. �

Identifier : Codé sur un octet, cette valeur permet d'associer requête et réponse. Length : Longueur du paquet Authenticator : Valeur codée sur 16 octets permettant de contrôler l'intégrité du paquet

et d'authentifier le serveur et l'authenticator via un secret partagé. Attributes : Liste d'attributs RADIUS, ayant le format suivant :

�

�

�

�H��

9��

2��

" ��ME,N�F�9 ��!�� -��

�

Type : code de l'attribut sur un octet. Le code d'un message EAP est 79

� >*� �

Length : Taille des trois champs cumulés Value : valeur de l'attribut

�

Lorsque l'authenticator reçoit un message EAPOL de la part du supplicant qu'il doit faire parvenir au serveur d'authentification, il le transforme en un paquet RADIUS ayant un attribut de code 79 indiquant qu’il encapsule un paquet EAP.

)��506�%�:�� "�� 1 �8��

1 �)�%��

Une fois en possession de la PMK, le processus de génération de toutes les clés nécessaires à la session WiFi peut commencer. Tout d’abord il faut fournir à une fonction de hashage (glossaire : hash) la PMK, deux nombres aléatoires (échangés en clair entre les deux parties), et les adresses MAC des deux parties. Quatre paquets EAPoL (cf. III. 1.2. EAPoL) seront échangés dans une phase appelée « 4-Way Handshake ». Le résultat (identique aux deux parties) est une clé de 512 bits appelée PTK (Pairwise Transient Key). Cette nouvelle clé va être découpée en quatre pour obtenir : • Une clé de 128 bits appelée KCK (Key Confirmation Key) qui permet de prouver à

l’autre partie que l’on possède bien la bonne PMK. • Une clé de 128 bits appelée KEK (Key Encryption Key) qui va assurer la distribution

de la clé de groupe GTK (Group Transient Key). • Une clé de 128 bits qui sera la clé de session utilisée dans le mécanisme de

chiffrement. • Deux clés de 64 bits dédiées au contrôle d’intégrité, une pour chaque sens de

communication. �

La clé de groupe GTK sert à chiffrer les trafics multicast [glossaire] et broadcast [glossaire]. Elle est commune à tous les participants (le point d’accès et les clients associés). Chacun d’eux la recevra chiffrée avec sa KEK.

Il reste maintenant à générer la clé qui sera fournie au moteur WEP pour chiffrer les

trames unicast. Cette clé est générée en deux phases (mixing phases) à partir de trois éléments : la clé de session de 128 bits, un vecteur d’initialisation (IV [glossaire]) de 48 bits appelé Extended IV et enfin l’adresse MAC de l’émetteur qui est codée sur 48 bits.

Lors de la première phase la clé de session, l’adresse MAC et les seize premiers bits de l’IV sont fournis à une fonction de hashage dont le résultat est une clé intermédiaire de 128 bits qui va être à nouveau fournie à une fonction de hashage avec les 32 derniers bits de l’IV. Le résultat final est la clé de chiffrement de 128 bits, la PPK (Pair Packet Key) qui sera fournie au moteur WEP de la carte sans fil de la même façon qu’auparavant, c'est-à-dire d’abord les 24 premiers bits (qui prendront la place de l’ancien IV dans la première génération du WEP) puis les 104 suivants (correspondant à la clé WEP). Le vecteur d’initialisation de 48 bits va en outre servir de numéro de séquence, il sera incrémenté à chaque transmission. Grâce à ce mécanisme la clé de chiffrement est décorrellée des éléments qui l’ont généré, et assure que deux trames ne seront pas chiffrées avec la même clé durant la même session.

� >E� �

�

)��5;6�%�� (�� 8��

Les étapes décrites ici sont pour une installation standard de Freeradius qui place les différents fichiers à leur emplacement prévu par défaut.

��+8@8?�8��8�K

�

�

��&&9�F�M��FLL��8��N�

� 9��(� �� #��+8@8?��

� �� F�

� � � �

7��7��8��8��

��+8@8?8��8�K�

-H�

��K;(7��+8@8?8��8�K�

#��+8@8?�

8L#��7 ��P�.�$P�.�$� ��

� � � �

"�� F�M��FLL"�� 8��#7��8��N�

� 9��(� �� .�.��C��:8+8+��E�

� � � �

��K;(7�"�� :8+8+��E8��8�K�

#��"�� :8+8+��E�

8L#��7 ��P�.�$P�.�$� ��

�

)��5<6�%��"��, ��3��

��"�� )��&*��%��[ALL] Got EAP-Request-Authentication. [STATE] ACQUIRED -> AUTHENTICATING) [STATE] Processing AUTHENTICATING state. [STATE] Sending EAPOL-Response-Authentication [ALL] (EAP-TLS) Initialized. [CONFIG] Loading certificate /etc/1x/cnrs-test.pem . . . [CONFIG] Loaded root certificate /etc/1x/cnrs-test.pem and dirctory (null) [CONFIG] Loading user Private Key from /etc/1x/key.pem... [AUTH TYPE] --- SSL : before/connect initialization [AUTH TYPE] --- SSL : before/connect initialization [AUTH TYPE] --- SSL : SSLv3 write client hello A [AUTH TYPE] --- SSL : SSLv3 read server hello A [ALL] Processing interface eth0... [ALL] Got EAP-Request-Authentication. [STATE] Processing AUTHENTICATING state. [STATE] Sending EAPOL-Response-Authentication [AUTH TYPE] --- SSL : SSLv3 read server hello A [AUTH TYPE] --- SSL : SSLv3 read server certificate A [ALL] Sending TLS ACK! [ALL] Processing interface eth0... [ALL] Got EAP-Request-Authentication. [STATE] Processing AUTHENTICATING state. [STATE] Sending EAPOL-Response-Authentication [AUTH TYPE] --- SSL_verify : depth 1 [AUTH TYPE] --- SSL_verify : depth 0

� >,� �

[AUTH TYPE] --- SSL : SSLv3 read server certificate A [AUTH TYPE] --- SSL : SSLv3 read server certificate request A [AUTH TYPE] --- SSL : SSLv3 read server done A [AUTH TYPE] --- SSL : SSLv3 write client certificate A [AUTH TYPE] --- SSL : SSLv3 write client key exchange A [AUTH TYPE] --- SSL : SSLv3 write certificate verify A [AUTH TYPE] --- SSL : SSLv3 write change cipher spec A [AUTH TYPE] --- SSL : SSLv3 write finished A [AUTH TYPE] --- SSL : SSLv3 flush data [AUTH TYPE] --- SSL : SSLv3 read finished A [ALL] Got EAP-Request-Authentication. [STATE] Processing AUTHENTICATING state. [STATE] Sending EAPOL-Response-Authentication [AUTH TYPE] --- SSL : SSLv3 read finished A [AUTH TYPE] --- SSL : SSL negotiation finished successfully [AUTH TYPE] --- SSL : SSL negotiation finished successfully [ALL] Sending TLS ACK! [ALL] Processing interface eth0... [ALL] Got EAP-Success! Authenticated! [ALL] Processing command : dhclient %i [ALL] Returning command : dhclient eth0 [ALL] Actual command being called is dhclient [ALL] Generating key block! [ALL] Using session key const of : client EAP encryption [STATE] (global) -> AUTHENTICATED [ALL] Processing interface eth0... [ALL] Clock tick! authWhile=29 heldWhile=53 startWhen=0 curState=AUTHENTICATED

�

� >>� �

Glossaire : �

AES : Advanced Encryption Standard CA : Autorité de Certification Certificat électronique : un certificat électronique est un fichier utilisé pour la signature et le

chiffrement de messages CNRS : Centre National de la Recherche Scientifique DHCP : Dynamic Host Configuration Protocol, protocole permettant l’affectation d’adresses

IP DMZ : DeMilitarized Zone, sous-réseau situé entre l’intranet et l’extranet dont les machines

sont directement accessibles de l’extérieur (serveur web, messagerie, concentrateur VPN…)

EAP : Extensible Authentication Protocol, protocole dédié au transport de crédit d'authentification ESSID : Extended Service Set ID, identifiant d’un réseau sans fil FAI : Fournisseur d’Accès Internet Hot-spot : Lieu public où une connexion WiFi, gratuite ou payante, est disponible IKE : Internet Key Exchange IGC : Infrastructure de Gestion de Clé IMAP : Internet Message Access Protocol, protocole d’accès à un serveur de courrier électronique IPsec : Internet Protocol SECurity LAN : Local Area Network, réseau local MAC (Adresse) : adresse physique d'une interface réseau, elle intervient au niveau 2 du modèle OSI NAT : Network Address Translation, un réseau où seul le routeur de sortie possède une

adresse IP publique effectue de la translation d'adresse (NAT) OID : Object IDentifier, identifiant d’un objet – identifie un champ particulier d’un certificat Open Source : Un programme est dit Open Source lorsque son code source est librement disponible OSI (Open System Interconnection) : Modèle standard décrivant un empilage de couches

ayant chacune un rôle précis dans les communications informatiques RADIUS : Remote Authentication Dial-In User Service RENATER : Réseau National de Télécommunications pour la Technologie, l'Enseignement

et la Recherche SI : Système d'Information SMTP : Simple Mail Transfer Protocol, protocole de transfert de courrier électronique entre

serveurs de messagerie SSH : Secure Shell, méthode permettant à un utilisateur de se connecter à distance sur une

machine via un lien chiffré SSI : Sécurité des Systèmes d’Information SSL : Secure Socket Layer TLS : Transport Layer Security UREC : Unité des Réseaux du CNRS VLAN : Virtual LAN, découpage logique en sous-réseaux d'un réseau physique VPN : Virtual Private Network, réseau privé virtuel WEP : Wired Equivalent Privacy WiFi : Wireless Fidelity, nom commercial de la norme 802.11 WPA : WiFi Protected Access

� >G� �

Bibliographie & Webographie : �

Documents du recueil du JRES 2003 (Journée RESeau 2003) MISC informatique n° 6 et 12 Cisco SAFE : Wireless LAN Security in Depth (White Paper – http://www.cisco.com/) “X.509 Style Guide”, Peter Gutmann “Linux Wireless LAN HowTo, A bit more about the technologies involved...”, Jean Tourrilhes “ http://www.open1x.org/ & [email protected] http://www.openssl.org/ http://www.terena.nl/ http://www.urec.cnrs.fr/ http://www.freeradius.org/ & [email protected] http://standards.ieee.org/getieee802/download/802.1X-2001.pdf http://openvpn.sourceforge.net/ https://www-ext.lmcp.jussieu.fr/informatique/IPsec/IPsec.htm http://sourceforge.net/projects/madwifi & gmane.Linux.drivers.madwifi.user (sur news.gmane.org) �

�

ˆ · 2017-05-30 · technologiques censées y répondre pour finir par une quatrième partie où...

Documents

Transcript of ˆ · 2017-05-30 · technologiques censées y répondre pour finir par une quatrième partie où...