2006 Stage Leonard Dhcpbyport Openvpn Ipsec

Rapport de stage de licence R&T Pierre LEONARD

Mobilit et Scurit sur le rseau Raumur, mise en place de solutions DHCP et VPN

Rapport de stage de licence R&T

Universit Bordeaux 1 Service Raumur 351 crs de la Libration 33400 Talence

Tuteur de stage: Stagiaire: Laurent FACQ Pierre LEONARD 13 mars 16 juin 2006 Responsable pdagogique: Christophe BAILLOT


Mobilit et Scurit Service RAUMUR 2

Remerciements

Je tiens tout d'abord remercier mon tuteur de stage Laurent FACQ, pour son aide et ses conseils enrichissants qui m'ont permis d'avancer intelligemment dans ma rflexion et mon travail. Son savoir aura t une mine de renseignements pendant les 3 mois qu'aura dur ce stage. Je tiens aussi remercier l'ensemble du personnel Raumur 1 pour m'avoir accueilli en son sein et m'avoir permis d'effectuer ce stage dans les meilleures conditions qui soient. Les diffrents contacts humain et professionnel auront t trs fructueux pour moi.

1 Rseau Aquitain des Utilisateurs en Milieu Universitaire et de Recherche



Table des matires

1 Prsentation du service Raumur................................................................................... 6 1.1 Origine.......................................................................................................................... 6 1.2 Missions ....................................................................................................................... 6 1.3 Personnel ...................................................................................................................... 7 1.4 Topologie du rseau Raumur ..................................................................................... 8

2 Prsentation du sujet et de son contexte......................................................................... 9 2.1 Introduction .................................................................................................................. 9 2.2 Contexte ....................................................................................................................... 9

3 Solution DHCP ............................................................................................................... 11 3.1 Prsentation du protocole........................................................................................... 11

3.1.1 Introduction....................................................................................................... 11 3.1.2 La trame DHCP ................................................................................................ 12

3.2 Fonctionnement du protocole..................................................................................... 13 3.2.1 Illustration......................................................................................................... 13 3.2.2 Explication........................................................................................................ 13

3.3 Option 82 : DHCP Relay Agent Information............................................................. 14 3.3.1 DHCP Snooping ............................................................................................... 14 3.3.2 DHCP Relay Information Option ..................................................................... 14 3.3.3 Structure de loption 82 .................................................................................... 15

3.4 Architecture de la maquette ....................................................................................... 15 3.5 Dveloppement du script PERL................................................................................. 16

3.5.1 Le script ............................................................................................................ 16 3.5.2 Dhcpd.conf........................................................................................................ 16 3.5.3 Utilisation du script et du fichier utilisateur ..................................................... 18

4 Solutions VPN................................................................................................................. 19 4.1 Notion de VPN........................................................................................................... 19

4.1.1 Introduction au VPN......................................................................................... 19 4.1.2 Principe de fonctionnement .............................................................................. 19 4.1.3 Utilisation d'un VPN......................................................................................... 19 4.1.4 Protocole utilis pour raliser une connexion VPN.......................................... 20 4.1.5 Schma d'un VPN............................................................................................. 20

4.2 Openvpn ..................................................................................................................... 21 4.2.1 Prsentation....................................................................................................... 21 4.2.2 Cration des certificats et des cls RSA ........................................................... 21 4.2.3 Protocole SSL / TLS......................................................................................... 22 4.2.4 Interfaces TUN / TAP....................................................................................... 25 4.2.5 Test de dbit...................................................................................................... 27 4.2.6 Architecture retenue.......................................................................................... 29

4.3 IOS Cisco ................................................................................................................... 30 4.3.1 Prsentation....................................................................................................... 30 4.3.2 Protocole IPSEC ............................................................................................... 30 4.3.3 Protocoles ISAKMP/Oakley/SKEME.............................................................. 33



4.3.4 Protocole IKE ................................................................................................... 35 4.3.5 VRF (Virtual Routing and Forwarding) ........................................................... 36 4.3.6 Authentification du client VPN pour ltablissement du tunnel....................... 37 4.3.7 Authentification de lutilisateur ........................................................................ 39 4.3.8 Protocole RADIUS ........................................................................................... 40

5 Conclusions ..................................................................................................................... 43 5.1 Conclusion gnrale ................................................................................................... 43

5.1.1 DHCP................................................................................................................ 43 5.1.2 VPNs................................................................................................................. 43

5.2 Conclusion personnelle .............................................................................................. 44

Annexes

1 Solution DHCP ............................................................................................................... 46 1.1 Script Perl................................................................................................................... 46 1.2 Exemple de fichiers de configuration ........................................................................ 48

1.2.1 Fichier utilisateur .............................................................................................. 48 1.2.2 Fichier de dfinitions des classes...................................................................... 48 1.2.3 Fichiers de dfinitions des pools....................................................................... 49 1.2.4 Fichiers de configuration des switchs............................................................... 49 1.2.5 Fichier de configuration dhcp........................................................................... 50

2 Solutions VPN................................................................................................................. 51 2.1 Openvpn ..................................................................................................................... 51

2.1.1 Fichier de configuration dOpenssl .................................................................. 51 2.1.2 Fichiers de configuration dOpenvpn ............................................................... 53

2.2 IOS Cisco ................................................................................................................... 57 2.2.1 Configuration du routeur Cisco 2851 ............................................................... 57 2.2.2 Configuration du serveur RADIUS (Freeradius).............................................. 60



Table des figures

Figure 1-1 : Topologie du rseau Rnater .................................................................................. 6 Figure 1-2 : Organigramme........................................................................................................ 7 Figure 1-3 : Topologie du rseau Raumur................................................................................ 8 Figure 3-1 : Fonctionnement DHCP ........................................................................................ 13 Figure 3-2 : Maquette DHCP ................................................................................................... 15 Figure 4-1: Fonctionnement VPN ............................................................................................ 20 Figure 4-2 : Le protocole SSL/TLS dans son environnement.................................................. 22 Figure 4-3 : Ngociation SSL Client/Serveur .......................................................................... 24 Figure 4-4: Schma darchitecture Openvpn............................................................................ 29 Figure 4-5: IPSec dans le modle OSI ..................................................................................... 31 Figure 4-6: Fonctionnement VRFs........................................................................................... 37 Figure 4-7: Schma dauthentification ..................................................................................... 38 Figure 4-8: Fonctionnement RADIUS ..................................................................................... 42



1 Prsentation du service Raumur 1.1 Origine

Le rseau Rnater 2 a t cr en 1991 dans le but d'interconnecter les diffrentes universits et laboratoires de recherche franais via des liaisons ddies et spcialises ainsi que de les relier Internet.

Figure 1-1 : Topologie du rseau Rnater

Le service Raumur est n d'un besoin de crer un service rgional d'interconnexion des diffrents organismes universitaires Aquitains.

1.2 Missions

Le service Raumur est un service inter-universitaire qui a t cr afin de prendre en charge le rseau informatique de campus haut dbit. Une de ses missions pour les partenaires du campus Talence, Pessac, Gradignan est dassurer la maintenance et le dveloppement de moyens et de services rseaux communs dans le cadre des enseignements universitaires et de la recherche. Raumur fixe notamment les conditions scuritaires dutilisation, en accord avec les partenaires. Le service de base ralis par Raumur consiste mutualiser les services de connexion Rnater. Raumur a galement une mission au niveau rgional, puisquil est gestionnaire de la plaque rseau rgionale ESRA pour les tablissements dEnseignement Suprieur et de Recherche en Aquitaine. Cette mission concerne les partenaires dj cits auxquels sajoutent le Rectorat de Bordeaux, le CEMAGREF, lEAPBx, lENITA de Bordeaux, lINRA Aquitaine, lIUFM dAquitaine, lUniversit de Pau et des Pays de lAdour, et enfin lEcole de Management de Bordeaux.

2 Rseau National de tlcommunications pour la Technologie lEnseignement et la Recherche



1.3 Personnel

Le service Raumur est compos de 8 personnes + 2 stagiaires actuellement:

Figure 1-2 : Organigramme



1.4 Topologie du rseau Raumur

Figure 1-3 : Topologie du rseau Raumur



2 Prsentation du sujet et de son contexte 2.1 Introduction

Le rseau universitaire de Bordeaux est trs vaste et ncessite de pouvoir authentifier et tracer tous les utilisateurs quelque soit leur mode de connexion sur celui-ci, pour cela chaque cas doit tre tudi et une solution adapt envisage. Il existe, sur le rseau du campus, plusieurs cas de connexion pouvant poser des problmes de scurit et/ou dauthentification tels que les congrs ou les runions avec des intervenants extrieurs ayant besoin daccs au rseau, les accs distants ou certains studios possdant des accs au rseau, etc... Il faut donc tre en mesure dapporter des solutions toutes ces situations, et ce, de manire scuris. Nous allons nous intresser ici deux cas particuliers que sont les serveurs DHCP avec attribution dadresse IP fixe en fonction du port, ainsi que les accs distants via VPN. Ces diffrents contrles daccs dpendent du lieu, de la population vis ainsi que du matriel utilis.

L'installation de serveurs DHCP 3 s'inscrit dans le cadre d'une ouverture et d'une simplification de l'utilisation du rseau Rnater et Internet. Mais ce mode d'attribution d'adressage implique un manque de suivi des connexions donc un amoindrissement de la scurisation des rseaux informatiques et de la prvention des actes illicites, c'est pourquoi il est trs important de nos jours de pouvoir maintenir un niveau de scurit suffisant et ncessaire au sein d'un rseau tel que le rseau Raumur, ou plus grande chelle Rnater.

Cette maintenance de scurit et de suivi passe par une bonne configuration de tous les quipements du rseau et notamment par la configuration de serveurs DHCP, en charge de l'attribution dynamique d'adresse IP:

Fix : dans le cas d'attribution en fonction de l'adresse MAC 5 de la carte rseau de l'utilisateur ou de la position de l'utilisateur sur le rseau

Alatoire : pour des utilisateurs totalement nomade au sein du rseau du campus recevant des adresses appartenant un pool d'adresses disposition et gr par le serveur.

En ce qui concerne la solution VPN 4, son but est dassurer la confidentialit des changes entre un utilisateur connect depuis lextrieur et le rseau universitaire via un tunnel chiffr et authentifi de part et d'autre, le tout via le media non sr qu'est l'Internet. Ce type de solution est bien moins cher que la location de lignes spcialises, bien que ces dernires assurent un dbit maximal et une qualit de service suprieure celle d'un VPN.

2.2 Contexte

Le campus possde des studios mis la disposition enseignants/chercheurs trangers de passage, et quips de prises Ethernet pour la connexion au Rseau du campus.

Dans la configuration actuelle de cette partie du rseau, les utilisateurs de ces chambres ont la possibilit de se connecter l'Internet l'aide d'une configuration IP fixe affiche sur la porte du studio. Chaque prise est ensuite filtre par des ACLs 6 configurs sur les quipements en charge de la connexion de ces studios sur le rseau universitaire. Cette mthode permet de pouvoir tracer un utilisateur puisqu une IP correspond un studio et, un studio et une date correspond un locataire.

3 Dynamic Host Configuration Protocol

4 Virtual Private Network

5 Media Access Control 6 Access Control List



Mais cette gestion de l'adressage pose plusieurs problmes puisque les utilisateurs novices en matire de rseau informatique, et principalement en ce qui concerne leur configuration, se trouvent confront une situation dans laquelle ils doivent eux mme configurer leur machine pour accder au rseau :

Mauvaise connaissance des rseaux informatiques

Mconnaissance des zones de configuration de leur machine

Mauvaise lecture de l'adressage impos dans le studio o ils se trouvent

Mauvaise configuration de la machine

Surcharge de travail pour le personnel du Raumur

Rsultat => Peu pratique et gourmand en assistance

La solution envisage est donc d'installer un serveur DHCP qui assignera automatiquement la bonne IP chacun des utilisateurs de ces studios, un peu comme un FAI 7 le ferait. La configuration en IP fixe en fonction de l'adresse MAC de la machine nest pas envisageable dans l'tat actuel des choses puisque la proprit principale d'une adresse MAC est justement son unicit or le locataire peut changer tous moment. Une des configurations possibles consiste utiliser l'option 82 du serveur DHCP, il s'agit du "Relay Information Option", en d'autres termes le champ option de la requte DHCP va tre complt par l'agent de relais (routeur ou switch); cette option permettra ensuite de retracer la provenance d'une requte DHCP.

Il existe galement un projet daccs distants mettant en uvre des VPN et permettant une fois lauthentification effectue, de placer lutilisateur dans son rseau de travail dorigine puisque chaque service ou site correspond un VLAN sur le rseau Raumur. Il existe pour cela deux solutions diffrentes tudier:

Openvpn : ce logiciel provenant du monde libre s'installe sur un systme d'exploitation de type Unix et fonctionne sur un modle client/serveur. Il permet d'assurer la communication chiffre, grce au protocole SSL/TLS, et authentifie l'aide de certificats et/ou d'un systme de cls partages.

Utiliser un routeur en tant que concentrateur VPN; il faut pour cela mettre jour lIOS8 du routeur en charge de concentrer les VPN, voir mme lui ajouter un module dacclration de cryptologie, dans le but de pouvoir crer simultanment un grand nombre de tunnels chiffrs tablis laide du protocole IPSec assurant la confidentialit des changes.

7 Fournisseur dAccs Internet 8 Internet Operating System



3 Solution DHCP 3.1 Prsentation du protocole

3.1.1 Introduction

Le protocole DHCP est un protocole de configuration dynamique sur un rseau via le protocole UDP 9. Il permet entre autre d'assigner une adresse IP aux diffrentes machines, mais aussi de leur fournir les informations ncessaires au bon fonctionnement du rseau (passerelle, serveurs DNS, domaine) et tout a dynamiquement sans que l'utilisateur n'est rien d'autre faire que de se relier physiquement au rseau et dactiver loption DHCP.

Il s'agit d'un protocole client/serveur dfini par les RFCs 10 2131 et 2132 et bas sur le protocole BOOTP 11, apportant celui-ci de nouvelles fonctionnalits comme lallocation dynamique dadresses IP : il nest plus utile de renseigner manuellement une table de correspondance adresse MAC / adresse IP. Une adresse IP peut tre attribue partir dun ou plusieurs pools dadresses IP disponibles. En effet, le DHCP permet ladministrateur du rseau de crer un ensemble dadresses pouvant tre attribues aux clients. De cette faon, il peut dterminer des intervalles dadresses IP. Il peut donc dcider de donner un intervalle pour un segment et un autre intervalle pour un deuxime segment. De cette faon, la gestion du rseau est simplifie. Le protocole BOOTP ne permet pas cette possibilit.

Pour des raisons doptimisation des ressources rseau, DHCP permet lallocation dune adresse IP pour une certaine priode de temps cest ce quon appel un bail (lease en anglais), les adresses IP sont dlivres avec une dure de validit. Cette caractristique du DHCP lui permet de garder en mmoire, pour une certaine priode de temps, les adresses IP quil assigne aux clients, ainsi que les informations de lordinateur en question, cela entrane donc moins de transferts lors dune connexion. La priode de temps est dfinie par ladministrateur du rseau. Le protocole BOOTP, quant lui, na pas cette fonction; les postes clients utiliseront donc leur adresse IP et les informations reus sur la configuration jusqu ce quil soit redmarr.

Le protocole DHCP est surtout considr comme un remplacent du BOOTP. La plupart des implmentations TCP/IP 12 moderne offre aux clients le protocole DHCP laide dun serveur DHCP.

Le serveur DHCP utilise 2 ports : Port serveur : 67 Port client : 68

C'est--dire, par exemple, que les requtes vont du port UDP 68 du client vers le port UDP 67 du serveur.

9 User Datagram Protocol 10 Request For Comment 11 Bootpstrap Protocol 12 Transmission Control Protocol / Internet Protocol



3.1.2 La trame DHCP

Voici le contenu dune trame DHCP :

Type du Message : op (1)

Type de l'adresse MAC : htype (1)

Longueur de l'adresse MAC : hlen (1)

Nombre de saut : hops (1)

Identifiant de la transaction choisi alatoirement : xid (4)

Temps coul depuis le dbut de la transaction : secs (2)

Flag de broadcast : flag (2)

Adresse IP du client renseigne uniquement en cas de statut Bound, Renew, Rebinding : ciaddr (4)

Adresse IP du client renvoye par le serveur DHCP : yiaddr (4)

Adresse IP du serveur utiliser dans la prochaine tape du processus Bootp : siaddr (4)

Adresse IP de lagent de relais DHCP : giaddr (4)

Adresse MAC du client : chaddr (16)

Adresse optionnelle dun serveur : sname (64)

Nom du fichier utiliser pour le boot : file (128)

Options : options (variable)

* Les paramtres entre parenthses indiquent la taille du champ en octets.

Quelques prcisions sur certains champs :

op : est le type de message, si op vaut 1 le message est un DHCPRequest (trame DHCP mise par le client destination du serveur) si op vaut 2 cest un DHCPReply (trame DHCP mise par le serveur destination du client).

htype : dfini le type de ladresse MAC (ex : 1=Ethernet 10Mb/s).

xid : est lidentifiant de la transaction. Utilis pour associer les requtes dun client et les rponses dun serveur une mme transaction DHCP, il est choisi par le client DHCP et doit tre unique sur le rseau local.

flags : Le bit positionn le plus gauche de ce champ est appel le "Flag de Broadcast". Certains clients DHCP ne sont pas capables de recevoir des datagrammes unicast avant que leur pile TC/IP ne soit configure. Dans ce cas, le client DHCP positionne 1 le "Flag de Broadcast" (le bit le plus gauche du champ flags) sur toute trame DHCP quil met. Un serveur DHCP recevant une telle trame rpond alors systmatiquement par broadcast. Si le "Flag de Broadcast" nest pas positionn, les rponses des serveurs peuvent tre mises sous forme dunicast, ladresse MAC destinatrice tant celle du champ chaddr lu dans la trame cliente et ladresse IP destinatrice tant celle offerte par le serveur.

siaddr : Adresse IP du serveur utiliser dans la prochaine tape du processus Bootp. Ce champ est renseign dans les messages DHCP Offer et DHCP Ack.



3.2 Fonctionnement du protocole

3.2.1 Illustration

Figure 3-1 : Fonctionnement DHCP

3.2.2 Explication

Client Serveur 1 DHCPDISCOVER Le client recherche les serveurs DHCP disponibles

2 DHCPOFFER Le serveur dit qu'il est prt attribuer une adresse IP

3 DHCPREQUEST Le client demande l'attribution de l'adresse IP

4 DHCPACK Le serveur DHCP confirme l'attribution de l'adresse IP et envoies des informations de configuration rseau diverses (DNS, passerelle, etc...)

...

DHCPREQUEST Demande de renouvellement du bail

DHCPACK Le serveur attribue le bail au client

...

DHCPRELEASE Le client n'a plus besoin d'accder au rseau, il libre son adresse IP

Le serveur met fin au bail et libre l'adresse IP, cette dernire devient donc rutilisable



3.3 Option 82 : DHCP Relay Agent Information

La mise en uvre dune architecture telle que dcrite dans le contexte du sujet de stage, ncessite dapprofondir la notion de DHCP. En effet il existe une option relativement rcente (portant le numro 82) permettant de retracer la provenance dune trame DHCP sur le rseau, dans notre cas cela va grandement nous aider tant donn que le but est dattribuer une adresse IP fige sur une prise Ethernet donne et cela quelque soit lutilisateur et la machine connect derrire.

Pour mettre en uvre cette option il est ncessaire de possder sur le rseau des quipements possdant les fonctionnalits suivantes (Attention ! Il sagit de fonctionnalit sur des quipements Cisco) :

Ip dhcp snooping

Ip dhcp relay information option

3.3.1 DHCP Snooping

Pour protger au maximum le rseau des intrusions malveillantes il existe une fonctionnalit disponible sur des switchs tels que le Cisco catalyst 2950 Extended Image (utilis pour la maquette) permettant de spcifier une interface de confiance sur laquelle seront mises des trames pouvant provenir dun serveur DHCP, ainsi il sera impossible un intrus dinstaller un deuxime serveur DHCP pirate sur un autre port que celui dfinit de confiance. Cette option doit galement tre applique sur les vlans concerns par le serveur DHCP. Cette option conditionne lutilisation de loption suivante.

3.3.2 DHCP Relay Information Option

Cette fonctionnalit est la plus intressante des deux puisque cest elle qui va nous permettre de tracer une requte DHCP. En effet une fois activ, cette fonctionnalit permet de marquer les trames DHCPRequest en insrant dans le champ option de celle-ci, avec le code option 82, les informations suivantes :

Numro de VLAN 13 du port

Numro du module

Numro du port

Adresse MAC du switch sur lequel la trame arrive.

Il suffit alors simplement de rcuprer ces informations et de les traiter du ct du serveur DHCP afin dassigner une adresse IP fig en fonction de ces paramtres.

13 Virtual Local Area Network



3.3.3 Structure de loption 82

Code Length Agent Information Field 82 N i1 i2 i3 i4 iN

Cette option est divise en deux sous options : Agent Circuit ID : cette sous option contient le vlan, le module et le port de

linterface sur laquelle la trame dhcp arrive et porte le code option 1.

Suboption type (1)

Length (1) Circuit ID type (1)

Length (1) Vlan (2) Module (1) Port (1)

01 06 00 04 XXXX YY ZZ


Agent Remote ID : cette sous option contient ladresse MAC du switch relayant la trame dhcp et porte le code option 2.

Suboption type (1)

Length (1) Remote ID type (1)

Length (1) MAC Address (6)

02 08 00 06 aa :bb :cc :dd :ee :ff


3.4 Architecture de la maquette

Figure 3-2 : Maquette DHCP

* Les configurations et informations indiques sur le schma sont les vritables donnes utilises pour les tests.

Remarque : Pour les besoins de la maquette il a t ncessaire de crer des sous interfaces virtuelles sur

linterface physique du serveur DHCP dans le but de communiquer avec les vlans configurs sur le switch. Cette manipulation a t effectu laide de loutil vconfig sous Debian.



3.5 Dveloppement du script PERL

3.5.1 Le script

Pour faciliter la gnration du fichier de configurations dhcp, il ma t demand de dvelopper un script en PERL 14 (joint en annexe).

Le cahier des charges tait le suivant : Gnration des fichiers de dfinition de ladressage IP

Gnration du fichier de classes

Gnration des fichiers contenant la configuration des switchs mis en oeuvre.

Le but de ce script tant de gnrer tous ces fichiers il est ncessaire de rcuprer les informations dans un autre fichier que lon appellera fichier utilisateur. Ce fichier possde une syntaxe simple mais impose afin que le script puisse linterprter correctement ; il suffit en fait de prciser derrire des mots cls les paramtres importants tels que le vlan, le module, le port, le nom et ladresse mac du switch, le nom du sous rseau que lon souhaite voir apparatre dans le fichier de configuration et le chemin denregistrement des fichiers finaux. Mais avant tout il est essentiel de connatre la syntaxe dun fichier de configuration DHCP: dhcpd.conf

3.5.2 Dhcpd.conf

3.5.2.1 Syntaxe

Comme tout fichier de configuration, le fichier de configuration du serveur dhcp une syntaxe prcise respecter, voil quoi il doit ressembler pour une configuration simple :

paramtres globaux (serveur dns, dure du bail, nom de domaine)

shared-network name { paramtres spcifiques au rseau partag subnet 192.168.1.0 netmask 255.255.255.0 { paramtres spcifiques au sous-rseau. range 192.168.1.1 192.168.1.50; } subnet 192.168.2.0 netmask 255.255.255.0 { paramtres spcifiques au sous-rseau range 192.168.2.1 192.168.2.50; } }

Il est aussi possible dassigner une adresse IP fixe en fonction de ladresse MAC de la machine avec la syntaxe :

host toto { hardware ethernet aa:bb:cc:dd:ee:ff ; fixed-address 192.168.0.10; } Pour ce genre de configuration on appellera cela du dhcp simple par opposition au dhcp volu que nous allons voir maintenant.

14 Practical Extraction and Report Language



3.5.2.2 Dhcp volu

Il sagit ici dutiliser les paramtres de loption 82 de la distribution DHCP de lInternet Software Consortium, que le switch a complt dans le paquet DHCP, en fait il est presque question de "programmer" dans le fichier de configuration. Pour utiliser ces paramtres il faut dfinir des classes vrifiant les conditions ncessaires lattribution dune adresse IP fige. Il faut galement savoir que pour des raisons pratiques les paramtres utiliss sont fournis en hexadcimal et avec des ":" pour sparer chaque octets.

Par exemple si on veut assigner ladresse IP fixe 192.168.0.20 nimporte quelle machine relie au switch ayant ladresse MAC aa:bb:cc:dd:ee:ff , sur le port 20 (interface du switch 19 + 1 chez cisco) du module 0 dans le vlan 10 on aura des paramtres qui seront alors en hxadcimal :

Mme adresse MAC Port : 14 Module : 00 Vlan : 00 :0a

La syntaxe insrer en haut du fichier de configuration sera alors du type :

class "classTest"{ match if (substring (option agent.circuit-id,2, 2) = 00:0a)

and (substring (option agent.circuit-id,4,1) = 00) and (suffix (option agent.circuit-id, 1) = 14) and (suffix(option agent.remote-id,6) = aa:bb:cc:dd:ee:ff);

}

et celle insrer dans la dfinition du subnet est :

shared-network name { paramtres spcifiques au rseau partag subnet 192.168.0.0 netmask 255.255.255.0 {

pool { allow members of " classTest"; range 192.168.0.20;

} } }

Remarque : Les mthodes substring ( ) et suffix ( ) permettent de dcouper les champs des sous options circuit-id et remote-id de loption agent.

Il existe aussi une directive "include" propre au fichier dhcpd.conf permettant dinclure des fichiers indpendant, le but ici tant de gnrer ces fichiers via le script PERL et de les inclure ensuite. C'est--dire que lutilisateur contrle le fichier dhcpd.conf puis peut y inclure des fichiers de configuration supplmentaire limitant ainsi les conflits. Cela permet un travail moins fastidieux et plus souple dans la mesure o si le nombre de configurations similaires est important il y a de grands risques de faire des erreurs de syntaxes.



3.5.3 Utilisation du script et du fichier utilisateur

Lutilisation du script et du fichier de configuration utilisateur est relativement simple (pour cela un manuel a t crit reprenant toutes les tapes dcrites ci-dessous), il suffit de spcifier les paramtres derrire des directives.

directive ROOT : elle permet de spcifier le chemin d'enregistrement de tous les fichiers et se prsente sous la forme

ROOT

directive NETWORK : elle permet de spcifier un nom qui servira de nom de fichier pour la dclaration des pools et apparatra galement dans le nom de la classe correspondante

NETWORK

directive SWITCH : elle permet de renseigner le nom, l'adresse mac et ventuellement le type du switch sur lequel sera branch l'utilisateur final filtrer

SWITCH [] Remarque: Par dfaut le type du switch est cisco .

directive VLAN : comme son nom l'indique on y spcifie le numro de vlan de l'utilisateur filtrer

VLAN

directive PORT : cette directive est la plus complte de toute puisqu'on spcifie ici le module et le port du switch sur lequel est branch l'utilisateur filtrer ainsi que l'adresse ip que l'on veut lui attribuer

PORT []

Une fois excut, il aura gnr plusieurs fichiers de configuration :

autant de fichiers de dfinition de pool que de sous rseaux dclars. Les noms de ces fichiers sont constitus du nom fournit au niveau de la directive NETWORK et se terminent par ".conf ".

un fichiers global contenant les dclarations des diverses classes. Ce fichier porte le nom de "classes.conf ".

1 fichier par switch concern et contenant sa configuration concernant les ACLs. Les fichiers de configuration des switchs porteront le nom du switch fournit la suite de la directive SWITCH et se termineront par ".conf ".

Des exemples de tous ces fichiers sont fournis en annexe.



4 Solutions VPN 4.1 Notion de VPN

4.1.1 Introduction au VPN

Les applications et les systmes distribus font de plus en plus partie intgrante du paysage d'un grand nombre d'entreprises. Ces technologies ont pu se dvelopper grce aux performances toujours plus importantes des rseaux locaux. Mais le succs de ces applications a fait aussi apparatre un de leur cueil. En effet si les applications distribues deviennent le principal outil du systme d'information de lentreprise, comment assurer leur accs scuris au sein de structures parfois rparties sur de grandes distances gographiques ? Concrtement comment une succursale dune entreprise peut-elle accder de faon scuris aux donnes situes sur un serveur de la maison mre distant de plusieurs milliers de kilomtres comme si elles taient locales ? Les VPN, Virtual Private Network ou RPV, Rseau Priv Virtuel en franais, ont commenc tre mis en place pour rpondre ce type de problmatique. Mais dautres problmatiques sont apparues et les VPN ont aujourdhui pris une place importante dans les rseaux informatique et linformatique distribues.

4.1.2 Principe de fonctionnement

Un rseau VPN repose sur un protocole appel "protocole de tunneling". Ce protocole permet de faire circuler les informations de l'entreprise gnralement de faon crypte, d'un bout l'autre du tunnel; ainsi les utilisateurs ont l'impression de se connecter directement sur le rseau de l'entreprise. Le principe du tunneling consiste construire un chemin virtuel aprs avoir identifi l'metteur et le destinataire. Par la suite, la source chiffre les donnes au moyen d'algorithmes de cryptographie ngocis entre le client et le serveur et les achemine en empruntant ce chemin virtuel. Afin d'assurer un accs ais et peu coteux aux intranets et extranets d'entreprise, les rseaux privs virtuels d'accs simulent un rseau priv alors qu'ils utilisent en ralit une infrastructure d'accs partage telle que l'Internet. Les donnes transmettre peuvent tre prise en charge par un protocole diffrent d'IP, mais dans ce cas le protocole de tunneling encapsule les donnes en ajoutant un en-tte. Le tunneling est l'ensemble des processus d'encapsulation, de transmission et de dsencapsulation.

4.1.3 Utilisation d'un VPN

Il existe trois types standard d'utilisation des VPNs:

Le VPN d'accs qui est utilis pour permettre des utilisateurs itinrants d'accder au rseau priv.

L'intranet VPN qui permet de relier deux intranets distants d'une mme entreprise.

L'extranet VPN qui permet d'ouvrir une partie ou la totalit du rseau priv un client ou un partenaire de l'entreprise afin de communiquer avec lui.

Un systme de VPN doit pouvoir mettre en oeuvre les fonctionnalits suivantes :

Authentification d'utilisateur: Seuls les utilisateurs autoriss doivent pouvoir s'identifier sur le rseau virtuel. De plus, un historique des connexions et des actions effectues sur le rseau doit tre conserv.



Gestion d'adresses: Chaque client sur le rseau doit avoir une adresse propre. Cette adresse doit rester confidentielle. Un nouveau client doit pourvoir se connecter facilement au rseau et recevoir une adresse.

Cryptage des donnes: Lors de leurs transports sur le rseau public les donnes doivent tre protges par un cryptage efficace.

Gestion de cls: Les cls de cryptage pour le client et le serveur doivent pouvoir tre gnres et rgnres.

Prise en charge multiprotocole: La solution VPN doit supporter les protocoles les plus utiliss sur les rseaux publics en particulier IP.

4.1.4 Protocole utilis pour raliser une connexion VPN

Il existe plusieurs classes de protocoles permettant de raliser une connexion VPN:

Protocole de niveau 2 comme PPTP (Point to Point Tunneling Protocol) dvelopp et soutenu de nos jours par Microsoft (notamment utilis dans les systmes d'exploitations Windows), L2F (Layer Two Forwarding) dvelopp par Cisco et presque disparu aujourd'hui, L2TP ( Layer Two TUnneling Protocol) qui est une volution des deux prcdents.

Protocole de niveau 3 comme IPSec (Internet Protocol Security), dvelopp par un groupe de travail du mme nom l'IETF 15 depuis 1992, MPLS (MultiProtocol Label Switching) principalement utilis par les fournisseurs d'accs Internet.

Protocole de niveau 4 comme SSL/TLS (Secure Socket Layer/Tranports Layer Security).

4.1.5 Schma d'un VPN

Figure 4-1: Fonctionnement VPN

15 Internet Engineering Task Force



4.2 Openvpn

4.2.1 Prsentation

Comme expliqu plus haut, Openvpn est un logiciel libre de droit et il est donc une trs bonne alternative en ce qui concerne la cration de tunnels protgs utilisant Internet comme support physique. Openvpn se base sur le protocole de scurisation SSL/TLS pour assurer la confidentialit des changes, ce protocole a t labor dans le but de protger les donnes via des navigateurs web (ex: https 16). Lauthentification se fait la plupart du temps laide de certificats accompagns de cls.

Il existe deux modes dutilisations principales concernant Openvpvn: Mode de niveau 2 : utilisation d'une interface TAP (mode bridg) Mode de niveau 3 : utilisation d'une interface TUN (mode rout)

Globalement, si l'on ne souhaite grer que du trafic IP (niveau 3) il faudra sorienter vers un mode dutilisation de niveau 3, tandis que si lon dsire transporter des protocoles autres que IP (niveau 2) il faudra sorienter vers le mode dutilisation de niveau 3.

Les paquetages Debian ncessaires son installation sont les suivants : bridge-utils_0.9.6-5_i386.deb -> uniquement pour le serveur (interface TAP) openssl_0.9.8a-8_i386.deb libssl0.9.8_0.9.8a-8_i386.deb liblzo1_1.08-3_i386.deb openvpn_2.0.6-1_i386.deb

Tous ces paquetages peuvent tre install laide de la ligne de commande "apt-get install " sous un environnement Debian.

4.2.2 Cration des certificats et des cls RSA

Pour sauthentifier lun et lautre, le client et le serveur schangent leur certificat et vrifient chacun de leur ct la validit de celui-ci avec le certificat de lautorit de certification. Pour gnrer ces documents, jai utilis un fichier de configuration dOpenssl joint en annexes.

Voici les commandes Unix ncessaires : Cration dun certificat autosign

openssl req nodes new x509 keyout /path/cacert.pem days 3650 config /path_vers_le_fichier_de_conf_openssl

Cration de la cl et de la requte de certificat faire signer par lautorit de certification

openssl req nodes new keyout server.key out server.csr config /path_vers_le_fichier_de_conf_openssl

Vrification et signature de la requte de certificat openssl ca out server.crt in server.csr config /path_vers_le_fichier_de_conf_openssl

Ces deux tapes sont rpter pour crer un certificat pour le client signer par la mme autorit de certification.

Cration des paramtres Diffie Hellman pour le cryptage du tunnel openssl dhparam out dh1024.pem 1024



4.2.3 Protocole SSL / TLS

4.2.3.1 A propos dSSL / TLS

Cest le besoin dliminer les interceptions sur les rseaux par des personnes non autoriss et par la mme occasion dempcher la rcupration de donnes personnels des utilisateurs qui a conduit llaboration dun standard permettant des transmissions scurises des donnes via les navigateurs Web. Netscape Communications est la compagnie qui a conu le protocole SSL (Secure Socket Layer), qui fut le premier protocole de scurisation des communications via les navigateurs Web.

La premire version du protocole a t publie dans le milieu de lanne 1994 et est intgre au navigateur Mosaic, puis fin 1994 la seconde version fut intgre dans le navigateur Netscape Navigator. La troisime version fut publie fin 1995 permettant de corriger les faiblesses de son prdcesseur.

Cest en mai 1996 que lIETF accepta de faire de SSL un standard universel. Et cest en 1999 que SSL fut renomm par lIETF : TLS (Transport Layer Security), TLS v1.0 nest quune extension de SSL v3.0.

A lheure actuelle la plupart des navigateurs Web supportent le protocole et cest ainsi que le protocole SSL est utilis dans les transactions sur Internet allant de lachat de livres jusquau transfert de fonds.

4.2.3.2 Gnralits

SSL est donc un protocole ngociation dvelopp lorigine par Netscape. Son but est de scuriser les transactions Internet, par authentification du serveur et ventuellement du client, et par chiffrement de la session.

Il est une couche optionnelle se situant entre les couches dapplication et de transport. Le but de SSL est dtre un protocole de scurit facile dployer assurant une scurit totale des changes de plusieurs applications. Pour TCP, SSL nest quune application qui utilise ses services.

Figure 4-2 : Le protocole SSL/TLS dans son environnement

SSL ne dpend pas des applications utilises lors des transactions et sapplique sous les protocoles HTTP, FTP, Telnet, LDAP, etc.

16 HyperText Transfert Protocol Security

HTTP, FTP .

SSL/TLS

TCP

IP

Application

TCP

Handshake

Alert CCS

Record



La scurisation des connexions l'aide du protocole SSL doit assurer que : La connexion assure la confidentialit des donnes transmises La connexion assure lintgrit des donnes transmises L'identit des correspondants peut tre vrifie La connexion est fiable

Clients et serveurs commencent par sauthentifier mutuellement (pas toujours de manire symtrique), puis ngocient une cl symtrique de session qui servira assurer la confidentialit des transactions. Lintgrit de ces dernires est assure par lapplication de HMAC 17.

4.2.3.3 Fonctionnalits

Les principales fonctions assures par SSL sont :

Authentification : dans SSL v3.0 et TLS, lauthentification du serveur est obligatoire. Elle a lieu louverture de la session. Elle emploie pour cela des certificats conformes la recommandation X 509 v3. Cela permet au client de sassurer de lidentit du serveur avant tout change de donnes. Dans la version actuelle de SSL et de TLS lauthentification du client reste facultative.

Confidentialit : Elle est assure par des algorithmes de chiffrement symtriques. Bien que le mme algorithme soit utilis par les deux parties chacune possde sa propre cl secrte quelle partage avec lautre. Les algorithmes utiliss sont : DES, 3DES, RC2, RC4.

Intgrit : Elle est assure par lapplication dun algorithme de hachage (SHA ou MD5) aux donnes transmises. Lalgorithme gnre, partir des donnes et dune cl secrte, une signature pour les donnes appele code dauthentification de message. Ainsi tout changement appliqu aux donnes provoquera un message derreur ct rcepteur puisque la signature contenue dans le message sera diffrente de celle calcule par le rcepteur.

4.2.3.4 Principe de fonctionnement

Le protocole SSL/TLS est compos de 4 sous protocoles qui sont :

Handshake Protocol : Ce protocole permet l'authentification obligatoire du serveur, du client (optionnelle), et la ngociation de la suite du chiffrement qui sera utilis lors de la session.

CCS (ChangeCipherSpec) Protocol : Ce protocole comprend un seul et unique message (1 octet) qui porte le mme nom que le protocole, il permet d'indiquer au protocole Record la mise en place des algorithmes de chiffrement qui viennent d'tre ngocis.

Alert Protocol : Ce protocole gnre des messages d'alerte suite aux erreurs que peuvent s'envoyer le client et le serveur. Les messages sont composs de 20 octets, le premier tant soit fatal soit warning. Si le niveau de criticit du message est fatal, la connexion SSL est abandonne.

Record Protocol : Ce protocole intervient aprs l'mission du message ChangeCipherSpec. Il permet de garantir la confidentialit l'aide de chiffrement des donnes et l'intgrit l'aide de gnration d'un condenst.

17 Hashed Message Authentification Code



Le protocole SSL comporte une phase de ngociation o client et serveur peuvent : dfinir le niveau de scurit voulu sauthentifier

Aprs cette phase, ils peuvent communiquer (change de donnes applicatives : HTTP, FTP, etc.) Rappelons que les trois fonctionnalits principales de SSL sont lauthentification du serveur,

lauthentification du client et le chiffrement des donnes. Le protocole se compose de deux couches principales : le protocole Record qui traite lencodage des donnes envoyer et le protocole Handshake qui gre la ngociation.

Nous allons dtailler les diverses tapes du processus de ngociation, avec les messages que s'envoient le client et le serveur qui permettent la construction de la communication scurise grce SSL.

4.2.3.5 Processus de ngociation client/serveur

Figure 4-3 : Ngociation SSL Client/Serveur Suite cette phase de ngociation, le client et le serveur peuvent schanger des donnes de

faon scurise. Celles-ci seront chiffres par lalgorithme symtrique choisit au cours de la ngociation.



4.2.4 Interfaces TUN / TAP

4.2.4.1 Prsentation

Les "devices" TUN et TAP permettent de crer une interface rseau virtuelle au niveau IP (couche 3); on parlera alors de TUN au niveau Ethernet (couche 2); on parlera alors de "device TAP"

et permettent des processus d'envoyer directement des paquets IP (TUN) ou des trames Ethernet (TAP) sur ces interfaces, via l'utilisation d'un fichier spcial (/dev/net/tun ou /dev/net/tap). Elles permettent galement des processus de recevoir les paquets IP ou les trames Ethernet arrivant sur les interfaces virtuelles.

Les interfaces rseaux peuvent tre utilises exactement comme des interfaces normales (physiques, comme des cartes ethernet, par exemple). On peut leur associer des adresses IP, mettre des paquets/trames dessus, ou faire du routage entre interfaces virtuelles et interfaces physiques (ou entre interfaces virtuelles).

Une des utilisations possibles de ces devices est la cration de tunnels en mode utilisateur, c'est--dire rcuprer le trafic arrivant sur une interface TUN ou TAP, et l'expdier ailleurs, encapsul dans des messages ou des connexions selon un autre protocole (udp ou tcp, par exemple), et rmettre, sur une interface TUN ou TAP, du trafic reu encapsul dans des messages ou des connexions selon un autre protocole. Un traitement intermdiaire (compression, chiffrement) peut tre intercal au moment de la rception ou de l'envoi du trafic sur les devices TUN/TAP. VTun et OpenVPN sont des exemples de tunnels utilisant des devices TUN/TAP.

4.2.4.2 Mode "bridged" : interface TAP (niveau 2 du modle OSI)

Linterface TAP est une interface de niveau 2 (couche liaison de donnes) et utilise donc des trames Ethernet.

Lorsque deux htes sont dans le mme sous rseau (connect au mme switch par exemple), ils communiquent entre eux en utilisant ladresse MAC du destinataire, cest ce que lon appelle une communication de niveau 2.

Dans ce mode de configuration, linterface de connexion au VPN du serveur doit tre une interface bridges, c'est--dire quil faut faire un pont entre linterface virtuelle TAP et une interface physique comme ethX sous Linux (avec X le numro didentification de linterface), cette interface bridg sera appele brX (avec X un identifiant de linterface).

A loppos tant donn que le client na nul besoin, en principe, de faire suivre les trames Ethernet quil reoit, son interface se limitera une simple interface virtuelle TAP.

Lutilisation de ce mode est utile dans le cas o lon souhaite faire communiquer des rseaux au niveau 2 (Ethernet) ; comme par exemple dans le cas o lon souhaite pouvoir retrouver les mmes vlans dans deux rseaux relis par un VPN ou bien transporter un autre protocole de mme niveau que IP.



4.2.4.3 Mode "routed" : interface TUN (niveau 3 du modle OSI)

Linterface TUN est une interface de niveau 3 (couche IP) et utilise comme il se doit des paquets IP. Etant donn que dans ce type de configuration nos deux htes, client/serveur ne se trouve pas dans le mme sous rseau les paquets devront tre routs via une passerelle.

Lorsque deux htes ne sont pas dans le mme sous rseau la seule solution pour communiquer est dutiliser une communication dite de niveau 3, c'est--dire en utilisant les adresses IP des destinataires. Les paquets IP sont ensuite routs par des routeurs qui peuvent ensuite communiquer en niveau 2 avec les clients (pc ou quipements tels que switchs) du sous rseau.

Comme il sagit ici dune interface virtuelle de niveau 3 (IP) il nest nullement ncessaire deffectuer un pont entre celle-ci et une interface physique elle aussi de niveau 3. Il suffira ventuellement de modifier la table de routage.

4.2.4.4 Lancement dOpenvpn

Mode "bridged" : La cration dune interface TAP puis dun pont seffectue laide de quelques commandes unix simples que lon peut regrouper dans un unique fichier excuter une fois pour toutes avant le lancement du serveur (fournis en annexe).

o Cration dune interface TAP : openvpn --mktun --dev tap0

o Cration du pont : brctl addbr br0

o Ajout des interfaces dans le pont : brctl addif br0 eth0 brctl addif br0 tap0

o Configuration IP des interfaces du pont : ifconfig tap0 0.0.0.0 promisc up ifconfig eth0 0.0.0.0 promisc up ifconfig br0 192.168.X.254 netmask 255.255.255.0 broadcast 192.168.X.255 up

Remarques: Le mode "promisc up" permet de pouvoir voir tout le trafic passant. La configuration IP de linterface br0 est donne comme exemple avec une adresse de

classe C mais nest pas significative.

o Lancement du service openvpn : openvpn --config /path_du_fichier_de_config ou openvpn --daemon --config /path_du_fichier_de_config si lon veut lancer le processus en tant que dmon.

Mode "routed" :

Il ny a aucune configuration pralable effectuer dans ce mode configuration. Une fois les fichiers de configuration dits de chaque ct du futur tunnel, il suffit de lancer le processus Openvpn de la mme manire que pour une configuration en mode "bridged".



4.2.4.5 Avantages et inconvnients

TAP o Avantages :

Fonctionne avec nimporte quel protocole de niveau trois (IP, IPX) Ne ncessite pas de routage

o Inconvnients : Reois tout le traffic (broadcast) Beaucoup de bande passante gaspille (enttes ethernet) Plus lent que TUN

TUN o Avantages :

Ne reoit que le traffic lui tant destin Moins de bande passante utilise Plus rapide que TAP

o Inconvnients : Ncessite dtre rout Nautorise que du traffic IP

4.2.5 Test de dbit

Pour valider le fait que les dbits avec une interface TUN sont plus rapides jai procd quelques tests de vitesses laide dun outils sous Debian : iperf

Son utilisation est relativement simple puisquil fonctionne sur un modle client/serveur :

Serveur : iperf s # test de connexion tcp ou iperf s -u # test de connexion udp Une fois ceci fait le serveur est en attente de connexion et coute sur toutes les interfaces.

Client : iperf c # test de connexion tcp par dfaut 100Mbits/s ou iperf c -u # test de connexion udp par dfaut 1Mbits/s ou iperf c -b 10M # test de connexion udp 10Mbits/s ou iperf c -b 100M # test de connexion udp 100Mbits/s



Les tests ont donn les rsultats suivants avec TAP ou TUN, pour diffrents algorithmes de chiffrement et avec/sans compression :

TCP Simple Lzo BL+Lzo BL DES+Lzo 3DES+Lzo AES128+Lzo AES256+Lzo TAP 85 153 126 83 131 119 126 131 TUN 90 159 135 84 136 125 131 133 *test de vitesse en TCPMbits/s

UDP [ 100Mbits/s ] Simple Lzo BL+Lzo BL DES+Lzo 3DES+Lzo AES128+Lzo AES256+Lzo TAP 85 100 100 84 100 95 100 100 TUN 90 100 100 85 100 100 100 100 *test de vitesse en UDP 100Mbits/s

Lgendes : o Simple : ni compression, ni chiffrement o Lzo : compression uniquement o BL : chiffrement Blowfish o DES/3DES : chiffrement DES/3DES o AES128/256 : chiffrement AES 128 bits ou 256 bits o Tous les dbits sont donns en Mbits/s

Les machines utilises pour ces tests sont un PC de bureau Intel Pentium 4 cadenc 3GHz avec 256 Mo de mmoire vive et un PC portable Intel Pentium M 1,73GHz avec 1Go de mmoire vive. Il ressort de ce test queffectivement lutilisation dune interface TUN est plus rapide et principalement lors de connexion TCP.

Remarque importante: Une observation supplmentaire concernant la consommation de pourcentage CPU lors de ces tests dmontre que la compression est trs gourmande en ressources, de lordre de 55-60% sans et 80% avec celle-ci, et cela malgr le changement dalgorithme de chiffrement qui influe peu sur cette consommation. Cette remarque devra tre tenu en compte lors du choix de la technologie utiliser pour crer des VPNs, en effet la compression peut grandement ralentir la machine en charge des VPNs et ainsi ralentir les utilisateurs. Si le besoin daugmentation de bande passante ne se fait pas ressentir il est bien entendu possible dignorer cette option.



4.2.6 Architecture retenue

Pour rpondre aux besoins du service Raumur, qui sont notamment la ncessit de traage de connexion et lappartenance un vlan, il a t ncessaire de se pencher davantage sur une configuration prcise.

Etant donn quil faut pouvoir contrler les connexions au niveau vlan il est ncessaire dutiliser des interfaces de niveau 2 (TAP) et dans la configuration utilise, nous faisons tourner autant dinstances du serveur Openvpn que de VLANs, et donc autant dinterfaces VLANs virtuelles sur le serveur.

4.2.6.1 Schma darchitecture

Figure 4-4: Schma darchitecture Openvpn

4.2.6.2 Explication

Cette architecture met en uvre autant dinstance du serveur Openvpn que de Vlan auquel il est rattach, il faut donc jouer sur le numro de port pour pouvoir grer diffrents Vlans.

Il est recommand dutiliser Openvpn avec le protocole UDP pour viter le "TCP over TCP", c'est--dire lencapsulation de TCP par lui-mme pouvant entraner des problmes de retransmissions beaucoup trop longue dus au mcanisme de fentrage.

Dans cet exemple, le client VPN du VLAN 12 devra se connecter sur le port 1194 de linstance du serveur Openvpn lui correspondant et le client VPN du VLAN 13 devra donc se connecter sur le port 5000 de linstance du serveur Openvpn correspondant son VLAN. Cela oblige bien entendu fournir aux diffrents clients le numro de port sur lequel ils devront se connecter.

Lattribution dune adresse IP se fera en fonction du Common Name prsent sur le certificat du client lors de la connexion au serveur ; en effet le serveur doit obligatoirement possder un fichier, portant le mme nom que le Common Name, dans lequel la configuration IP fixe pour ce client est prsente. Ainsi mme si un client se connecte sur une autre instance du serveur que la sienne, aucune adresse ne lui sera attribue et il naura pas accs au rseau.



4.3 IOS Cisco

4.3.1 Prsentation

Dans cette partie nous allons tudier une autre mthode pour crer des VPNs, il sagit dutiliser un routeur Cisco, tel quun 2851 et de changer son IOS, si besoin, pour un autre plus spcifique et permettant de crer des tunnels IPSec avec un chiffrement 3DES : la version utilise est la 12.4. Lauthentification par nom dutilisateur et mot de passe sera effectue ici via un serveur radius opensource Freeradius inclus dans la distribution Debian utilise.

Il sagit ici dutiliser un routeur Cisco en tant que concentrateur VPN sur lequel arriveront toutes les demandes de connexions VPN, les connexions seront tablies laide du protocole IPSec 18 et chiffres laide de lalgorithme de chiffrement 3DES.

4.3.2 Protocole IPSEC

4.3.2.1 A propos dIPSec

IPsec se prsente sous la forme dun standard, dvelopp par un groupe de travail du mme nom lIETF depuis 1992. Une premire version basique de cette extension dIP a paru, sous forme de RFC, en 1992. Dvelopp lorigine dans le cadre de la future version dIP, savoir IPv6, IPsec a russi se porter la version actuelle IPv4, en attendant la mise en service grande chelle dIPv6, et est maintenant disponible pour tous.

4.3.2.2 Gnralits

IPsec est un protocole destin fournir diffrents services de scurit. Il propose ainsi plusieurs choix et options qui lui permettent de rpondre de faon adapte aux besoins des entreprises, particuliers, etc IPsec sinsre dans la pile de protocole TCP/IP, au niveau dIP. Cela signifie quil agit sur chaque paquet IP reu ou mis et peut soit le laisser passer sans traitement particulier, soit le rejeter, soit lui appliquer un mcanisme de scurisation.

Ainsi toutes les implmentations dune pile de protocole TCP/IP dIPv6 intgre nativement IPsec, en revanche IPsec est optionnel pour la version actuelle dIPv4 et nest pas encore fourni en standard sur la plupart des systmes courants. Le placement dIPsec au niveau IP, c'est--dire au niveau rseau, prsente lavantage de le rendre exploitable par les niveaux suprieurs, et donc doffrir un moyen de protection unique pour toutes les applications.

Le rseau IPv4 tant largement dploy et la migration vers IPv6 ncessitant encore beaucoup de temps, il est vite apparu intressant de dfinir des mcanismes de scurit qui soient communs la fois IPv4 et IPv6.

18 Internet Protocol Security



Figure 4-5: IPSec dans le modle OSI

4.3.2.3 Fonctionnalits

Les principales fonctions que peut assurer le protocole IPsec sont :

Authentification des donnes : permet de sassurer, pour chaque paquet chang, quil a bien t mis par la bonne machine et quil est bien destination de la seconde machine.

Authentification des extrmits : Cette authentification mutuelle permet chacun de sassurer de lidentit de son interlocuteur ltablissement du tunnel. Elle sappuie sur le calcul dintgrit pour garantir ladresse IP source.

Confidentialit des donnes : IPSec permet si on le dsire de chiffrer le contenu de chaque paquet IP pour viter la lecture de ceux-ci par quiconque. Elle est assure par un chiffrement symtrique des donnes.

Intgrit des donnes : IPSec permet de sassurer quaucun paquet na subit de modification quelconque durant son trajet en rajoutant chaque paquet IP le rsultat dun calcul de hachage (SHA-1 ou MD5) portant sur tout ou partie du datagramme.

Protection contre les coutes et analyses de trafic : IPsec permet de chiffrer les adresses IP relles de la source et de la destination, ainsi que toute len-tte IP correspondant.

Protection contre le rejeu : IPSec permet de se prmunir des attaques consistant capturer un ou plusieurs paquets dans le but de les envoyer nouveau pour bnficier des mmes avantages que lenvoyeur initial. Elle est assure par la numrotation des paquets IP et la vrification de la squence darrive des paquets.

Transport

IP

IPSec

Liaison




IPSec fait appel deux mcanismes de scurit pour le trafic IP :

AH (Authentication header) : Le protocole AH assure lintgrit des donnes en mode non connect et lauthentification de lorigine des datagrammes IP sans chiffrement des donnes. Son principe est dajouter un bloc au datagramme IP. Une partie de ce bloc servira lauthentification, tandis quune autre partie, contenant un numro de squence, assurera la protection contre le rejeu.

ESP (Encapsulation Security Payload) : Le protocole ESP assure, en plus des fonctions ralises par AH, la confidentialit des donnes et la protection partielle contre lanalyse du trafic, dans le cas du mode tunnel (voir ci-dessous). Cest pour ces raisons que ce protocole est le plus largement employ.

La technologie IPSec prsente deux modes de fonctionnement :

Le mode transport : prend un flux de niveau transport (couche de niveau 4 du modle OSI) et ralise les mcanismes de signature et de chiffrement puis transmet les donnes la couche IP. Dans ce mode, l'insertion de la couche IPsec est transparente entre TCP et IP. TCP envoie ses donnes vers IPsec comme il les enverrait vers IPv4. L'inconvnient de ce mode rside dans le fait que l'en-tte extrieur est produit par la couche IP c'est--dire sans masquage d'adresse. De plus, le fait de terminer les traitements par la couche IP ne permet pas de garantir la non utilisation des options IP potentiellement dangereuses. L'intrt de ce mode rside dans une relative facilite de mise en uvre, il est donc utilis pour crer des tunnels entre des machines.

Le mode tunnel : Dans le mode tunnel, les donnes envoyes par l'application traversent la pile de protocole jusqu' la couche IP incluse, puis sont envoyes vers le module IPsec. L'encapsulation IPsec en mode tunnel permet le masquage d'adresses en plus de ce quautorise le mode transport. Ce mode est donc utilis pour crer des tunnels entre des rseaux.

Avant que les paquets puissent tre scuriss par IPSec, une SA (Security Associations ou Associations de Scurit en franais) doit exister. Elle peut tre cre manuellement ou dynamiquement. Le protocole IKE 19 est utilis pour la cration dynamique de cette SA; il s'agit d'un protocole hybride bas sur les protocoles ISAKMP 20 (voir ci-dessous), Oakley et SKEME 21: il utilise les bases de ISAKMP, les modes de Oakley et les techniques de partage des cls de SKEME. Ces trois protocoles tant des protocoles dchanges de cls.

19 Internet Key Exchange 20

Internet Security Association and Key Management Protocol 21

Secure Key Exchange Mecanism for intErnet



4.3.3 Protocoles ISAKMP/Oakley/SKEME

4.3.3.1 Prsentation

Ces trois protocoles dchange de cl ont pour but deffectuer lchange des divers paramtres de chiffrement et dauthentification ncessaire la future communication. Ces paramtres sont notamment la cl, lidentification des deux parties et trois algorithmes utiliss durant lauthentification :

Chiffrement : pour assurer la confidentialit des changes Hachage : une fonction pseudo alatoire pour protger lintgrit des messages et

lauthentification des champs de ces messages Authentification : lalgorithme sur lequel est bas lauthentification mutuelle des deux parties.

4.3.3.2 Protocole ISAKMP

4.3.3.2.1 Rle

Le protocole ISAKMP, utilis par IPSec pour la cration de tunnel, pour rle d'tablir, de ngocier, de modifier ou de supprimer des Associations de Scurit et leurs attributs. Les SA contiennent les paramtres de scurit suivants :

Algorithme de chiffrement et taille des cls Cl de session Choix du protocole AH ou ESP Mode tunnel ou transport

4.3.3.2.2 Principe de fonctionnement

ISAKMP se droule en deux phases :

Cration de la SA ISAKMP, qui servira la scurisation de l'ensemble des changes futurs: on a donc ngociation d'attributs relatifs la scurit, vrification des identits des tiers, gnration des cls...

Ngociation de paramtres de scurit relatifs une SA tablir pour un mcanisme donn (par exemple AH ou ESP), via la SA ISAKMP tablie en phase 1.

4.3.3.2.3 Echange ISAKMP

Il existe 5 types dchanges ISAKMP diffrents :

Base Exchange : l'change de base permet l'change simple et rapide de toutes les donnes ncessaires la communication, mais ne fournit aucune scurit supplmentaire (comme la confidentialit...).

Identity Protection Exchange : l'change de protection d'identit assure l'anonymat des tiers, en n'effectuant leur authentification que sous la protection des systmes mis en place avec l'change des donnes de gnration de secret partag.

Authentification Only Exchange : l'change d'authentification seul permet uniquement l'authentification des tiers.



Aggressive Exchange : l'change aggressif assure les mmes services que l'change de base, mais en un nombre minimal de messages (il contracte en fait en un seul message les donnes de ngociation de la SA, d'authentification et d'change de cl); on notera qu'il empche du mme coup l'utilisation de l'change de cls selon Diffie-Hellman.

Informational Exchange : l'change d'information est un message univoque d'information concernant la gestion des SA d'un tiers (modification, suppression, ...).

4.3.3.3 Protocole Oakley

Le protocole Oakley est un protocole dchange de cl bas sur Diffie-Hellman (DH = chiffrement cl publique). Voici quelques caractristiques de ce protocole :

Cookies : o prcaution contre les attaques de type dni de service en les rendant plus difficile. o identifiant unique bas sur les informations de connexions (un peu comme un

identifiant de socket) o utilis chaque message durant les communications

Groupes prdfinis : o Paramtres globaux DH fixs o DH et ECDH (Elliptic Curve DH) rguliers

Unicite : o Evite les attaques de type "replay attack" ou attaque de type "rejeu" en franais

Authentification : o Via des systmes de chiffrements symtrique ou asymtrique

Trois modes de fonctionnement : o Main Mode Exchange permettant dutiliser la proprit de Perfect Forward Secrecy

(PFS). Cette proprit signifie que la dcouverte des secrets long terme (cl prive RSA) ne compromet pas la cl session, elle nest pas prsente lors dun change de cl de session simplement chiffre laide dune cl publique. Ce mode permet aussi dassurer lanonymat des deux parties.

o Aggressive Mode Exchange o Quick Mode Exchange (dcrit ci-dessous)

4.3.3.4 Protocole SKEME

SKEME est un protocole dchange de cls proposant plusieurs modes de fonctionnement. Le mode de fonctionnement basic est bas sur lutilisation de cls publiques et la gnration dun secret partag Diffie-Hellman. Cependant SKEME nest pas restreint lutilisation de cls publiques, mais autorise aussi lutilisation dune cl pr-partage. Cette cl peut tre obtenue par distribution manuelle ou par lintermdiaire dun centre de distribution de cls tel que Kerberos. Le centre de distribution des cls permet la communication dun secret entre deux machines via un troisime intermdiaire de confiance. Lutilisation de ce secret pour lauthentification du secret Diffie-Hellman et pas directement en tant que cl de session diminue la ncessit de faire confiance au centre de distribution des cls. SKEME permet aussi dchanger les cls plus rapidement en supprimant lutilisation de Diffie-Hellman lorsque la propit de PFS nest pas requise.



SKEME contient quatres modes disctincts:

Le mode basic qui fournit un change de cls bas sur une cl publique et assure la proprit de PFS grce Diffie-Hellman

Un change de cls bas sur lutilisation dune cl publique, mais sans Diffie-Hellman

Un change de cls bas sur lutilisation dune cl pr-partage et Diffie-Hellman

Un mcanisme de saisie de nouvelles cls bas simplement sur un algorithme de chiffrement symtrique.

De plus SKEME est compos de trois phases : SHARE, EXCH et AUTH.

Durant la phase SHARE, les deux protagonistes schangent des demi-cls, chiffres respectivement avec leur cl publique. Ces deux demi cls sont ensuite utilises pour crer une cl secrte. Si lanonymat est requis, les identits des deux extrmits sont aussi chiffres. Bien sr si un secret partag existe dj cette phase est passe.

La phase dchange EXCH est utilise, en fonction du mode choisi, pour changer lune ou lautre des valeurs publiques Diffie-Hellman ou dunicit. Le secret partag DH ne sera cr quaprs la fin de cet change.

Les valeurs publiques ou dunicit sont authentifies durant la phase dauthentification AUTH en utilisant la cl secrte tablie durant la phase SHARE.

Les messages de ces trois phases ne doivent pas ncessairement suivre lordre dcrit ci-dessus, dans la pratique ils sont combins pour minimiser le nombre des messages dchanges. Une autre phase, connue sous le nome de COOKIES, peut tre ajouter avant la phase SHARE pour fournir une protection contre les attaques de type "dni de service" grce au mcanisme de cookies.

4.3.4 Protocole IKE


IKE est le protocole de gestion des cls implment par IPSec. Il comprend 3 modes, qui grent les changes de paramtres entre les entits souhaitant communiquer; le but est de crer la SA dans les deux pairs l'aide des deux phases d'ISAKMP. La premire phase est utilise pour crer une SA IKE - via les changes identity protect exchange et aggressive exchange d'ISAKMP -, la deuxime pour ngocier les paramtres ncessaires la cration de la SA IPSec.

4.3.4.2 Echange IKE

Le protocole IKE utilise, quant lui, trois modes diffrents pour ses changes :

Main Mode Exchange : Pour l'tablissement de la SA IKE, six messages sont utiliss : trois requtes et trois rponses. Cet change se droule en trois tapes:

o change des paramtres Diffie-Hellman, o change dalas, o authentification des parties



Le premier change sert la ngociation des paramtres ncessaires la mise en place de la SA IKE. Le deuxime change sert la ngociation des valeurs publiques de l'algorithme Diffie-Hellman et des valeurs pseudo-alatoires contenues dans le bloc d'alas (Nonce Payload). Lors du dernier change les deux pairs s'envoient leurs identits respectives et le bloc Hash ncessaire l'authentification.

Aggressive Mode Exchange : Ce mode utilise directement l'Aggressive Exchange de ISAKMP; l'change se droule donc en seulement trois messages.

Quick Mode Exchange : Une fois la SA IKE tablie avec le Main Mode ou l'Aggressive Mode, le Quick Mode est utilis pour tablir une SA pour un autre protocole de scurit, comme AH ou ESP, sous la protection de la SA IKE prcdemment tablie. Dans un change en Quick Mode, les deux pairs ngocient les caractristiques de la SA IPSec tablir, et gnrent les cls correspondantes. La SA IKE protge ces changes en chiffrant et en authentifiant les messages transmis.

En plus de l'en-tte ISAKMP, du Hash, de la SA, du Nonce et des paramtres optionnels de Diffie-Hellman, les deux pairs peuvent s'changer des informations concernant leur identit, comme leur adresse IP.

La connexion scurise ayant t tablie par les protocoles ci-dessus, il est alors ncessaire de protger les donnes utiles: c'est le rle des protocoles AH et ESP.

4.3.5 VRF (Virtual Routing and Forwarding) 4.3.5.1 Principe de fonctionnement

La mise en oeuvre de VRFs (ou RAV pour Routage et Acheminement Virtuel, en franais) permet de crer plusieurs routeurs logiques au sein d'un mme et unique routeur physique, celui-ci tant dcoup et chacune des VRFs possdant alors sa propre table de routage qui est totalement indpendante des autres tables de routages des diffrentes VRFs. On se retrouve alors avec plusieurs routeurs virtuels tanches entre eux. Cette technologie permet de faire cohabiter des populations diverses sur un mme routeur sans ncessairement mettre en oeuvre d'ACLs, ainsi on pourra router des paquets provenant des sites divers et cela de manire scurise, c'est dire sans que les sites ne puissent se voir entre eux et sans avoir besoin de dployer un routeur physique par site. Cette technologie permet galement de connecter plusieurs sites distants possdants des plages d'adresses IP pouvant se chevaucher puisque celles-ci seront virtuellement sur des routeurs diffrents. Dans notre cas d'utilisation, les VRFs vont nous permettrent d'isoler les diffrents groupes d'utilisateurs/clients VPN se connectant sur le concentrateur VPN, ainsi on est sr que chaque utilisateur se retrouvera dans, et uniquement dans, son VLAN de travail d'origine sans pouvoir accder aux rseaux de travail adjacents auxquels il n'aurait pas le droit d'accder en tant normal en tant connect directement sur le rseau.



4.3.5.2 Schma de fonctionnement

Figure 4-6: Fonctionnement VRFs

La connexion vers les diffrents sites est matrialise par la configuration de linterface interne en sous interfaces coutant sur les VLANs respectifs aux sites, il sagit ici du protocole 802.1Q, ainsi chacune de ces sous interfaces appartient un seul VLAN couter, et il est possible de rcuprer les trames arrivant de VLANs diffrents. Lajout dun paramtre de configuration, relatif aux VRFs, sur chacune de ces sous interfaces permettant de prciser quelle table de routage appliquer ces sous interface vitant ainsi la communication intersites. (La configuration du routeur est fournie en annexe).

4.3.6 Authentification du client VPN pour ltablissement du tunnel


La configuration du modle de routeur Cisco test sest avre complique mettre en uvre : elle est base sur des profils qui sont crs dans le but de dfinir les systmes dauthentifications, de chiffrement, de comptabilit ainsi que les VRFs associes. Trois mthodes dauthentifications des clients VPN sont proposs sur le routeur Cisco : secret pr-partag, cl RSA, certificats. Nous verrons ici lauthentification par cl pr-partag qui bien qutant la plus facile mettre en uvre nest pas dpourvu de faille contrairement un systme bas sur les certificats.

Voil comment se droule la configuration du routeur : Pour tre en mesure de traiter correctement les demandes de connexions arrivant sur une

interface Ethernet, il est ncessaire dappliquer une "crypto map" une interface Ethernet, cette "crypto map" regroupe tous les paramtres ncessaires au traitement des donnes.

Cette "crypto map" pointe vers une "crypto map dynamic", la diffrence entre les deux tant quune map dynamic permet de grer des connexions venant dhtes inconnus.



Dfinition de "crypto map dynamic" dfinissant le "transform-set" et pointant vers un ou plusieurs profils.

Dfinition dun "transform-set" permettant de spcifier les paramtres de chiffrement et de hachage

Dfinition dun profil dans lequel sont prciss : o Les paramtres dauthentification, dautorisation et de comptabilit (AAA via

RADIUS ici) o La VRF dans laquelle sont dfinies les routes spcifiques un rseau o Le paramtre "match" permettant de pointer sur un groupe dfini ci-dessous (ou sur un

certificat) o Divers paramtres (paramtres de connexion, description du profil)

Dfinition dun groupe et dune cl associe pour lauthentification du client VPN sur le concentrateur (ISAKMP phase 1)


Figure 4-7: Schma dauthentification



4.3.7 Authentification de lutilisateur

4.3.7.1 Prsentation

Dans la configuration utilise, nous allons authentifier les clients VPNs en fonction de leur nom dutilisateur et de leur mot de passe enregistrs sur un serveur de type RADIUS 22. Dans le cas prcis sur lequel nous travaillons, le client VPN se connecte au routeur/concentrateur VPN et celui-ci va aller vrifier lauthentification cliente auprs du serveur RADIUS distant. Ce dernier retournera alors la configuration IP correspondante au client nouvellement enregistr, puis le concentrateur VPN relayera cette configuration au client pour que celui-ci puisse avoir accs au rseau depuis son VLAN dorigine.

Le serveur RADIUS utilis est Freeradius qui est, comme expliqu plus haut, un serveur open source, c'est--dire que les codes sources de ce logiciel sont libre de droit et publi sur Internet. Ce logiciel est de plus inclus en tant que paquetage dans toutes les distributions bases sur Debian. Le paquetage ncessaire son utilisation est "freeradius" dans sa version actuelle 1.1.0-1.1 installable via la ligne de commande "apt-get install freeradius" sous un environnement Debian.

De nos jours la scurit est devenue primordiale est saxe autour de trois grands points, savoir, les AAA pour Authentication-Authorization-Accounting ou en franais Authentification-Autorisation-Comptabilit.

4.3.7.2 AAA

Authentication : Cela correspond lidentification fiable de lutilisateur, que ce soit une personne physique ou un service. Cette identification passe par la prsentation de lidentit de lutilisateur. Cette information est unique chaque utilisateur et non scrte. Elle sert de rfrence dans la base des utilisateurs. Le contrle de cette information consiste vrifier un secret partag entre lutilisateur et le serveur. Elle peut tre de plusieurs types :

o Statique : linformation transmise est alors la mme lors dauthentifications successives : mot de passe type UNIX par exemple.

o Dynamique : on passe alors par un challenge entre le serveur et lutilisateur, ce qui permet davoir une information diffrente chaque nouvelle authentification : calculette, carte puce

o Biomtrique : reconnaissance vocale, empreintes, iris

Authorization : Cest le fait de dterminer quels sont les droits de lutilisateur. Par exemple, aprs stre logg, lutilisateur peut essayer certaines commandes. Lautorisation dtermine si lutilisateur peut ou non les utiliser. Dans certaines implmentations, lidentification et lautorisation sont regroupes en une seule tape.

Accounting : Cela consiste mesurer les ressources quun utilisateur consomme, en terme dchange rseau, de ressources systme Cela sert en fait journaliser un certain nombre dinformations sur lutilisateur. Cela permet de connatre la fois les services demands par lutilisateur et la quantit de ressources requises. Ces informations peuvent tre souvent utilises dans des buts de facturation.

22 Remote Access Dial-In User Service



4.3.8 Protocole RADIUS

4.3.8.1 Prsentation

Le protocole RADIUS a t cr par Livingston et normalis par lIETF sous la forme des RFCs 2138 et 2139. Le fonctionnement de RADIUS est bas sur un systme client/serveur charg de dfinir les accs d'utilisateurs distants un rseau. Il s'agit du protocole de prdilection des fournisseurs d'accs internet car il est relativement standard et propose des fonctionnalits de comptabilit permettant aux FAI de facturer prcisment leurs clients.

Le protocole RADIUS repose principalement sur un serveur (le serveur RADIUS), reli une base d'identification (fichier local, base de donnes, annuaire LDAP, etc.) et un client RADIUS, appel NAS (Network Access Server), faisant office d'intermdiaire entre l'utilisateur final et le serveur. Le mot de passe servant authentifier les transactions entre le client RADIUS et le serveur RADIUS est chiffr et authentifi grce un secret partag.

Il est noter que le serveur RADIUS peut faire office de proxy, c'est--dire transmettre les requtes du client d'autres serveurs RADIUS.

Protocole UDP port 1812 : authentification/autorisation Port 1813 : comptabilit

Chiffrement Chiffrement du mot de passe laide du secret partag

Architecture Autorisations lies lauthentification Emission du profile Profile global envoy au NAS 23 la fin de

lauthentification Protocoles non supports ARA 24 et NetBEUI 25

Challenge/rponse Unidirectionnelle


Le fonctionnement de RADIUS est bas sur un scnario proche de celui-ci : Un utilisateur envoie une requte au NAS afin d'autoriser une connexion distance,

Le NAS achemine la demande au serveur RADIUS,

Le serveur RADIUS consulte la base de donnes d'identification afin de connatre le type de scnario d'identification demand pour l'utilisateur. Soit le scnario actuel convient, soit une autre mthode d'identification est demande l'utilisateur. Le serveur RADIUS retourne ainsi une des quatre rponses suivantes pour ce qui est de lauthentification :

o ACCEPT : l'identification a russi ; o REJECT : l'identification a chou ; o CHALLENGE : le serveur RADIUS souhaite des informations

supplmentaires de la part de l'utilisateur et propose un dfi (en anglais challenge ) ;

o CHANGE PASSWORD : le serveur RADIUS demande l'utilisateur un nouveau mot de passe.

Suite cette phase dite d'authentification, dbute une phase d'autorisation o le serveur retourne les autorisations de l'utilisateur. Dans le cas des implmentations de RADIUS, ces deux tapes dauthentification et dautorisation sont regroupes en une seule phase.

23 Network Access Server 24 Apple Remote Access 25

NetBIOS Enhanced User Interface (NetBIOS = Network Basic Input Output System)



4.3.8.3 Format des trames RADIUS

Code : Identifie le type du message

1 Access-Request 2 Access-Accept 3 Access-Reject 4 Accounting-Request 5 Accounting-Response 11 Access-Challenge 12 Status-Server (exprimental) 13 Status-Client (exprimental) 255 Reserved

Identificateur : associe requtes et rponses (1 octet)

Longueur : longueur de toutes les zones donnes (2 octets)

Authentificateur : utilis pour authentifier la rponse du serveur et pour protger les mots de passe (16 octets)

Attributs : format (type, longueur, valeur) utilis pour vhiculer toutes les informations ncessaires

Les valeurs des attributs sont les suivantes :

1 User-Name 2 User-Password 3 CHAP-Password 4 NAS-IP-Address 5 NAS-Port 6 Service-Type 7 Framed-Protocol 8 Framed-IP-Addres 9 Framed-IP-Netmask 10 Framed-Routing 11 Filter-Id 12 Framed-MTU 13 Framed-Compression 14 Login-IP-Host 15 Login-Service 16 Login-TCP-Port 17 (unassigned) 18 Reply-Message 19 Callback-Number 20 Callback-Id 21 (unassigned) 22 Framed-Route 23 Framed-IPX-Network 24 State 25 Class 26 Vendor-Specific

0 21 3

Code Ident Longueur

Authentificateur (16 octets)

Attributs




Figure 4-8: Fonctionnement RADIUS

4.3.8.5 Mise en uvre

Pour lutilisation de la maquette, le serveur RADIUS va ici nous permettre dattribuer une adresse IP fixe en fonction de lutilisateur qui vient de se connecter, ainsi on sera toujours sr de lidentit dun individu connect sur le rseau. Lattribution dadresse IP permet aussi denvoyer une configuration, au client, en fonction de son VLAN dorigine et de la VRF applique linterface concerne ; cette configuration permet dassurer quaucun changement de rseau nest possible par lutilisateur.

Trois fichiers de configuration sont essentiels pour le bon fonctionnement du serveur (fournis en annexes) :

Radiusd.conf : configuration gnral (port, rpertoire, module utiliss, comptabilit)

2006 Stage Leonard Dhcpbyport Openvpn Ipsec

Documents

Transcript of 2006 Stage Leonard Dhcpbyport Openvpn Ipsec