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: Laurent FACQ Responsable pdagogique: Christophe BAILLOT
Stagiaire: Pierre LEONARD 13 mars 16 juin 2006
Pierre LEONARD
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.
Rseau Aquitain des Utilisateurs en Milieu Universitaire et de Recherche
Mobilit et Scurit
Service RAUMUR
Pierre LEONARD
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 Prsentation du sujet et de son contexte......................................................................... 9 2.1 Introduction .................................................................................................................. 9 2.2 Contexte ....................................................................................................................... 9 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 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 Service RAUMUR 3
Mobilit et Scurit
Rapport de stage de licence R&T 4.3.4 4.3.5 4.3.6 4.3.7 4.3.8 5
Pierre LEONARD
Protocole IKE ................................................................................................... 35 VRF (Virtual Routing and Forwarding) ........................................................... 36 Authentification du client VPN pour ltablissement du tunnel....................... 37 Authentification de lutilisateur........................................................................ 39 Protocole RADIUS ........................................................................................... 40
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 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
Mobilit et Scurit
Service RAUMUR
Pierre LEONARD
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
Mobilit et Scurit
Service RAUMUR
Pierre LEONARD
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.
Rseau National de tlcommunications pour la Technologie lEnseignement et la Recherche
Mobilit et Scurit
Service RAUMUR
Pierre LEONARD
1.3 Personnel
Le service Raumur est compos de 8 personnes + 2 stagiaires actuellement:
Figure 1-2 : Organigramme
Mobilit et Scurit
Service RAUMUR
Pierre LEONARD
1.4 Topologie du rseau Raumur
Figure 1-3 : Topologie du rseau Raumur
Mobilit et Scurit
Service RAUMUR
Pierre LEONARD
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 4
Dynamic Host Configuration Protocol Virtual Private Network 5 Media Access Control 6 Access Control List
Mobilit et Scurit
Service RAUMUR
Pierre LEONARD
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 8
Fournisseur dAccs Internet Internet Operating System
Mobilit et Scurit
Service RAUMUR
10
Pierre LEONARD
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.
User Datagram Protocol Request For Comment 11 Bootpstrap Protocol 12 Transmission Control Protocol / Internet Protocol
10
Mobilit et Scurit
Service RAUMUR
11
Pierre LEONARD
3.1.2 La trame DHCP

Voici le contenu dune trame DHCP :
Type de l'adresse MAC Longueur de l'adresse Type du Message : op (1) : htype (1) MAC : hlen (1) Identifiant de la transaction choisi alatoirement : xid (4) Nombre de saut : hops (1)
Temps coul depuis le dbut de la transaction : Flag de broadcast : flag (2) secs (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.
Mobilit et Scurit
Service RAUMUR
12
Pierre LEONARD
3.2 Fonctionnement du protocole

3.2.1 Illustration
Figure 3-1 : Fonctionnement DHCP
3.2.2 Explication
Client 1 DHCPDISCOVER Le client recherche les serveurs DHCP disponibles Serveur
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
Mobilit et Scurit
Service RAUMUR
13
Pierre LEONARD
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
Mobilit et Scurit
Service RAUMUR
14
Pierre LEONARD
3.3.3 Structure de loption 82

Code 82 Length N Agent Information Field i3 i4
i1
i2
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) 01 Length (1) 06 Circuit ID type (1) 00 Length (1) 04 Vlan (2) XXXX Module (1) YY Port (1) ZZ
* Les paramtres entre parenthses indiquent la taille du champ en octets.

Agent Remote ID : cette sous option contient ladresse MAC du switch relayant la trame dhcp et porte le code option 2. Suboption type (1) 02 Length (1) 08 Remote ID type (1) 00 Length (1) 06 MAC Address (6) aa :bb :cc :dd :ee :ff
* Les paramtres entre parenthses indiquent la taille du champ en octets.
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.
Mobilit et Scurit
Service RAUMUR
15
Pierre LEONARD
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
Mobilit et Scurit
Service RAUMUR
16
Pierre LEONARD
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.
Mobilit et Scurit
Service RAUMUR
17
Pierre LEONARD
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 <chemin absolu> 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 <nom du 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 <nom du switch> <@mac> [<type du 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 <numro de 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 <numro de module> <numro de port> <@ip attribuer> [<commentaire>] 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.
Mobilit et Scurit
Service RAUMUR
18
Pierre LEONARD
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.
Mobilit et Scurit
Service RAUMUR
19
Pierre LEONARD
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
Mobilit et Scurit
Service RAUMUR
20
Pierre LEONARD
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 <nom_du_paquet>" 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
Mobilit et Scurit
Service RAUMUR
21
Pierre LEONARD
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.
Application HTTP, FTP . Handshake SSL/TLS Alert TCP Record IP TCP CCS
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
Mobilit et Scurit
Service RAUMUR
22

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
Pierre LEONARD
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
Mobilit et Scurit
Service RAUMUR
23
Pierre LEONARD
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.
Mobilit et Scurit
Service RAUMUR
24
Pierre LEONARD
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.
Mobilit et Scurit
Service RAUMUR
25
Pierre LEONARD
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 : Cration du pont : Ajout des interfaces dans le pont :
openvpn --mktun --dev tap0
o
brctl addbr br0
brctl addif br0 eth0 brctl addif br0 tap0
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 ou
openvpn --daemon --config /path_du_fichier_de_config
Lancement du service openvpn :
openvpn --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".
Mobilit et Scurit
Service RAUMUR
26
Pierre LEONARD
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 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 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 # test de connexion udp
ou
iperf s -u
Une fois ceci fait le serveur est en attente de connexion et coute sur toutes les interfaces.
Client :
iperf c <@ip serveur> # test de connexion tcp par dfaut 100Mbits/s # test de connexion udp par dfaut 1Mbits/s # test de connexion udp 10Mbits/s
ou
iperf c <@ip serveur> -u
ou
iperf c <@ip serveur> -b 10M
ou
iperf c <@ip serveur> -b 100M # test de connexion udp 100Mbits/s
Mobilit et Scurit
Service RAUMUR
27
Pierre LEONARD
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 o o o o o Simple : ni compression, ni chiffrement Lzo : compression uniquement BL : chiffrement Blowfish DES/3DES : chiffrement DES/3DES AES128/256 : chiffrement AES 128 bits ou 256 bits 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.
Mobilit et Scurit
Service RAUMUR
28
Pierre LEONARD
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.
Mobilit et Scurit
Service RAUMUR
29
Pierre LEONARD
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
Mobilit et Scurit
Service RAUMUR
30
Pierre LEONARD
Transport
IP
IPSec
Liaison
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.
Mobilit et Scurit
Service RAUMUR
31
Pierre LEONARD

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 20
Internet Key Exchange Internet Security Association and Key Management Protocol 21 Secure Key Exchange Mecanism for intErnet
Mobilit et Scurit
Service RAUMUR
32
Pierre LEONARD
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.
Mobilit et Scurit
Service RAUMUR
33
Pierre LEONARD
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.
Mobilit et Scurit
Service RAUMUR
34

SKEME contient quatres modes disctincts:
Pierre LEONARD
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 4.3.4.1 Principe de fonctionnement

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
Mobilit et Scurit
Service RAUMUR
35
Pierre LEONARD
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.
Mobilit et Scurit
Service RAUMUR
36
Pierre LEONARD
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 4.3.6.1 Principe de fonctionnement
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.
Mobilit et Scurit
Service RAUMUR
37
Pierre LEONARD
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
Mobilit et Scurit
Service RAUMUR
38
Pierre LEONARD
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 AuthentificationAutorisation-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
Mobilit et Scurit
Service RAUMUR
39
Pierre LEONARD
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 Chiffrement Architecture Emission du profile Protocoles non supports Challenge/rponse UDP port 1812 : authentification/autorisation Port 1813 : comptabilit Chiffrement du mot de passe laide du secret partag Autorisations lies lauthentification Profile global envoy au NAS 23 la fin de lauthentification ARA 24 et NetBEUI 25 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 24
Network Access Server Apple Remote Access 25 NetBIOS Enhanced User Interface (NetBIOS = Network Basic Input Output System)
Mobilit et Scurit
Service RAUMUR
40
Pierre LEONARD
4.3.8.3 Format des trames RADIUS

0 Code 1 Ident 2 3 Longueur
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
Authentificateur (16 octets)
Attributs
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 4 NAS-IP-Address 7 Framed-Protocol 10 Framed-Routing 13 Framed-Compression 16 Login-TCP-Port 19 Callback-Number 22 Framed-Route 25 Class 2 User-Password 5 NAS-Port 8 Framed-IP-Addres 11 Filter-Id 14 Login-IP-Host 17 (unassigned) 20 Callback-Id 23 Framed-IPX-Network 26 Vendor-Specific 3 CHAP-Password 6 Service-Type 9 Framed-IP-Netmask 12 Framed-MTU 15 Login-Service 18 Reply-Message 21 (unassigned) 24 State
Mobilit et Scurit
Service RAUMUR
41
Pierre LEONARD
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) Clients.conf : configuration des clients (NAS) autoriss se connecter au serveur RADIUS Users : configuration des profils des utilisateurs (login, mot de passe, configuration IP)
Mobilit et Scurit
Service RAUMUR
42
Pierre LEONARD
5 Conclusions
5.1 Conclusion gnrale
5.1.1 DHCP
Le paramtrage dun serveur DHCP laide de ce que lon peut appeler "DHCP volu" permet beaucoup plus quune simple attribution de configuration rseau un client en faisant la demande. Il est possible deffectuer cette attribution en fonction de nombreux paramtres tels que le lieu de connexion de lutilisateur ou encore son VLAN dappartenance. Il est cependant noter que cette prsentation na pas la prtention de fournir une configuration type et une liste exhaustive de paramtres et de directives pouvant tre utiliss, cette configuration sapplique ici un environnement bien dfini quest lattribution dadresse IP fixe en fonction du lieu de connexion. Il faut galement savoir que ce modle de configuration sapplique non seulement dans ce cas prcis mais galement avec des logiciels adapts et avec la version de DHCP cit ci-dessus, aucune autre version nayant t test, il en va de mme en ce qui concerne le commutateur utilis pour les tests. Ce nouveau service rendu aux utilisateurs, sera mis en production prochainement et permettra une meilleure utilisation du rseau avec une configuration grandement simplifi. On limite ainsi le nombre de demandes daide ou de dpannage manant des utilisateurs novices principalement, et on accrot lautonomie des populations utilisatrices du rseau de campus.
5.1.2 VPNs
Nous avons pu voir ici deux types de connexions client/serveur VPN, la premire utilisant un logiciel libre et un serveur de type PC, et la seconde faisant appel du matriel Cisco encore une fois joint un serveur de type RADIUS. Et cest cette dernire qui sera retenu et ventuellement amliore pour parer des problmes de scurit connus. Les problmes pouvant apparatre sur cette deuxime configuration touche lauthentification par mot de passe puisque celui-ci peut ventuellement tre intercept sur le systme client par faute de chiffrement solide et efficace. Toutefois ce genre de problme peut tre rsolu en utilisant une authentification par certificat sans mot de passe pr-partag et qui reste cependant plus complexe mettre en oeuvre. Il est galement noter que cette configuration a t test sur 3 modles de routeurs diffrents que sont les Cisco 2620, 1811 et 2851. Un problme de compatibilit a t trouv concernant le premier de ces modles (2620), puisque bien quaucun bugs ne soit rpertoris entre ce routeur et limage utilis et supportant les VPN/IPSec (image cisco 12.3(18)), la configuration refusait de fonctionner et un simple changement de routeur vers des modles plus rcents (1811 et 2851) embarquant dj des IOS supportant les fonctionnalits requises, sest avr salutaire. Malgr tout, ce problme de compatibilit ma permit de fouiller dans les documentations de configuration Cisco et dcouvrir de nombreuses options paramtrables, ainsi que plusieurs modles de routeur Cisco.
Ces deux services sinscrivent dans la mission du service Raumur qui est de fournir toujours davantage de services aux utilisateurs dans le but de leur simplifier lutilisation du rseau universitaire, ainsi de nouveaux accs scuriss distance et une configuration IP dynamique simple dutilisation viennent enrichir la liste des nombreuses options proposes par le service de gestion du rseau aquitain.
Mobilit et Scurit
Service RAUMUR
43
Pierre LEONARD
5.2 Conclusion personnelle

Ce stage aura t vraiment enrichissant pour moi, jai pu travailler sur du matriel relativement chre et possdant de nombreuses fonctionnalits, cela ma galement permis de dcouvrir de nombreuses choses concernant les rseaux informatiques. Je me suis heurt beaucoup de problmes et cest en rflchissant dessus pendant de long moment que jai pu comprendre en profondeur le fonctionnement dun serveur DHCP et des VPN Openvpn et Cisco. Si jai appris une chose importante pendant ce stage cest que lon napprend rien lorsque tout marche de suite sans avoir se creuser la tte. Ces trois mois mauront donc permit dutiliser beaucoup de matriel (switch et routeur) mais galement apprendre un nouveau langage de programmation/scripting quest le PERL, car il sagit l encore dune dcouverte dont je suis peu prs sre quelle me resservira dans ma futur vie professionnelle dadministration et de scurit des rseaux informatiques. Au-del de tout cela les contacts humains socioprofessionnels mont beaucoup apport dans ma culture gnrale informatique et me permettent ainsi dtre plus solide et intress sur de nombreux sujets ayant trait linformatique en gnral. Je suis donc trs fier davoir pu effectuer ce stage dans un environnement serein et sain avec toute laide dont je pouvais avoir besoin et cela tout moment ; cest la raison pour laquelle je tiens remercier une nouvelle fois mon tuteur de stage Laurent FACQ mais galement tout le personnel du service Raumur qui a su lpauler lorsque celui tait occup.
Mobilit et Scurit
Service RAUMUR
44
Pierre LEONARD
Mobilit et Scurit Annexes

Universit Bordeaux 1 Service Raumur 351 crs de la Libration 33400 Talence
Tuteur de stage: Laurent FACQ Responsable pdagogique : Christophe BAILLOT
Stagiaire : Pierre LEONARD 13 mars 16 juin 2006
Mobilit et Scurit
Service RAUMUR
45
Pierre LEONARD
1 Solution DHCP
1.1 Script Perl
Dhcp_gen_conf.pl
#!/bin/perl print "Gnration des fichiers de configuration dhcp...\n"; # ouverture du fichier de conf utilisateur open (CONF,'conf_utilisateur') || die "Pb d'ouverture de \'conf_utilisateur\' : $!"; # lecture du fichier de conf utilisateur while (<CONF>) { if ($_ =~ /^\s/) {$_ =~ s/^\s*//;} # suppression des blancs en dbut de lignes if ($_ =~ /^#/ ) {next;} # ne pas tenir compte des commentaires
# rcupration du chemin denregistrement if ($_ =~ /ROOT/) { @root = split('\s+',$_); $root = $root[1]; $rootclasses = $root."classes.conf"; if ((@root != 2 and $_ =~ /ROOT/) or $_ !~ /ROOT/) {print STDERR "chemin d'enregistrement manquant\n";exit;} } # rcupration du nom du rseau if ($_ =~ /NETWORK\s+\w/) { @network = split('\s+',$_); $network = $network[1]; open (SUBNET,">$root$network.conf") || die "Pb d'ouverture network: $!"; print "ecriture fichier $root$network.conf\n"; # signale un nom network manquant if ((@network != 2 and $_ =~ /NETWORK/)) {print STDERR "nom de rseau manquant\n";} } # rcupration @mac switch if ($_ =~ /SWITCH/) { $_ =~ s/\s+$//; # supprime les blancs en fin de ligne @switch = split('\s+',$_,4); $switch_name = $switch[1]; # ouverture du fichier de conf switch open (SWITCH,">>$root$switch_name.conf") || die "Pb d'ouverture de \'$switch_name.conf\': $!"; print "ecriture fichier $root$switch_name.conf\n"; $mac = $switch[2]; if (@switch == 3) {$type = cisco;} else {$type = $switch[3];} } # rcupration du vlan if ($_ =~ /VLAN/) {@vlan = split('\s+',$_);} $vlan = $vlan[1]; # conversion en hexa $vlanHexa = sprintf "%04x",$vlan[1];
Mobilit et Scurit
Service RAUMUR
46
Pierre LEONARD
$vlanHexa = substr($vlanHexa,0,2).':'.substr($vlanHexa,2,2); # rcupration de : module / port / @ip if ($_ =~ /^PORT\s+\d+\s+\d+\s/ and $network[1] !~ /\s/) { $_ =~ s/\n$//; @port = split('\s+',$_,5); if (@port == 5){$description = $port[4];} $module = $port[1]; $moduleHexa = sprintf "%02x",$module; module if ($type eq "cisco") { $port = sprintf "%02x",$port[2]-1; port }else {$port = sprintf "%02x",$port[2];} $ip = $port[3]; $classes_name = $network."-vlan ".$vlanHexa."-mod ".$moduleHexa."-port ".$port." on ".$switch_name; # ouverture du fichier de conf des classes open (CLASSES,">>$rootclasses") || die "Pb d'ouverture de \'classes.conf\' : $!"; print "ecriture fichier ".$rootclasses."\n"; # criture dans le fichier de conf des classes print CLASSES "class \"".$classes_name."\"\{\n\tmatch if $substring \(option agent\.circuit-id,2, 2$ = ".$vlanHexa."\) and $substring \(option agent\.circuit-id,4,1$ = ".$moduleHexa."\) and $suffix \(option agent\.circuit-id, 1$ = ".$port."\) and $suffix\(option agent\.remote-id,6$ = ".$mac."\)\;\n\}\n"; # fermeture du fichier de conf des classes close (CLASSES); # criture dans le fichier de conf des pools print SUBNET "pool \{\n\tallow members of \"".$classes_name."\";\n\trange ".$ip.";\n\}\n\n"; $interface = $port[2]; # criture dans les fichiers de conf des switchs print SWITCH "interface FastEthernet $type $module/$interface\n description: $description\n ip access-group IP:$ip in\n switchport access vlan $vlan\n switchport mode access\n access-list IP:$ip permit 0.0.0.0\n access-list IP:$ip permit $ip\n\n"; } } # fermeture de tous les fichiers encore ouverts close (CONF); close (SUBNET); close (SWITCH); print "Fichiers gnrs\n";
# conversion hexa du
# conversion hexa du
Mobilit et Scurit
Service RAUMUR
47
Pierre LEONARD
1.2 Exemple de fichiers de configuration

1.2.1 Fichier utilisateur
Conf_utilisateur
ROOT /home/toto/fichiers_generes/ NETWORK name1 SWITCH robert 00:11:22:33:44:55 VLAN 10 PORT 00 20 192.168.0.20 chambre 20 PORT 01 3 192.168.0.3 NETWORK name2 SWITCH albert aa:bb:cc:dd:ee:ff allied-telesyn VLAN 14 PORT 00 21 172.18.0.2 studio 2
1.2.2 Fichier de dfinitions des classes

Classes.conf
class "name1-vlan 00:0a-mod 00-port 13 on robert"{ 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) = 13) and (suffix(option agent.remote-id,6) = 00:11:22:33:44:55); } class "name1-vlan 00:0a-mod 01-port 02 on robert"{ match if (substring (option agent.circuit-id,2, 2) = 00:0a) and (substring (option agent.circuit-id,4,1) = 01) and (suffix (option agent.circuit-id, 1) = 02) and (suffix(option agent.remote-id,6) = 00:11:22:33:44:55); } class "name2-vlan 00:0e-mod 00-port 15 on albert"{ match if (substring (option agent.circuit-id,2, 2) = 00:0e) and (substring (option agent.circuit-id,4,1) = 00) and (suffix (option agent.circuit-id, 1) = 15) and (suffix(option agent.remote-id,6) = aa:bb:cc:dd:ee:ff); }
Mobilit et Scurit
Service RAUMUR
48
Pierre LEONARD
1.2.3 Fichiers de dfinitions des pools

Name1.conf
pool { allow members of "name1-vlan 00:0a-mod 00-port 13 on robert"; range 192.168.0.20; } pool { allow members of "name1-vlan 00:0a-mod 01-port 02 on robert"; range 192.168.0.3; }
Name2.conf
pool { allow members of "name2-vlan 00:0e-mod 00-port 15 on albert"; range 172.18.0.2;
1.2.4 Fichiers de configuration des switchs

Robert.conf
interface FastEthernet cisco 00/20 description: chambre 20 ip access-group IP:192.168.0.20 in switchport access vlan 10 switchport mode access access-list IP:192.168.0.20 permit 0.0.0.0 access-list IP:192.168.0.20 permit 192.168.0.20 interface FastEthernet cisco 01/3 description: ip access-group IP:192.168.0.3 in switchport access vlan 10 switchport mode access access-list IP:192.168.0.3 permit 0.0.0.0 access-list IP:192.168.0.3 permit 192.168.0.3
Albert.conf
interface FastEthernet allied-telesyn 00/21 description: studio 2 ip access-group IP:172.18.0.2 in switchport access vlan 14 switchport mode access access-list IP:172.18.0.2 permit 0.0.0.0 access-list IP:172.18.0.2 permit 172.18.0.2
Mobilit et Scurit
Service RAUMUR
49
Pierre LEONARD
1.2.5 Fichier de configuration dhcp

Dhcpd.conf
include "/home/toto/fichiers_generes/classes.conf"; # option definitions common to all supported networks option domain-name "test.u-bordeaux.fr"; default-lease-time 600; max-lease-time 7200; # Use this to send dhcp log messages to a different log file (you also # have to hack syslog.conf to complete the redirection). log-facility local7; #Display tag in syslog when an user is connected if exists agent.circuit-id { log ( info, concat( "Lease for ", binary-to-ascii (10, 8, ".", leased-address), " is connected to interface ",binary-to-ascii (10, 8, "/", suffix ( option agent.circuit-id, 2)), " (add 1 to port number!), VLAN ", binary-to-ascii (10, 16, "", substring( option agent.circuit-id, 2, 2)), " on switch ", binary-to-ascii(16, 8, ":", substring( option agent.remote-id, 2, 6)))); } shared-network test { subnet 192.168.0.0 netmask 255.255.255.0 { authoritative; include "/home/toto/fichiers_generes/name1.conf"; } subnet 172.18.0.0 netmask 255.255.255.0 { authoritative; include "/home/toto/fichiers_generes/name2.conf"; } }
Mobilit et Scurit
Service RAUMUR
50
Pierre LEONARD
2 Solutions VPN
2.1 Openvpn
2.1.1 Fichier de configuration dOpenssl
Openssl-vpn.cnf
HOME RANDFILE = . = $ENV::HOME/.rnd
# Extra OBJECT IDENTIFIER info: oid_section = new_oids [ new_oids ] #################################################################### [ ca ] default_ca = CA_default #################################################################### [ CA_default ] dir = /etc/ssl/openvpn certs = $dir/certs crl_dir = $dir/crl database = $dir/index.txt #unique_subject = no new_certs_dir certificate serial = $dir/newcerts = $dir/cacert.pem = $dir/serial
crl = $dir/crl.pem private_key = $dir/private/cakey.pem RANDFILE = $dir/private/.rand x509_extensions name_opt cert_opt = usr_cert
= ca_default = ca_default
default_days = 365 default_crl_days= 30 default_md = md5 preserve = no policy = policy_match
[ policy_match ] countryName = match stateOrProvinceName = match organizationName = match organizationalUnitName = optional commonName = supplied emailAddress = optional
Mobilit et Scurit
Service RAUMUR
51

[ policy_anything ] countryName = optional stateOrProvinceName = optional localityName = optional organizationName = optional organizationalUnitName = optional commonName = supplied emailAddress = optional
Pierre LEONARD
#################################################################### [ req ] default_bits = 1024 default_keyfile = privkey.pem distinguished_name = req_distinguished_name attributes = req_attributes x509_extensions = v3_ca string_mask = nombstr [ req_distinguished_name ] countryName = Country Name (2 letter code) countryName_default = FR countryName_min = 2 countryName_max = 2 stateOrProvinceName = State or Province Name (full name) stateOrProvinceName_default = Gironde localityName localityName_default = Locality Name (eg, city) = bordeaux
0.organizationName = Organization Name (eg, company) 0.organizationName_default = pierre organizationalUnitName = Organizational Unit Name (eg, section) organizationalUnitName_default = test reaumur commonName commonName_max emailAddress emailAddress_max [ req_attributes ] challengePassword challengePassword_min challengePassword_max unstructuredName [ usr_cert ] basicConstraints=CA:FALSE nsComment = "OpenSSL Generated Certificate" = Common Name (eg, YOUR name) = 64 = Email Address = 64
= A challenge password = 4 = 20 = An optional company name
subjectKeyIdentifier=hash authorityKeyIdentifier=keyid,issuer:always [ v3_req ]
Mobilit et Scurit
Service RAUMUR
52

basicConstraints = CA:FALSE keyUsage = nonRepudiation, digitalSignature, keyEncipherment [ v3_ca ] subjectKeyIdentifier=hash authorityKeyIdentifier=keyid:always,issuer:always basicConstraints = CA:true [ crl_ext ] authorityKeyIdentifier=keyid:always,issuer:always
Pierre LEONARD
2.1.2 Fichiers de configuration dOpenvpn 2.1.2.1 Mode Bridged interface TAP (configuration retenue)
Bridge-start
#!/bin/bash openvpn --mktun --dev tap0 openvpn -mktun -dev tap1 brctl addbr br012 brctl addbr br013 vconfig add eth0 12 vconfig add eth0 13 brctl addif br0 eth0.12 brctl addif br0 tap0 brctl addif br0 eth0.13 brctl addif br0 tap1 ifconfig ifconfig ifconfig ifconfig ifconfig # cration des interfaces virtuelles # tap0 et tap1 # cration des interfaces de bridge # br012 et br013 # cration des interfaces vlan # virtuelles eth0.12 et eth0.13 # ajout de linterface eth0.12 au bridge # ajout de linterface tap0 au bridge # ajout de linterface eth0.13 au bridge # ajout de linterface tap1 au bridge linterface linterface linterface linterface linterface tap0 eth0.12 tap1 eth0.13 eth0
tap0 0.0.0.0 promisc up # configuration de eth0.12 0.0.0.0 promisc up # configuration de tap1 0.0.0.0 promisc up # configuration de eth0.13 0.0.0.0 promisc up # configuration de eth0 0.0.0.0 promisc up # configuration de
# configuration des interfaces de pont br012 et br013 ifconfig br012 192.168.2.254 netmask 255.255.255.0 broadcast 192.168.2.255 ifconfig br013 172.18.0.254 netmask 255.255.255.0 broadcast 172.18.0.255
Bridge-stop
#!/bin/bash
Mobilit et Scurit
Service RAUMUR
53

ifconfig br012 down ifconfig br013 down brctl delbr br012 brctl delbr br013 ifconfig tap0 0.0.0.0 ifconfig tap1 0.0.0.0 vconfig rem eth0.12 vconfig rem eth0.13
Pierre LEONARD
# dsactivation des bridges
# suppression des bridges
# remise zro de la configuration tap0 et tap1 # suppression des interfaces vlan virtuelles
# reconfiguration initiale de linterface eth0 ifconfig eth0 192.168.0.1 netmask 255.255.255.0 broadcast 192.168.0.255
Configuration Serveur
local <@ip> port 1194 proto udp dev tap0 tun-mtu 1500 mssfix # ip publique du serveur # port changer pour deuxime serveur
# type interface = tap (layer2) ( changer pour deuxime serveur)
persist-key persist-tun ca /etc/openvpn/tls/cacert.pem cert /etc/openvpn/tls/vpn.pierre.crt key /etc/openvpn/tls/vpn.pierre.key dh /etc/openvpn/tls/dh1024.pem tls-auth /etc/openvpn/tls/ta.key
# certificat de l'autorit de certification # certificat du serveur # cl priv du serveur # cl DH pour initialisation du tunnel # cl partage
server-bridge 192.168.2.254 255.255.255.0 192.168.2.5 192.168.2.15 chroot /etc/openvpn/jail client-config-dir ccd # dossier contenant les associations CN/IP ccd-exclusive # fichiers dassociations obligatoires client-to-client # autorise les clients se voir entre eux keepalive 10 120 cipher BF-CBC comp-lzo max-clients 15 user nobody group nogroup status /etc/openvpn/jail/log/status_bridged.log log-append /etc/openvpn/jail/log/openvpn_bridged.log verb 4 mute 10
# chiffrement Blowfish # compression des donnes => meilleures perfs
Configuration Client
client
Mobilit et Scurit
Service RAUMUR
54

dev tap proto udp remote <@ip> 1194 resolv-retry infinite nobind persist-key persist-tun ca /etc/openvpn/tls/cacert.pem # type interface tap (layer2)
Pierre LEONARD
# ip publique du serveur joindre + port
# certificat de l'autorit de certification cert /etc/openvpn/tls/nomade1.pierre.crt # certificat du client key /etc/openvpn/tls/nomade1.pierre.key # cl prive du client tls-auth /etc/openvpn/tls/ta.key # cl partage keepalive 10 60 cipher BF-CBC comp-lzo
chroot /etc/openvpn/jail/log log-append /etc/openvpn/jail/log/openvpn_bridged_client_tap.log verb 2 mute 5
2.1.2.2 Mode routed interface TUN

Configuration Serveur
local <@ip> port 1194 proto udp dev tun tun-mtu 1500 mssfix # ip publique du serveur
# type interface = tun (layer3)
persist-key persist-tun ca /etc/openvpn/tls/cacert.pem cert /etc/openvpn/tls/vpn.pierre.crt key /etc/openvpn/tls/vpn.pierre.key dh /etc/openvpn/tls/dh1024.pem duplicate-cn server 192.168.1.0 255.255.255.0 chroot /etc/openvpn/jail client-config-dir ccd ccd-exclusive client-to-client keepalive 10 120 cipher BF-CBC comp-lzo max-clients 15 user nobody group nogroup
# certificat de l'autorit de certification # certificat du serveur # cl priv du serveur # cl DH pour initialisation du tunnel
# dossier contenant les fichiers de conf clients # fichier de conf obligatoire sinon client refus # autorise les clients se voir entre eux # chiffrement Blowfish # compression des donnes => meilleures perfs
Mobilit et Scurit
Service RAUMUR
55

status /etc/openvpn/jail/log/status_routed.log log-append /etc/openvpn/jail/log/openvpn_routed.log verb 4 mute 10
Pierre LEONARD
Configuration Client
client dev tun proto udp remote <@ip> 1194 resolv-retry infinite nobind persist-key persist-tun ca /etc/openvpn/tls/cacert.pem # type interface tun (layer3) # ip publique du serveur joindre + port
# certificat de l'autorit de certification cert /etc/openvpn/tls/nomade1.pierre.crt # certificat du client key /etc/openvpn/tls/nomade1.pierre.key # cl prive du client keepalive 10 60 cipher BF-CBC comp-lzo
chroot /etc/openvpn/jail/log log-append /etc/openvpn/jail/log/openvpn_routed_client_tun.log verb 2 mute 5
Mobilit et Scurit
Service RAUMUR
56
Pierre LEONARD
2.2 IOS Cisco

2.2.1 Configuration du routeur Cisco 2851
Configuration routeur
Current configuration : 4147 bytes ! version 12.4 service timestamps debug datetime msec service timestamps log datetime msec no service password-encryption ! hostname vpn2851 ! boot-start-marker boot-end-marker ! ! aaa new-model # activation AAA ! ! aaa group server radius group-radius # definition dun serveur RADIUS server 192.168.1.3 auth-port 1812 acct-port 1813 ! # dfinition du modle AAA sur le serveur RADIUS aaa authentication login authentication-radius group group-radius aaa authorization network authorization-radius local aaa accounting network accounting-radius start-stop group group-radius ! aaa session-id common ! resource policy ! ! ! ip cef ! ! ip vrf vrflabo # dfinition des VRFs rd 1:1 ! ip vrf vrflabo2 rd 2:2 ! no ip domain lookup ip domain name u-bordeaux.fr ! ! voice-card 0 no dspfarm ! ! username cisco privilege 15 secret 5 xxxxxxxxxxxxxxxxxxxxxx ! ! no crypto xauth GigabitEthernet0/0 ! crypto isakmp policy 3 # dfinition des paramtres de scurit de encr 3des # la phase 1 dISAKMP authentication pre-share
Mobilit et Scurit
Service RAUMUR
57
Pierre LEONARD
group 2 ! ! # dfinition des groupes crypto isakmp client configuration group test-cisco-vpn key key-vpn # cl partage concentrateur VPN/client domain u-bordeaux.fr ! crypto isakmp client configuration group test-toto key key-toto domain toto.fr ! # dfinition des profils crypto isakmp profile profile-pierre description profile test reaumur vrf vrflabo # dfinition de la vrf match identity group test-cisco-vpn # identification du groupe client authentication list authentication-radius # paramtres AAA isakmp authorization list authorization-radius client configuration address respond accounting accounting-radius keepalive 30 retry 5 initiate mode aggressive # mode de ngociation crypto isakmp profile profile-toto description profile test reaumur toto vrf vrflabo2 match identity group test-toto client authentication list authentication-radius isakmp authorization list authorization-radius client configuration address respond accounting accounting-radius keepalive 30 retry 5 initiate mode aggressive ! ! # dfinition des paramtres de scurit utilis pour chiffrer les donnes crypto ipsec transform-set set-cisco-vpn esp-3des esp-sha-hmac ! # dfinition des maps dynamiques crypto dynamic-map map-4 5 set transform-set set-cisco-vpn # application des parametres de scurit set isakmp-profile profile-pierre # application du profil reverse-route # prciser le chemin retour des paquets crypto dynamic-map map-4 10 set transform-set set-cisco-vpn set isakmp-profile profile-toto reverse-route ! ! # dfinition de la map principale crypto map map-5 10 ipsec-isakmp dynamic map-4 ! # paramtrage des interfaces Ethernet interface GigabitEthernet0/0 ip address 192.168.1.1 255.255.255.0 duplex auto speed auto crypto map map-5 ! ! ! interface GigabitEthernet0/1
Mobilit et Scurit
Service RAUMUR
58

no ip address duplex auto speed auto
Pierre LEONARD
! interface GigabitEthernet0/1.1 # sous interface 0/1.1 encapsulation dot1Q 12 # appartient au VLAN 12 ip vrf forwarding vrflabo # faire suivre les trames de la vrflabo ip address xxx.xxx.xxx.251 255.255.255.224 no snmp trap link-status ! interface GigabitEthernet0/1.2 encapsulation dot1Q 13 ip vrf forwarding vrflabo2 ip address xxx.xxx.xxx.222 255.255.255.224 no snmp trap link-status ! ! # table de routage standard & VRFs ip route 0.0.0.0 0.0.0.0 xxx.xxx.xxx.254 ip route vrf vrflabo xxx.xxx.xxx.224 255.255.255.224 xxx.xxx.xxx.251 ip route vrf vrflabo2 xxx.xxx.xxx.192 255.255.255.224 xxx.xxx.xxx.222 ! ! ip http server no ip http secure-server ! ! # dfinition de la cl partage NAS/RADIUS radius-server host 192.168.1.3 auth-port 1812 acct-port 1813 key key-radius ! control-plane ! line con 0 line aux 0 line vty 0 4 privilege level 15 transport input ssh ! scheduler allocate 20000 1000 ! webvpn context Default_context ssl authenticate verify all ! no inservice ! ! end
Mobilit et Scurit
Service RAUMUR
59
Pierre LEONARD
2.2.2 Configuration du serveur RADIUS (Freeradius)

Radiusd.conf
prefix = /usr exec_prefix = /usr sysconfdir = /etc localstatedir = /var sbindir = ${exec_prefix}/sbin logdir = /var/log/freeradius raddbdir = /etc/freeradius radacctdir = ${logdir}/radacct confdir = ${raddbdir} run_dir = ${localstatedir}/run/freeradius log_file = ${logdir}/radius.log libdir = /usr/lib/freeradius pidfile = ${run_dir}/freeradius.pid user = freerad group = freerad max_request_time = 30 delete_blocked_requests = no cleanup_delay = 5 max_requests = 1024 bind_address = * port = 0 hostname_lookups = no allow_core_dumps = no regular_expressions = yes extended_expressions = yes log_stripped_names = no log_auth = no log_auth_badpass = no log_auth_goodpass = no usercollide = no lower_user = no lower_pass = no nospace_user = no nospace_pass = no checkrad = ${sbindir}/checkrad security { max_attributes = 200 reject_delay = 1 status_server = no } proxy_requests = yes $INCLUDE ${confdir}/proxy.conf $INCLUDE ${confdir}/clients.conf snmp = no $INCLUDE ${confdir}/snmp.conf thread pool { max_servers = 32 min_spare_servers = 3 max_spare_servers = 10 max_requests_per_server = 0 } # Les modules permettent de dfinir les traitements appliquer
Mobilit et Scurit
Service RAUMUR
60

modules { preprocess { huntgroups = ${confdir}/huntgroups hints = ${confdir}/hints with_ascend_hack = no ascend_channels_per_line = 23 with_ntdomain_hack = no with_specialix_jetstream_hack = no with_cisco_vsa_hack = no }
Pierre LEONARD
detail { detailfile = ${radacctdir}/%{Client-IP-Address}/detail-%Y-%m-%d detailperm = 0600 } files { usersfile = ${confdir}/users acctusersfile = ${confdir}/acct_users preproxy_usersfile = ${confdir}/preproxy_users compat = no } } # Les modules sont appliqus aux tapes du traitement dune requte authorize { preprocess files } authenticate { } preacct { preprocess files } accounting { detail } session { } post-auth { } pre-proxy { } post-proxy { }
Clients.conf
Mobilit et Scurit
Service RAUMUR
61

client 192.168.1.1 { secret shortname nastype } = key-radius = router = other
Pierre LEONARD
# cl partage serveur/NAS
Users
pierre User-Password == "pierre" Framed-IP-Address = xxx.xxx.xxx.236, # IP attribuer pierre Framed-IP-Netmask = 255.255.255.224 toto User-Password == "toto" # IP attribuer toto Framed-IP-Address = xxx.xxx.xxx.193, Framed-IP-Netmask = 255.255.255.224
Mobilit et Scurit
Service RAUMUR
62

2006 Stage Leonard Dhcpbyport Openvpn Ipsec

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

2006 Stage Leonard Dhcpbyport Openvpn Ipsec

Transféré par

Droits d'auteur :

Formats disponibles

Rapport de stage de licence R&T

Tuteur de stage: Laurent FACQ Responsable pdagogique: Christophe BAILLOT

Stagiaire: Pierre LEONARD 13 mars 16 juin 2006

Rapport de stage de licence R&T

Rseau Aquitain des Utilisateurs en Milieu Universitaire et de Recherche

Rapport de stage de licence R&T

Table des matires

Rapport de stage de licence R&T 4.3.4 4.3.5 4.3.6 4.3.7 4.3.8 5

Rapport de stage de licence R&T

Table des figures

Rapport de stage de licence R&T

1 Prsentation du service Raumur

Rseau National de tlcommunications pour la Technologie lEnseignement et la Recherche

Rapport de stage de licence R&T

Figure 1-2 : Organigramme

Rapport de stage de licence R&T

1.4 Topologie du rseau Raumur

Figure 1-3 : Topologie du rseau Raumur

Rapport de stage de licence R&T

2 Prsentation du sujet et de son contexte

Rapport de stage de licence R&T

Fournisseur dAccs Internet Internet Operating System

Rapport de stage de licence R&T

Rapport de stage de licence R&T

3.1.2 La trame DHCP

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

Rapport de stage de licence R&T

3.2 Fonctionnement du protocole

Figure 3-1 : Fonctionnement DHCP

Rapport de stage de licence R&T

3.3 Option 82 : DHCP Relay Agent Information

3.3.1 DHCP Snooping

3.3.2 DHCP Relay Information Option

Virtual Local Area Network

Rapport de stage de licence R&T

3.3.3 Structure de loption 82

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

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

3.4 Architecture de la maquette

Rapport de stage de licence R&T

3.5 Dveloppement du script PERL

3.5.2 Dhcpd.conf 3.5.2.1 Syntaxe

Practical Extraction and Report Language

Rapport de stage de licence R&T

3.5.2.2 Dhcp volu

et celle insrer dans la dfinition du subnet est :

Rapport de stage de licence R&T

3.5.3 Utilisation du script et du fichier utilisateur

Rapport de stage de licence R&T

4.1.2 Principe de fonctionnement

4.1.3 Utilisation d'un VPN

Rapport de stage de licence R&T

4.1.4 Protocole utilis pour raliser une connexion VPN

4.1.5 Schma d'un VPN

Figure 4-1: Fonctionnement VPN

Internet Engineering Task Force

Rapport de stage de licence R&T

4.2.2 Cration des certificats et des cls RSA

Rapport de stage de licence R&T

4.2.3 Protocole SSL / TLS 4.2.3.1 A propos dSSL / TLS

HyperText Transfert Protocol Security

Rapport de stage de licence R&T

4.2.3.4 Principe de fonctionnement

Hashed Message Authentification Code