ECOLE DE TECHNOLOGIE SUPRIEURE UNIVERSIT DU QUBEC

MEMOIRE PRESENTE A L'COLE DE TECHNOLOGIE SUPRIEURE

COMME EXIGENCE PARTIELLE L'OBTENTION DE LA MATRISE EN GNIE AVEC CONCENTRATION EN RSEAUX DE TLCOMMUNICATIONS M. Ing.

PAR LAURENT CHARBONNIER

EVALUATION DE LA SECURITE DES RESEAUX PRIVES VIRTUELS SUR MPLS

MONTREAL, LE 10 DECEMBRE 2007

Laurent Charbonnier, 2007

CE MEMOIRE A ETE EVALUE PAR UN JURY COMPOS DE :

M. Michel Lavoie, directeur de mmoire Dpartement de gnie logiciel l'cole de technologie suprieure

Mme Maria Bennani, codirecteur de mmoire Dpartement de gnie logiciel l'cole de technologie suprieure

M. Michel Kadoch, prsident du jury Dpartement de gnie lectrique l'cole de technologie suprieure

M. Jean Marc Robert, membre du jury Dpartement de gnie logiciel l'cole de technologie suprieure

IL A FAIT L'OBJET D'UNE SOUTENANCE DEVANT JURY ET PUBLIC LE 5 NOVEMBRE 2007 L'COLE DE TECHNOLOGIE SUPRIEURE

REMERCIEMENTS

Je souhaite remercier en premier lieu mon directeur de recherche, Michel Lavoie, pour m'avoir accompagn tout au long de ce projet de recherche et avoir suscit chez moi un intrt toujours grandissant pour le domaine de la scurit informatique. Son aide clairvoyante et ses rponses rapides, enthousiastes et dtailles m'ont permis d'avancer lorsque des difficults taient prsentes.

Pour leur collaboration sans laquelle ce projet n'aurait pu tre possible, mes remerciements s'adressent galement Bell Canada. Leur rseau MPLS m'a permis de vrifier mes suppositions thoriques et de raliser des exprimentations techniques constructives. Merci galement Maria Bennani pour m'avoir propos ce projet, pour son temps et sa disponibilit.

Je tiens exprimer ma gratitude Jean Marc Robert pour son expertise scientifique avance et son concours sur la vrification de lgitimit de problmes potentiels dans l'architecture MPLS/VPN. Ma reconnaissance va en outre Michel Kadoch qui a engendr mon intrt actuel pour la voix sur IP et m'a permis de transmettre ce qu'il m'a appris dans le domaine des tlcommunications des tudiants de TETS depuis plusieurs sessions.

Je ne pourrais conclure ces remerciements sans avoir une pense pour ma famille et mes amis qui m'ont toujours soutenu et donn la force de mener bien cette matrise. Un grand merci toi, Andre, pour ton appui permanent, tes conseils et tes encouragements. Enfin, je vous remercie, Olivier, Rmi et Guillaume pour avoir t plus que de simples collgues de travail, Zizou pour ton geste librateur.

EVALUATION D E LA SECURITE DES RESEAUX PRIVE S VIRTUELS SU R MPLS LAURENT CHARBONNIER RSUM Les besoins actuels en termes de transmission scurise de l'information sont colossaux. Si les lignes loues reprsentaient dans le pass la mthode la plus communment employe pour relier deux sites distants, les rseaux privs virtuels prennent de plus en plus le pas sur ces lignes loues, essentiellement grce leur cot beaucoup plus faible. Nanmoins, les VPN de niveau 2 sont complexes mettre en uvre et difficiles mettre l'chelle. Rcemment sont appams les VPN sur MPLS, offrant de meilleures performances et ne ncessitant pas de chiffrement des donnes. Le concept des VPN sur MPLS repose sur l'utilisation de tables de routage et de contextes spars dans les routeurs de bordure pour chaque VPN. Les paquets sont achemins dans le rseau MPLS en ajoutant une tiquette supplmentaire permettant de dfinir leur appartenance un VPN. Le rseau MPLS est transparent pour les clients des VPN, toutefois ceux-ci doivent faire confiance au foumisseur de service. tant de plus en plus dploys, il est ncessaire de vrifier que les VPN sur MPLS sont effectivement scuritaires et ne permettent pas des attaquants de s'introduire dans le rseau MPLS ou dans les VPN. Ces demiers doivent tre tanches, ne permettant pas de divulguer ou modifier l'information. La recherche prliminaire des diffrents modes d'attaques sur un rseau nous permet de confironter la technologie MPLSA^PN des menaces varies, puis de tester des architectures particulires utilisant cette technologie. Des exprimentations ont t menes sur un rseau MPLS de Bell Canada pour montrer que certaines conditions peuvent compromettre la scurit des VPN sur MPLS. Le protocole BGP, utilis sous sa variante MP-BGP pour effectuer la signalisation des VPN dans le rseau MPLS fait l'objet d'une tude approfondie. Nos rsuUats montrent que l'architecture MPLS/VPN est scuritaire la condition qu'aucune erreur de configuration ne soit prsente. Finalement, des conseils et recommandations sont prsents afin d'esquiver toute tentative d'attaque.

EVALUATION D E LA SECURITE DE S RESEAUX PRIVE S VIRTUELS SU R MPLS LAURENT CHARBONNIER ABSTRACT The actual needs in terms of secure data communication are tremendous. In the past, the use of leased lines was the most widespread method to link two distant sites. Today, virtual private networks are stealing the show with their much lower costs. However, layer 2 VPN are difficult to implement and they suffer poor scalability. Nevertheless, VPN using MPLS hve recently appeared on the market, offering higher performance without needing data encryption. The concept of MPLS VPN relies on separate contexts and routing tables on border routers for each VPN. Packets are forwarded in the core network using an extra label defining a VPN membership. Each customer is unaware of the MPLS cloud because of the address space sparation. However, high levels of tmst toward the service provider are essential. Considering its ever-growing popularity, it is cmcial to make sure that the MPLS VPN technology is indeed secure and would never allow intmsions in the core network or in the VPNs. Likewise, the previously mentioned should provide users with isolation and security, protecting information against eavesdropping or modification. Preliminary researches on numerous network attack techniques allows us to evaluate the response of MPLS VPN to varions threats and then to test particular architectures using that technology. Exprimental testing has been performed on a Bell Canada network in order to demonstrate that spcifie conditions can put the security of MPLS VPNs at risk. MP-BGP, a variant of BGP protocol, used to propagate VPN routing information is extensively analyzed. Our results show that the MPLS VPN architecture is secure, given that no configuration mistake has been made. Finally, advices and recommendations will be suggested in order to dodge any attack attempt.

TABLE DES MATIERES Page INTRODUCTION CHAPITRE 1 TAT DE L'ART 1.1 La technologie MPLS 1.1.1 Fonctionnement de MPLS 1.1.2 Buts de MPLS 1.1.2.1 Buts initiaux 1.1.2.2 Nouveaux buts et applications 1.1.2.3 L'ingnierie de trafic 1.1.2.4 Les rseaux privs virtuels sur MPLS (MPLS/VPN) 1.2 La scurit dans MPLS 1.2.1 Gnralits 1.2.2 Diffrents aspects considrer 1.2.3 Comparaison avec les VPN classiques 1.2.4 Considrations techniques avances 1.2.4.1 Le plan de contrle 1.2.4.2 Le plan de donnes 1.2.4.3 Le plan de gestion 1.2.5 La sparation des VPN 1.2.5.1 Sparation des espaces d'adressage 1.2.5.2 Sparation du trafic 1.3 Problmatique CHAPITRE 2 ANALYSE DE LA SCURIT DE MPLS/VPN 2.1 Menaces et attaques dans un environnement rseau 2.1.1 Catgories de menaces 2.1.2 Types d'attaques 2.1.2.1 coute sur le rseau 2.1.2.2 Modification de donnes 2.1.2.3 Mystification dans la pile protocolaire TCP/IP 2.1.2.4 Attaque Man in the middle 2.1.2.5 Dni de service 2.1.2.6 Scan de ports 2.1.2.7 Accs non autoris 2.1.2.8 Attaques sur les mots dpasse des routeurs 2.1.2.9 Attaques sur cls de chiffrement 2.1.2.10 Attaques utilisant l'ingnierie sociale 2.1.2.11 Remise en cause du modle TCP/IP 2.1.3 Bilan 1 3 3 4 9 9 9 10 11 12 12 15 17 18 18 19 20 21 21 23 24 27 28 28 31 31 32 32 34 36 39 40 41 43 44 45 46

VII

2.2

Analyse de la scurit des VPN sur MPLS 2.2.1 Une attaque directe impossible 2.2.2 Attaques indirectes 2.2.2.1 Attaque sur le cur du rseau 2.2.2.2 Mystification d'tiquettes MPLS ou d'adresses IP 2.2.2.3 Dni de service 2.2.2.4 Attaques sur le lien CE-PE 2.2.2.5 Attaques sur les protocoles de signalisation 2.2.3 Des points de vue extrieurs 2.2.3.1 Intgnt des VPN 2.2.3.2 Performances des VPN sur MPLS 2.2.4 Comparaison avec ATM/FR 2.2.5 Scurit des architectures MPLS avances 2.2.5.1 Rseau cur multi-AS 2.2.5.2 Rseaux MPLS hirarchiss

48 49 50 51 53 54 54 56 57 58 59 60 63 63 66 68 68 74 78 82 84 89 90 92 92 94 95 98 98 100 100 101 103 103 104 105 106 108 110 110 111

CHAPITRE 3 TESTS 3.1 Menaces lies la connectivit Extranet 3.2 Menaces lies une connectivit Intemet 3.3 Tests d'tanchit de l'architecture Extranet 3.3.1 Test de communication avec la ressource partage 3.3.2 Test de communication avec un VPN non partag 3.3.3 Vrification du succs de la communication vers ETS2 3.3.4 Bilan CHAPITRE 4 SCURIT DU PROTOCOLE BGP 4.1 Gnralits sur le protocole BGP 4.2 valuation de la scurit du protocole BGP 4.3 La scurit actuellement utilise : MD5 4.4 Les extensions proposes pour renforcer la scurit de BGP 4.4.1 Secure BGP (S-BGP) 4.4.2 Secure Origin BGP (soBGP) 4.4.3 Pretty Secure BGP (psBGP) 4.4.4 Pretty Good BGP (PGBGP) 4.4.5 Inter-Domain Routing Validator (IRV) 4.4.6 Listen and Whisper 4.4.7 Secure Path Vector (SPV) 4.4.8 Topology-based dtection of anomalous BGP messages 4.5 Bilan 4.6 Lien avec les tests raliss CHAPITRE 5 PRCEPTES FONDAMENTAUX 5.1 Scurit de la cration d'un VPN dans un rseau MPLS/VPN 5.1.1 Routage intra-cur MPLS

VIII

5.2

5.1.1.1 Protocoles utiliss 5.1.1.2 Failles possibles 5.1.1.3 Conseils 5.1.2 Le routage CE-PE 5.1.2.1 Protocoles utiliss 5.1.2.2 Failles possibles 5.1.2.3 Conseils 5.1.3 Cration des VPN 5.1.3.1 Protocoles utiliss 5.1.3.2 Failles lies MP-BGP 5.1.3.3 Attaque directe sur l'tiquette 5.1.3.4 Conseils 5.1.4 tablissement des LSP dans le rseau MPLS 5.1.4.1 Protocoles utiliss 5.1.4.2 Failles possibles 5.1.4.3 Conseils 5.1.5 Autres considrations 5.1.5.1 Authentification CE CE 5.1.5.2 Problme des Route Targets 5.1.5.3 Recette selon Cisco 5.1.6 Bilan Recommandations gnrales 5.2.1 Respect d'un modle scuritaire 5.2.2 Respect d'un modle de scurit utilisant la dfense en profondeur..

111 111 112 113 114 114 114 115 116 116 117 117 118 119 119 119 120 120 121 122 123 124 124 126 129 133 135

CONCLUSION RECOMMANDATIONS LISTE DE RFRENCES

LISTE DES TABLEAUX Page Tableau 1.1 Exemple de table de commutation d'tiquette sur un routeur MPLS 4

Tableau 3.1 Configuration des vrf pour les sites 1, 2 et 3 de la connectivit Extranet.... 71 Tableau 3.2 Configuration des VRF sur le PEl Tableau 3.3 Configuration des VRF sur le PE3 Tableau 3.4 Disposition des FrameScopePro dans le rseau Tableau 3.5 Rsultat de la commande traceroute vers la ressource partage Tableau 3.6 Rsultat de la commande traceroute vers ETS2 Tableau 3.7 Dduction de la commande traceroute complte vers ETS2 Tableau 5.1 Configuration d'un rseau MPLS scuritaire (Tir de Lewis, 2004) 81 81 82 83 85 88 122

LISTE DE S FIGURE S Page Figure 1.1 Contenu de Tentte MPLS Figure 1.2 Schma simplifi d'un routeur MPLS/VPN avec trois l'outeurs virtuels 7 14 14 22 36 65 69 71 73 76 77 79 80 83 86 87

Figure 1.3 Principe de 1 empilement d tiquettes MPLS (Tir de Ixia, 2004) Figure 1.4 For-mat d'une adr-esse VPN-IPv4 (Tir de Berkowitz, 2003) Figure 2.1 Inondation de messages TCP SYN Figure 2.2 Les diffr-entes possibilits de filtrage inter-AS (Tir de Cisco, 2003) Figure 3.1 Sites clients dans plusieurs VPN (Tir de Cisco, 2006) Figure 3.2 Reprsentation de Figure 3.3 Reprsentation de la connectivit Extranet - Cas 1 la connectivit Extranet - Cas 2

Figure 3.4 Connectivit Internet dans un VRF (Tir de Behringer et Morrow, 2005) Figure 3.5 Accs partag Internet (Tir de Behringer et Morrow, 2005) Figure 3.6 Schma de l'architecture Extranet (Tir de Behringer et Mor'row, 2005) Figure 3.7 Schma Visio du rseau de test de Bell Canada Figure 3.8 Capture d'cran d'un traceroute lgitime Figure 3.9 Capture d'cran d'un traceroute vers un VPN non partag - VLAN 50 Figure 3.10 Capture d'cran d'un traceroute vers un VPN non partag - VLAN 60

LISTE DE S ABREVIATIONS, SIGLE S E T ACRONYMES AES AH AS ASBR ATM BGP CDP CE CERT CGI CIDR CR-LDP CSRF CTCPEC DES DLCI DNS DoS DS DSCP eBGP Advanced Encryption Standard Authentication Header Autonomous System Autonomous System Border Router Asynchronous Transfer Mode Border Gateway Protocol Cisco Discovery Protocol Customer Edge (router) Computer Emergency Response Team Common Gateway Interface Classless Inter-Domain Routing Constraint Routing - Label Distribution Protocol Cross-Site Request Forgery Canadian Tmsted Computer Product Evaluation Criteria Data Encryption Standard Data Link Connection Identifier Domain Name Server Deny of Service Differentiated Services Differentiated Services Code Point exterior Border Gateway Protocol

XII

EIGRP ESP FEC FLIX FR FTP GRE HTTP lANA ICANN IBC iBGP lETF ICMP IDS IGP IKE IP IPsec IPv4 IPv6 IPX

Enhanced Interior Gateway Routing Protocol Encapsulating Security Payload Forwarding Equivalence Class Florida Intemet Exchange Frame Relay File Transfer Protocol Generic Routing Encapsulation Hypertext Transfer Protocol Intemet Assigned Number Authority Intemet Corporation of Assigned Numbers and Names Identity Based Cryptography interior Border Gateway Protocol Intemet Engineering Task Force Intemet Control Message Protocol Intmsion Dtection System Interior Gateway Protocol Intemet Key Exchange Intemet Protocol Intemet Protocol security Intemet Protocol version 4 Intemet Protocol version 6 Intemetwork Packet Exchange

Xlll

IRR IRV ITSEC L2TP L2TPv3 LAN LDP LER LSP LSR MAC MD5 MP-BGP MPLS NAT NOC OSI OSPF P PE PGBGP PHP

Intemet Routing Registry Inter-Domain Routing Validator Information Technology Security Evaluation Criteria Layer 2 Tunneling Protocol Layer 2 Tunneling Protocol version 3 Local Area Network Label Distribution Protocol Label Edge Router Label Switch Path Label Switch Router Mdium Access Control Message Digest 5 Multi Protocol Border Gateway Protocol Multi Protocol Label Switching Network Address Translation Network Oprations Center Open Systems Interconnection Open Shortest Path First Provider (router) Provider Edge (router) Pretty Good Border Gateway Protocol Penultimate Hop Popping

XIV

PKI P2P PPTP psBGP PWE RC4 RD RFC RIP RIR RR RSA RSVP RT S-BGP SHA soBGP SOO SPV SSH SSID SSL

Public Key Infrastructure Peer to Peer Point to Point Tunneling Protocol pretty secure Border Gateway Protocol Pseudo Wire Emulation Rivest Cipher 4 Route Distinguisher Request For Comments Routing Information Protocol Rgional Intemet Registry Route Reflector Rivest, Shamir, Adleman Resource Rservation Protocol Route Target Secure Border Gateway Protocol Secure Hash Algorithm secure origin Border Gateway Protocol Site Of Origin Secure Path Vector Secure Shell Service Set IDentifier Secure Socket Layer

XV

TCP TCSEC TE TLS ToS TTL VCI VLAN VPI VPLS VPN VPWS VRF WEP WPA XSS

Transmission Control Protocol Trusted Computer System Evaluation Criteria Traffic Engineering Transport Layer Security Type of Service Time to Live Virtual Circuit Identifier Virtual Local Area Network Virtual Path Identifier Virtual Private LAN Service Virtual Private Network Virtual Private Wire Service VPN Routing and Forwarding Wireless Equivalent Privacy Wi-Fi Protected Access Cross-Site Scripfing

INTRODUCTION L'avnement d'un accs rapide Intemet pour tous et partout a simplifi l'accs aux services et aux connaissances, ce qui constitue un rel progrs dans notre faon de vivre. Hlas, les procdures d'attaques, qu'elles visent une enfil particulire ou Intemet tout entier, s'en sont galement trouves facilites. De nos jours, un vims ou un dni de service de porte plantaire peuvent tre lancs dans l'anonymat le plus complet en sirotant un chai latte sur la terrasse du Star-bucks du coin grce au rseau sans-fil mis gratuitement la disposifion des clients.

Ce contexte de la croissance exponenfielle d'Internet implique la ncessit de crer des rseaux toujours plus dmesurs, toujours plus rapides, toujours plus scuritaires. Comme la complexit des rseaux se fait grandissante, la gestion et le dimensionnement des rseaux deviennent primordiaux.

Le plus gros dfi des concepteurs n'est peut-tre plus de concevoir des technologies fonctionnelles - les outils de dveloppement tant de plus en plus volus - mais de crer des technologies sans faille de scurit. MPLS {Multi Protocol Label Switching) est une technologie de rseau permettant de nouvelles applications comme l'ingnierie de trafic et les rseaux privs virtuels. Ces demiers, les VPN sur MPLS, permettent de relier plusieurs sites gographiquement distants d'une manire totalement transparente pour les clients, tout en garantissant la confidentialit et l'intgrit des donnes sans que celles-ci ne soient chiflres durant leur transport.

La perspective d'une technologie ne ncessitant aucun chiffrement est trs intressante, ce demier crant toujours une perte de performance incompatible avec les applications temps rel et ncessitant une architecture de gestion des cls pointue. Cependant, la

caractristique premire d'un rseau priv demeure d'assurer le maintien du secret des informations transportes. Ce mmoire tentera de dmontrer que MPLS a su relever ce dfi.

Tout d'abord, nous prsentons divers aspects de MPLS, son fonctionnement, ses applications, la gestion de la scurit et la mise en uvre des VPN sur MPLS. La garantie de l'tanchit des rseaux privs virtuels constitue la problmatique et est discute la fin de ce premier chapitre.

Aprs avoir dress une liste quasi-exhaustive des diffrents types d'attaques possibles sur un rseau MPLS, le second chapitre fait l'analyse complte de la scurit de MPLS/VPN. En premier lieu, nous dcrivons les attaques directes ou indirectes qui pourraient permettre de briser l'tanchit des VPN et analysons en corrlation le point de vue d'autres chercheurs ce sujet. Une comparaison avec ATM {Asynchronous Transfer Mode) et Frame Relay, technologies rputes scuritaires utilisant un principe similaire au niveau 2 est ensuite effectue, avant d'tudier plus spcifiquement certaines architectures MPLS/VPN avances.

Le troisime chapitre dtaille quelques connectivits labores de rseaux MPLS puis prsente la ralisation de tests pratiques permettant de vrifier la scurit d'une de ces connectivits sur un rseau MPLS de Bell Canada. la lumire de ces tests, une tude de la scurit du protocole BGP est effectue dans le quatrime chapitre.

Enfin, le cinquime chapitre suggre une marche suivre visant la garantie d'un fonctionnement scuritaire de MPLS/VPN. Pour y parvenir, nous parcourons chaque tape de cration d'un VPN en considrant les failles possibles des protocoles utiliss.

CHAPITRE I ETAT D E L'AR T Ce chapitre prsente la technologie MPLS, son fonctionnement et ses applications et se concentre particulirement sur la scurit des VPN sur MPLS. La vrificafion de l'tanchit des VPN est l'objet de la problmatique. 1.1 L a technologie MPL S

MPLS est une technologie de rseau qui applique certains aspects des technologies commutation de circuits telles qu'ATM ou Frame Relay un rseau commutation de paquets. MPLS vient s'intercaler entre la couche 2 et la couche 3 du modle OSI {Open Systems Interconnection), il y est d'ailleurs souvent fait rfrence comme appartenant la couche 2.5.

MPLS ajoute un entte situ entre l'entte de la couche rseau et l'entte de la couche liaison de donnes. Cet entte porte le nom d'entt shim. Comme l'indique son

abrviafion, MPLS supporte n'importe quel protocole de couche rseau (Rosen, 2001). En gnral, le protocole de la couche rseau est IPv4, bien qu'IPv6 {Inteniet Protocol version 6), IPX {Inter-network Packet Exchange), AppleTalk, etc. soient aussi supports. Le principe de MPLS a t suggr en 1996 par Ipsilon Networks en tant que

technologie d'IP switching fonctionnant sur ATM, et par Cisco sous le nom de Tag switching. Le nom a t chang pour Label switching lorsque l'IETF a cr le groupe de travail sur MPLS pour standardiser MPLS en 1997.

1.1.1

Fonctionnement d e MPLS

MPLS ralise une commutation d'tiquette en lieu et place du routage IP tradifionnel. Dans un environnement classique IP, chaque routeur ralise sa dcision d'acheminement en fonction de l'adresse IP situe dans l'entte rseau du paquet et du contenu de sa table de routage. Dans un environnement MPLS, chaque routeur possde une table de commutation des tiquettes. En fonction de la valeur de l'fiquette situe dans l'entte MPLS et de l'interface d'entre du paquet, le routeur cherchera dans cette table l'tiquette utiliser en sortie ainsi que l'interface de sortie. Une fois entr dans le rseau MPLS, l'entte rseau d'un paquet ne sera plus jamais consulte jusqu' sa sortie de ce rseau. Seules les fiquettes affectent l'acheminement des paquets.

L'avantage de cette technique de commutafion d'tiquette est qu'elle n'impose pas de dcomposer le paquet reu jusqu' l'entte rseau afin de pouvoir effectuer la dcision d'acheminement, se rapprochant ainsi des technologies de niveau 2. De plus, la notion de chemin est transparente pour les routeurs du rseau, appels LSR {Label Switching Router), qui n'ont donc aucune connaissance ncessaire des rseaux interconnects au nuage MPLS (reprsent par le cur du rseau). Le tableau ci-dessous prsente un exemple de table de commutation d'tiquette.

Tableau 1.1 Exemple de table de commutation d'tiquette sur un routeur MPLS Interface I N 0 0 2 Label IN 15 41 6 Interface OU T 1 2 1 Label OU T 24 39 24

En plus des routeurs LSR, qui se chargent d'effectuer la commutafion d'tiquette au cur du rseau MPLS, il existe des routeurs de bordure, appels LER {Label Edge Router), qui sont les points d'entre et de sortie du rseau MPLS. Leur rle est d'assigner l'tiquette au paquet entrant dans le rseau, et de l'ter au paquet sortant du rseau.

L'itinraire empmnt par un paquet dans le rseau MPLS suit un chemin appel LSP {Label Switch Path). Ces chemins, reliant entre eux les routeurs LER, peuvent tre configurs manuellement par le gestionnaire du rseau ou automatiquement par les LER. Ces demiers s'appuient pour cela sur des protocoles de distribution d'fiquettes tels que LDP {Label Distribution Pr-otocol, cf RFC3036 (Anderson et al., 2001)) ou RSVP-TE {Resource Reser-\'ation Pr-otocol, cf. RFC3209 (Awduche et al., 2001)). Ce demier est utilis pour l'ingnierie de trafic, une des applications des rseaux MPLS.

Les tiquettes peuvent tre distribues de plusieurs faons : tout d'abord de faon descendante {downstream) ou montante {upstream), selon le sens de propagation de l'information, puis soit la demande, soit automafiquement {unsolicited). Le tout tant soit ordonn, soit indpendant (sans ordre). Le routage classique, ufilisant un IGP {Interior Gateway Pr-otocol) comme OSPF {Open Shortest Path First), est ncessaire afin de permettre aux routeurs du nuage MPLS de communiquer entre eux. Il n'est par contre pas utilis pour indiquer les rseaux joignables en dehors du nuage MPLS ou pour router les paquets de donnes dans le nuage. Les classes d'quivalences ou FEC {Forwarding Equivalence Class) permettent de classifier les paquets leur entre dans le rseau MPLS. Tous les paquets faisant partie de la mme FEC suivront le mme chemin dans le rseau et donc ufiliseront les mmes tiquettes. La classification est effectue par rapport soit au rseau de destination, soit

la classe de service, soit suivant des paramtres d'ingnierie de trafic. Elle se base sur le contenu de l'entte rseau, par exemple l'adresse IP de destination ou le champ ToS {Type ofSenice).

Les chemins LSP n'ont pas d'existence concrte, mais sont la somme des correspondances tiquette d'entre/tiquette de sortie entre un routeur d'entre dans le rseau MPLS, appel LER Ingress et un routeur de sortie du rseau MPLS, appel LER Egrss. Lors du fonctionnement normal du rseau MPLS, le routeur LER Ingress ajoute l'entte MPLS en appliquant l'tiquette correspondant au chemin suivre puis l'envoie sur le LSP. Chaque routeur LSR travers va lire l'tiquette situe dans l'entte , chercher l'tiquette de sortie dans sa table de correspondance, changer la valeur de l'tiquette dans l'entte pour celle trouve dans la table et enfin raliser la commutation du paquet. Le routeur LER Egress enlev l'entte MPLS et envoy le paquet sur l'interface correspondant au rseau de destination, en fonction nouveau de l'adresse IP. Il faut noter qu'il existe une fonctionnalit, le penultimate hop popping

(PHP),

permettant de rduire la charge sur les routeurs LER Egress. Elle consiste enlever l'entte MPLS non pas au routeur LER mais au demier routeur LSR travers. Ainsi le LER Egr-ess ralisera simplement le routage du paquet lorsqu'il le recevra, puisque celui-ci ne comportera pas d'entt MPLS.

L'entte ajout par MPLS, prsent ci-dessous, contient plusieurs champs : l'fiquette MPLS, d'une longueur de 20 bits, utilise pour la commutation, le champ exprimental sur trois bits, qui peut tre utilis pour indiquer la qualit de service du paquet, en association avec le champ ToS/DiffServ de l'entte IP, le bit S, dfinissant s'il vaut 1 qu'il s'agit du demier entte MPLS, le TTL (Time to Live) sur huit bits qui permet d'viter les boucles infinies.

tiquette MPL S 20 bits

EXP S 3 bits 1 bit

TTL 8 bits

32 bit s

Figure 1. 1 Contenu de l'entte MPLS. La longueur totale de l'entte est de 32 bits soit 4 octets. La surcharge cause par l'ajout de cet entte est donc restreinte par rapport aux enttes existants (Ethemet = 16 octets, IP = 20 octets, TCP = 20 octets, etc.), ce qui permet de limiter la perte d'efficacit du rseau, exprime en fonction du rapport entre les donnes utiles de la couche application et les donnes effectivement transmises sur le rseau, avec les enttes. Le champ exprimental

est parfois nomm Classe de service . l'origine sans

fonction attitre, il peut servir pour faire le lien entre la qualit de service indique au niveau de l'entte IP par le champ ToS ou DS {Differentiated Services) de l'entte IP. Cela permet de classer les paquets arrivant dans les LSR dans diffrentes queues traites selon leur qualit de service associe. Les trois bits du champ exprimental peuvent tre associs facilement aux bits de prcdence du champ ToS. Par contre un problme se pose s'ils doivent tre associs aux codes DSCP {Difirendated Services Code Point) utiliss par les services diffrencis (ou DiffServ) qui utilisent six bits (il en est ainsi car l'entte MPLS a t conu avant les codes DSCP). Le manque de place peut nanmoins tre compens en affectant des tiquettes MPLS diffrentes selon la qualit de service, le routeur LSR faisant alors la distinction de traitement entre les paquets en fonction de la valeur de l'fiquette MPLS. Plus d'information sur ce point peut tre obtenue en lisant la RFC3270 (Le Faucheur et al., 2002).

En plus de permettre un acheminement plus rapide des paquets, un autre des avantages de la technologie MPLS est la possibilit d'empiler les fiquettes, technique connue sous le nom de label stacking. Cela rend possible - entre autres - des applications telles que l'ingnierie de trafic, les rseaux privs virtuels ou VPN sur MPLS, ou encore le transport sur des rseaux MPLS hirarchiss {cf partie 2.2.5.2). De la mme faon qu'IPv6 utilise un champ next header pour grer les options en indiquant la nature de l'entte suivant, le bit S de l'entte MPLS permet d'indiquer si l'tiquette concerne est la demire de l'empilement (si S=l) ou non (si S=0).

Enfin, le champ TTL a les mmes fonctionnalits que son pendant de l'entte IP, avec pour objectif d'viter que le paquet ne rentre dans une boucle infinie. Le LER Ingress va recopier la valeur du champ TTL de l'entte IP dans celui de l'entte MPLS. Chaque routeur LSR travers par le paquet va dcrmenter sa valeur. Arriv au LER Egress, il sera recopi la place du champ quivalent de l'entte IP. II est noter qu'un paramtre de configuration permet de rendre transparents tous les routeurs du rseau MPLS et donc le nuage MPLS en ne recopiant pas la valeur du champ TTL de l'entte MPLS dans l'entte IP.

Pour plus d'information sur l'architecture MPLS, le lecteur peut consulter la RFC3031 (Rosen, 2001). De son ct, la RFC3032 (Rosen et al., 2001) prsente la technique d'encodage de l'tiquette MPLS par les routeurs LSR, les rgles et procdures pour traiter les diffrents champs de l'tiquette ainsi que certaines considrations telles que la limitation de taille des paquets par la couche de niveau 2 utilise.

1.1.2 But

s de MPLS s initiau x

1.1.2.1 But

Le but initial de MPLS tait d'amliorer les performances de routage des grands rseaux en apportant la vitesse de commutation de la couche 2 la couche 3. Cela a t rendu possible en suivant le principe dvelopp lors de technologies prcdentes comme ATM ou FR : les circuits ou chemins virtuels. Au lieu de devoir consulter chaque routeur travers la table de routage afin de dterminer l'interface de sortie, MPLS permet de ne consulter qu'une table de commutation d'tiquettes, indiquant selon l'tiquette inclue dans l'entte shim l'interface de sortie ainsi que l'tiquette placer dans ce mme entte (de la mme faon que les VPI {Virtual Path Identifier) et VCI {Virtual Circuit Identifier) inclus dans l'entte des cellules ATM ou les DLCI {Data Link Connection Identifier) de l'entte FR).

Cependant, avec l'amlioration des performances des routeurs modemes, la diffrence de performances entre un routage IP et une commutation par MPLS est devenue ngligeable.

Un autre but de MPLS tait de simplifier le transport d'IP sur ATM, complexe cause des protocoles de signalisation d'ATM. Cette simplification a t apporte par les fiquettes remplaant les VPI/VCI d'ATM, par un protocole de distribution des tiquettes spcifique MPLS : LDP et par des protocoles de routage du monde IP, tels que BGP {Border Gateway Pr-otocol) et OSPF. 1.1.2.2 Nouveau x but s et applications

L'intrt de MPLS ne rside pas dans son ufilisafion isole. Des applications comme l'ingnierie de trafic ainsi que les rseaux privs virtuels sur MPLS ont t dveloppes pour permettre de nouvelles potentialits.

Tel qu'nonc prcdemment, MPLS n'apporte pas lui-mme de gain notable en termes de performances. De plus, cette technologie ne permet pas elle seule d'empcher la congestion, surtout si le trafic dans le rseau n'est pas stable mais volutif Nanmoins, en tant utilise en associafion l'ingnierie de trafic, elle permet un accroissement trs apprciable de performances. 1.1.2.3 L'ingnieri e d e trafic

L'ingnierie de trafic permet l'utilisation optimale des ressources du rseau, contrairement au routage IP qui privilgie le chemin le plus court, en termes de nombre de sauts (RIP, Routing Information Protocol) ou d'tats de liens (OSPF par exemple). Elle office la possibilit d'utiliser diffrents chemins pour relier un nud source et un nud destination afin de rpartir la charge sur le rseau et ainsi amliorer l'efficacit de ce demier. Pour y parvenir, un routage explicite est utilis, c'est--dire que des contraintes telles que la bande passante ncessaire pour le trafic, sont prises en compte lors de la cration des LSP. Le protocole CR-LDP {Constraint Routing-LDP) permet de crer de tels LSP. D'autres protocoles comme RSVP-TE (RSVP-Traffic Engineering) et OSPF-TE {OSPF-Traffic Engineering) sont aussi utiliss pour grer efficacement le rseau MPLS et rserver des chemins non congestionns de manire dynamique, s'adaptant en temps rel la charge sur le rseau et pas uniquement sur des rglages prtablis.

Une des possibilits permises par l'ingnierie de trafic, en l'occurrence par le protocole RSVP-TE, est la rservafion d'une bande passante garanfie sur le rseau. Il est ainsi possible d'offrir une qualit de service de haut niveau des applications temps rel comme la voix sur IP, la vidoconfrence, etc.

11

Afin de ne pas surcharger le rseau avec les donnes de contrle, MPLS permet l'agrgafion de flux de trafic. Cela signifie que pour plusieurs flux de trafic entrants par diffrents LSP, il est possible d'utiliser un seul LSP en sortie et ainsi rduire la quanfit d'informations sur les chemins crs ainsi que le nombre de connexions grer par les routeurs LSR du rseau MPLS. Des extensions l'ingnierie de trafic existent, comme le reroutage rapide {Fast Reroute) qui est un mcanisme de protection locale de MPLS-TE. Pour chaque LSP primaire cr il existe un LSP secondaire dit de secours qui sera activ ds la dtection d'une panne sur le LSP primaire. Le but de ce mcanisme de protection est de limiter le temps de panne du chemin concern une valeur infrieure 100ms, permettant aux applications temps rel de ne pas souffrir de la panne.

Il existe d'autres solutions permettant d'empcher la congestion, telle que l'ingnierie de rseau. Si l'ingnierie de trafic place le trafic l o le rseau n'est pas congestionn, l'ingnierie de rseau augmente quant elle la capacit des liens fortement achalands. II est ais de comprendre que l'ingnierie de trafic est de loin la plus avantageuse, surtout si le trafic dans le rseau est dynamique.

1.1.2.4

Les rseaux privs virtuels sur MPLS (MPLS/VPN)

Avec l'ingnierie de trafic, l'autre grande application de MPLS est la possibilit de crer des rseaux privs virtuels (appels par la suite VPN : Virtual Private Network) utilisant MPLS comme mode de transport. L'avantage dcoulant de l'ufilisation de MPLS est la possibilit de ne pas avoir chiffrer les donnes lors de leur transport tout en garanfissant leur confidentialit. C'est le but primordial d'un VPN.

Pour permettre cela, MPLS utilise la notion de routeurs virtuels garantissant, au sein d'un mme routeur physique, la cration de diffrents contextes de routage, chaque VPN

possdant son propre contexte. Ainsi, deux sites gographiquement spars peuvent tre lis et demeurer privs sans pour autant ncessiter l'ufilisation de protocoles de chiffrement comme IPsec {Internet Pr-otocol security) ou de technologies de VPN classiques, par exemple L2TP {Layer 2 Tunneling Protocol).

Les technologies de VPN classiques , c'est--dire de niveau 2, sont rputes et frquemment utilises pour permettre le transport de donnes de faon scuritaire sur un mdium qui ne l'est pas. Un des usages possibles est d'offrir un accs distance scuris d'un poste client au rseau de l'entreprise par exemple. Le niveau de scurit de ces technologies VPN n'est pas remis en cause, cependant elles sont caractrises par une certaine lourdeur et une complexit d'utilisation lies au chiffrement des donnes et l'interconnexion des passerelles VPN point point.

MPLS/VPN est une solufion plus simple, lgre, transparente l'utilisateur final, la configuration tant effectue par le foumisseur de service au niveau des routeurs de bordure du rseau MPLS et non sur les ordinateurs des clients. En consquence, un utilisateur mobile devra employer un VPN classique, MPLS/VPN tant valide pour des rseaux connects directement un nuage MPLS. Cette nouvelle technologie trouve donc son application dans la connexion de sites de VPN ne se dplaant pas gographiquement. 1.2 L a scurit dans MPLS s

1.2.1 Gnralit

Le succs d'une technologie utilise grande chelle ne dpend pas uniquement de son bon fonctionnement, il faut aussi en garantir la scurit. S'il est possible une personne malintentionne de corrompre ou d'en interrompre sa marche normale, qui voudrait alors l'utiliser? tant donn que des enjeux financiers sont la plupart du temps

13

impliqus, qu'il s'agisse de l'invesfissement pour adopter une nouvelle teclinologie ou des revenus qui dcouleront de son utilisation, tout risque est viter.

Comme mentionn prcdemment, le but initial de MPLS tait d'amliorer les performances des rseaux. La notion de rseaux privs virtuels utilisant MPLS est venue plus tard. Nanmoins, la conception de cette technologie a permis d'y intgrer la scurit assez simplement.

Par hypothse, la scurit de MPLS repose sur l'intgrit des tables d'tiquettes. Aussi, le principe fondamental de MPLS/VPN s'tablit sur la notion de routeurs virtuels. Au sein d'un seul routeur, MPLS/VPN permet de grer plusieurs contextes, ce qui quivaut avoir autant de routeurs physiquement spars. Si chaque contexte est associ un VPN, le rseau MPLS/VPN devient similaire - au niveau logique - des lignes ddies pour chaque VPN en ce qui a trait la scurit. Voir la Figure 1.2 pour le principe.

Enfin, il est primordial de faire l'hypothse que le rseau MPLS est un rseau priv. Nul ne doit pouvoir s'introduire l'intrieur du rseau, car les donnes y sont transfres sans tre chiffres. Permettre l'accs aux donnes par quiconque supprimerait la notion de rseau priv virtuel.

L'empilement des enttes MPLS permet de maintenir cette scurit entre les routeurs du rseau MPLS/VPN. L'tiquette extrieure , c'est--dire la premire rencontre lors de la dsencapsulation du paquet (reprsente en blanc sur la Figure 1.3), conserve son rle d'tiquette de LSP et permet la commutation entre le LER Ingress et le LER Egress. L'tiquette intrieure indique l'instance de routage et d'acheminement (VRF : VPN Routing and Forwarding), autrement dit le contexte de VPN concem. Elle reprsente pour chaque VRF le tunnel mis en place entre les routeurs de bordure.

14

Routeur MPLS-VP N

Figure 1.2 Schma simplifi d'un routeur MPLS/VPN avec trois routeurs virtuels Les routeurs de bordure du rseau MPLS/VPN sont appels PE pour Provider Edge. Il n'y a, sauf exception {cf partie 2.2.5), qu'entre les routeurs PE que sont utilises les tiquettes LSP et VPN. Les routeurs situs chez les clients et lis aux PE sont appels CE pour Customer Edge.

IP paMte t

LSPlaael ;

VRFial^e

l,

IPpacKe t

IP packfi t

VHf l a K o : VP.N S IP roilting

hg3^,-S4<eS^V B ") PN PE ,- ' ^^-_C EJ

- V . VPN A t u r r c l vrisi B t u i n c

..
IP fo^i-ft S laWe Service Pm'net MPL S Networ k

PC-- '

^ -> . E

VPN A

VRFIdb:c:VP\ A IP routin g tabe

Figure 1. 3 Principe de l'empilement d'tiquettes MPLS (Tir de Ixia, 2004)

15

Les paquets provenant des rseaux privs des clients sont sans tiquette, les routeurs PE classent ces paquets en fonction de leur origine dans les diffrents contextes qu'ils grent, leur assignent ensuite selon leur contexte une tiquette de VPN spcifique, puis selon le chemin empmnt une tiquette de LSP. Durant leur trajet sur le rseau MPLS, seule l'tiquette de LSP sera lue et modifie par les LSR, appels routeurs P pour Provider. L'tiquette de VPN demeurera intacte jusqu'au PE Egress, o le paquet sera envoy sur l'interface de sortie en fonction de son tiquette de VPN, qui lui aura pralablement t te.

Les diffrents contextes d'un PE possdent chacun leur table de VRF, autrement dit la liste des rseaux accessibles depuis leur VPN uniquement, afin de maintenir la notion de rseau priv. Il est possible de voir un exemple du principe de fonctionnement sur la Figure 1.3.

En ce qui conceme les donnes circulant dans chaque VPN, elles ne sont pas chiffres. Cela leur permet de ne pas subir la baisse de performances qu'impose le chiffrement des donnes, comme dans un VPN classique par exemple. Pour des applications temps rel, c'est un point cmcial.

1.2.2

Diffrents aspects considrer

Lorsque l'on value la scurit d'un systme, il est essentiel de considrer trois diffrents aspects qui sont l'architecture du systme, l'implmentation de l'architecture et le fonctionnement du systme (Behringer et Morrow, 2005). Nanmoins, c'est surtout le premier de ces aspects, l'architecture du systme, qui nous intresse vraiment dans ce mmoire.

16

L'architecture du systme est donne par la spcification fonnelle, dans le cas de MPLS/VPN il s'agit de la RFC4364 : BGP/MPLS IP Virtual Private Networks (VPNs) (Rosen et Rekhter, 2006).

L'implmentation de l'architecture correspond la faon dont les spcifications de cette demire sont rellement intgres. Certains choix d'implmentation peuvent remettre en cause la scurit de tout le systme, ou plus simplement donner lieu des erreurs et oublis de programmation, crant de possibles portes drobes (backdoors). Le fonctionnement du systme dpend quant lui du gestionnaire du rseau, comment il gre et maintient son systme, sachant que le problme le plus frquemment rencontr est le non-changement des mots de passe par dfaut des routeurs. Bien trop de gestionnaires de rseaux ne changent pas les mots de passe par dfaut (tels que admin , cisco , etc.) ou utilisent des mots de passe trop simples ou vidents deviner (Wayne et Edward, 2004). Ce simple oubli peut mettre en pril la scurit de tout le rseau MPLS. Le maillon le plus faible reste donc bien l'tre humain.

Les mots de passe ne sont pas les seules erreurs humaines ventuelles. La configuration des routeurs est ardue, c'est pourquoi pour rduire les risques d'erreurs l'ufilisation d'outils de configuration automatique - bien que possdant eux aussi leurs limites - est fortement conseille. L'utilisation de joumaux d'vnements {logs) dtaills permet de surveiller le rseau et les oprations inhabituelles qui pourraient s'y produire.

Si nous considrons que seule l'architecture du systme requiert une tude plus pousse, c'est parce que les problmes dcoulant des deux autres aspects sont lis des erreurs humaines, des oprateurs du rseau dans Tutilisafion ou des concepteurs dans l'implmentafion. De plus, concemant l'implmentafion, elle dpend des choix de chaque constmcteur, il faudrait par consquent l'tudier au cas par cas.

17

1.2.3 Comparaiso

n ave c les VPN classiques

A l'inverse des VPN classiques, qui utilisent des protocoles d'encapsulation comme GRE {Generic Routing Encapsulation), IP/IP, etc., les VPN sur MPLS ne sont pas orients connexion. Ce sont les VRF qui permettent de diriger l'informafion dans les VPN. Ceci est un atout important de MPLS/VPN. 11 est possible de crer un grand nombre de VPN sans ncessiter de maintenir un grand nombre d'informations chaque extrmit sur les VPN.

En utilisant les VPN classiques, les clients ont une visibilit complte sur leurs VPN et la possibilit de les contrler. Par contre, avec MPLS/VPN les clients perdent cette visibilit - due la transparence de cette technologie - toutefois la gestion s'en trouve simplifie puisqu'il n'y a rien faire par les clients. Cependant, il est ncessaire que le foumisseur de service porte une attention soutenue la configuration des VPN dans les routeurs PE, afin d'viter de briser l'intgrit d'un VPN en incluant, par exemple, un routeur PE qui n'a pas lieu dans un VPN. Un client se retrouvant devant un tel cas avec MPLS/VPN ne saura pas ncessairement que son VPN est corrompu. Le chiffrement avec IPSec, SSL {Secure Socket Layer) ou TLS {Transpori Layer Security) doit tre utilis dans les VPN classiques, car ceux-ci peuvent tre amens voyager sur Intemet et c'est ce chiffrement qui garantit la confidentialit des donnes.

Il est certes possible d'ufiliser IPSec dans les VPN sur MPLS entre les routeurs PE. Toutefois, les VPN sur MPLS tant logiquement spars, et en posant l'hypothse que le rseau MPLS est priv, ceux-ci ne requirent pas ce chiffrement pour garantir la scurit des informations. Donc, dans ce cas, quel en est l'intrt, sachant que le chiffrement ncessite du traitement, ce qui cause du dlai? Est-ce que la scurit n'est pas considre comme parfaitement fiable? Ou bien est-ce une mesure visant rassurer les clients?

D'aprs de nombreux chercheurs, la scurit de MPLS/VPN repose sur la confiance que les clients font au foumisseur de service et donc du rseau MPLS. Car si ce demier garantit que nul ne peut s'introduire dans le rseau - ce qui reste vrifier - il pourrait avoir pour sa part accs aux donnes l'intrieur du rseau MPLS. 1.2.4 Considration s technique s avance s

Cette partie dcrit plus en dtails la technologie MPLS/VPN en la sparant en plusieurs niveaux : le plan de contrle, le plan de donnes et le plan de gestion. 1.2.4.1 L e plan de contrle

Le plan de contrle dfinit comment l'informafion de contrle (ici, les routes VPN) est change sur le rseau. Les trois points importants sont les adresses VPN-IP, les Route Distinguishers (RD) et les Route Targets (RT). Afin de permettre aux diffrents sites d'un rseau priv de parler entre eux, il y a une procdure d'change de routes, entre routeurs CE et PE d'une part, et entre routeurs PE d'autre part. Les CE envoient leurs routes aux PE par du routage statique ou dynamique. De mme, les PE envoient les routes provenant des autres sites d'un mme VPN aux CE. Sur chaque PE, l'information de routage pour chaque VPN est maintenue dans des instances de routages de VPN, les VRF. un VRF donn correspond une ou plusieurs interfaces du client connectes au CE et appartenant au mme VPN. Les PE distribuent les routes reues des CE et stockes dans les VRF aux autres PE qui connectent des sites du mme VPN grce au protocole MP-BGP (Btes et al., 2007).

L'espace d'adressage utilis par chaque VPN pouvant se chevaucher, il est ncessaire de diffrencier les routes issues des diffrents VPN et ainsi viter toute confusion quant l'appartenance d'une adresse IP un VPN donn. Pour y parvenir, les PE utilisent des Route distinguishers qui sont ajouts chaque route VPN reue d'un routeur CE. Avec

19

cet ajout, il ne peut y avoir confusion avec l'information de contrle de diffrents VPN. II n'est alors plus question d'adresses IPv4 mais d'adresses VPN-IPv4 (ou v6, respectivement). Plus de dtails seront foumis dans la section 1.2.5.

Ainsi, les annonces de routes changes par le protocole MP-BGP (Btes et al., 2007) ne contiennent que des adresses VPN-IPv4 (et/ou VPN-lPv6, le cas chant) associes aux tiquettes VPN lies aux routes changes (Rekhter et Rosen, 2001). Les adresses VPNIPv4 ne sont toutefois utilises que dans le cur du rseau. Entre PE et CE, ce sont les adresses IPv4 usuelles qui sont utilises. Cela cause, entre autres consquences, que les CE ignorent ce qui se passe dans le cur du rseau, n'ayant ainsi aucune visibilit sur les autres VPN dploys. Les routeurs PE s'changent aussi au travers de MP-BGP des Route Targets, qui dfinissent quelles routes doivent tre importes ou exportes pour chaque VRF. Une mauvaise configuration des RT peut gravement compromettre la scurit de MPLS/VPN. Il s'agit toutefois l aussi d'une erreur humaine.

Pour plus de dtails sur Tutilisafion d'IPv6 dans le cadre des VPN sur MPLS, le lecteur peut consulter la RFC4659 (De Clercq et al., 2006). 1.2.4.2 L e plan de donnes

Le plan de donnes dfinit comment les donnes sont transmises sur le rseau. Entre le routeur CE et le PE, il s'agit de routage IP classique. Dans le cur du rseau, les donnes transitent dans des tunnels, qu'ils s'agissent de chemins LSP, ou ventuellement de tunnels IPsec. Pour cela, les ?E-ingress ralisent un empilement d'tiquettes : en premier lieu, ils ajoutent une tiquette dfinissant le VPN auquel le paquet appartient, puis une seconde

20

fiquette MPLS qui permet de diriger le paquet travers le rseau MPLS, en tant change chaque routeur P travers, jusqu'aux ?E-egress. Ces tiquettes sont enleves par ces demiers et les paquets sont transmis aux routeurs CE de destination comme de simples paquets IP, en foncfion de la valeur de l'tiquette VPN. Dans le cas du pemdtimate hop popping, c'est le demier routeur P travers avant le routeur 'PE-egress qui enlve l'tiquette MPLS. 1.2.4.3 L e plan de gestion

Le plan de gestion dcrit comment sont grs les lments du rseau. La gestion d'un rseau IP peut tre de type in-band (les donnes de gestion passent sur le rseau avec les autres donnes) ou out-of-band (hors-bande, la gestion s'effectue par un autre moyen, par exemple par le rseau tlphonique ou tout autre rseau indpendant). Dans le cas de la gestion in-band, il est important de prendre plusieurs mesures de scurit afin d'empcher toute possibilit d'intrusion et/ou de modification des informations de gestion. Il faut notamment limiter l'accs sur chaque routeur aux seules interfaces et adresses d'origine ncessaires (et encore, il est possible de mystifier une adresse IP), utiliser des protocoles scuriss comme SSH {Secure Shell) et une

authentification forte (certificats, jetons, cls), bloquer les donnes de gestion venant de l'extrieur au moyen par exemple de listes d'accs, les access lists des routeurs. En outre, le nud principal de gestion {NOC : Network Oper-ations Center-), s'il existe, doit tre fortement protg contre les intmsions afin d'viter qu'un utilisateur aux mauvaises intentions n'en prenne le contrle, et puisse par la suite grer les routeurs depuis cet emplacement.

La gestion des CE peut se rvler plus complexe mettre en uvre. Elle ncessite soit deux liens logiques sparant le trafic normal et de gestion entre CE et PE (ce qui reprsente la meilleure solution), soit l'utilisation d'une interface de loopback du CE

21

place dans le VRF de gestion du CE (auquel cas tout le VPN a accs la station de gestion). Il faut donc l aussi ufiliser des access-lists dans les interfaces ingress des routeurs PE.

Dans tous les cas, il ne faut pas oublier que les CE ne peuvent tre considrs comme srs puisqu'ils se trouvent chez les clients. La gestion out-ofband

est la base plus sre car elle n'est pas ralise sur le mme

rseau que celui o transitent les dormes. Toutefois, l'accs ce rseau de gesfion doit lui aussi tre scuris, par exemple par les mthodes nonces prcdemment. 1.2.5 L a sparation de s VPN

Les exigences relatives la scurit des VPN dans le rseau MPLS du foumisseur de service peuvent tre nonces ainsi : Le trafic provenant d'un VPN ne doit pas tre visible d'un autre VPN Le trafic issu du cur ou d'autres VPN ne doit pas pouvoir s'introduire dans un VPN donn.

En outre, la possibilit d'ufiliser des espaces d'adressage se chevauchant sans qu'il y ait confusion fait aussi partie des attentes. 1.2.5.1 Sparatio n de s espaces d'adressag e

La sparation des espaces d'adressage des diffrents VPN, ncessaire dans le cas o plusieurs VPN utilisent des plages d'adresses se chevauchant, est atteinte tel que dcrit dans la RFC4364 (Rosen et Rekhter, 2006) par l'utilisation des adresses VPN-IPv4 (ou v6, le cas chant - il faut noter que MPLS/VPN fonctionne indiffremment avec IPv4 ou IPv6).

"9

Les adresses VPN-IPv4 sont la concatnation d'une adresse IPv4 classique et d'un i-oute distinguisher sur 8 octets, tel que prsent ci-dessous :

8 byt e Rout e Dlslingutehor Type Administrator Assigned niumbe

4 byt o IPAddroo , Subscriber IPv 4 prefi x _^ Identifie s Ihe AN, asstgner by autnorfty

Identifies the assi^die d mjmber authorit y _^ Identifie s ihe :engtha f me octr MO neids [!E-L3VPN-WP1-Q6f

Figure 1. 4 Format d'une adresse VPN-IPv4 (Tir de Berkowitz, 2003) Les route distinguishers tant spcifiques chaque VPN, il est possible d'utiliser la mme plage d'adresse IP dans diffrents VPN sans que cela ne cause le moindre problme de chevauchement.

Les adresses VPN-IPv4 obtenues sont donc uniques, elles sont utilises dans le cur du rseau entre les PE pour raliser les routes VPN. Le cur utilise quant lui des adresses IPv4 classiques pour raliser le contrle. Il n'y a donc pas non plus possibilit de chevauchement entre les adresses des VPN et les adresses des lments du rseau cur.

L'interface PE-CE du PE ( ne pas confondre avec le lien PE-CE) utilise aussi l'adressage VPN-IPv4, donc mme au sein d'un routeur PE la sparation des VPN est oprante. Le seul inconvnient de ce dernier point est que cette interface du PE est joignable depuis le VPN concern et donc des attaques contre le PE pourraient tre tentes.

23

1.2.5.2 Sparatio

n d u trafi c

La sparation du trafic au sein du rseau MPLS cur est ralise par l'encapsulation des donnes dans les LSP {Label Switch Path). Cette encapsulation consiste ajouter aux donnes un entte dfinissant le VPN, en plus de l'entte MPLS classique.

Au niveau des routeurs PE, la sparation du trafic est accomplie en fonction des interfaces. Les interfaces faisant face au cur ralisent le routage, ou plutt, la commutation, en fonction de leur table de routage globale. Les paquets arrivant sur ces interfaces sont traits comme des paquets IP usuels. Les interfaces faisant face aux CE sont lies des VRF par l'intermdiaire de la commande ip vrf forwarding commutation est alors faite suivant l'instance de VRF. ; la

Les LSP ne sont pas le seul moyen d'encapsulation disponible : les tunnels IPSec, L2TPv3, IP/IP et GRE sont aussi ufilisables. Mais quelle que soit la mthode employe (simple marquage des paquets ou utilisation de tunnels), les VPN sont isols les uns des autres.

Un point important dans la scurit de MPLS/VPN au niveau de la sparation des VPN est que les routeurs P du cur n'interviennent pas du tout au niveau des VPN. Ils ne font que la commutation des paquets en fonction de l'tiquette MPLS et n'ont aucune visibilit sur le contenu des VPN. Ils n'ont aucune interacfion avec les VPN, donc un impact trs restreint quant la scurit du rseau.

Comme beaucoup d'autres, ce demier point n'est valable que si les routeurs P sont correctement configurs. La configurafion des quipements est un point extrmement important qu'il est possible de simplifier avec Tutilisafion d'oufils de configuration automatique.

24

1.3 Problmatiqu

Par une stratgie rendant possible l'accs Intemet pour tous et partout, le monde de l'informatique s'est retrouv compltement boulevers. La scurit, qui avait jusque-l une importance assez relative, est devenue primordiale. Les logiciels antivims, antiespiogiciels, les pare-feux, etc. sont devenus monnaie courante dans les entreprises comme chez les particuliers. La scurit est dsonnais au cur du dveloppement des nouvelles applications et technologies.

Les rseaux informatiques permettent aux donnes de se rendre de leur source leur destination. Le protocole IP est devenu, avec l'volution d'Internet, le plus utilis sur les rseaux, grce sa simplicit. Le protocole ATM offrait pour sa part une solution plus sre, plus efficace, mais aussi plus complexe. 11 est toujours utilis, mais principalement pour transporter des paquets IP, laissant de ct une grande partie de ses avantages.

La notion de rseaux privs virtuels n'est pas nouvelle. Depuis longtemps, les entreprises ont besoin de liens privs reliant par exemple leurs diffrentes succursales. La solution la plus vidente est celle d'une ligne loue, qui peut nanmoins se rvler trs dispendieuse. Les VPN ont t crs afin de permettre ces entreprises d'utiliser le rseau Intemet pour communiquer entre elles, en tablissant des tunnels dont chaque extrmit se trouve dans une succursale. Afin de garantir la confidentialit des donnes, tous les paquets IP sont chiffrs et encapsuls par des protocoles comme L2TP, PPTP {Point to Point Tunnelling Protocol) ou IPsec.

L'arrive de MPLS parmi les protocoles de communication a permis d'apporter la simplicit de la commutation dans les rseaux et aussi de proposer de nouvelles technologies comme l'ingnierie de trafic et les rseaux privs virtuels sur MPLS. Les VPN sur MPLS sont une volution des VPN classiques noncs prcdemment, les simplifiant fortement pour les clients. L'utilisation des VPN sur MPLS offre ces

25

demiers plusieurs avantages : la transparence (pas de client VPN installer ou de configuration raliser) et la perfonnance (pas de chiffrement donc moins de temps de calcul, plus de dbit ufile). Mais qu'en est-il de la scurit?

Selon Behringer et Morrow (Behringer et Morrow, 2005), une politique de scurit rseau qui se veut efficace se doit d'tre prvue ds l'tape de la conception de celui-ci. La cration d'un rseau et l'application de la scurit sur ce rseau sont souvent le fait d'quipes de travail spares. Aussi, l'ajout de la scurit implique habituellement de restreindre une partie des capacits du rseau, afin d'empcher les intmsions et de prvenir de possibles brches.

Un des dfis de l'expert en scurit est de s'assurer qu'aucune brche n'existe dans l'implmentation. Alors qu'un ingnieur rseau atteint son but lorsqu'il trouve une mthode fonctionnelle et performante pour implanter le rseau, l'expert en scurit subit un chec s'il existe ne serait-ce qu'une seule faille dans la scurit du rseau.

Avant de pouvoir dterminer ce qui est scuritaire et ce qui ne l'est pas, il est important de dfinir le sens du terme scurit et ce qui doit tre mis en uvre pour y parvenir. L'inconvnient est que selon le domaine, l'application, la valeur des biens ou de l'information protger, la rponse est trs variable. Par exemple, la scurit d'un aroport intemational diffre de celle d'un arodrome de tourisme. De mme, la scurit d'un site web bancaire n'est pas la mme que celle d'un blogue ralis par un particulier.

Pour beaucoup, la scurit implique le chiffrement des donnes. Il ne faut pas croire que MPLS n'est pas une technologie scuritaire parce que le chiffrement n'est pas ufilis par dfaut. Si la scurit consiste en l'isolement rciproque des rseaux privs virtuels, dans ce cas MPLS/VPN peut tre vu comme scuritaire.

Les objectifs de la scurit informatique applique aux rseaux sont dfinis par :

26

l'intgrit, qui garantit que les donnes ne sont pas altres dans leur transport, la confidentialit, qui assure que les donnes ne sont pas rvles des personnes non autorises, la disponibilit, garanfissant l'accs en tout temps aux donnes et l'absence de dni de service dans le rseau, rauthentification, qui permet de limiter l'accs aux personnes autorises, la non-rpudiation, qui empche de nier une opration ralise.

L'isolement des rseaux privs virtuels permet de remplir les objectifs d'intgrit et de confidentialit. La disponibilit et l'authentification doivent tre gres par le foumisseur de service, afin d'empcher tout dni de service ou intmsion. Enfin, la nonrpudiation est la charge du client, ce n'est pas en gnral un service offert par le foumisseur de service.

L'lment cl de ce projet de recherche est de dmontrer l'tanchit des diffrents tunnels VPN, garantissant que la sparation des VPN est toujours effective. Cela afin de garantir la scurit des donnes des clients.

La disponibilit du rseau MPLS cur est toutefois aussi importante, afin d'viter des attaques de type dni de service (DoS, Deny of Service). Cet aspect de la scurit conceme nanmoins plutt le foumisseur de service, car il en dcoule la disponibilit du rseau et non l'tanchit des VPN en place.

Ce mmoire se concentrera sur les VPN de niveau 3 sur MPLS, solution la plus couramment employe dans la ralit. Les VPLS ( Virtual Private LAN Service) et autres liens Pseudo-wire ne seront par contre pas traits. Par ailleurs, les problmes lis l'implmentation de l'architecture seront brivement cits mais non dtaills. Les bugs lis aux systmes d'exploitation des routeurs peuvent tre corrigs et sortent du cadre de ce mmoire.

CHAPITRE 2 ANALYSE DE LA SCURIT DE MPLS/VP N Tel qu'indiqu dans la problmatique, l'aspect important de la scurit pour ce projet est l'tanchit des VPN, et par consquent des VRF. Entre autres : aucun VPN ne doit pouvoir communiquer avec un autre VPN, aucun VPN ne doit pouvoir changer de l'information avec le cur du rseau.

Une autre faon de prsenter cette tanchit est de garantir que ce qui rentre dans le rseau MPLS par un VPN donn est forc de sortir du rseau MPLS par ce mme VPN.

Ce chapitre se propose d'analyser la scurit et les menaces sur les rseaux MPLS/VPN en considrant les diffrents lments constituant un rseau MPLS/VPN comme le rseau cur et les rseaux d'accs (les liens CE-PE par exemple) mais aussi en considrant les diffrents types de menaces, quelles que soient leurs origines et destinations.

Dans un premier temps, nous prsentons une tude assez exhaustive des menaces possibles dans un environnement rseau MPLS, ensuite nous verrons plus

spcifiquement la scurit des VPN sur MPLS en cherchant les vecteurs possibles d'attaques, en comparant avec les technologies prouves comme ATM/FR, et en dtaillant des architectures utilisant le rseau MPLS/VPN qui ncessitent beaucoup plus d'attention pour tre scuritaires. Une des conditions permettant la ralisation d'une attaque inter-VPN dans une de ces architectures avances a t le point de dpart d'une tude du protocole BGP, prsente dans le chapitre 3. Elle expose entre autres ses faiblesses ainsi que les extensions qui lui sont proposes.

28

2.1 Menace

s et attaques dans un environnement rsea u

Cette partie a pour but de prsenter une liste assez exhaustive des attaques ventuelles pouvant tre perptres dans un rseau MPLS. Tous les types d'attaques rseau ne sont donc pas abordes ici, comme par exemple celles relies aux environnements sans-fil et Web 2.0. 2.1.1 Catgorie s d e menaces

Avant de dresser une liste des attaques s'appliquant MPLS, il peut tre intressant de les regrouper pour les dfinir. Les attaques possibles sur un systme ou un rseau peuvent cet gard tre catgorises selon divers paramtres comme les dgts causs, leur complexit, ou leur but (Easttom, 2006).

En classant les attaques selon leur objectif, nous pouvons distinguer : les tentatives d'intmsion, permettant de gagner un accs aux ressources d'un systme, les dnis de service, bloquant l'accs au systme pour les utilisateurs lgitimes, les logiciels malveillants, comme les vims, les chevaux de Troie, les portes drobes, les espiogiciels, etc. permettant le vol d'information ou l'utilisation illgitime de ressources.

Les intmsions peuvent permettre l'intms de disposer d'informafions confidentielles, de modifier les paramtres du systme pntr son avantage, en bref de compromettre la scurit de ce systme et ventuellement celle des systmes attachs. Les intmsions utilisent gnralement les failles des systmes, bien que l'ingnierie sociale {social engineering), l'art de soutirer de l'information en abusant de la confiance des personnes, soit trs utile pour obtenir les informations manquantes.

29

Le dni de service fait partie des attaques de type bloquantes qui ne pennettent pas l'attaquant de pntrer le systme vis (hormis dans certains cas o la surcharge d'un quipement peut permettre de laisser passer tout le trafic par dfaut, par exemple avec certains anciens pare-feux), mais affaiblissent les ressources disponibles et par consquent entravent le fonctionnement normal de l'quipement. Les ufilisateurs lgitimes du systme vont alors se voir l'accs considrablement ralenti ou, idalement pour l'attaquant, refus. Ce type de menaces est en gnral bien plus simple mettre en uvre que les intmsions, c'est pourquoi les dnis de services sont trs rpandus. Les logiciels malveillants (de l'anglais malware, contraction des deux mots malicious et softwar-e) forment la catgorie de menaces la plus utilise. Mlange d'outils automatiques d'intmsion (les vers), de dclenchement (les bombes logiques) et d'action nfaste (les vims), ils peuvent souvent se rpliquer d'eux-mmes (vers, vims) pour se propager vers d'autres systmes. L'exemple de malware le plus connu est le virus, programme ayant pour but de se dupliquer et pouvant perturber le fonctionnement du systme infect. Il se rpand par diverses mthodes, les plus populaires tant l'envoi de courriels via le camet d'adresses d'une personne touche (car les utilisateurs ne se mfient que peu ou pas des courriels provenant de personnes connues), l'change de donnes (en particulier sur les rseaux d'change P2P, Peer to Peer), les logiciels de messagerie instantane (en utilisant les listes de contacts), ou en surfant sur certains sites web malveillants. Souvent, ils utilisent les failles de certains programmes, fureteurs Intemet ou systmes d'exploitation pour agir.

Parmi les autres logiciels malveillants se trouvent les chevaux de Troie qui appliquent le principe d'une porte drobe pour s'installer sur le systme, et qui vont ensuite tlcharger eux-mmes des vims ou ouvrir d'autres portes drobes, permettant de futures intmsions.

30

Les espiogiciels reprsentent la demire mode en termes de logiciels malveillants. Plus connus sous leur terme anglophone de spvwai-es, ils surveillent les acfions effectues sur un systme. Ils peuvent se limiter un fichier tmoin {cookie) du fureteur, celui-ci tant un fichier texte pourtant cr avec la noble cause de se souvenir de l'utilisateur pour lui permettre d'acclrer la reconnexion un site web dj visit o il aura enregistr des informations personnelles, un panier d'achat, etc. Le problme est que n'importe quel site peut venir lire ces fichiers et ainsi rvler de nombreuses informations confidentielles si le fureteur ne l'en empche pas. Un autre type d'espiogiciel est l'enregistreur de fr^appe {keylogger), il enregistre tout ce qui est tap par l'utilisateur du systme infect et peut aussi prendre rgulirement des captures d'cran, le tout tant soit envoy par courriel ou relev par celui l'ayant conu et/ou install.

La catgorie des logiciels malveillants volue de plus en plus vite, le nombre de vims, vers, espiogiciels incluant leurs variantes ne cessant d'augmenter. Les logiciels malveillants permettent parfois des attaques qui se rapprochent des deux premires catgories de menaces, permettant intmsions via les portes drobes et dnis de service via les bombes logiques. Dans ce demier cas, un vims tant hberg sur de trs nombreux systmes de par le monde va lancer un moment prvu l'avance une attaque simultane vers un site, une adresse ou un systme dans le but de le faire tomber. L'attaque est parfois impossible prvoir, et cause de la rpartition des machines zombies possdant la bombe logique, difficile arrter.

Enfin, en ce qui conceme l'environnement d'excution, les logiciels malveillants visent surtout le systme d'exploitation le plus ufilis, Windows XP/2000/Vista, prsent sur les stations de travail ou sur les serveurs, mais pas sur les quipements rseaux. Ces demiers sont donc moins touchs par cette catgorie de menaces. Par contre, rien n'empche un vims, un ver ou un cheval de Troie de s'installer sur une machine hte mal protge chez un client avant de s'attaquer aux quipements rseaux auxquels celui-ci est reli.

31

2.1.2 Type

s d'attaque s

Aprs avoir tudi les diffrentes catgories de menaces possibles, cette partie prsente les diffrents types d'attaques possibles dans un environnement rseau. 2.1.2.1 cout e sur le rseau

L'coute sur le rseau est une attaque passive permettant d'obtenir des informations (tels des mots de passe) pouvant tre rutilises dans le futur pour raliser des accs non autoriss. L'coute peut se faire grce un renifleur {sniffer), logiciel ou matriel plac dans le rseau. La prsence d'un concentrateur {hub) dans le rseau rend cette attaque trs simple, cause du fonctiormement duplicatif du concentrateur qui offre l'information toutes les stafions qui lui sont connectes. L'attaque est par contre beaucoup plus dlicate mettre en uvre si le mdium est de la fibre optique, mais pas impossible (Everett, 2007).

L'attaquant doit possder un accs au mdium pour pouvoir couter ce qui y transite. Si l'accs est physiquement impossible, l'installation de logiciels malveillants sur le poste d'une personne l'intrieur peut tre une solution de rechange. Il suffit alors d'un courriel contamin envoy de multiples employs pour tre quasiment certain que le programme malveillant (ver, cheval de Troie) soit install en un point sensible et puisse alors renifler le trafic sur le rseau.

La meilleure parade l'coute sur le rseau est le chiffrement de tout le trafic qui passe sur celui-ci, ce qui est rarement faisable grande chelle. L'utilisation de SSH et de tunnels VPN permet aussi de rduire le risque. De mme, les concentrateurs devraient tous tre bannis et remplacs par des commutateurs, qui ne partagent pas l'information. noter qu'en 2000 un outil pouvant dtecter les stafions coutant sur le rseau (de par leur mode promiscuit actif) nomm AntiSniff a fait son apparifion. Mais hlas, ses

32

mthodes de dtection des renifleurs ont t utilises par la suite pour rendre ces demiers indtectables. Une attaque passive reste donc difficile dtecter. 2.1.2.2 Modificatio n d e donnes

Si l'coute n'tait qu'une attaque passive, la modification de donnes va plus loin et constitue une attaque active : l'attaquant va modifier certaines donnes qu'il parvient lire sur le rseau et ainsi, en plus de briser la confidenfialit, changer le sens du contenu des paquets. Mme si la confidenfialit n'est pas toujours primordiale, les donnes ne doivent pas tre modifies dans leur transmission : l'intgrit des donnes est essentielle quel que soit le domaine.

L'utilisation de chiffrement ou, si la confidentialit n'est pas requise, de signatures numriques l'aide de systmes de chiffrement asymtrique ou asymtrique peut permettre de garantir cette intgrit. 2.1.2.3 Mystificatio n dan s la pile protocolaire TCP/I P

La mystification est l'action de bemer, d'abuser une personne en dformant la ralit. Applique aux rseaux, elle consiste tromper un systme (un pare-feu par exemple) en se faisant passer pour une autre entit que celle qui a rellement envoy le message. Les diffrents paramtres pouvant tre mystifis se situent principalement dans les enttes ajouts par les couches liaison, rseau et transport : les adresses MAC et IP sources, les numros de squence TCP {Transmission Control Protocol), etc.

La mystification d'adresse MAC permet des attaques de niveau 2 au sein d'un rseau local, d'outrepasser les filtres d'adresses physiques autorises dans un rseau sans-fil, de rediriger le trafic, etc. L'adresse physique ou adresse MAC est pourtant une donne inscrite sur la carte d'accs rseau, unique dans le monde, hlas il est dsormais possible

33

sur de nombreux modles de modifier manuellement l'adresse de sa propre carte rseau. Un filtre bas sur des adresses physiques n'est donc pas sr.

La mysfificafion d'adresses IP ressemble celle d'adresses MAC, tout en agissant la couche rseau. Elle profite des systmes utilisant l'adresse IP source comme base d'authentification, comme les filtres ou les listes d'accs des routeurs, les pare-feux, etc. 11 suffit de deviner une adresse IP autorise puis de la mystifier afin de traverser ces filtres sans tre arrter. Toutefois, dans le cas o les seules adresses autorises sont celles appartenant au rseau local, le filtrage d'adresses sera efficace en bloquant les paquets provenant de l'extrieur portant une adresse source locale.

Au niveau de la couche transport, il est possible de mystifier les numros de squences TCP. Le protocole TCP permet d'tablir une connexion entre deux systmes, cette connexion est identifie par des numros de squences qui permettent de raliser du contrle de congestion et de dtecter les pertes de paquets. Les numros de squence voluent au cours d'une communication en fonction de la quantit de donnes changes. Un intms coutant une transmission TCP va alors pouvoir y injecter des paquets en prvoyant le numro de squence suivant correctement et ventuellement en prendre le contrle. Cette technique est aussi appele vol de session . Il est aussi possible de prdire les numros de squences mme si ceux-ci sont initialiss alatoirement, cause du caractre peu alatoire des gnrateurs de nombres alatoires sur les systmes informatiques (Venema, 1996).

Les attaques par mystification diffrents niveaux de la pile protocolaire TCP/IP sont rendues possibles par la relation de confiance que deux systmes tablissent simplement en se basant sur les informations contenues dans les diffrents enttes de la pile TCP/IP.

34

La mystification est aussi possible la couche application, mthode trs utilise par exemple par les metteurs de pourriels pour masquer leur identit en indiquant comme adresse source une adresse de courriel alatoire les empchant d'tre trouvs.

La

protection

contre

la mystification

serait

le

chiffrement

des

enttes

et

r authentification, techniques aisment ralisables la couche application, plus difficilement applicables aujourd'hui pour les autres couches (liaison, rseau, transport) cependant. Le chiffrement des enttes pose en effet le problme suivant : si ceux-ci sont chiffrs, comment les quipements rseaux peuvent-ils acheminer les paquets

correctement?

IPv6 propose pourtant ces techniques, chiffrement et authentification de la charge utile de bout en bout, de la charge utile et de l'entte en mode tunnel entre deux passerelles. Dans le premier mode, la scurit repose sur le fait que mystifier une adresse source n'est pas suffisant pour que le paquet soit accept la destination. Si le contenu n'est pas authentifi correctement, le paquet sera rejet mme si l'adresse source semble valide. Donc IPv6 offre une solution valide contre la mystification la couche rseau.

Toutefois, l'utilisation de ces techniques dans IPv6 prsente des problmes de compatibilit avec les quipements rseaux (McGehee, 2003). Plusieurs fonctionnalits rseaux comme la traduction d'adresses (NAT, Network Address Translation) et le filtrage des pare-feux, la qualit de service, le changement dynamique d'adresses pour les applications mobiles, etc. ne fonctionnent pas avec IPsec et par consquent avec IPv6 lorsqu'il utilise IPsec. 2.1.2.4 Attaqu e Man in the middle

Une attaque de type Man in the middle se produit lorsque l'intms se trouve sur le rseau entre deux utilisateurs lgitimes, coute le trafic circulant entre eux et peut l'intercepter

35

et le modifier sans que ceux-ci ne le remarquent. En quelque sorte, l'intrus se fait passer pour chacun des utilisateurs lorsqu'il converse avec l'autre.

Une des mthodes pennettant ce type d'attaque est la mystification de serveur DNS {Domain Name Ser-\'er), qui va indiquer une fausse adresse du serveur auquel le client souhaite se connecter, le renvoyant vers un systme contrl par l'attaquant qui acheminera les paquets vers le rel serveur une fois ceux-ci lus afin que le client ne se rende compte de rien. Celui-ci va alors ventuellement donner des informations persormelles comme ses mots de passe, numros de cartes de crdit, etc.

Il est aussi possible l'attaquant de profiter des erreurs defi-appede l'utilisateur qui crit mal l'adresse URL {Uniform Ressource Locator) du serveur en crant des serveurs ayant des URL trs proches phontiquement ou orthographiquement du serveur lgitime. Un exemple : taper www.goggle.com au lieu de www.google.com redirige vers un site qui n'a aucun rapport avec Google. Ce n'est pas le cas ici, mais si ce site (profitant de la clbrit de Googlel) redirigeait les paquets vers le vrai Google, tout en lisant les informations entres par l'utilisateur, il pourrait enregistrer de nombreuses informations personnelles...

Le chiffrement des messages changs peut empcher l'intms de comprendre la signification de ces demiers. Mais ce demier peut toujours les supprimer, n'empchant donc pas le dni de service, ou tre plus fin et raliser des attaques de rejeu.

Une attaque de rejeu consiste couter un message qui passe et le rpter ultrieurement. Il n'est pas ncessaire l'attaquant d'en comprendre la signification c'est--dire de le dchiffrer. Le cas le plus courant est l'idenfification d'un client envoyant son nom d'utilisateur et son mot de passe, le tout tant chiffr. Si l'attaquant souhaite se connecter au mme service, il lui suffit de rpter le mme message, et il sera authentifi.

36

Pour empcher le rejeu, il est ncessaire que les protocoles de chiffrement utilisent des challenges ou des cls de session qui diffrent chaque fois, tenant ventuellement compte du temps. 2.1.2.5 Dn i de service

Le but du dni de service est d'affaiblir ou de rendre inoprable un systme ou un rseau. Il se base sur le fait que les ressources d'un systme sont limites physiquement. S'il est surcharg, il ne pourra plus rpondre aux requtes normales. L'attaquant ne peut acqurir aucun accs ou information mais empche les utilisateurs lgitimes d'accder aux ressources vises par l'attaque. Il ne lui est toutefois pas pos.sible de briser l'tanchit des tables de labels ou de s'introduire dans un VPN de cette faon. Trs rpandu car simple effectuer, le dni de service peut se raliser de diffrentes faons.

L'inondation de messages TCP SYN est une attaque de dni de service qui utilise l'tablissement de connexion dans TCP (aussi appel three-way handshake). Le systme source inonde la cible de messages SYN en indiquant une adresse source inexistante, de sorte qu'il n'en reoive pas les rponses. Celle-ci se retrouve alors avec un grand nombre de connexions dans un tat semi-ouvert, jusqu' ce qu'elle ne puisse plus accepter de nouvelles connexions, mmes lgitimes.

SYN

f =

W^ ^

y/ SYN-AC

Systme sourc e

- ^

Sys tme cible

Figure 2.1 Inondation de messages TCP SYN

37

La Figure 2.1 illustre cette inondation. Nous pouvons y voir que les messages SYNACK ne sont pas renvoys vers la source mais dans une autre direction, d'ailleurs il n'est pas ncessaire que la fausse adresse source spcifie existe. La raison du dni de service est que les systmes ne peuvent grer plus d'un certain nombre de connexions TCP simultanment. Pour empcher que cette inondation ne soit destmctrice, des temporisateurs courts doivent tre utiliss afin de fermer rapidement les connexions semi-ouvertes.

Il existe d'autres techniques permettant d'empcher une perte trop importante de mmoire due ces inondations, comme les micro blocs, qui permettent d'allouer de la mmoire par micro fragments chaque nouvelle connexion TCP SYN, ou les tmoins S'YN, qui permettent de n'allouer la mmoire qu'une fois que le client envoie le message ACK final grce l'utilisation de tmoins {cookies) lors du renvoi du message SYNACK comprenant les informations du client ayant envoy un message SYN. Il est aussi possible d'ufiliser des tmoins autrement (Chau, 2004) : la rcepfion d'un message SYN, le serveur envoie un message SYN-ACK erron au client. Ce demier, s'il est lgitime, va envoyer un message de rinitialisation de connexion (RST). Si le serveur le reoit, il sait que ce client est sr et acceptera les requtes S'YN suivantes du mme client. Pour se souvenir des clients, des tmoins sont utiliss. Cette mthode est plus simple implmenter que la prcdente, mais fait perdre du temps pour tablir la connexion (six messages doivent tre changs au lieu de trois).

L'inondafion existe aussi pour des paquets UDP. Si un paquet UDP est dirig vers un port non utilis par exemple, le systme cible va rpondre par un message d'erreur ICMP. Si un grand nombre de messages UDP sont envoys, il est possible que le systme soit dpass.

38

L'attaque de smurf (d'aprs le nom du code source utilis pour lancer cette attaque) consiste envoyer un paquet ICMP l'adresse br-oadcast d'un rseau, en mystifiant l'adresse source du paquet pour y placer l'adresse de la machine cible de l'attaque. Toutes les stations du rseau recevant le message ICMP ping request vont en gnral rpondre la machine cible et si cette attaque est rpte de nombreuses fois, la machine cible va tre surcharge par la rception de messages ICMP ping reply en provenance d'autres stations de son propre rseau. La seule difficult de cette attaque est d'envoyer les paquets ICMP dans le rseau si un filtrage appropri est utilis en bordure, il est toutefois possible d'y parvenir par l'intermdiaire d'un cheval de Troie. Les pourriels (ou spam) sont d'un ct un agacement pour les utilisateurs qui les reoivent mais peuvent aussi consister en un dni de service pour les serveurs de relais de courriels s'ils sont trs nombreux. Une inondation d'un serveur de relais par des milliers de pourriels peut empcher celui-ci de dlivrer les courriels lgitimes convenablement, ou le ralentir fortement. Le dni de service peut aussi s'appliquer aux utilisateurs qui perdent du temps faire le tri entre les courriels lgitimes et les pourriels. Ces demiers peuvent aussi en ayant recours une adresse de courriel d'origine mystifie (rien n'tant plus facile que de modifier une adresse de courriel source) permettre de lancer une attaque dtoume vers une cible dont l'adresse courriel est celle apparaissant comme prtendue source tous ceux ayant reu les pourriels. Afin de limiter la gne due aux pourriels, des filtres de courriels entrants peuvent tre exploits, mais ne sont pas efficaces 100%, en outre pour viter que les adresses courriels sources soient mystifies, tous les fournisseurs d'accs devraient vrifier que leurs utilisateurs emploient bien leur propre adresse comme adresse source.

La puissance d'une attaque de dni de service repose dans le nombre de machines participant l'attaque. Plus l'attaque est distribue, plus elle est puissante et ventuellement difficile stopper. Les bombes logiques sont un trs bon moyen d'accomplir une attaque distribue. Lies un vims, elles vont se placer dans de

39

nombreux systmes en attendant le moment prprogramm pour lancer l'attaque de dni de service, toutes simultanment. 2.1.2.6 Sca n de ports

Habituellement ce genre d'attaque prcde une intrusion : l'attaquant cherche sur le systme cible, par exemple le routeur PE, les ports ouverts, comme le port 80 (web), 23 (telnet), 22 (SSH), 21 (ftp), etc., reprsentant autant de portes d'entre permettant d'tablir une communication avec la cible. Certaines des applications rsidant derrire les ports ouverts possdent des failles connues qui peuvent tre exploites pour parvenir gagner l'accs au systme vis. Le scan de port peut tre ralis grande chelle avec des scripts automatiss, la recherche de systmes attaquables car non suffisamment protgs. Tous les ports non ncessaires doivent tre ferms, dans le cas de l'interface CE d'un routeur PE seuls les ports utiliss par les protocoles de routage devraient tre ouverts, avec des restrictions sur les listes d'accs vis--vis de l'metteur des mises jour de routage. Le port d'accs au mode console (telnet ou SSH) devrait tre limit la seule interface de configuration, distincte des interfaces CE/PE/P qui font transiter le trafic de donnes.

Il existe de nombreuses techniques de scan. La principale consiste ouvrir une connexion TCP en envoyant un message S'YN vers un port donn. Si le port est ouvert, la cible enverra un message SYN-ACK, s'il est ferm elle enverra un message RST. S'il est filtr (par un pare-feu par exemple), rien ne sera envoy. L'attaquant peut donc savoir quels ports sont ouverts, filtrs ou ferms. D'autres techniques se servent des drapeaux de l'entte TCP pour envoyer des messages Null (aucun drapeau), FIN ou XMas (FfN, PSH, URG). L'attaquant saura dans ce cas que le port est ferm s'il reoit un message RST, filtr s'il reoit un message ICMP de type 3 unr-eachable, et finalement, ouvert si aucune rponse n'est reue.

40

L'inconvnient d'un scan de ports pour l'attaquant est qu'il laisse des traces. Les systmes de dtection d'intmsion (IDS, Intrusion Dtection System) reconnaissent les scans de port et peuvent en avertir les administrateurs rseaux. Le problme est que les programmes de scan comme nmap peuvent cependant tre assez discrets pour ne pas se faire remarquer, en initiant des connexions TCP exploitant uniquement le premier message SYN (technique appele SYN scan), puis en envoyant un message RST si un message SYN-ACK revient. Ces comiexions non compltes ne sont pas inscrites dans les joumaux d'vnements des IDS. L'ufilisation de pare-feux mmoire d'tat {stateful), ne laissant que le trafic essentiel passer, est ncessaire.

2.1.2.7

Accs non autoris

Si un attaquant parvient dterminer l'aide d'un scan de port qu'une application (par exemple, un serveur FTP) fonctionne, l'tape suivante va consister en gagner l'accs. Habituellement, l'accs aux services travers le rseau s'effectue l'aide du couple nom d'utilisateur et mot de passe. L'inconvnient de ce systme (sans parler du fait que trop souvent ces informations d'identification sont transmises de faon non chiffre) est la faiblesse humaine. Comme tout utilisateur doit se souvenir d'un grand nombre de mots de passe pour diffrentes applications (comptes de courriels, connexion aux nombreux sites requrant une identification, etc.) il a tendance recourir des mots de passe faciles mmoriser. L o le bt blesse, c'est que plus un mot de passe est facile mmoriser, plus il est facile de le casser. C'est donc un rel problme tant donn la croissance du nombre de mots de passe qu'il faut retenir. Il n'est pas possible d'augmenter la mmoire d'un tre humain comme celle d'un ordinateur, notre cerveau possde ses limites. Une fois que l'attaquant possde le mot de passe d'un ufilisateur, il a libre accs aux ressources offertes l'utilisateur. Cela est encore pire pour la biomtrie car si notre empreinte est duplique, il est impossible d'en changer...

41

La mthode d'identification classique nom et mot de passe est insuffisante, non pas cause de son fonctionnement, fiable si chiffr, mais cause des tres humains. Il est donc ncessaire de ne pas se limiter cette identificafion pour les services sensibles. L'authentification, qui permet en plus de s'assurer que la personne est bien celle qu'elle prtend tre, devrait tre utilise. Par exemple, les jetons lectroniques (le plus connu tant RSA) associs un mot de passe reprsentent une technique d'authentification forte, dans laquelle l'utilisateur doit non seulement donner une information que lui seul connat, et la valeur du jeton (quelque chose qu'il possde) qui change chaque minute. Une autre possibilit d'authentification forte est la combinaison de la biomtrie (qui se sert d'une caractristique physique de l'utilisateur) avec un mot de passe ou avec un jeton lectronique. Il est toutefois difficile aujourd'hui d'envisager de l'authentification forte pour toute application, particulirement dans un cadre personnel non-commercial (serveurs de courriels, fomms de discussion). L'authenfificafion forte a un prix, et ncessite une gestion supplmentaire. Si l'information protger est d'une importance moindre, l'identification simple par mot de passe peut finalement tre suffisante. 2.1.2.8 Attaque s sur les mots de passe des routeurs

L'identification par mots de passe peut tre scuritaire si elle est chiffi-e et que les mots de passe sont labors (c'est--dire qui emploient les diffrents caractres du clavier, lettres, chiffres et symboles). L'emploi de mots de passe plus courts n'utilisant que des lettres ou des chiffres peuvent tre casss de plus en plus aisment, et remettent en cause la valeur de l'identification.

Les attaques par dictionnaire consistent essayer une liste de mots possibles, compose des mots usuels (noms communs, prnoms, etc.), utilisant ventuellement quelques rgles complmentaires comme la variation de la casse des mots, la rptition des mots, l'ajout d'un chiffre la fin d'un mot, etc. Pour augmenter les chances de trouver le mot de passe, il peut tre ncessaire de faire quelques recherches sur la personne ayant cr

42

le mot de passe. Par exemple, utiliser un dicfionnaire dans une langue plutt qu'une autre selon la nationalit de la personne, les dates de naissance des diffrents membres de la famille, etc.

Les attaques par force bmte sont diffrentes. Elles utilisent toutes les combinaisons possibles de caractres afin de trouver le mot de passe. Trs efficaces si le mot de passe est constitu d'un nombre raisonnable de caractres (moins de huit), elles peuvent ncessiter un temps de calcul trs important si le mot de passe est long. Par exemple, il
1 ''

existe 5,4.10 " mots de passe diffrents utilisant uniquement neuf lettres minuscules. Un ordinateur tant capable de tester jusqu' quelques millions de mots de passe la seconde, il faut en thorie jusqu' 10^ secondes (presque 12 jours) pour tester toutes les possibilits, ce qui est dj beaucoup malgr le peu de caractres utiliss (les 26 lettres minuscules). Par contraste, il ne faut qu'une centaine de secondes pour tester toutes les possibilits de mots de passe de six lettres minuscules. D'o l'importance d'utiliser des mots de passe longs et utilisant tout type de caractres. Afin d'empcher un attaquant de deviner le mot de passe d'un utilisateur, il faut absolument restreindre le nombre d'essais autoriss. Au-del d'un certain nombre d'essais errons, le compte doit tre bloqu. De nombreux sites Intemet comme ceux des banques offrent cette possibilit, mais ce n'est pas toujours le cas : la plupart des autres sites web, les comptes utilisateurs dans Windows (par dfaut), etc. ne sont pas limits en nombre d'essais errons. Il est alors possible, surtout si le mot de passe est faible, de le casser dans un temps raisonnable. Des pratiques similaires, c'est--dire la restriction du nombre d'essais et l'utilisation de mots de passe complexes, devraient tre ralises pour empcher les attaques par dictionnaire ou par force bmte sur l'interface de console des routeurs, si celle-ci est accessible.

43

2.1.2.9 Attaque

s sur cls de chiffremen t

Au lieu de deviner un mot de passe pour se connecter un compte donn, il peut tre intressant un attaquant de deviner une cl de chiffrement afin d'avoir accs des informations confidentielles. Il existe deux types de chiffrement, soit symtrique et asymtrique.

La cryptographie symtrique consiste ufiliser une mme cl pour le chiffrement et le dchiffirement. Son avantage est la rapidit de chiffrement due la petite taille des cls, son inconvnient est la communication de la cl la tierce partie, habituellement ralise en utilisant la cryptographie asymtrique. Les algorithmes les plus courants sont DES {Data Encryption Standard), 3DES {Triple DES), AES {Advanced Encryption Standard). Si l'attaquant parvient obtenir la cl de chiffrement, il peut alors prendre connaissance de tout message chiffr.

La cryptographie asymtrique est diffrente : elle utilise le principe de cl publique et cl prive, la premire tant donne tous et sert chiffrer les donnes alors que la seconde n'est connue que d'une seule personne et permet de les dchiffrer. Plus lente que la cryptographie symtrique, elle est par contre plus simple utiliser, aucun change secret de cl n'tant ncessaire. L'algorithme le plus connu est RSA {River, Shamir, Adleman, du nom des inventeurs). La ncessit d'utiliser de longues cls vient du fait que les cls sont gnres mathmatiquement et non alatoirement. La robustesse des algorithmes de cryptographie asymtrique vient de la difficult factoriser de trs grands nombres. De plus, la longueur de la cl est telle qu'il est impossible de procder par force bmte.

Les algorithmes de cryptographie symtrique et asymtrique sont l'preuve d'un attaquant puisqu'ils imposent une taille minimale de cl garanfissant la scurit (aujourd'hui respecfivement de l'ordre de 128 et 2048 bits). Les seules attaques

44

possibles visent la cryptographie symtrique au niveau de l'change de la cl unique, lequel doit tre ralis avec soin ; pour la cryptographie asymtrique des attaques de type Man in the Middle. Des infrastmctures de gestion de cls (PKI, Public Key Infrastructure) doivent tre employes pour tre sr de faire usage de la bonne cl et de ne pas se laisser bemer par un intms. 2.1.2.10 Attaque s utilisan t l'ingnierie social e Les attaques sur un rseau ne s'effectuent pas uniquement par l'exploitation de failles ou d'erreurs de conception. L'tre humain est parfois bien malgr lui un participant actif l'attaque, grce aux droits qu'il possde et que l'attaquant n'a pas. L'ingnierie sociale permet d'obtenir de l'information telle le mot de passe d'un routeur PE ou de lancer directement des attaques depuis l'intrieur.

L'ingnierie sociale regroupe les diffrentes mthodes qu'un attaquant utilise pour soutirer de l'information un ufilisateur lgitime, comme son nom d'utilisateur et son mot de passe. Il existe une multitude de faons de bemer ce demier : l'attaquant peut se faire passer pour l'administrateur rseau et demander directement le mot de passe de l'utilisateur en prtextant une urgence, pntrer dans les locaux de l'entreprise en se faisant passer pour un consultant et se faire ainsi ouvrir la porte par un employ peu scmpuleux (ce qui permet de rechercher des informations l'intrieur, fouiller dans les corbeilles, etc.), appeler le comptoir d'assistance aux utilisateurs et indiquer l'oubli de son mot de passe pour en obtenir un nouveau, regarder au dessus de l'paule d'un employ ou espionner avec des jumelles, etc.

Le plus surprenant est que la plupart des attaques d'ingnierie sociale fonctionnent avec de nombreux employs. Des politiques strictes de scurit dans l'entreprise doivent tre appliques, interdisant par exemple de rvler son mot de passe, mme aux administrateurs rseaux, d'ouvrir la porte des inconnus mme lorsque ceux-ci semblent

45

soigns et peu suspects, etc. Car l'ingnierie sociale utilise justement le fait qu'un individu moyen se mfierait beaucoup plus d'une personne mal habille qui ne semblerait pas avoir de rapport avec l'entreprise que d'une personne trs bien habille et sympathique qu'il va chercher aider - c'est la nature humaine. Le plus connu des pirates en ingnierie sociale se prnomme Kevin Mitnick. Celui-ci a crit plusieurs livres, dont L 'art de la supercherie, relatant de nombreuses techniques d'ingnierie sociale (Mitnick et Simon, 2002). 2.1.2.11 Remis e en cause du modle TCP/IP Chaque couche du modle TCP/IP peut tre sujette attaque. Les paragraphes prcdents prsentaient des attaques concemant le mdium physique, la couche liaison de donnes, la couche rseau, la couche transport et la couche application. Le principe des modles en couches, qu'il s'agisse du modle OSI ou du modle TCP/IP, est de donner un rle et des fonctions indpendants chaque couche. Par exemple, la couche physique s'occupe de transmettre les bits sur le rseau (optique, cuivre, sans-fil, etc.), la couche rseau permet entre autres l'adressage logique, la dtermination d'un chemin et l'acheminement des paquets, et ainsi de suite. Chaque couche N tablit une communication avec les couches adjacentes N-1 et N+1 dans le but de pouvoir communiquer avec la couche N d'un systme distant.

Si au niveau fonctionnel le tout est correct, il n'en va pas de mme en ce qui conceme l'aspect scuritaire du modle en couches. Les protocoles des diffrentes couches ne se proccupent pas de savoir si les donnes reues des couches infrieures sont valides ou non, en fait, elles ont confiance en supposant que les couches infrieures sont sres.

Lorsqu'une attaque se produit une couche basse (physique, liaison, rseau), les couches suprieures vont en subir les effets car ces demires n'intgrent pas par dfaut de mcanisme permettant de vrifier l'intgrit des donnes. La couche application

46

devrait le plus souvent possible employer des protocoles de chiffrement d'authentification lorsque les donnes sont sensibles.

et

Le travail de scurit doit toutefois s'effectuer tous les niveaux. Paralllement au modle de rseau OSI, il existe un modle d'architecture de scurit OSI (ISO 7498-2), qui dcrit les requis permettant de garantir la scurit d'un systme d'information : authentification, contrle d'accs, non rpudiation, intgrit des donnes, confidentialit, disponibilit et signatures lectroniques. 2.1.3 Bila n

En dressant un bilan, il existe un grand nombre d'attaques qui peuvent tre portes sur un rseau MPLS. Afin de pouvoir attaquer l'intgrit des tables, il est ncessaire d'attaquer en premier lieu le routeur PE, entre du rseau MPLS. Plusieurs mthodes permettent y parvenir, de l'coute l'ingnierie sociale, du scan de port la recherche des mots de passe.

Les vulnrabilits permettant les attaques prsentes peuvent tre classes en trois types, selon leur origine (Canavan, 2001) : mauvaise conception des systmes ou des logiciels, mauvaise implmentation des systmes, configuration errone, mauvaise gestion des quipements, pitre dfinition des rles et des procdures.

Ces trois types de vulnrabilits correspondent aux diffrentes phases du cycle de vie d'un systme ou d'un programme : sa conception, durant laquelle des brches peuvent tre cres et ouvrir des portes drobes, par exemple ; son implmentation par un constmcteur suivant maladroitement la norme ; sa configuration par l'administrateur rseau laissant les mots de passe par dfaut ou donnant trop de droits certains utilisateurs ; sa maintenance en oubliant de raliser des audits de scurit, en ne

47

changeant pas les mots de passe rgulirement ou en ne dfinissant pas les responsabilits de chacun.

La scurit est un tout, qui doit tre appliqu chaque phase du cycle de vie. Des audits doivent permettre de contrler que les procdures de scurit sont cohrentes, des analyses de risques quantitatives et qualitatives peuvent aider dterminer ce qui doit tre protg prioritairement de ce qui est moins important, dterminant un plan architectural des investissements raliser pour la scurit (Panko, 2004).

La dfense en profondeur est le premier principe de conception d'une architecture de scurit. Il doit y avoir plusieurs niveaux de dfense, permettant de limiter l'impact d'une faille sur une couche dfensive, et laissant le temps de ragir lorsqu'une intmsion est dtecte. Un autre principe est d'assurer une diversit des foumisseurs de solutions de scurit. Chaque foumisseur ayant ses forces et ses faiblesses, combiner des produits de diffrents foumisseurs permet de joindre leurs forces et de rduire leurs faiblesses respectives. L'utilisation de pare-feux et de dtecteurs d'intmsion est ncessaire pour raliser une dfense en profondeur.

Afin de simplifier la mise en place de la scurit, des standards sont disponibles. Les Critres Communs (ISO/CEI 15408), bass sur trois anciens standards europen (ITSEC, Information Technology Security Evaluation Criteria), canadien (CTCPEC, Canadian Trusted Computer Product Evaluation Criteria) et amricain (TCSEC, Trusted Computer System Evaluation Criteria) - aussi connu sous le nom du livre orange. Ils peuvent, en association avec des autorits en scurit tel le CERT, aider concevoir une architecture scuritaire, dterminer le niveau de scurit atteint et se tenir au courant des nouvelles vulnrabilits.

48

2.2 Analys

e d e la scurit des VPN sur MPLS

La possibilit de crer des rseaux privs virtuels sur MPLS performants a t rendue possible par la simplicit de leur conception : la notion de routeurs virtuels, la comiectivit de chaque VPN l'aide d'imports/exports de routes, l'absence de chiffrement des donnes.

Afin de vrifier que l'architecture des VPN sur MPLS ainsi que son implmentation sont correctes, plusieurs analyses ont t ralises par des experts en scurit. La RFC4381 (Behringer, 2006) ralise une analyse de la scurit des VPN utilisant BGP/MPLS, principalement au niveau architectural, considrant toutefois aussi leur implmentation et leur fonctionnement. Elle suppose que le rseau MPLS est sr parce que bien configur et qu'il est normal de faire confiance au foumisseur de service administrant ce rseau. Ce n'est pas une gageure, car il en va de mme pour les rseaux ATM/FR que tout le monde prtend scuritaires.

Le principe de base de scurit est que le trafic d'un VPN ne doit jamais pouvoir entrer dans un autre VPN. Le cur doit quant lui tre invisible du monde extrieur comme c'est le cas pour les architectures de niveau 2 quivalentes comme ATM/FR.

Cette partie analyse les diffrents vecteurs d'attaques sur le rseau MPLS. Elle considre les types d'attaques noncs dans la partie 2.1.2 s'appliquant aux VPN sur MPLS. Les failles applicatives telles que les bugs du systme d'exploitation des routeurs sortent du cadre de cette tude, parce que d'une part il n'est pas possible d'accder au code du systme d'exploitation des routeurs pour l'analyser, et d'autre part, des bugs dans une implmentation peuvent tre colmats par une rustine contrairement des erreurs de conception qui ncessitent une mise jour majeure.

49

2.2.1 Un

e attaque directe impossibl e

Une attaque directe consisterait injecter des paquets partir d'un VPN dans le rseau, qui pourraient s'introduire dans un autre VPN par une faille de l'architecture ou de l'implmentafion de MPLS.

BGP perniet aux VPN dans MPLS d'utiliser des espaces d'adressage se chevauchant, ceci grce aux route distinguishers dfinis dans le chapitre 1. Le routage dans un rseau MPLS utilisant BGP est spar pour chaque VPN par la notion de routeurs virtuels. Le trafic est quant lui maintenu spar sur le plan de donnes grce l'tiquette VPN ajoute par le routeur PE ingress. De ce fait, ayant une sparation de l'adressage, du routage et du trafic, il est possible d'admettre que les MPLS/VPN utilisant BGP offrent la mme scurit que les VPN de couche 2 et rendent impossible la pntration directe dans un autre VPN.

Les attaques ayant pour source le rseau MPLS sont dangereuses et dlicates, car au sein du rseau MPLS il est possible d'couter sur le rseau, de renifler le trafic, de l'intercepter, de le modifier et d'en injecter sans que les utilisateurs du rseau n'en soient seulement conscients tant donn que ni les donnes ne sont chiffres ni les changes protgs. Enno Rey, consultant chercheur spcialis en scurit a montr la confrence Blackhat Europe 2006 qu'une attaque par mystification des tiquettes tait possible et simple, et qu'une attaque par modification de session MP-BGP tait envisageable, bien que plus difficile (Rey, 2006). Nonobstant, toutes ces attaques exigent un accs au cur du rseau MPLS.

Les menaces intemes peuvent tre dues une mauvaise configuration volontaire ou involontaire. Par exemple, une erreur involontaire de configuration dans la dfinition des route targets peut avoir pour effet d'exporter les routes d'un VPN vers un autre VPN et donc de briser l'intgrit des donnes. Ce genre d'erreur peut de plus tre difficile

50

dtecter pour l'un des deux VPN (l'autre perdant sa connectivit normale, donc le remarquant rapidement). Cependant les outils de configuration automatique permettent d'viter ce genre d'erreur.

Dans le cas des erreurs volontaires, o un oprateur va dlibrment crer une faille dans le rseau, il n'y a pas vraiment d'autre solution que de s'assurer de la responsabilit et de l'intgrit des employs. Car les consquences peuvent tre catastrophiques, puisque pas ncessairement dtectables.

Donc, si le rseau est convenablement configur, une attaque d'origine inteme ne peut venir que du foumisseur de service. Or comme il est prsuppos - peut-tre tort! - que le foumisseur de service est un tiers de confiance, les attaques de ce type sont prsumes inexistantes. Si un client ne fait pas confiance au foumisseur de service, alors il doit utiliser IPsec pour protger son trafic. Bien que cela n'empcherait pas de briser l'tanchit des VPN, le trafic ne serait toutefois pas compatible car chiffr et donc illisible. 2.2.2 Attaque s indirecte s

Puisque la conception des VPN sur MPLS empche une pntration directe dans un VPN, un intms devrait trouver un autre moyen pour parvenir ses fins. Une mthode consisterait attaquer le cur du rseau MPLS dans un premier temps, puis pntrer les VPN de ce point. Les points suivants vont tre considrs dans cette partie : Attaque sur le cur du rseau Mysfificafion d'fiquettes MPLS ou d'adresses IP, Dni de service, Attaques sur le lien CE-PE, Attaques sur les protocoles de signalisafion

51

2.2.2.1 Attaqu

e su r le cur du rseau

Avant de pouvoir attaquer le cur du rseau, un attaquant doit savoir ce qui s'y trouve exactement. Pour cela, il va tenter des attaques de reconnaissance, difficiles dtecter car n'ayant pas d'impact ngatif sur le rseau. Dans un rseau classique, l'utilisation de joumaux d'vnements reprsente une des seules solutions pour dtecter ce type d'attaque. Afin d'viter le succs de telles attaques, il faut masquer le rseau au maximum. Or l'avantage du rseau MPLS cur est d'tre invisible de l'extrieur. Les seuls quipements visibles sont les routeurs PE, il faut donc scuriser les interfaces externes de ces routeurs grce aux listes d'accs, pour ne pas accepter de paquets destination du cur. La reconnaissance d'un rseau MPLS est donc loin d'tre une chose aise. Les deux seules exceptions cette invisibilit sont d'une part le paramtre MPLS traceroute qui est activ par dfaut depuis les versions suprieures 12.0(9)ST et 12.1(3)T de l'IOS Cisco, et l'utilisation de services Intemet sur les routeurs du cur {cf Connectivit Intemet, section 3.2). Par dfaut les PE copient le champ TTL (Time To Live) du paquet IP dans l'entte MPLS. Chaque routeur P du cur va dcrmenter ce champ au passage d'un paquet, le PE de sortie recopiera la valeur rsiduelle du TTL dans l'entte IP. Un MPLS tracer-oute va permettre de rvler de l'information sur la topologie du rseau MPLS. Il est important de le dsactiver l'intrieur du rseau MPLS pour viter de dvoiler le contenu du rseau cur.

Mme en connaissant ou en devinant l'adresse d'un routeur P, les attaques vers le cur du rseau ne sont pas ralisables, y compris en l'absence de liste d'accs. cause de la sparation des espaces d'adressage effectue par les routeurs PE, les adresses IP sont traduites en adresses VPN-IP qui n'ont une signification que pour le VPN auquel elles appartiennent. Les routeurs PE traiteraient alors des paquets destination du cur comme appartenant l'espace d'adressage du client, donc destinafion d'un des sites du

52

VPN et non du rseau MPLS. Une fois entres dans le rseau MPLS, les donnes sont mises en tunnel jusqu'au routeur PE de sortie. Le seul point d'entre est l'interface exteme des PE, lie au CE.

Il y a deux possibilits d'attaques au niveau du PE. D'une part, attaquer le routeur PE directement, et d'autre part attaquer les mcanismes de signalisation de MPLS. Afin d'empcher des attaques sur les routeurs PE, des listes d'accs doivent tre adoptes, rendant inefficace tout scan de port. Ces listes d'accs doivent entre autres restreindre les droits d'accs aux ports de configuration des PE. De plus, seul SSH devrait tre employ pour la configuration, tant plus scuritaire que l'accs par telnet. Les mots de passe ne doivent jamais tre ceux par dfaut, ni faciles deviner ou encore les mmes partout.

Le type de routage le plus favorable entre CE et PE est le routage statique. Aucune route ne peut tre introduite par un intms puisqu'il n'y a pas de mise jour du routage dans un tel cas. Aucun paquet ne doit donc avoir le PE comme destination si le routage statique est utilis.

Le routage dynamique est plus simple configurer, particulirement en cas de changement d'adressage. En raison de sa facifit de mise l'chelle, eBGP {exterior Border Gateway Protocol) est recommand en tant que protocole de routage dynamique, et dans tous les cas l'authentification est primordiale. BGP propose des mcanismes tels que la commande maximum-prefix qui limite le nombre de routes que le routeur doit accepter afin d'viter un dni de service par surconsommation des ressources du processeur ou de la mmoire. Dans le cas o BGP n'est pas support, des IGP {Interior Gateway Protocol) tels qu'EIGRP (Enhanced Interior Gateway Routing Protocol), OSPF ou RIPv2 peuvent tre ufiliss. La RFC4577 suggre dans ce cas l'utilisation d'OSPF comme protocole de routage CE-PE (Rosen, Psenak et Pillay-Esnauh, 2006).

53

Quel que soit le protocole de routage dynamique utilis, le seul trafic pouvant se diriger au PE doit tre li ce protocole de routage. Ce demier doit tre protg, grce des listes d'accs avances ainsi que l'authentification des pairs par MD5 {Message Digest 5). La section 2.2.2.5 donne des dtails supplmentaires sur cette possibilit. L'authentification des participants est aussi ncessaire pour viter que les routeurs CE ne puissent mystifier l'appartenance un VPN donn ou raliser du dni de service en inondant le PE de mises jour de routage. Le chapitre 4 analysera plus en dtail le protocole de routage utilis pour l'change de routes VPN dans le rseau MPLS, MPBGP.

Enfin, les attaques peuvent aussi se diriger vers le centre de gestion du rseau, le NOC {NetM'ork Oper-ations Center), et l'quipement qui lui est li, comme les stations de gestions, les serveurs FTP et TFTP, etc. Le centre de gestion peut tre reli Intemet pour permettre une administration distance. Le risque est ici trs grand puisque si un intrus russit atteindre le centre de gestion, il devient en quelque sorte le matre du rseau, pouvant sa guise changer la configuration des PE, et permettre ainsi d'accder des VPN depuis l'extrieur. L'utilisation de listes d'accs et de communications chiffres est essentielle pour que diffrents VPN ne puissent tre interconnects au travers du NOC. 2.2.2.2 Mystificatio n d'tiquette s MPL S ou d'adresses I P

Une autre attaque possible est la mystification de paquets comportant des tiquettes MPLS ou VPN. S'il tait possible d'introduire des paquets labliss (fiquets) dans le rseau MPLS, les routeurs les achemineraient selon leur tiquette MPLS, cela pourrait ventuellement briser l'tanchit des VPN. Il faudrait nanmoins deviner les tiquettes MPLS et VPN ufiliser. Heureusement, comme l'interface entre le CE et le PE est purement IP, il n'y a pas circulafion de paquets labliss cet endroit. Il est donc important que les routeurs PE n'acceptent jamais de paquets labliss en provenance des

54

CE, except dans certaines configurations particulires, telle celle de plusieurs rseaux MPLS relis entre eux (architecture Inter-AS, cf. 2.2.5.1), ainsi que celle des rseaux MPLS hirarchiss {Carrier 's carrier, cf. 2.2.5.2). Le cas de la mystification d'adresses IP ne reprsente pas en soi une attaque valide, car quelle que soit l'adresse de destination du paquet entrant dans un routeur PE, ce demier effectue l'entre du rseau MPLS une sparation des espaces d'adressage avec les route distinguishers. Un utilisateur ne peut donc pas attaquer un autre VPN, mais seulement un autre utilisateur de son propre VPN, ce qui ne constitue pas une menace remettant en cause l'tanchit de l'architecture MPLS/VPN. 2.2.2.3 Dn i de service

Les attaques de type dni de service, possibles sur les routeurs PE, ne remettent pas en cause l'intgrit des donnes, par contre ils vont avoir pour consquence d'empcher le fonctionnement correct et normal des VPN, en termes de garantie de niveau de service et de performances. Le dimensionnement correct du rseau associ des politiques de policing/shaping doit permettre d'viter le dni de service en empchant les clients de chaque VPN d'mettre un rythme suprieur celui souscrit. En outre, les routeurs rcents commencent intgrer des fonctionnalits de ressources spares par VPN, autrement dit si un client d'un VPN met une attaque de dni de service, il ne compromettra que son propre VPN et n'affectera pas les performances des autres VPN. 2.2.2.4 Attaque s sur le lien CE-PE

Des chercheurs (Ren, Feng et Ma, 2004) de l'Acadmie chinoise des sciences de Pkin ont montr que le point faible de l'architecture MPLS/VPN est le lien CE-PE. Bien qu'ils concdent qu'il est impossible d'injecter des paquets labliss dans le rseau MPLS, les attaques sur le lien CE-PE sont possibles. Elles ne permettent toutefois pas de rejoindre un autre VPN, cause des VRF propres chaque VPN prsents dans les PE

55

(ce qui est valable uniquement si un seul VPN utilise le lien CE-PE). Par contre, rien n'empche un intms se connectant entre un CE et un PE d'attaquer les clients du VPN concem, le trafic tant cet endroit purement IP.

Le fait que MPLS ne soit utilis en gnral que sur le rseau du foumisseur de service au niveau de sa dorsale cre un lien CE-PE vulnrable. Ils suggrent donc une solution amliore de VPN sur MPLS utilisant IPSec, avec entre autres une autorit de certification et de distribution de cl de scurit, en l'occurrence IKE (Intemet Key Exchange). Les simulations ralises montrent que plus le degr de scurit est lev (aucun chiffrement, puis ESP {Encapsulating Security Payload) seul, et enfin ESP + AH {Authentication Header-)), plus le dlai est important et le dbit dans le rseau diminu. Il faut donc faire un compromis entre scurit et performances, selon les besoins des clients.

Le problme du lien CE-PE est donc d'tre ventuellement accessible un intms ralisant une attaque de type Man in the Middle. L'idal serait de ne pas utiliser d'adressage entre le CE et le PE, ce qui empcherait toute attaque au niveau 3. Mais des limitations telles que l'impossibilit d'effectuer un ping pour vrifier le fonctionnement du lien sont trop contraignantes pour permettre cette solution.

L'authentification par MD5 des protocoles de routage doit permettre d'empcher toute intervention sur ceux-ci, avec les rserves nonces dans la section 2.2.2.5. Si un seul VPN utilise le lien CE-PE, au pire l'intms pourra couter les donnes transmises, injecter des donnes dans le VPN en question mais pas attaquer les autres VPN de ce point cause de la sparation des espaces d'adressage. Si par contre plusieurs VPN se partagent le lien CE-PE, il peut s'avrer ncessaire de les protger par du chiffrement (IPSec). Aussi, l'utilisation de VLAN {Virtual Local Area Network) permet de sparer au niveau 2 le trafic des diffrents VPN. Il est cependant important dans ce cas d'viter que l'intms puisse se placer entre le CE et le PE, pour cela il ne faut pas utiliser de

56

nuds de niveau 2 entre CE et PE. Par ailleurs, si les multiples VPN entre CE et PE sont mis en uvre pour plusieurs clients, le CE doit absolument tre administr par le foumisseur du rseau MPLS, et non par les clients. La zone de confiance va dans ce cas inclure le routeur CE.

Si la confidentialit est importante pour le client, il est possible comme suggr par Ren, Feng et Ma d'utiliser IPsec entre les CE. Cela permet d'viter toute rvlation d'information un intms coutant le lien CE-PE, et ventuellement, si le client ne fait qu'une confiance relative au foumisseur de service, de protger ses donnes de ce demier. Toutefois des dgradations en termes de performances sont accepter en contrepartie.

Les paquets changs sur le lien CE-PE tant purement IP et non MPLS, les problmes qui peuvent y survenir sont les mmes que sur n'importe quel lien IP. Au niveau de la couche 2, les risques existent {ARP attacks, VLAN trucking attacks, etc.) et c'est pourquoi mme s'il y a pour chaque risque des mesures de protection de la couche 2 qui doivent tre prises en compte, il est fortement dconseill d'utiliser par exemple entre CE et PE des quipements tels que des nuds d'change Intemet. L'tude de ces risques sort du cadre de ce mmoire, de la documentation ce sujet tant disponible sur Intemet. 2.2.2.5 Attaque s su r les protocoles de signalisation

Les protocoles de routage tant les seuls autoriss dialoguer avec tous les lments du rseau cur (routeurs PE, P), il est essentiel de les scuriser afin d'empcher tout intms d'injecter des mises jour de routes errones, ce qui aurait pour effet de compromettre le fonctionnement du rseau, et ventuellement l'intgrit des donnes des clients VPN.

Les routeurs voisins doivent donc s'authentifier entre eux avant d'accepter du trafic de routage. Pour cela, l'authenfificafion avec MD5 est fortement conseille. Celle-ci est

57

possible pour BGP (Heffeman, 1998), OSPF (Murphy, Badger et Wellington, 1997) et RIPv2 (Baker et Atkinson, 1997). Les protocoles de routage ne sont pas les seuls pouvoir tre authenfifis, le protocole de distribution LDP utilise lui-aussi MD5 pour prvenir de la mysfificafion d'tiquettes.

L'avantage de MD5 est que seule une empreinte compose de la cl et d'un message est transmise, sans cette cl il est impossible de recalculer une empreinte. L'inconvnient est que MD5 n'est plus sr au niveau cryptographique : ds 1996, des failles ont pu tre trouves (Dobbertin, 1996) ; en 2004 MD5 a t considr comme cass aprs dcouverte de collisions relles (c'est--dire qu'une mme empreinte peut tre obtenue en utilisant deux messages diffrents) par une quipe chinoise (Wang et Yu, 2005).

D'autres mcanismes peuvent tre utiliss en plus de l'authenfificafion afin de scuriser les protocoles de routage. BGP propose un mcanisme de contrle par TTL (Gill, Heasley et Meyer, 2004) afin de protger les sessions eBGP d'attaques de dni de service par surcharge sur les routeurs. En vrifiant que les paquets de mise jour des protocoles de routage possdent une valeur de TTL suprieur un minimum fix, cela empche tout paquet IP de routage BGP provenant d'un lment distant, extrieur au rseau MPLS, d'tre considr comme valide. 2.2.3 Des points de vue extrieur s

Mme si le nombre d'articles sur les VPN sur MPLS n'est pas trs important, certains articles sont assez intressants. En voici deux qui prsentent des points de vue diffrents, considrant dans le premier article la scurit obtenue par applicafion de la RFC2547 sur les rseaux privs virtuels sur MPLS et la ncessit d'y apporter des modifications, et l'impact de cette technologie sur les performances du rseau ainsi qu'une comparaison avec les VPN sur IPsec dans le second article.

58

2.2.3.1 Intgrit

de s VPN

Randy Bush et Timothy G. Griffin, qui contrairement Behringer, ne sont pas lis Cisco, ont ralis une tude (Bush et Griffin, 2003) portant leur attention sur la notion d'intgrit des informations circulant dans les VPN, afin de garantir une isolation entre les diffrents tunnels VPN. Cette notion d'intgrit signifie que la spcification est correcte et que l'implmentation est bien ralise. Les erreurs humaines qui peuvent intervenir (mots de passe par dfaut, etc.) ne font toutefois pas partie de leurs considrations. Leur but tait de trouver des ambiguts dans la spcification de la RFC2547 (Rosen et Rekhter, 1999), la prcdente version de la RFC4364, et de proposer quelques solutions altemafives celles-ci.

La RFC2547 propose d'isoler les VPN en utilisant des tables d'acheminement par site et l'assurance de l'adresse source. Mais cette isolation ne peut tre garantie en tout temps. Afin de rsoudre ce problme, l'utilisafion de tables d'acheminement par VPN fut propose, elle a d'ailleurs t adopte dans la RFC4364.

Bush et Griffin suggrent, afin d'amliorer l'intgrit des VPN, d'employer des tables d'acheminement entrantes et sortantes pour chaque interface, ou alors une table d'acheminement tendue pour chaque interface, ne transmettant le trafic vers la destination que s'il provient d'une source dfinie. Ce demier type de table constitue cependant un srieux challenge dans son implmentation, de par le nombre d'entres. Toutefois, l'isolation permise par les solutions suggres par les auteurs correspond celle obtenue en utilisant des tables d'acheminement par VPN.

Bush et Griffin ont remarqu un point intressant : comme la spcification (RFC2547) tait l'poque incomplte, les manques de la spcification taient plus ou moins rattraps par les implmentations de chaque fabricant. C'est pourquoi - en particulier avant la sortie de la RFC4364 plus complte - les diffrents produits sur le march

59

n'taient pas tous quivalents et ncessitaient d'tre individuellement tests pour en vrifier les proprits, et donc la garanfie de l'isolation des VPN.

Outre les considrafions de performances quant la mise l'chelle du rseau MPLS et les effets de la quantit de tunnels VPN sur le fonctionnement du rseau, un point soulev par les auteurs ayant trait la scurit et pouvant tre important conceme le temps de convergence des protocoles de routage comme BGP en cas de modifications sur le rseau. Il est important que cette convergence soit rapide, pour viter d'obtenir des chemins LSP rompus et une isolation des VPN brise. 2.2.3.2 Performance s de s VPN sur MPLS

Palmieri a ralis une tude (Palmieri, 2003) comparant les performances, forces et faiblesses des VPN utilisant IPsec ou MPLS.

D'aprs l'auteur, le point qui pose problme et qui peut se rvler ngatif pour les VPN bass sur MPLS est la ncessit de pouvoir faire une totale confiance au foumisseur de service. Cela est aussi vrai pour ATM. Par contre, parmi les avantages, la latence est trs rduite car il n'y a avec MPLS aucune encapsulation importante ni aucun chiffrement des donnes.

La scurit de MPLS/VPN est obtenue par l'approche distincte plan de donnes / plan de contrle. Le plan de donnes empche un paquet appartenant un VPN d'en sortir et au trafic extrieur d'y rentrer, notamment en examinant l'tiquette du paquet. Le plan de contrle permet de s'assurer que les clients ou intms ne puissent injecter des routes dans le rseau MPLS, il protge aussi les routeurs en empchant tout accs non autoris.

L'auteur prcise toutefois que si la sparation de trafic la couche 2.5 (MPLS) et les chemins rservs ne sont pas considrs comme une scurit suffisante pour le client, ou

60

que la confidentialit est critique mme vis--vis du foumisseur de service, alors l'emploi d'IPsec est fortement conseill.

Des tests fonctionnels ont t raliss par Palmieri pour tenter de montrer que MPLS/VPN est aussi sr que les VPN classiques ufilisant le chiffrement. Des paquets ont par exemple t injects dans un VPN destination d'un autre VPN sans que ce demier ne soit touch. L'invisibilit du rseau a t teste quant elle en ralisant un traceroute montrant l'impossibilit d'atteindre les routeurs du rseau MPLS. Des tests de performances ont permis de montrer que l'approche MPLS/VPN est en terme de latence beaucoup plus rapide que IPsec, surtout avec de gros paquets, et au mme niveau qu'une transmission classique de paquets IP. De mme, MPLS/VPN perd beaucoup moins de paquets qu'IPsec. L'utilisafion du processeur des CE est augmente uniquement en utilisant IPsec, pas avec MPLS. Par contre, et ce rsultat est plus surprenant, la bande passante mesure de bout en bout est similaire avec IPsec et avec MPLS/VPN, mais bien moindre ( peine un tiers) que sans encapsulation et chiffrement. Cela est tonnant, car MPLS ne fait qu'ajouter un entte de 4 octets quand IPsec ajoute 20 octets. La surcharge est donc suprieure avec IPsec, et cela ne se traduit pas dans les rsultats.

La conclusion de l'auteur est que MPLS/VPN est trs bon en termes de performances, fiabilit, mise l'chelle et offre une scurit comparable aux VPN utilisant ATM/FR, ce qui, en faisant confiance au foumisseur de service, peut tre considr aussi scuritaire que des tunnels chiffrs par IPsec. 2.2.4 Comparaiso n ave c ATM/FR

Plusieurs acteurs de la communaut scienfifique (Miercom, 2001), (Cisco, 2004) reconnaissent qu'un rseau MPLS proposant uniquement des VPN, c'est--dire sans

61

accs partag Intemet, offre un niveau de scurit similaire aux VPN de niveau 2 utilisant ATM et FR parce que les raisons qui permettent de considrer les technologies ATM/FR comme sres s'appliquent aussi MPLS : la sparation de l'espace d'adressage, du routage et des donnes l'invisibilit du rseau cur depuis l'extrieur un rseau rsistant aux attaques

La grande diffrence entre MPLS/VPN et ATM/FR est qu'ATM et Frame Relay fonctionnent la couche 2, alors que MPLS utilise la couche 3. La sparation des VPN dans ATM est ralise grce l'utilisation de la couche 2 dans le cur, ce qui permet aux informations de couche 3 d'tre compltement ignores ; alors que MPLS ufilis les VRF afin de sparer les VPN la couche 3.

La sparation de l'adressage, du routage et du trafic vient naturellement dans ATM/FR car la couche rseau n'est jamais consulte lors du transport des trames, la seule information sollicite pour la commutation des trames tant le champ DLCI pour FR ou le couple VCI/VPI pour ATM. Dans MPLS, la sparation de l'adressage est ralise par les route distingtnshers, permettant d'utiliser le mme espace d'adressage dans plusieurs VPN disjoints. La sparation du routage et du trafic est quant elle permise par le principe de routeurs virtuels, les tables de routages par VPN (c'est--dire les VRF), les rgles d'import/export au sein des VRF et par l'change des routes par MP-BGP entre les routeurs PE.

L'invisibilit du rseau est permise dans ATM/FR par l'absence de connectivit au niveau de la couche rseau entre le client et les commutateurs ATM/FR. Dans MPLS, les clients ne connaissent que l'adresse du PE, les routes du rseau n'tant pas diffuses car leur connaissance est inutile au bon fonctionnement des VPN. De plus, si la foncfion MPLS traceroute est dsactive, le rseau MPLS entier sera vu comme un seul saut par

62

les clients. Cette invisibilit n'est toutefois pas possible dans certaines configurations d'accs partag Intemet {cf secfion 3.2).

Enfin, ATM/FR offre une bonne rsistance aux attaques d'intmsion car une attaque ne peut atteindre que les participants du VPN duquel est partie l'attaque, le rseau ne faisant que diriger les trames en fonction du champ DLCI ou du couple VCI/VPI sans consulter les couches suprieures. C'est assez similaire pour MPLS, les routeurs P ne consultant pas l'adresse IP pour effectuer l'acheminement des paquets mais plutt les tiquettes MPLS. Une fois entr dans le rseau un paquet ne peut que ressortir dans le mme VPN que celui par lequel il est entr. Donc toute attaque ne peut toucher qu'un VPN, pas le rseau cur. Les attaques indirectes doivent passer par les PE, or ceux-ci sont protgs par des listes d'accs.

Les problmes de configuration des PE noncs dans MPLS sont tout aussi valables pour ATM/FR, si un circuit est mal configur par exemple.

Le seul endroit o ATM/FR a un avantage sur MPLS est dans leur possibilit de raliser une communication de CE CE, utilisant par exemple le protocole CDP {Cisco Discovery Protocol). Cette communication est permise par l'aspect point pomt fullmesh des liaisons ATM/FR, ce qui n'est pas le cas des VPN sur MPLS. La mise l'chelle est plus facile avec MPLS, mais ce demier ne permet pas les communications CE-CE, qui pourraient mettre en vidence l'ajout par erreur d'un CE dans un mauvais VPN, difficilement dtectable par le VPN cible. Ce n'est nanmoins qu'une erreur de configuration de la part du foumisseur de service. La connectivit CE-CE est toutefois possible avec les VPN de niveau 2 dans MPLS, comme Pseudo Wire Emulation (PWE).

Globalement, MPLS/VPN et ATM/FR se comportent de faon similaire au niveau de la scurit, tout du moins lorsque l'accs partag Intemet n'est pas offert. Mais dans tous les cas, il faut absolument viter toute configuration errone.

63

2.2.5 Scurit

de s architectures MPL S avance s

Au del de l'architecture simple dans laquelle il n'y a qu'un seul systme autonome ou AS {Autonomous System), il existe des architectures plus complexes de MPLS qui possdent des particularits rendant l'analyse de leur scurit diffrente : rseau cur multi-AS {Autonomous System), aussi appel Inter-AS, rseaux MPLS hirarchiss, du terme anglais Carrier 's Carrier. 2.2.5.1 Rsea u cur multi-A S

Dans l'architecture Inter-AS dfinie dans la RFC4364 (Rosen et Rekhter, 2006), le rseau cur se compose de plusieurs systmes autonomes (AS), appartenant en gnral diffrents foumisseurs de service.

Le cas de ce type d'architecture, reliant par exemple deux foumisseurs de service, est beaucoup plus complexe en termes de scurit. Il faut dans ces situations faire confiance l'autre foumisseur de service quant aux paquets qu'il envoie. Une nouvelle fois, la notion de confiance vis--vis des foumisseurs de service y compris entre eux-mmes est importante.

Il existe trois mthodes permettant de connecter des AS entre eux : connexion VRF VRF sur les ASBR {Autonomous System Border Router), redistribution avec eBGP {exterior BGP) des routes VPN-IPv4, redistribution eBGP saut multiple de routes VPN-IPv4 inter-AS et redistribufion eBGP des routes IPv4.

Les menaces pouvant affecter les VPN sont les mmes que prcdemment, par contre selon la mthode employe pour relier les diffrents AS, leur exposition ces menaces est diffrente.

64

La premire mthode consiste utiliser une sous-interface de la connexion entre les ASBR pour chaque VRF. La sparation est maintenue tout au long du transport et les paquets transitant sont de classiques paquets IP. Cette mthode permettant moins d'interaction entre les AS, elle peut tre considre comme plus sre. Cependant, celleci n'est pas adapte l'change d'un grand nombre de VRF car pour chaque VPN interAS gr, un VRF et une interface spcifique doivent tre configurs sur chaque ASBR.

Dans la seconde mthode, il n'y a qu'une connexion logique entre les ASBR : la diffrenciation se fait ici sur les tiquettes des paquets. MP-eBGP est utilis pour redistribuer l'infonnation entre les ASBR. Bien que plus facile mettre l'chelle que la premire mthode, celle-ci ncessite d'changer des paquets labliss entre les diffrents AS et donc d'accepter des paquets labliss en entre du rseau. Le lien entre les ASBR doit tre isol, idalement par une liaison prive, au pire dans un VLAN et ne jamais traverser des nuds d'change Intemet (IXP, Inter-net Exchange Point), pour viter toute attaque compromettante comme la mystification d'tiquettes VPN.

La troisime mthode transforme les ASBR en routeurs P qui n'ont aucune connaissance des VRF dans le rseau. Les deux nuages MPLS sont en quelque sorte regroups en un seul nuage. Les rflecteurs de routes (RR, Route Reflector) peuvent tre ici utiliss afin de permettre une mise l'chelle encore plus grande (Btes, Chen et Chandra, 2006). Cette mthode a le dsavantage d'tre trs ouverte dans le sens o les sessions BGP et les LSP sont tablies entre PE de diffrents AS et non plus limites aux ASBR comme dans la seconde mthode. Plus encore que dans cette demire, il est primordial que la liaison entre ASBR soit sre, car un intms se trouvant entre les deux ASBR quivaut un intms ayant accs au cur d'un rseau MPLS classique. noter qu'au niveau de la scurit, les rflecteurs de routes sont invisibles comme les routeurs P, et possdent les mmes informations que les PE, avec lesquels ils les changent.

65

Ces deux dernires mthodes permettant tout AS d'envoyer du trafic dans n'importe quel VPN d'un autre AS, elles pourraient permettre de faciliter les intrusions ou dnis de service. Il est ici fondamental de pouvoir faire confiance chaque fournisseur de service. De mme, ces derniers doivent pouvoir se faire confiance entre eux, afin d'viter qu'un fournisseur ne compromette tous les autres. Par exemple, dans la troisime mthode, comme l'tiquette VPN n'est pas vrifie par les ASBR lors du passage d'un AS un autre, il serait possible au fournisseur de service du premier AS de modifier l'tiquette VPN d'un paquet destination d'un autre AS et ainsi d'envoyer du trafic de faon unidirectionnelle vers un VPN de cet autre AS sans problme.

Cette ncessit de faire confiance tous les fournisseurs de service ne devrait de nos jours plus exister, ne faisant qu'augmenter exponentiellement les sources de problmes. Les technologies - comme ici MPLS, ou BGP - devraient tre amliores afin de ne plus imposer cette condition.

4. Inbound filterin g per-peer O R rr-grou p 3. Automatic rout e filtering inboun d 1. Inboun d filterin g on PE-ASB R 2. Outbound filterin g per-peer

Figure 2.2 Les diffrentes possibilits de filtrage inter-AS (Tir de Cisco, 2003)

66

Il est possible d'utiliser un filtrage diffrents niveaux (en entre, en sortie pour chaque PE partenaire, selon la route, etc.) comme le prsente la Figure 2.2 ci-dessus.

Pour plus d'informafions sur le routage et la scurit des rseaux multi-AS, le lecteur est invit consulter la prsentation de Cisco Advanced Concepts - Inter AS MPLS/VPN (Cisco, 2003) d'o est tir ce schma. 2.2.5.2 Rseau x MPLS hirarchis s

L'architecture Carrier's Carrier est aussi dfinie dans la RFC4364. Elle correspond une hirarchisation des rseaux MPLS. Les diffrents rseaux infrieurs sont relis par leurs CE des PE du rseau de niveau suprieur par des VPN, il y a une encapsulation VPN dans VPN qui est ralise, ce qui au niveau de la scurit est avantageux. Le rseau de niveau suprieur n'a aucune visibilit sur le contenu des paquets qui transitent, puisqu'il ne s'intresse qu' l'adresse du PE auquel il doit envoyer les paquets et ne regarde que les deux premires tiquettes (comme dans le cas d'un rseau MPLS/VPN simple, sauf que les donnes transportes dans le rseau de niveau suprieur sont encapsules deux reprises). La seconde tiquette (normalement l'tiquette VPN) reprsente le CE de sortie du rseau suprieur, ce demier ne s'occupant en fait que de transporter les paquets MPLS pour les rseaux infrieurs.

La scurit dans cette architecture se ramne globalement celle d'un rseau MPLS mono-cur. Par contre, dans ce cas les PE du rseau de niveau suprieur sont amens accepter des paquets portant des tiquettes. Cela est possible uniquement parce que ces paquets quitteront le rseau de niveau suprieur sans que ces tiquettes n'aient t tes {cf. RFC4364). Les PE doivent vrifier que les fiquettes des paquets reus d'un CE du rseau infrieur correspondent bien aux tiquettes distribues pour ce CE. La mystification de l'tiquette VPN extrieure (reprsentant le VPN cr dans le rseau suprieur) par le foumisseur du rseau infrieur est alors impossible : si elle est

67

incorrecte, le paquet est dtmit ; si elle est correcte, le paquet ressortira ncessairement dans le rseau infrieur prdfini, quelles que soient les donnes et la valeur de l'tiquette VPN inteme. Le rseau suprieur est donc scuris de la mme faon que l'est un rseau MPLS mono-cur. Cela provient du fait que le CE appartient au foumisseur de service et il fait ainsi partie de la zone de confiance.

Les seules attaques sur le rseau suprieur pourraient tre lies aux protocoles de signalisation utiliss : n'importe quel IGP, LDP ou BGP. Ceux-ci doivent tre protgs pour viter des attaques de dni de service ou l'envoi de mises jour errones. Le protocole BGP fera l'objet d'une tude dans le chapitre 4.

CHAPITRE 3 TESTS Ce chapitre a pour objectif de prsenter le cas d'architectures MPLS/VPN avances. Il dcrit dans un premier temps les menaces lies la connectivit Extranet et Intemet, puis les tests pratiques mens sur le rseau de Bell Canada aprs la dcouverte d'une possibilit de faille dans l'architecture Extranet, prsente dans la partie 3.1. 3.1 Menace s lie s la connectivit Extrane t

Un Extranet est une extension d'un rseau priv permettant de partager de l'information avec des utilisateurs extrieurs. Un Extranet peut par exemple tre cr lorsqu'une entreprise permet ses sous-traitants d'avoir accs ses propres bases de donnes. Leur accs se fait gnralement via Intemet en utilisant un procd d'authentification.

Dans MPLS, un Extranet peut se voir sous la forme d'une ressource partage par plusieurs VPN. Leur cration est simple, il suffit de manipuler les imports/exports de route targets afin de donner accs chaque client la ressource partage tout en vitant de relier les diffrents VPN entre eux. La ressource commune va ainsi voir les rseaux de tous les clients qui y sont connects, par contre chaque client ne pourra voir que les routes appartenant la ressource partage. La seule contrainte de la cormectivit Extranet est l'obligation d'utiliser des espaces d'adressage distincts, puisqu'il y a communicafion avec l'extrieur des rseaux privs des clients.

Il est cependant important d'utiliser des pare-feux dans une connectivit Extranet, car malgr la configuration correcte des imports/exports de route targets il peut tre possible d'envoyer du trafic de faon unidirectionnelle d'un VPN l'autre, ce qui peut permettre l'envoi de vers.

69

La Figure 3.1 ci-dessous prsente une possibilit de rseau Extranet. Le client 1 (site 1) change des informations avec le client 2 (site 2), tandis que ce demier change des informafions avec le client 3 (site 3). Les VRF pour les sites 1, 2 et 3 (voir schma) montrent bien que le client 1 ne voit pas les routes du client 3 et inversement. Pourtant il pourrait sous certaines conditions envoyer du trafic de faon unidirectionnelle au client 3. Il en va de mme avec le client 4, situ au site 4, toutefois pour simplifier cet exemple nous ne considrons pas le site 4 et les imports/exports de routes lis au VPN C.

:Sitsi; \ VPN A v - ' i ' *

_ S ; .'PN

, / Site B .'&ite'.t VP

4} NC , /

" f:-

-X;:-'-"

' ' ' K J ^ U ! * ' , :''

" Mullito

p MP-ibG P '""

s '^';!l^^'i

i.i'Ute-tai-qft .r.p.n t l O ' j l _ roLile-tage i.:.utr-t.ii9?t imf:ii t l ' j ; l _ ^ ' ^ ip vr i r.il2 / ' ^ i ^ g ^ ^.jC |.d 100. 2 ^ ^ d ^ P ^ i.:'Ut5-tcii95t f.p.iT t 100: 2 p ^ i F'E route-taf.jit impoi l 100: 2 ^ C ^ f c ^SP^ i.:.uti-t..-li.qel ii-np..-i l 10 0 1 SSg3l B ^ ^ ' . VRF VR for sit e 1 IC ,100:11 i l 0 : 2 i.ite 1 lOLites i i l Sitr 2 icutes Sit .

l e.poi t 1 OiS ^ louls-lai.je l imp.:.it l O 2 ^ i..-Lrt^LTr.5flii-np.:.inO; 3 g ^ f * roirt.^tJli.jele.poiMOOl i 2 ip-.'i t :.ite4 i d 100: 4 S l o U e L l i . q e l e . p o it 100:--: S

F VR I site 2 |.: i ilOO.' e 1 loutes i i l e 2 ivLils ::.il

~t-" ': F VR T sit e ; t.:. i il00:4 e 2 lOLite s i.il e 2 i.r.ules ::.it

F* i sit e 4 . e ^ i.:.ijte s e 4 loirle s

Figure 3.1 Sites clients dans plusieurs VPN (Tir de Cisco, 2006) Afin d'analyser ce qui se passe dans ce rseau Extranet, rappelons les conditions sur le rseau MPLS : Les sites 1 et 3 reprsentent deux clients, le site 2 reprsente la ressource partage, Utilisation des route-targets import/export.

70

La visibilit des sites (minimale pour l'exemple) est donne dans le Tableau 3.1, Les sites 1 et 3 n'ont aucune visibilit entre eux, Implmentafion par Cisco (version de l'IOS : 12.3(8r2)T) sur 3725 et 7206.

Par ailleurs, les hypothses suivantes sur l'environnement sont prises : L'intms se trouve dans le site 1, la cible dans le site 3, L'intms connat ou devine une adresse IP appartenant au site 3, Il y a une route par dfaut du CE (site 1 ) vers le PE (VRF site 1 ), Il y a une route par dfaut PE (VRF site 1) vers une adresse du site 2, Il n'y a pas d'attaquant dans le site 2,

La topologie du rseau prsent dans la Figure 3.1 au niveau du site 2 peut tre interprte de plusieurs faons, prsentes ci-aprs. Dans un premier cas {cf Figure 3.2), le site 2 contient les deux VPN distincts A et B, ce qui nous intresse peu car dans ce cas nous n'avons pas de ressource partage. Nous obtenons deux VPN A et B disjoints par l'utilisation de VLAN spars entre le PE et le CE du site 2. Il faut nanmoins faire attention dans ce cas la bonne configuration du CE, afin d'empcher le trafic d'aller d'un VPN l'autre. Cela ncessite l'ufilisafion de listes d'accs au sein de ce routeur, car les CE ne font pas de sparation du trafic ou du routage au niveau 3 comme les PE MPLS. L'autre possibilit, meilleure, consiste effectuer un routage statique entre chaque interface de VPN et l'interface du VLAN relie au PE.

71

Sitel

Site 3

Figure 3.2 Reprsentation de la connectivit Extranet - Cas 1 Le tableau ci-dessous prsente la visibilit des sites, dtermine par les imports et exports de route raliss.

Tableau 3.1 Configuration des vrf pour les sites 1, 2 et 3 de la connectivit Extranet
ip vrf sit e 1 rd 100: 1 route-target export 100 1 route-target import 100 1 ip vrf sit e 3 rd 100: 3 route-target export 100 2 route-target import 100 2 ip vrf sit e 2 rd 100: 2 route-target export 100 1 route-target import 100 1 route-target export 100 2 route-target import 100 2

Le second cas {cf

Figure 3.3) est plus intressant. Il reprsente le principe d'une

ressource partage, donc d'une connectivit Extranet, en donnant accs un mme

72

Le second cas {cf

Figure 3.3) est plus intressant. Il reprsente le principe d'une

ressource partage, donc d'une connectivit Extranet, en donnant accs un mme rseau (le site 2) deux VPN diffrents, A et B et par consquence aux deux sites 1 et 3. Il serait faux de penser que le simple fait de raliser cette configuration particulire est directement synonyme de bris d'tanchit ou de libert de circulafion entre le site 1 et le site 3. La notion des VPN A et B est ici assez subjective, puisqu'en fait MPLS ralise des imports/exports de routes pour permettre chaque site de voir certaines routes et d'autres pas. Les membres du site 1 vont ainsi voir les routes du site 2, mais pas les routes du site 3, et inversement les membres du site 3 ne pourront voir que les routes du site 2, mais pas celles du site 1.

Par contre, la prsence d'une route par dfaut vers la ressource partage peut permettre un intms plac dans le site 1 d'envoyer des paquets de faon unidirectionnelle du site 1 au site 3. Bien que le plan de contrle soit correct (les routes du site 3 ne sont pas dvoiles au site 1), il n'y a rien qui empche la transmission des paquets du site 1 vers le site 3. Les paquets destination du site 3 vont suivre la route par dfaut vers le site 2, or ce demier tant la ressource partage, il connat les routes des sites 1 et 3 et peut donc acheminer ces paquets vers le site 3. Si en plus la route par dfaut vers la ressource partage est acquise pour tous les clients, alors la transmission de paquets peut tre bidirectionnelle entre les sites 1 et 3.

73

Sitel

Site 3

Site 2

Figure 3.3 Reprsentation de la connectivit Extranet - Cas 2 Des tests ont t mens avec succs sur le rseau de Bell Canada pour vrifier la ralisation de cette attaque. La partie 3.3 prsente ces tests ainsi que les rsultats obtenus.

La question qui demeure concerne la lgitimit d'une route par dfaut. Si elle a sa raison d'exister, alors l'attaque est possible. Le fournisseur de service tant le seul grer les PE o cette route doit tre ajoute, il n'est pas impossible que des erreurs de configuration existent. En outre, l'attaquant pourrait tromper le fournisseur en faisant de l'ingnierie sociale, lui demandant d'ajouter la route par dfaut dans un VRF lui appartenant vers une ressource sur laquelle il a le droit d'accs, ce qui semblerait lgitime au fournisseur. Si ce dernier ne .se laisse pas avoir, le .seul moyen resterait l'injection de cette route, via le protocole MP-BGP. Afin de vrifier si une telle injection est possible, nous avons dans le chapitre 4 ralis une tude de la scurit du protocole BGP.

74

Par ailleurs, il ne faut pas faire confiance au CE de la ressource partage. tant gr par le client, des erreurs de configurations volontaires ou pas peuvent tre prsentes. Mais mme si ce demier est bien gr et n'annonce pas de routes ne lui appartenant pas, l'attaque reste possible. Toutefois, s'il est corrompu, la route par dfaut n'est plus ncessaire.

L'utilisation de pare-feux est en tout cas indispensable dans une telle architecture. Le partage d'une ressource est possible en utilisant l'architecture MPLS/VPN, mais cela sort du cadre classique prsent dans la RFC4364.

L'accs Intemet prsent dans la partie suivante peut poser un problme similaire, tout en simplifiant la lgitimit de l'existence de la route par dfaut entre les PE. Cette architecture est cependant plus complexe analyser, car des passerelles, NAT et parefeux sont dj prsents pour bloquer les attaques en provenance d'Intemet. 3.2 Menace s lies une connectivit Interne t

Souvent, les clients d'un foumisseur de service MPLS/VPN souhaitent un accs Intemet en plus de leur VPN. 11 existe plusieurs faons de foumir cet accs.

La premire mthode consiste placer Intemet dans un VRF. Cette mthode ne remet pas en question la scurit du cur du rseau, mais exige beaucoup de mmoire dans les PE afin de stocker dans les VRF toutes les routes Intemet. Si les routes d'Intemet sont stockes dans un routeur CE supplmentaire situ entre le PE et le foumisseur d'accs Intemet, cela permet d'conomiser de la mmoire d'une part, un prfixe stock dans un VRF prenant plus de place que dans la table de routage globale, d'autre part le routeur CE permet de protger le routeur PE, en tant la seule interface publique visible. Si l'espace d'adressage CE-PE n'est pas annonc (ce qui inclut l'adresse du PE), aucune

75

attaque ne pourra se porter directement sur le PE, ce qui renforce encore plus la scurit du rseau contre les attaques provenant de l'Intemet.

La seconde mthode suppose d'effectuer le routage Intemet directement dans le cur. Le cur du rseau MPLS/VPN devient semblable au cur d'un rseau IP : les tables de routage de chaque routeur (P, PE) sont ufilises afin de raliser le routage. Le cur n'est plus invisible d'Intemet et comme des VPN utilisent le cur, il faut empcher avec des listes d'accs situs sur les PE de pouvoir joindre tout routeur P ou PE du cur. Cette mthode reste tout de mme plus dangereuse pour le rseau que la prcdente.

La troisime possibilit utilise MPLS seul pour tablir des LSP entre les PE des clients souhaitant se cormecter Intemet et le PE d'accs Intemet. Des sessions iBGP pennettent aux PE de communiquer entre eux les tables de routage Intemet sans que les routeurs P ne s'en proccupent, ces demiers n'ont donc pas maintenir de l'information quant au routage Intemet. Par contre, ces demiers sont joignables de faon unidirectionnelle depuis Intemet au travers du PE d'entre (ce demier connaissant les routes menant aux routeurs P du cur), ce qui ncessite l aussi l'utilisation de listes d'accs adquates pour viter les attaques de type dni de service.

Quelle que soit la mthode employe (VPN, IP, MPLS), la sparation des VPN n'est pas remise en cause. Cependant, le rseau MPLS devient sensible aux attaques de dni de service en provenance d'Intemet, et selon la mthode employe le cur du rseau peut tre attaqu. La connectivit Intemet doit tre considr avec pmdence, les clients concems se retrouvant face aux mmes types d'attaques que dans un rseau IP classique, le foumisseur du rseau doit donc prendre les mesures ncessaires pour se protger (pare feu, IDS, antivims).

Nonobstant, les attaques ne proviennent pas uniquement d'Intemet. En utilisant la premire mthode (Intemet dans un VRF), le mme type d'attaque que dans la

76

connectivit Extranet peut se produire. Si l'adressage des clients est public, la Figure 3.4 montre la configuration raliser. Le pare-feu, situ dans le CE Intemet, doit alors imprativement filtrer tous les paquets, quelle que soit leur provenance pour viter que des paquets provenant du VPN d'un client pntrent le VPN d'un autre client (voir les tests raliss dans la partie 3.3 pour plus de dtails).

Inlftrn-:^! Sfi.r>.'ir,p.

Proviclar

^:---', :n:3rri2; CE

-1
Incnot P L \'Fh, Clist:;rr-t:Custonc PE
. - .. )

-'"T^TVPN Custcrne^

f,. / ^

p Cuf.:"rrr, V_ ^ . P

r E

VPN Ciislcrrir;;-

C -

'^'.' -

-kwi-i!-:

A. r- -

'Y "'' '

X i '-^^
i. - "p n
. , ' _ _

in';;rr;ol Cuslcmu'

l' h

!' :

\=} .

1 .

Figure 3.4 Connectivit Internet dans un VRF (Tir de Behringer et Morrow, 2005) Si l'adressage des clients est priv, la situation est diffrente car un NAT doit tre employ pour faire la traduction d'adresses prives en adresses publiques. La Figure 3.5 prsente le cas de plusieurs clients qui partagent un accs Intemet ainsi que le NAT charg de faire la traduction d'adresses publiques/prives. Si les espaces d'adressage des diffrents clients (ici 1, 2 et 3) ne se recoupent pas, ils peuvent partager le mme VRF puis la mme passerelle Intemet.

77

C u S . ' O " f. " 1

"' ' " " 1

i l.

pr
i^riif,'"

Ji

u;
; .i:\
-

'.'-^
" " " " " '

C--f

\'-.~ 1

V..
;
- M
-' 1

T" /
I

' |..
.'l'K.::

~T1.
f

: .

,,
1

!
..1..

. ... ,>^

'*.

^
'C':':':

"1 '^

'*

Figure 3.5 Accs partag Internet (Tir de Behringer et Morrow, 2005) La scurit dans cette situation peut tre garantie uniquement si les paquets provenant d'un client sont forcs de se rendre au moins jusqu'au pare-feu avant de pouvoir tre routs. Si la passerelle Intemet effectue un routage dynamique en fonction de la destination des paquets au lieu de se limiter la traduction d'adresse, il peut tre possible un des clients d'envoyer des paquets aux autres clients partageant le VRF Intemet. Cela ne sera par contre pas possible en forant les paquets se rendre au-del du pare-feu avant d'tre routs.

En conclusion sur la connectivit Intemet, le maintien de la scurit du rseau et de la sparation des VPN se limite donc dans certains cas la robustesse d'une liste d'accs. Pour respecter le principe de dfense en profondeur, il serait ncessaire d'ajouter d'autres lments comme un IDS ou des pare-feux la bordure du rseau. Ou d'utiliser la premire mthode, qui n'expose aucun lment du cur du rseau mais ncessite plus de mmoire.

78

Concemant l'attaque d'un VPN vers un autre VPN, la connectivit Intemet rend valide une des hypothses/conditions de la connectivit Extranet, la route par dfaut. En l'absence de pare-feu, cette attaque est ici possible. Cependant, le fait d'avoir Intemet impliqu rend indispensable l'utilisation de pare-feux. La scurit peut finalement tre garantie en respectant quelques rgles, comme l'obligation de filtrer tous les paquets et non pas seulement les paquets en provenance d'Intemet, et en imposant tous les paquets de se rendre au-del du pare-feu avant d'tre routs. 3.3 Test s d'tanchit d e l'architecture Extrane t

Nous voulons montrer dans ces tests l'existence de failles dans la technologie Extranet (aussi dnomme hub-and-spoke), dans laquelle plusieurs VPN ont accs une

ressource partage. Normalement il devrait tre impossible pour un client d'un VPN de pouvoir communiquer avec un client ou n'importe quelle machine d'un autre VPN au travers de la ressource partage, c'est--dire en utilisant la ressource partage comme proxy. Le fait d'avoir accs une ressource partage n'inclut pas la possibilit de laisser l'accs aux ressources d'un site appartenant un autre VPN, grce aux imports/exports de route tel que prsent dans la section 3.1.

La Figure 3.6 prsente un exemple d'architecture Extranet. Les VPN A et B sont indpendants et communiquent avec la ressource partage. Les imports/exports de routes sont rgls de telle faon que les VPN A et B ne s'changent pas leurs routes.

79

Figure 3.6 Schma de l'architecture Extranet (Tir de Behringer et Morrow, 2005) Or, d'aprs Behringer et Morrow, il semble possible que si un client du VPN A connat ou devine l'adresse d'un client du VPN B (dans l'exemple, 193.0.1/24), il puisse envoyer de faon unidirecfionnelle des paquets vers le VPN B. Ceci serait suffisant pour envoyer un ver ou un virus.

Nos tests vont consister tenter de reproduire cette exprience. Pour cela nous allons ufiliser le rseau MPLS de test de Bell Canada. Il s'agit d'une plate-forme de routeurs Cisco interconnects par diffrentes technologies de niveau 2 (ATM et Ethemet) et implmentant MPLS (RFC4364). Les LER (routeurs PE) sont des 3725, les LSR (routeurs P) sont des 7206. La version de l'IOS est 12.3(8r2)T. La configuration ncessaire pour les tests est prsente ci-dessous.

80

LO-172 20.254 32 ijigOO

LAB MPL S - TES T Qo S

Agilenl N2 X 172 11 6 22 7 1 1 0

..S3

-nrateurs de . icsurle N2X

VLANs ET31 5 0 ETS2 6 0 ETS3 7 0

U)-1T2.20 2541 3 gao

Customer site 3

VRF ETS3 / 10.70.31,0/24 / VLAN 52 5 100 2

/' \

\ VRFETS 2 \ l O 60.3 1 0/2 4 2

FrameScope 2 ^

Figure 3.7 Schma 'Visio du rseau de test de Bell Canada Sur le customer site 3, deux instances VRF ETS2 et ETS3 sont configures pour reprsenter deux clients indpendants. La ressource partage est ici reprsente dans le customer site 1, dans le VRF ETSl. Les VRF ETS2 et ETS3 exportent leurs routes au VRF ETSl situe sur le Customer Site 1, et importent les routes du VRF ETSl selon les tableaux prsents ci-dessous. De mme, le VRF ETSl importe les routes des VRF ETS2 et ETS3 et exporte ses propres routes.

Tableau 3.2 Configuration des VRF sur le PEl

ip vrf ETS l rd 65000:5 0 route-target G.xport 65000 50 route-target import 65000 50 route-target import 65000 60 route-targe t import 65000 70
1

ip vrf ETS 2 rd 65000:6 0 route-target export 65000 60 route-target import 65000 60

ip vrf ETS3 rd 65000:7 0 route-target expor t 6500 0 70 route-target impor t 6500 0 70

Tableau 3.3 Configuration des VRF sur le PE3

ip vrf ETSl rd 65000:5 0 route--target export 65000 50 route--target import 65000 50 ip vrf ETS2 rd 65000:6 0 route--target export 65000 60 route--target import 65000 60 route--target import 65000 50 ip vrf ETS3 rd 65000:7 0 route--target export 65000 70 route--target import 65000 70 route--target import 65000 50

Dans ces tableaux les informations essentielles, autrement dit les imports/exports de routes ajouts une configuration classique de VPN indpendants qui permettent de partager une ressource situe dans le VRFl du customer site 1, sont indiqus en gras.

82

Afin de raliser les tests, nous utilisons des appareils mobiles tout faire FrameScope Pro de Agilent. Bien que ces appareils soient capables de raliser une multitude d'acfions (tests de connectivit, gnration de trafic, etc.), nous allons nous limiter la fonctionnalit traceroute afin d'observer ce qui se passe lorsque nous tentons de communiquer entre diffrents VPN. Les FrameScope Pro sont branchs respectivement derrire CEI et CE3 avec les dtails prsents dans le tableau ci-dessous.

Tableau 3.4 Disposition des FrameScopePro dans le rseau

FrameScope 1 2

Posifion Derrire CEI Derrire CE3

VLAN 511 535

VPN correspondant ETSl ETS3

Adresse IP 10.50.11.101 10.70.31.100

Afin d'observer le contenu des paquets transitant sur le rseau, nous utilisons en outre un sniffer Agilent DNA Pro positionn entre PEl et CEI. Dans un premier temps nous allons vrifier que le rseau fonctionne bien en envoyant un paquet dans un mme VPN d'un site l'autre. Ensuite, nous gnrerons des paquets dans le VRF ETS3 destination d'un poste dans le VRF ETS2, en utilisant une adresse IP de destination appartenant au VRF ETS2. La commande traceroute va tre ufilise. Elle permettra de tester la connectivit entre les VRF ETS2 et ETS3, et en outre d'afficher le chemin suivi. 3.3.1 Tes t de communication ave c la ressource partag e

Afin de voir ce qui se passe lors d'une communication lgitime, nous ralisons d'abord un traceroute du FrameScope 2 vers le FrameScope 1. tant donn que le VRF ETS1 dans PEl exporte ses routes vers le VRF ETS3 et que le VRF ETS3 dans PE3 importe

83

toutes les routes du VRF ETSl, les deux FrameScope peuvent se parler bien qu'tant dans des VRF spars. Cela est normal, ETSl est la ressource partage donc atteignable par ETS 3. La commande tracer-oute donne le rsultat contenu dans le tableau ci-dessous.

Tableau 3.5 Rsultat de la commande traceroute vers la ressource partage

#traceroute 10.50.11.101 1. 10.70.31.1 2. 10.70.3.1 3. 172.20.1.17 4. 10.50.1.1 5. 10.50.1.2 6. 10.50.11.101 (CE3 - interface VLAN 535) (PE3 - interface VLAN 70) (P3 - signifie que le MPLS traceroute est actif) (PEl - interface VLAN 50) (CEI-interface VLAN 511) (FrameScope 1)

La capture d'cran suivante montre ce qui est observ par l'analyseur entre PEl et CEI.
Src. Address 172 20 1 1 7 172.20.ri7 10 70.31 10 0 10.50.1 2 10 70.31 10 0 1050.11.101 DestAddr 10 70 31 10 0 10.70.31.100 105011.101 107031 100 105011.101 107031100 Protocol VLAH VIAN VUi.N VLi.M VUN VIAM Description IP 172201 17 - 10703 1 100ld= 4504 6 : IF ' Tmi ey.r^^deo 1 IP 172.20.1.17 > 107031.100 ld=45046 IP 1070.31.100-> 105011.10 1 ld= 2 4 : IP 10.501.2-> 107031.100ld= 378G 7 IP lO70.-31.100-> 105011.10 1 ld=25 .: ' . ::. IP 105011.101 > 107031.100 ld=52 . bifi a teoiy

Figure 3.8 Capture d'cran d'un traceroute lgitime Les deux premiers paquets correspondent au saut 3, certes le TTL a expir avant d'atteindre CEI, mais comme il a expir dans le nuage MPLS (sur le routeur P3), les

84

paquets ICMP sont forcs de sortir du rseau MPLS en poursuivant leur route jusqu'au CEI avant de pouvoir retoumer vers l'metteur du paquet, situ de l'autre ct.

Les deux paquets suivants correspondent au saut numro 5, le CEI rpond alors au message ICMP Echo r-equest par un ICMP Time Exceeded (voir le fonctionnement de la commande tr-aceroute (Hares et Wittbrodt, 1994) pour plus de dtails).

Finalement, les deux demiers paquets correspondent au demier saut, avec cette fois-ci un message ICMP Echo Reply en rponse puisque la destination a t atteinte. 3.3.2 Tes t de communication ave c un VPN non partag

Maintenant que nous avons vu ce qu'il se passe lors d'un change lgitime, nous allons tenter de faire communiquer un client de ETS3 avec un client de ETS2. Comme le VRF ETS3 dans CE3 et PE3 ne connat aucune route vers le VRF ETS2, il est ncessaire d'ajouter une route par dfaut vers le VRF ETSl. Cette route par dfaut peut sembler lgitime car le VRF ETSl reprsente la ressource partage et ce titre, accepte les paquets provenant de ETS3. Le paquet devrait donc partir de ETS3 sur PE3, dans un premier temps atteindre ETSl sur le CEI (la ressource partage), et en cas de succs de l'attaque rejoindre ETS2 sur PE3.

Deux routes par dfaut ont donc t ajoutes. La premire route par dfaut a t place dans le PE3 au niveau du VRF ETS3. Celle-ci pointe sur l'interface du VLAN 511 au niveau de CEI, c'est--dire l'adresse 10.50.11.1. De plus, une seconde route par dfaut a t place dans le CE3 pour diriger les paquets vers le PE3. Ainsi, il existe une route par dfaut qui permet d'atteindre le VRF ETSl partir du VRF ETS3. La lgifimit de cette route par dfaut est discute de faon plus approfondie dans la section 3.3.4.

85

Nous effectuons donc une nouvelle fois la commande tr-acer-oute vers une interface du VRF ETS2, en l'occurrence le port du routeur CE3 li ETS2. Le tableau ci-dessous montre le rsultat obtenu.

Tableau 3.6 Rsultat de la commande tr-aceroute vers ETS2 #traceroute 10.60.31.1 1. 10.70.31.1 2. 10.70.3.1 3. 172.20.1.17 4. 10.50.1.1 5. 10.50.1.2 6. 10.50.1.1
-7 *

(CE3 - interface VLAN 535) (PE3 - interface VLAN 70) (P3 - signifie que le MPLS tr-acer-oute est actif) (PEl-interface VLAN 50) (CEI - interface VLAN 511) (PEl - interface VLAN 50) (timeouts)

g **

Les quatre premiers sauts sont identiques au test prcdent. Les paquets ICMP se rendent alors jusqu'au routeur CEI, ce qui semble logique puisque la route par dfaut dans le PE3 pointe vers le VLAN 511 du VRF ETSl. Au sixime saut, nous constatons que le TTL des paquets est expir en arrivant au niveau du PEl. Ils semblent alors poursuivre leur chemin en retoumant vers le rseau MPLS. Par la suite, aucune rponse n'est reue. Tous les essais suivants, malgr l'augmentation de la valeur du TTL du paquet cho request, ne reoivent aucune rponse, et il en est ainsi jusqu'au nombre maximal de sauts paramtr dans la commande traceroute.

86

Mme si la requte n'aboutit pas, elle montre dj un premier lment positif : une fois rendus au CEI dans le VPN ETSl, les paquets ICMP semblent retourner vers le site 3. Nous allons vrifier sur la capture d'cran de l'analyseur lors de ce second test que les paquets font bien demi-tour une fois rendus au CEI.

La capture ci-dessous montre les paquets transitant entre le PEl et le CEI dans le VLAN50 (rien ne passe dans les autres VLAN entre CEI et PEl ).
Src. Address 172 20 1 1 7 172.201.17 10.70 31 10 0 1050:1.2 10 70 31 10 0 107031.100 10 70 31 10 0 10.7031.100 DestAddr 10 70 31 10 0 107031.100 10 80 31 1 1070.31.100 108031 1 1O60.31.1 10 60 31 1 'VU 1OS0.31.1 VLA Protocol VUi.M VLAN
J\J..H

VLAN VLA,H VLAN N N

Description IP: 172 20 1 17 -. 10 70 31 100 ld=l6360 ' -' - IP: 172201.17-> 10.7031.10 0 Id=ie3e0 'CHP- T-K- IP 1070.3 1 100- > 1 0 60 31 1 ld=119 ^ IP 10501.2 -> 107031.10 0 ld=32247 IP. 10.70.31 100 V 10 6031 1 ld=120 LM P Ecli o re.Je;: IP: 1O7O31.100-> 106031. 1 ld=120 '>IP- . fT^i'-'rfet';';;' IP 1 0 70 31 100-,- 1 0 60 31 1 ld=121 ,"- ' IP 107031.10 0 > 106031.1 ld=121

Figure 3.9 Capture d'cran d'un traceroute vers un VPN non partag - VLAN 50 Les quatre premiers paquets observs sont similaires aux sauts 3 et 5 du test prcdent, nous ne reviendrons donc pas dessus. Les deux lignes suivantes (Id=120) correspondent au sixime saut. Comme ce moment prcis le paquet ICMP fait d'abord le trajet PEl -^ CEI puis CEI -^ PEl, il apparat deux fois sur l'analyseur. Les adresses MAC

releves par l'analyseur sont inverses entre les deux lignes confirmant l'ide du retour. Les deux dernires lignes (Id=121) correspondent au septime saut, et sont assez similaires aux prcdentes concernant l'aller-retour vers le CEI.

Les paquets correspondant aux sauts suivants n'ont pas t inclus dans la capture cidessus, leur trace sur l'analyseur quivalant aux quatre dernires lignes de la capture. Nous remarquons aussi que vu l'emplacement de l'analyseur, nous ne pouvons recueillir les rponses des sauts 6 et suivants, le cas chant. En effet, lorsque le TTL de la requte ICMP devient nul en arrivant sur le PEl au saut 6, le chemin le plus direct depuis le PEl vers le CE3 (VRF ETS3) ne passe pas par le CEI.

87

Ce test met en avant un problme : mme si les paquets mis parviennent rejoindre le VPN ETS2, il est impossible d'avoir une rponse car ETS2 ne connat pas de route pour accder l'adresse source des requtes ICMP contenue dans ETS3. C'est pour cela qu'aucune rponse n'est reue aprs le saut 6.

Plusieurs possibilits s'offrent nous : soit nous dplaons l'analyseur entre PE3 et CE3 afin de regarder si des requtes passent dans le VLAN 60 (correspondant ETS2) entre ces deux routeurs, soit nous ajoutons une route par dfaut dans ETS2 (au niveau du PE3 et CE3) pour envoyer les paquets vers ETSl, pour ventuellement permettre une communication bidirectionnelle.

Comme il ne semble pas logique d'ajouter une route par dfaut supplmentaire dans le VRF ETS2 (puisque celui-ci est la cible de l'attaque), nous allons dplacer l'analy.seur entre PE3 et CE3. Cela ne permettra pas d'avoir de rponse la commande tracer-oute, mais au moins il sera possible de voir si les requtes ICMP se rendent jusque dans le VLAN 60.

La capture d'cran ci-dessous correspond aux paquets traversant le VLAN 60.

Src. Address 172201.30 172201.30 107031 10 0 10 7 0 3 1 10 0 10 703 1 10 0 107031 100 107031.100 DestAddr 1070.31.100 10 70. .31 100 106031 1 10 6 0 3 1 1 106031 1 106031 1 106031.1 Protocol VLAN VIA.N yL.N VLAN VL.N VLAN VWN Description IP 1 7 2 2 0 1 30- > 1 0 7 0 31 10 0 ld= 1054 8 ;

e:.,c.e;de. d lri-!;.3n:.i (

IP: 17 2 20.1.3 0 > 10 70.31 10 0 ld= 1056 8 , = *;-:cerded In-tranLi t IP 107031.100- > 1 0 6 0 3 1 1 ld=225 -CM P Echo leque t IP- 1 0 70 31.100 > 10 60 31 1 ld=226 MIMP : Ech o reque: t IP 10.7031.10 0 > 1 0 6 0 3 1 1 ld=228 J L M P Ech o reques t IP 10.7 0 31.10 0 > 10 60 31 1 ld=229 I : M P Echo reque:. t IP: 10.703 1 100- > 10.6031. 1 ld= 23 1 iCM P Ech o iequ.;: t

Figure 3.10 Capture d'cran d'un traceroute vers un VPN non partag - VLAN 60

88

II faut noter en premier lieu que comme tous les paquets observs ne peuvent retoumer leur origine (aucune route n'tant connue dans le VPN ETS2 pour joindre le VPN ETS3), ils crent tous un timeout la source (le FrameScope 2 dans ETS3). Celui-ci va raliser deux tentatives pour chaque saut. Si aucune rponse n'est reue, alors il va incrmenter le TTL de 1 et raliser deux nouvelles tentatives.

Les deux premiers paquets correspondent au saut 7 (le routeur P3, lors du retour vers PE3). Nous observons ici la rponse car il s'agit d'un routeur MPLS qui doit faire suivre la rponse la sortie du rseau MPLS avant de pouvoir la renvoyer l'metteur.

Les deux paquets suivants (Id=225, Id=226) correspondent au saut 9 (le saut 8 vers le routeur PE3 n'est pas observ cause de la position de l'analyseur entre PE3 et CE3). Bien qu'ils atteignent leur desfination (CE3, avec l'adresse 10.60.31.1), aucune rponse ne peut tre mise cause de l'absence de route par dfaut dans le VRF ETS2 de CE3.

Le FrameScope ne pouvant savoir que la destination a t atteinte, il continue envoyer des paquets en incrmentant le champ TTL. Les paquets 5 et 6 ont un TTL de 2 en sortant de PE3, le paquet 7 (demier enregistr, mais d'autres suivraient en continuant l'exprience) a un TTL de 3.

Tableau 3.7 Dduction de la commande traceroute complte vers ETS2

#traceroute 10.60.31.1 1. 10.70.31.1 2. 10.70.3.1 3. 172.20.1.17 4. 10.50.1.1 (CE3 - interface VLAN 535) (PE3 - interface VLAN 70) (P3 - signifie que le MPLS tracer-oute est actif) (PEl - interface VLAN 50)

89

5. 10.50.1.2 6. 10.50.1.1 7. 172.20.L3 0 8. 10.60.3. 1 9. 10.60.31. 1

(CEI - interface VLAN 511) (PEl - interface VLAN 50) (P3 - interfac e d u ct de PEl ) (PE3 - interfac e VLAN 60 ) (CE3 - interfac e VLA N 533 ) - destinatio n atteint e

Grce ces nouvelles observations, nous pouvons maintenant obtenir le chemin complet des paquets vers ETS2. En gras sont indiqus dans le tableau ci-dessus les sauts dduits des observations subsquentes au dplacement de l'analyseur. En conclusion, il a bien t possible d'envoyer des paquets dans le VRF ETS2 en partant du VRF ETS3 en transitant par le VRF ETSl, l'aide d'une route par dfaut. 3.3.3 Vrificatio n d u succs de la communication ver s ETS2

Afin de confirmer que les paquets mis par le FrameScope2 depuis le VPN ETS3 ont bien t reus par le VPN ETS2, nous tentons une autre exprience consistant brancher le FrameScope 1 dans le VPN ETS2 derrire CE3, c'est--dire sur le VLAN 533, et d'essayer de le rejoindre depuis le FrameScope 2, toujours branch dans le VPN ETS3 derrire CE3 (VLAN 535).

Nous lanons depuis le FrameScope 2 (dont l'adresse est 10.70.31.100) la commande traceroute vers le FrameScope 1 qui possde l'adresse 10.60.31.100. Bien que les rsultats obtenus par le FrameScope 2 soient toujours ngatifs, pour les mmes raisons que prcdemment, un vnement intressant se produit au niveau du FrameScope 1.

Une

des

spcificits

des

FrameScopes

est

d'afficher

par

dfaut

leur

environnement rseau, c'est--dire tous les quipements rseaux tels que routeurs, ordinateurs, serveurs, etc. auxquels ils sont connects, en utilisant les paquets qu'ils

90

reoivent (mises jour des protocoles de routage, entre autres). Ces quipements peuvent tre dans le mme sous-rseau mais aussi distants. Or le FrameScope 1, aprs le saut 9 de la commande traceroute

mise par le

FrameScope 2, affiche sur son cran une nouvelle stafion distante, avec l'adresse 10.70.31.100, autrement dit l'adresse du FrameScope 2. 11 y a bien une connecfivit entre les deux FrameScopes, donc entre les deux VRF ETS2 et ETS3, bien que celle-ci soit unidirecfionnelle ETS3 -^ ETS2. 3.3.4 Bila n

Ces tests ont montr que sous certaines conditions une ressource partage peut permettre deux VPN ne se voyant pas de pouvoir communiquer entre eux, au moins de faon unidirectionnelle. La condition de russite de cette communication est la prsence d'une route par dfaut vers la ressource partage dans le VRF du CE et le PE de l'attaquant.

La possibilit de deviner une adresse IP, par essais successifs par exemple, montre que la scurit par l'obscurit n'est pas suffisante pour garantir la scurit d'une architecture.

Mais, si l'adresse de destination peut facilement tre connue ou devine (surtout si l'adressage est priv), il n'en va pas de mme pour la route par dfaut. Le PE n'est en effet pas gr par le client, et le foumisseur de service ne devrait pas implmenter de route par dfaut dans les VRF, sauf pour la connectivit Intemet. Par contre, il est toujours envisageable que des erreurs de configuration soient prsentes, ou de faon plus labore le client malveillant pourrait ufiliser des techniques d'ingnierie sociale pour demander au foumisseur de service d'ajouter une route vers une zone lgitime (la ressource partage). Si le foumisseur de service n'est pas au courant des complications que cela peut causer, pourquoi refuserait-il? Une route par dfaut vers une ressource

lgitime dans un VRF appartenant au client en faisant la demande peut sembler raisonnable...

L'autre possibilit pour l'attaquant est de tenter de corrompre le protocole MP-BGP afin d'ajouter la route par dfaut. Le chapitre 4 prsente cet gard une tude de la scurit du protocole BGP.

CHAPITRE 4 SCURIT D U PROTOCOLE BG P Le but de ce chapitre est d'analyser la scurit du protocole BGP, utilis sous sa variation de MP-BGP pour raliser l'change de routes entre les diffrents VPN. Cette tude devrait aussi permettre de voir de quelle faon l'attaque dans la connectivit Extranet prsente dans les parties 3.1 et 3.3 est reproductible.

La condition ncessaire permettant la ralisation de cette attaque tant la prsence d'une route par dfaut dans le CE et le PE pointant vers la ressource partage, si elle peut tre considre comme vidente dans le CE, administr en gnral par le client, il n'en va pas ncessairement de mme concemant le PE, gr par le foumisseur de service.

Toute la difficult de cette tude est d'tablir s'il est possible d'injecter une route par dfaut dans un routeur PE, depuis le client (ou son CE), mais dirige vers la ressource partage, situe de l'autre ct de ce PE. De plus, les protocoles de routage ne sont pas toujours les mmes de part et d'autre du PE. Le foumisseur de service utilise BGP audel du PE, par contre c'est gnralement OSPF qui est utilis entre CE et PE (Rosen, Psenak et Pillay-Esnault, 2006), bien que RIP, BGP ou un routage statique soient aussi possibles. 4.1 Gnralit s su r le protocole BGP

Le protocole BGP permet le routage inter domaine. Il est notamment utilis pour changer les informations de routage sur Intemet afin de relier entre eux les diffrents foumisseurs de service, reprsents par des systmes autonomes, nomms AS. C'est en effet le seul protocole pouvant supporter un trs grand nombre de routes annoncer (actuellement, prs de 225000 routes sont contenues dans les tables de routage d'Intemet (Smith, 2007, 28 juin)) et qui permet de maintenir une certaine stabilit du routage. Pour

93

cela, BGP utilise notamment l'agrgation de routes, qui consiste runir en un seul prfixe (adresse rseau + masque explicite, par exemple 154.23.64.192/26) diffrentes adresses rseaux, en utilisant le principe de CIDR (Classless Inter-Domain Routing). Sur les 225000 routes prcdentes, l'agrgafion permet de limiter le nombre d'entres moins de 120000, soit presque deux fois moins. Le routage dans BGP fonctionne par l'change de messages UPDATE qui contiennent trois lments : Les prfixes qui ne sont plus joignable par une route prcdemment annonce. Les attributs du chemin travers depuis les prfixes annoncs, sous la forme d'un vecteur comportant les numros d'AS traverss (AS_PATH), Les prfixes qui sont annoncs. Chaque locuteur BGP (communment appel BGP Speaker) propage les messages UPDATE reus en y ajoutant son numro d'AS dans l'attribut AS_PATH, sauf s'il y apparat dj. Dans ce cas, il supprime le message reu, ce qui permet d'viter les boucles de routage. L'change de ces messages et des autres messages BGP (OPEN, etc.) se fait par l'intermdiaire de TCP. Les messages UPDATE ne sont gnralement envoys qu'en cas de changement dans le rseau.

BGP n'ayant t conu que pour transporter des routes lPv4, cela crait une limitation pour le routage de nouvelles technologies rseau. MP-BGP, qui n'est qu'une extension de BGP, a ainsi t standardis (Btes et al., 2007) pour permettre l'ajout d'informations supplmentaires aux messages UPDATE ; dans le cas des VPN sur MPLS il s'agit d'information sur les routes VPN changes {target VPN, VPN-of-origin, site-of-or-igin).

Il n'est pas quesfion ici de prsenter dans le dtail le protocole BGP, pour cela il est possible de consulter la RFC 4271 (Rekhter, Li et Hares, 2006). L'aspect qui nous intresse plus particulirement est la scurit de BGP.

94

4.2 valuatio

n de la scurit du protocole BG P

Les faiblesses lies la scurit de BGP proviennent en partie du fait que ce protocole a t cr une poque o les chercheurs taient les seuls utilisateurs d'Intemet. De nos jours, Intemet est ufilis par des millions de personnes, supporte de nombreuses applications et est ainsi sujet des attaques diverses qui remettent en cause la scurit des protocoles de routage.

Les attaques sur BGP peuvent se produire en attaquant la communication entre deux pairs BGP, mais aussi en injectant des informations errones qui vont tre reprises par les pairs BGP. L'attaque de la communication va se faire par dtoumement de session, mystification d'adresse IP ; autrement dit grce aux protocoles sous-jacents. La RFC4272, BGP Security Vulnerabilities Analysis (Murphy, 2006), prsente les vulnrabilits de BGP. Ce document dcrit les failles possibles de BGP, ainsi que la manire de les mettre profit.

La communication entre les pairs BGP peut tre sujette une coute passive ou active. Le protocole de transport, TCP, peut tre attaqu car non protg, que cela conceme les donnes de contrle, ou les donnes de la charge utile. Cela peut permettre l'injection de messages BGP sur un lien, la modification de messages BGP lgitimes, ou l'annonce illgitime de routes par un metteur BGP compromis.

Les attaques visant l'change de messages entre pairs BGP via TCP sont le fait d'un attaquant extrieur. Mais si un des pairs BGP se met annoncer n'importe quoi, les autres pairs vont relayer l'information sans mme la vrifier. Il y a ainsi quatre types d'attaques : l'annonce de prfixes illgitimes, l'annonce de sous-prfixes illgitimes (plus dangereux et plus difficile stopper que le prcdent type car lorsqu'il a le choix

95

entre plusieurs prfixes de longueur diffrente, BGP choisit prfrablement le prfixe ayant le masque le plus lev possible), mais aussi la mysfificafion du chemin dans les annonces de routes. Ce troisime type d'attaque, plus rare, survient lorsqu'un pair BGP annonce non pas qu'il possde un prfixe mais qu'il fait partie du chemin invalide vers ce prfixe, ce qui lui permet de lire les donnes qui passeront par lui. Enfin, un quatrime type d'attaque consiste dtmire des paquets de mises jour lgitimes crant ainsi des trous noirs et des boucles infinies (Ke, Xiaoliang et Wu, 2004).

Les problmes de scurit de BGP proviennent davantage du fait que l'information transmise par les pairs n'est pas vrifie (par exemple : est-ce que tel pair a le droit d'annoncer telle route), plutt que de l'authenticit des pairs BGP. Bien sr, il est prfrable qu'il n'y ait pas de pair BGP illgitime annonant de fausses routes, mais mme si c'est le cas, cela ne signifie pas pour autant que le protocole est scuris, comme l'a montr l'incident FLIX {Florida Internet Exchange, AS7007). Cet incident est survenu en 1997 lorsqu'un AS s'est mis annoncer toutes les routes de l'Internet provoquant entre autres une explosion des tables de routage et une indisponibilit globale d'Intemet. Il a t par la suite dcouvert que cet incident n'est li qu' un bug logiciel du routeur. D'autres incidents similaires (AS8584 en 1998, AS15412 en 2001, AS 174 en 2005) se sont produits par la suite. 4.3 L a scurit actuellement utilis e : MD5

La scurit dans BGP se limite plus ou moins la phrase suivante d'aprs la demire version du standard sur BGP (Rekhter, Li et Hares, 2006) : A BGP implmentation MUST support the authentication mechanism specified in RFC 2385. La RFC2385, Protection of BGP Sessions via the TCP MD5 Signatwe Option (Heffeman, 1998) prsente l'ufilisafion de MD5 (Rivest, 1992) pour empcher

l'introducfion de segments TCP mystifis dans la communication entre les voisins BGP.

96

Chaque segment TCP contient une empreinte de 16 octets obtenue en appliquant l'algorithme MD5 sur diffrents lments du segment, dans l'ordre : le pseudo-entte prfix TCP (adresse IP source, adresse IP destination, numro de protocole, longueur du segment), l'entte TCP, sans les options, et avec un checksum suppos nul, les donnes (le cas chant), une cl connue par les deux voisins, et idalement spcifique chaque connexion. Cette empreinte est place dans le champ Options de l'entte TCP. Elle permet d'authentifier les pairs BGP mais pas de vrifier les informations transmises : le chemin pris par les routes ni leur origine.

Concemant les vulnrabilits de MD5 face des attaques de recherche de collisions (montres en 1996 par Dobbertin (Dobbertin, 1996) et en 2004 par une quipe chinoise (Wang et Yu, 2005)), la seule solution suggre est le remplacement de MD5 par un autre algorithme plus scuritaire, comme SHA-1 {Secure Hash Algorithm). Cette

solution impliquerait d'ajouter un champ dfinissant l'algorithme utilis, entre autres, ce qui resterait dvelopper. L'inconvnient, c'est que la scurit de SHA-1 commence dj tre remise en question, avant mme d'avoir t adopte. La mme quipe chinoise a dcel en 2005 (Wang, Yin et Yu, 2005) des collisions compltes sur SHA-1 ncessitant 2^^ oprations, ce qui bien qu'important est ralisable avec du calcul distribu. Heureusement, ces collisions ne permettent pas de trouver partir d'une empreinte fixe un message, mais ventuellement deux messages alatoires produisant une mme empreinte. Nanmoins, les experts conviennent qu'il serait maintenant prfrable d'utiliser SHA-256, comportant une cl de 256 bits au lieu de 160, la place deMD5.

L'utilisafion de MD5 pose un autre problme : celui-ci n'inclut pas de mthode de gestion des cls ufilises. Il est donc ncessaire de choisir les cls pour chaque

97

association de pairs BGP statiquement, ce qui est fasfidieux et peut augmenter le risque d'erreur long terme, si la cl n'est jamais change. L'utilisafion d'IPSec (Kent et Atkinson, 1998) ou de TLS (Dierks et Allen, 1999), parfois suggre, permettrait d'amliorer quelque peu la scurit au niveau de l'authentification des pairs. Cela n'est pourtant que trs rarement effectu.

En ce qui conceme la scurit des communications entre les voisins BGP, l'utilisation de MD5 est une solution reconnue comme faible mais utilise actuellement. En outre, cette solution ne permet pas d'empcher l'change d'infomiations fausses par les pairs BGP lgitimes. Des mcanismes plus forts devraient tre utiliss dans le futur.

Comme nous pouvons le voir, la mthode actuelle, pourtant fortement conseille (en tmoigne le MUST utilis dans la RFC4271 qui date de 2006), n'est pas infaillible ; en outre elle ne conceme qu'une partie de la scurit du protocole (l'authenficit des pairs BGP). Il peut tre ncessaire de se tourner vers les nouvelles avances proposes par BGP, que sont Secure BGP (S-BGP) et Secur-e origin BGP (soBGP). La RFC4272 suggre d'ailleurs comme solutions la protection de l'origine et de l'adjacence par l'utilisation de signatures (Smith et Garcia-Luna-Aceves, 1996), la protection de la route et de l'origine (Kent, Lynn et Seo, 2000), ainsi que le filtrage bas sur les registres Intemet pour vrifier certains attributs des messages UPDATE (Villamizar et al., 1999).

Il existe nanmoins en plus de MD5 quelques techniques permettant de renforcer quelque peu la scurit actuelle de BGP. Parmi celles-ci se trouve le mcanisme de contrle du champ TTL (Gill, Heasley et Meyer, 2004) qui s'applique surtout aux sessions eBGP en empchant d'accepter les mises jour de routage provenant d'lments distants. La partie 2.2.2.5 prsente le fonctionnement de ce mcanisme, qui toutefois n'amliore pas T authentification des chemins annoncs par les routes ni l'origine de ces demires. part ce mcanisme, les foumisseurs de service peuvent utiliser une adresse loopback ou secondaire pour raliser l'appartement avec les autres

98

routeurs BGP (Dubee, 2003), utiliser la commande de route dampening appliquant une pnalit aux routes qui changent souvent d'tat, effectuer un filtrage sur les annonces de routes reues ou mises, par exemple vrifier si telle route a le droit d'tre annonce par l'AS qui le fait, s'il est lui-mme autoris mettre tel prfixe, mettre en quarantaine des prfixes ayant fait l'objet de mises jour incessantes, bloquer les annonces de routes comportant des adresses prives, etc. 4.4 Les extensions proposes pour renforcer l a scurit de BGP

Cette partie prsente quelques extensions proposes au protocole BGP afin de le rendre plus scuritaire. Secure BGP a t la premire proposition, et semble la plus concrte. D'autres propositions ont suivi, ventuellement plus simples adapter BGP. 4.4.1 Secur e BGP (S-BGP )

Secure BGP (Kent, Lynn et Seo, 2000) est une extension permettant de rsoudre la plupart des problmes de scurit du protocole BGP, en l'occurrence S-BGP permet de s'assurer du respect des proprits suivantes : chaque message UPDATE reu de la part d'un metteur (BGP Speaker) donn provient bien de cet metteur, n'a pas t modifi durant son transport, et ne contient pas d'informations plus anciennes que celles contenues dans un message prcdemment reu, le destinataire du message UPDATE s'attendait bien le recevoir, l'metteur possdait le droit au nom de son AS d'envoyer les informations de routage contenues dans le message UPDATE, le propritaire de tout prfixe annonc dans un message UPDATE possde bien l'espace d'adressage associ (enregistr auprs d'un registre Intemet), le premier AS sur les routes annonces est bien autoris par les propritaires des prfixes atteignables annoncer ces prfixes. Ce point permet notamment d'viter des incidents du type FLIX {cf. partie 4.2),

99

l'metteur supprimant des prfixes pralablement annoncs tait bien autoris les annoncer.

Par contre, S-BGP ne garantit pas que l'metteur du message UPDATE applique convenablement les rgles de BGP et les politiques intemes l'AS de modification, d'enregistrement et de distribution du message, ainsi que de slection de route ; de mme que le pair BGP ayant reu le message UPDATE applique correctement lui aussi les rgles de BGP et politiques intemes l'AS quant accepter ou non le message UPDATE.

Ceci n'est pas permis par S-BGP car les caractrisfiques de politique locale de BGP laissent une trop grande latitude aux pairs BGP quant la faon de traiter les messages UPDATE. Remdier ceci ncessiterait de changer la smantique de BGP.

S-BGP utilise deux infrastmctures cls publiques (Seo, Lynn et Kent, 2001), bases sur des certificats X.509, pour permettre de valider les identits et autorisations des pairs BGP, des propritaires des AS et de leurs espaces d'adressage. Une de ces infrastmctures est ufilise pour l'allocafion d'adresse, l'autre pour l'assignation des AS et l'association des routeurs. Ces certificats permettent aussi de valider les routes annonces. En outre, IPSec est utilis pour protger les informations changes. Nanmoins, quelques vulnrabilits nonces ci-dessus ne sont pas corriges par S-BGP, car non dtectables par les mesures proposes.

Bien que la suggestion de S-BGP comme solution aux problmes de scurit de BGP date de 2000, elle n'est pas concrtement utilise aujourd'hui. Cela parce qu'il est difficile de dployer des infrastmctures cls publiques l'chelle de l'Internet.

100

4.4.2

Secure Origi n BGP (soBGP )

Le but de soBGP (White, 2003) est de vnfier si l'metteur d'un message BGP a le droit d'annoncer une route donne, autrement dit s'il a bien un chemin valide correspondant la route annonce. Il ne dpend pas d'une autorit centralise et ne se base pas sur le routage pour scuriser BGP. 11 propose l'utilisation d'un rseau de confiance {web-oftrust).

Afin de rester compatible avec BGP, il ne modifie pas les messages actuels mais ajoute un type de message supplmentaire, dnomm SECURITY. Celui-ci transporte des certificats authenfifiant les pairs BGP {entity certificate), les espaces d'adressage qu'ils possdent {authorization certificate) et des politiques s'y rapportant (policy certificate). Selon Cisco, soBGP ajoute S-BGP la possibilit de choisir quelles routes accepter dans un message UPDATE reu, c'est--dire la possibilit d'appliquer des politiques permettant de trier l'information reue. En outre, soBGP est prsent comme flexible, pouvant se dployer de faon incrmentielle (bien que le niveau de scurit dpende de la compltion du dploiement). Par contre, la cryptographie (IPSec par exemple) n'est pas utilise pour protger les messages UPDATE.

Le dploiement de soBGP ncessite de mettre jour les logiciels de routage dans les routeurs, d'ajouter une infrastmcture permettant de gnrer des certificats, et une entit d'authentification des certificats provenant de l'extrieur. En 2003, le code pour l'IOS Cisco tait en dveloppement, aussi des drafts ont t soumis l'IETF, mais date aucune RFC n'est sortie ce sujet. 4.4.3 Prett y Secure BGP (psBGP )

Pretty Secure BGP (Kranakis, van Oorschot et Wan, 2005) est une proposition d'extension BGP cre en 2005. Elle est suppose combiner le meilleur de S-BGP et

101

de soBGP. Un de ses avantages est de pouvoir se dfendre contre des attaques de pairs BGP mal configurs ou mal intentionns.

PsBGB approuve l'ide de S-BGP de crer une entit PKI centralise pour authenfifier les numros d'AS, se basant sur les autorits comptentes telles l'IANA {Inter-net Assigned Number Authority), l'ICANN {Iriternet Corporation of Assigned Numbers and Names) et les registres Intemet rgionaux (RIR, Rgional Internet Registry). PsBGP utilise un modle de confiance centralis pour raliser l'authentification des numros d'AS. Chaque AS obtient un certificat pubhc de l'une des entits de certification comme les RIR, associant une cl publique un numro d'AS.

Par contre, PsBGP part du principe qu'il est difficile de crer une PKI centralise pour vrifier l'appartenance des prfixes aux AS. PsBGP utilise donc un modle de confiance dcentralis tel que soBGP pour vrifier cette appartenance des prfixes aux AS. Chaque AS doit ainsi vrifier que les associations de prfixes et d'AS qu'il connat sont les mmes que celles de ses voisins.

PsBGP permet donc d'authentifier les numros d'AS, d'authentifier les pairs BGP, de garantir l'intgrit des donnes par l'utilisafion d'IPsec ou de MD5, de vrifier l'origine des prfixes et de vrifier la pertinence du paramtre AS PATH (attributs du chemin travers depuis les prfixes annoncs, sous la forme d'un vecteur comportant les numros d'AS traverss). La surcharge en termes de ressources existe nanmoins, tout comme pour sBGP, principalement concemant la signature ou le chiffrement des messages transmis.

4.4.4

Pretty Good BGP (PGBGP)

Pretty Good BGP (Karlin, Forrest et Rexford, 2006) est une amlioration du protocole BGP qui permet de ralentir la diffusion de routes errones en privilgiant les chemins

102

dj connus pour ces routes. Les routes suspectes sont dtectes par les routeurs en consultant une table d'informations de routage valides constmite partir de diverses informations parmi lesquelles le contenu des messages UPDATE reus auparavant. L'introducfion d'un dlai permet l'administrateur de l'AS ou des systmes automafiss de vrifier les routes suspectes dtectes. Un systme d'alerte d'attaques par courriel est propos, afin de donner la possibilit aux oprateurs de pouvoir ragir durant la phase de dlai.

Le fait d'imposer un dlai aux nouvelles routes n'est pas dommageable grce la redondance offerte par Intemet, c'est--dire grce aux multiples chemins permettant de se rendre au mme point. Au contraire, cela permet de ne pas tenir compte des problmes temporaires tout comme les oscillations de routes ; il est aussi possible de vrifier pendant ce temps la validit des routes nouvelles ou suspectes.

Lorsqu'une nouvelle route est annonce pour un prfixe dj connu dans la table de confiance , elle est considre pendant une dure S (par exemple 24 heures) comme suspecte. Si quand cette dure est coule la route annonce pour ce prfixe est toujours prsente dans les mises jour, elle sera considre comme valide et sera insre dans la table de confiance. Enfin, les prfixes n'tant plus annoncs depuis une dure H (variable, par exemple 10 jours) sont supprims de la table de confiance.

Un avantage de PGBGP est de ne requrir aucune modification du protocole BGP mais simplement une mise jour logicielle des routeurs. Les dsavantages de cette amlioration de BGP sont les fausses alertes positives (un changement de foumisseur de service par exemple), mais surtout la possibilit qu'un attaquant effectue juste avant l'annonce illgitime une attaque de dni de service empchant l'annonce de la route lgitime et permettant la route illgitime d'tre immdiatement considre comme valide. D'autres solufions comme S-BGP devraient tre ufilises conjointement pour viter ce genre de problme.

103

4.4.5 Inter-Domai

n Routin g Validator (IRV )

D'autres solutions ont t proposes pour amliorer BGP. Goodell, par exemple, a dvelopp un protocole appel Inter-Domain Routing Validator (IRV) (Goodell et al., 2003), permettant d'amliorer la scurit et l'exactitude de BGP en combinant des fonctionnalits de S-BGP et du registre de routage Intemet (IRR, Internet Routing Registry). Chaque AS cre un serveur IRV qui a autorit sur l'information de routage inter-domaine de son AS. Les serveurs IRV peuvent s'interroger pour vrifier et valider les messages UPDATE changs. Cela permet de dtecter une origine de prfixe de mme qu'un chemin ASPATH impropres, en dbusquant les ventuelles inconsistances avec les rponses des autres serveurs IRV. La communication entre IRV doit tre authentifie ou chiffi-e pour ne pas dvoiler de l'information sensible n'importe qui.

Un avantage de cette technologie est sa capacit avoir un dploiement incrmental, puisqu'elle ne ncessite aucun changement dans l'infrastmcture de routage. Mais sa limitation principale provient de la ncessit d'un nombre important d'IRV dans des AS distincts afin de pouvoir comparer et vrifier l'information. Une autre limitation est lie la validit des informations entres manuellement dans les IRV, pouvant diffrer de la configuration relle des routeurs. Des outils automatiques devraient tre utiliss lors de la modification de la configuration des routeurs. 4.4.6 Liste n and Whisper

Listen and Whisper (Subramanian et al., 2004) reprsente deux mcanismes ufiliss conjointement permettant de protger le plan de donnes et le plan de contrle de BGP. Listen coute passivement le plan de donnes, vrifie si les donnes envoyes sur les routes annonces parviennent destination et dcle les routes invalides en dtectant les connexions TCP douteuses (un paquet S'YN qui n'est pas suivi de paquets de donnes (DATA) dans un laps de temps donn, par exemple 2 minutes).

104

Whisper dtecte les annonces illgitimes de routes au niveau du plan de contrle en dcelant une inconsistance parmi les routes annonces par plusieurs messages UPDATE, originaires d'un mme AS mais ufilisant diffrents chemins (par exemple, le chemin lgitime et le chemin illgitime).

Ces deux mcanismes sont faciles dployer, et ne reposent pas sur une infrastmcture cls publiques ou une autorit centralise comme l'ICANN. Toutefois, ils ne peuvent que signaler un problme, sans pouvoir identifier sa source. Ils ne peuvent pas non plus prvenir des pairs BGP corrompus coutant le trafic, injectant ou supprimant des donnes. 4.4.7 Secur e Path Vector (SPV )

Le protocole Secure Path Vector (Hu, Perrig et Sirbu, 2004), utilise des primitives cryptographiques efficaces comme les arbres d'authentification et les chanes de hachage pour protger les attributs du chemin travers depuis les prfixes annoncs (le vecteur ASPATH). Ce demier est sign chaque passage par un pair BGP, le contenu du vecteur reu n'tant alors pas modifiable par les AS subsquents. L'authentification des pairs se fait au saut par saut. Les diffrentes oprations ralises utilisent des cls par AS, par poque (les messages UPDATE ayant ici une dure de vie limite) et par prfixe.

Ce protocole est cens tre plus efficace que S-BGP, en remplaant une cryptographie asymtrique coteuse en temps de calcul par une cryptographie symtrique plus lgre et par quelques simplifications. Par exemple, pour authentifier les messages des prfixes, il n'est pas ncessaire d'avoir de PKI, les prfixes devenant alors les cls publiques. Ceci est permis par la cryptographie base sur l'identit (IBC, Identity Based Cryptography).

105

Il suffit alors l'autorit de certification de crer les cls prives correspondantes, utilisant de la mme faon les prfixes comme cls publiques. 4.4.8 Topology-base d dtectio n o f anomalous BG P messages

Kmegel (Kmegel et al., 2003) suggre une technique permettant de dtecter et de bloquer les annonces de routes illgitimes en coutant passivement le trafic de contrle BGP. En utilisant les informations de localisation gographique disponibles dans les bases de donnes whois, une distinction est faite entre les AS de la dorsale Intemet (les nuds curs) et les autres AS (nuds priphriques). Un chemin lgitime doit contenir au plus une seule squence de nuds curs traverss, ce qui signifie qu'un chemin traversant plusieurs nuds curs puis un nud priphrique et nouveau des nuds curs a toutes les chances d'tre illgitime et dtoum par un AS malveillant. Par ailleurs, un chemin lgitime ne doit passer que par des nuds priphriques gographiquement proches les uns des autres. En constmisant un graphe de connectivit des AS et en analysant le contenu de l'attribut AS_PATH, il est alors possible de dterminer si le chemin reu est lgitime ou pas, et donc s'il faut l'accepter ou le bloquer.

Cette mthode a l'avantage de fonctionner sans aucune modification de l'infrastmcture et ne ncessite pas un dploiement important pour tre performante localement, se basant sur la connectivit des AS pour vrifier la cohrence des annonces de routes avec la topologie du rseau. C'est donc une mthode simple implanter. Les limitations de cette solution sont lies la modification de la topologie rseau, l'ajout de nouvelles cormexions entre AS par exemple pouvant tre peru comme un dtoumement du chemin. Il serait ncessaire avec cette solution de recrer le graphe de connectivit lorsqu'un changement dans la topologie survient.

106

4.5 Bila

BGP est un protocole qui n'a pas t conu avec l'ide d'tre scuritaire, mais fonctionnel et efficace. Ce qui au dpart n'tait pas un obstacle se rvle aujourd'hui tre un problme pour l'Internet tout entier, car celui-ci dpend de ce protocole pour raliser les annonces de routes travers la plante.

Bien que plusieurs extensions aient t proposes pour amliorer la scurit de BGP (SBGP, soBGP, psBGP, PGBGP, mais aussi IRV, SPV, Listen&Whisper, etc.), elles ne sont pas encore mises en uvre de faon pratique. Des problmes de gestion et de performance (Zhao, Smith et Nicol, 2005) restent tre rsolus, la surcharge cre par l'ajout de la scurit en termes de bande passante, d'utilisation de la mmoire et du processeur tant loin d'tre ngligeable. La scurisation de BGP existe donc aujourd'hui principalement sous la forme de surveillance manuelle et de l'utilisation de filtres (par exemple, le mcanisme de TTL lev) par certains foumisseurs de service. Bien que cela ne permette pas d'empcher les attaques, toute irrgularit peut tout le moins tre dtecte (Dubois et al., 2004). La seule notion de scurit qui a t ajoute BGP depuis ses dbuts est l'obligation d'ufiliser MD5 pour authenfifier les pairs BGP. Mais cette solution (cf section 4.3) ne rend pas le protocole BGP compltement scuritaire. Elle permet tout au plus d'viter l'injection de messages dans la communication entre deux pairs et aucunement de vrifier la lgitimit des pairs.

En comparant les extensions actuellement proposes, il est vident que les plus avances semblent tre S-BGP et soBGP. Pour parvenir un objectif similaire S-BGP (scuriser le protocole BGP), soBGP emploie une mthode diffrente avec l'ajout d'un nouveau type de message (SECURITY), alors que S-BGP ne change pas la smanfique ou le vocabulaire utilis. S-BGP n'est pas pour autant plus simple mettre en uvre. Cela est d aux choix de conception architecturaux dans les deux cas, les infrastmctures

107

hirarchiques cls publiques. Par ailleurs, de l'avis de la plupart des experts travaillant sur la scurisafion de BGP, S-BGP est trop lourd pour tre dploy.

PsBGP, une ide plus rcente, se situe mi-chemin entre S-BGP et soBGP, essayant de combiner leurs meilleures ides - architecture centralise et dcentralise. Mais comme ces deux extensions, psBGP essaye de se concentrer sur la scurit au dtriment des performances. La cryptographie utilise dans ces extensions ajoute une surcharge non ngligeable, voire trop importante, tout comme la ncessit d'employer infrastructures cls publiques, lourdes mettre en place. des

PGBGP apporte la simplicit, sans ncessiter d'architecture lourde ou de chiffrement des messages, mais induit un dlai avant acceptation des mises jour. La convergence du protocole est alors moins rapide, ce qui est une limitation importante, surtout dans le cadre de MPLS, pouvant crer des associations d'tiquettes VPN rompues.

La solution est peut-tre parmi les propositions plus lgres mettre en place, comme IRV, SPV, Listen&Whisper, etc. Il reste voir si ces solutions vont tre dveloppes dans le futur.

Pour la plupart des solutions, c'est la centralisation de l'information qui pose problme : qui doit jouer ce rle? qui est-il possible de faire confiance? En outre, la plupart des solutions impliquent une utilisation de la cryptographie, la modification du protocole BGP, du logiciel des routeurs, etc. Vu le dploiement actuel de BGP, il est ainsi ais de comprendre pourquoi aucune n'a t jusqu'ici adopte.

108

4.6 Lie

n avec les tests ralis s

Concemant le point qui a suscit cette tude, savoir si la faille trouve dans les tests prcdents est valable, et quelles mesures adopter pour la prvenir, considrons diffrents cas : Si la ressource partage est utilise pour accder Intemet, une route par dfaut est obligatoire pour permettre l'accs Intemet. L'ufilisafion de pare-feux est indispensable. Si BGP est correctement configur sur le rseau, il n'est normalement pas possible d'injecter une route dans le PE depuis un routeur qui ne fait pas partie des pairs BGP lgitimes, mme sans utiliser des versions amliores de BGP comme S-BGP ou SecureBGP. De simples listes d'accs doivent suffire. La seule possibilit consisterait se faire passer pour un voisin {BGP neighbor) en mystifiant l'adresse IP {IP spoofing) d'un routeur du rseau MPLS. Est-ce toutefois ralisable? Dans notre cas, les signatures MD5 ou l'authenfification de l'origine (Aiello, loannidis et McDaniel, 2003) devraient tre ufilises, afin d'viter des mises jour par un utilisateur non autoris.

Il faut noter que dans le cas de notre tude, il n'y a qu'un seul AS. Mais ici, ce n'est pas BGP qui est utilis pour faire le routage inter-domaine, mais son extension MP-BGP pour raliser l'change de routes VPN entre les routeurs PE. Nonobstant, MP-BGP se comporte exactement de la mme faon que BGP et ne change pas les problmes de scurit existant dans ce demier.

MPLS ne donnant pas accs au cur du rseau, la mthode permettant d'attaquer MPBGP en se plaant entre deux pairs et en attaquant le protocole TCP pour injecter des mises jour est difficilement ralisable. MP-BGP ne s'excutant qu'entre les routeurs PE et non pas l'extrieur du cur, il n'y a aucun point d'accs pour un attaquant. De plus, le vol de session TCP n'est pas ncessairement vident, bien que faisable.

109

L'autre mthode, qui consiste corrompre un pair BGP pour mettre des mises jour illgitimes ncessite de prendre le contrle d'un routeur PE. En respectant les conseils prcdemment noncs et les recommandations du chapitre 3, il ne devrait pas tre possible de raliser cette opration.

CHAPITRE 5 PRCEPTES FONDAMENTAU X Ce chapitre a pour objectif de suggrer des principes de base suivre afin de permettre de garantir le fonctionnement scuritaire des rseaux privs virtuels sur MPLS en considrant l'tat actuel des standards et les moyens aujourd'hui disponibles. Quelques conseils ont dj t mis tout au long de ce mmoire, en particulier au fil de l'analyse des failles possibles se basant sur des rseaux existant. Certains de ceux-l, dj voqus, sont nanmoins examins de nouveau, sous un angle diffrent cette fois, puisque cette partie propose d'valuer au pas pas l'laborafion d'un plan de scurit sur MPLS en suivant les tapes de la cration de ce demier. Bien entendu, ils sont galement enrichis d'autres principes couvrant certains points qui n'ont jusqu' maintenant toujours pas t abords. Concrtement, la cration d'un VPN dans un rseau MPLS est analyse. chaque tape, les failles possibles et des conseils sont prsents. Ensuite, des recommandations plus gnrales sont donnes. 5.1 Scurit de la cration d'u n VP N dans un rseau MPLS/VP N

Cette partie prsente une tude de la scurit du design de MPLS/VPN. Chaque tape ncessaire la cration d'un VPN sur le rseau MPLS/VPN est dpendante de protocoles, qu'il s'agisse de protocoles de routage, de signalisation, etc. Ces protocoles peuvent contenir des failles exploitables sous certaines circonstances.

L'objectif de cette tude est de prsenter pour chaque tape majeure de la cration du rseau MPLS/VPN les failles possibles, et les recommandations sous forme de conseils permettant d'viter qu'un attaquant ne puisse exploiter quelque faille que ce soit.

Cette tude se base sur un rseau MPLS/VPN mono-cur, et ne tient pas compte des rseaux volus de type multi-curs ou hirarchiss {Car-r-ier's Carr-ier). Aussi, seuls

111

des VPN simples sont envisags. Le cas de VPN partags (accs Intemet, Extranet, etc.) a fait l'objet d'une tude particulire dans les parties 3.1, 3.2 et 3.3. Bien que l'environnement utilis soit celui de Cisco, cette tude ne considre pas les bugs et failles possibles de l'IOS Cisco.

La premire tape consiste effectuer le routage des routeurs du rseau cur MPLS, afin que les routeurs PE puissent se parler entre eux. Ensuite, il faut crer au niveau des PE une instance de VRF puis transmettre les informations sur le VRF ainsi cr aux autres PE. En outre, il faut tablir les LSP qui vont pouvoir changer les donnes par la suite dans le rseau MPLS. Le routage entre PE et CE doit aussi tre considr, puisqu'il faut bien diriger les paquets de la porte de sortie du client (le routeur CE) la porte d'entre du rseau MPLS (le routeur PE). 5.1.1 Routag e intra-cu r MPL S

Il s'agit du routage utilis au sein du rseau cur MPLS, c'est--dire entre les diffrents routeurs P et PE. Il permet aux routeurs du rseau de communiquer les uns avec les autres. 5.1.1.1 Protocole s utilis s

Un protocole de routage IGP va tre utilis, tel que RIP ou OSPF. Plus le rseau est grand, plus OSPF va tre conseill de par sa convergence plus rapide et sa meilleure stabilit. 5.1.1.2 Faille s possible s

Les failles vont ici concemer le protocole de routage ufilis, RIP ou OSPF. Les deux protocoles, bien que fonctionnant de manire assez diffrente ( vecteur de distance pour RIP, tat de lien pour OSPF), vont pouvoir tre tromps si un routeur espion {rogne

12

router) est ajout dans le rseau. RIPvl ne propose aucune protection, par exemple, contre l'annonce de routes inexistantes ou dformes.

Un dni de service peut ainsi tre cr, mais surtout lire le contenu de tous les paquets changs (en maintenant le routage des paquets). Si aucune mesure de scurisafion des changes du protocole de routage RIP n'est prise, le rseau MPLS/VPN va alors pouvoir fonctionner de manire totalement transparente, sans trouble apparent, alors que toutes les informations qui transitent par le cur vont pouvoir tre lues par le routeur espion. C'est une attaque du type Man in the middle.

OSPF est plus complexe car les messages que peut transmettre un routeur espion ne vont pas ncessairement tre pris en compte tant donn le fonctionnement de ce protocole. Nanmoins, avec une inondation prolonge, il semblerait possible de crer une attaque similaire RIP dcrite ci-dessus.

Si le routage IGP est compromis, l'attaquant va pouvoir recevoir les donnes de tout le monde - quitte les redistribuer par la suite pour que l'attaque soit transparente. Les tapes subsquentes en subiront les consquences : il y a possibilit de brche entre plusieurs VPN.

5.1.1.3

Conseils

En premier lieu, nous pouvons fortement suggrer l'utilisation des demires versions des protocoles de routage, comblant certains manques ou ventuellement certains problmes de scurit. Mais ce n'est pas suffisant. Bien que RIPv2 supporte l'authenfificafion, celle-ci se limite Tufilisation d'un mot de passe transmis en clair. Si cela permet au routeur recevant l'annonce RIP non authentifie de ne pas en tenir compte, il suffit d'couter le trafic circulant sur le rseau pour connatre le mot de passe, et ainsi l'utiliser dans un routeur espion. OSPF supporte aussi cette authentification simple.

113

Idalement, afin de ne pas pennettre un routeur espion de s'ajouter dans le rseau, il est ncessaire de raliser une authentification des voisins. Ainsi chaque routeur peut tre certain que les annonces de routes reues sont lgitimes. Deux RFC prsentaient dj en 1997 pour RIP (Baker et Atkinson, 1997) et OSPF (Murphy, Badger et Wellington, 1997) des mthodes d'authentification, utilisant MD5 ou les signatures numriques. OSPFv2 (Moy, 1998) peut pour sa part utiliser une authentification par secret partag, ufilisant MD5, similaire la signature des messages TCP par MD5 (Heffeman, 1998).

Par contre, une authentification avec l'adresse IP source ne suffit pas. Il est possible un attaquant de raliser une mystification de l'adresse IP et donc de passer outre cette authentification. Il ne faut pas se fier uniquement au simple contenu des enttes ajouts par les diffrentes couches pour raliser une authentification. Cela peut permettre de filtrer une partie des attaques, en supprimant les paquets provenant de sources non autorises, mais pas de garantir une scurit absolue.

Finalement, parce qu'il est plus difficile de briser le fonctionnement normal d'un protocole tat de liens comme OSPF comparativement un protocole vecteur de distance comme RIP, il est prfrable d'utiliser OSPF comme protocole de routage pour le rseau cur MPLS. 5.1.2 L e routage CE-P E

Le routage dans le rseau cur MPLS/VPN a cet avantage d'tre protg naturellement partir du moment o il est impossible d'accder au rseau cur. Par contre, le routage entre PE et CE est diffrent : le CE est en gnral administr par le client du service MPLS/VPN et le lien PE-CE n'est pas protg.

14

5.1.2.1 Protocole

s utilis s

Le protocole de routage CE-PE peut tre soit dynamique avec RIP, OSPF, mais aussi eBGP ou tout simplement une route statique. 5.1.2.2 Faille s possible s

Si un attaquant peut intercepter les changes CE-PE, il peut raliser une attaque Man in the Middle. Mais il n'est pas ncessaire pour cela de briser le protocole de routage, il suffit de se placer entre le CE et le PE. Ce qui est par contre important est d'viter que des routes inexistantes soient envoyes au PE, afin de ne pas compromettre le VPN concem. Cela ne compromet toutefois pas l'tanchit des VPN, sauf si sur le lien CEPE passent plusieurs VPN sous la forme de VLAN par exemple (si Ethemet est utilis au niveau 2). Dans ce cas, un attaquant pourrait, tout comme il pouvait ventuellement changer les tiquettes VPN dans le rseau cur, modifier les tags VLAN des paquets et ainsi briser l'tanchit des VPN. C'est le mme problme que pour le changement d'tiquette VPN (voir partie 2.3), mais au niveau 2 cette fois-ci. Toutefois la prsence du checksum de l'entte Ethemet rend cette pratique plus difficile.

Les failles de RIP, OSPF dcrites dans la partie prcdente (routage intra-cur) sont aussi valables ici. 5.1.2.3 Conseils Gnralement, l'authenfificafion mutuelle du CE avec le PE est ralise avec MD5. Ou du moins, il est fortement conseill d'utiliser MD5, alors qu'en prafique, cela est rarement effectu. Si PPP est utilis au niveau 2, il est aussi possible d'utiliser une authentification par PPP (Lloyd et Simpson, 1992).

115

OSPF tant en gnral employ comme protocole de routage IGP chez le client, la RFC4577 (Rosen, Psenak et Pillay-Esnault, 2006) suggre son utilisafion sur le lien PECE comme une simplification pour le client. Au niveau scurit par contre, cela n'apporte pas grand-chose. Idalement, le routeur CE et le routeur PE doivent tre relis directement.

Le routage statique est le plus sr, aucune route ne peut alors tre introduite par un intrus. BGP a aussi ses avantages, proposant d'autres mcanismes tels que la commande maximum-prefix qui limite le nombre de routes que le routeur doit accepter afin d'viter un dni de service par surconsommation des ressources du processeur ou de la mmoire.

Enfin, s'il n'est pas possible de faire autrement, le chiffi-ement des communications entre CE et PE par IPsec est possible, bien que s'il est effectu, ce sera gnralement de CE CE. Ce chiffrement permet de protger un VPN contre des coutes, intmsions ou injections de trafic. Il ne protge par contre pas contre les attaques intemes aux VPN ou sur le cur. Nonobstant, il faut s'attendre avec ce chiffrement des dgradations en termes de performances. 5.1.3 Cratio n de s VPN

Pour permettre la cration de VPN sur MPLS dans une architecture Cisco, il est ncessaire d'employer des Route Distinguisher (RD), transformant les adresses IPv4 en adresses VPNv4 (voir le dtail dans la partie 1.2.5.1), ainsi que des Route Target (RT). Ce processus est ralis manuellement sur chaque routeur PE. Les route distinguishers crent ainsi l'isolation entre les diffrents VPN et rendent possible l'emploi d'espaces d'adressage se chevauchant. Le but d'un RT est de permettre d'importer les routes correspondant au VPN qui lui est li d'un ou de plusieurs routeurs PE distants au routeur PE local afin de pouvoir raliser l'acheminement des paquets au sein du VPN. Une

116

tiquette spcifique est attribue par chaque routeur PE egr-ess par instance de VRF, ventuellement par interface de sortie ou FEC. 5.1.3.1 Protocole s utilis s

Afin de transmettre travers le rseau MPLS les annonces de routes, le protocole MPBGP est utilis. Il fonctionne sur le mme principe que BGP, en lui ajoutant des attributs supplmentaires, connus sous le nom d'informations tendues {extended communities). Les PE utilisent MP-BGP pour transmettre leurs mises jour sur le rseau MPLS. Ces mises jour, qui sont des redistributions de routes apprises par le routage PE-CE pour chaque VPN, contiennent les informations exportes par chaque instance de VRF (reprsente par une table de routage virtuelle dans un PE) avec, entre autres, le(s) prfixe(s) rseau(x), les RD-RT, le prochain saut, ainsi que l'tiquette VPN utiliser. Ainsi, chaque routeur PE sait quel est le prochain saut permettant d'atteindre un prfixe donn au sein d'un VPN. Il faut noter que la sparation toute entire est base sur l'tiquette VPN. Lors de la rcepfion d'un paquet depuis le cur du rseau, MPLS consultera l'tiquette VPN pour savoir dans quelle table VRF regarder, autrement dit quel VPN le paquet est associ. 5.1.3.2 Faille s lies MP-BGP

S'il est possible d'intervenir dans l'change des messages des sessions MP-BGP, le contenu des prfixes annoncs de mme que la valeur des tiquettes, etc. peuvent tre modifis. Cependant, pour y parvenir, il faut pouvoir accder au cur, et attaquer au bon moment (en interceptant le premier change MP-BGP par exemple, ou en supprimant des routes existantes en envoyant d'autres prfixes pour un mme VPN).

117

5.1.3.3 Attaqu

e direct e sur l'tiquett e

Etant donn l'absence de chiffrement tant au niveau des donnes que des enttes des paquets VPN circulant sur le rseau, s'il est possible d'intercepter des paquets, il va tre possible en changeant l'tiquette VPN de les diriger vers une autre desfination que celle prvue ; donc de briser l'tanchit des VPN. Et le plus intressant est que cette technique d'attaque est indtectable, car il n'y a pas de contrle de somme {checksum) ralis sur l'entte MPLS. Par contre, cette attaque est sens unique (Rey, 2006). Il n'est possible que d'envoyer des donnes d'un VPN vers un autre, mais pas de recevoir de rponse. Cela suffit cependant transmettre des vers.

Nanmoins, cela suppose la possibilit d'accder aux routeurs du cur, du moins un PE. Ce qui est gnralement prsent comme impossible. 5.1.3.4 Conseil s

Les failles ne deviennent exploitables que s'il est possible de communiquer avec le cur. Il faut donc le rendre invisible. Pour cela il existe un moyen assez simple : il suffit de dsactiver la fonctionnalit MPLS traceroute qui permet, tel la commande traceroute du monde IP, de dterminer les points de passage des paquets dans le rseau MPLS. Si cette commande est active, il est possible de dterminer l'adresse IP des routeurs traverss dans le rseau cur MPLS. En la dsactivant, le champ TTL de IP n'est pas copi dans le champ correspondant de l'entte MPLS, et par consquence le nuage MPLS apparat comme transparent.

Afin d'empcher l'accs au cur, au cas o les adresses des routeurs du cur pourraient tre connues ou devines, il faut utiliser des listes d'accs {access list, ACL) situes l'entre des routeurs PE. Lorsqu'un paquet IP provenant d'un VPN ou de l'extrieur a comme adresse de destination une adresse du rseau cur, il doit tre automatiquement

118

dtmit. En outre, il peut aussi tre utile de filtrer les paquets entrants qui possdent une adresse source diffrente de l'espace allou ou ufilis par le VPN concem. Au sujet des route distinguishers, il est conseill de choisir un RD unique par routeur et par VRF. Bien qu'en gnral un RD unique par VPN puisse suffire, dans le cas o des rflecteurs de route sont prsents dans le rseau, ou bien pour effectuer de l'ingnierie de trafic, la premire solution est prfrable.

Au niveau des PE, il faut porter une attention particulire la configuration des interfaces lies au VRF. Rien ne sert de bien raliser la configuration des VPN dans le rseau cur si au niveau des PE l'interface de sortie vers le CE est mal configure. Hormis l'attribut de route target qui permet au routeur recevant une annonce MP-BGP de savoir dans quelle instance de VRF il doit ajouter les routes reues, l'attribut SOO (Site Of Origin) permet de s'assurer de la provenance des annonces de routes, c'est-dire de quel site provient la route annonce et d'viter un site de recevoir une route qu'il a lui-mme mise. Ceci peut tre valable si BGP est utilis entre CE et PE avec de multiples connections d'un site au rseau MPLS, ou encore en cas d'attaque sur le protocole MP-BGP. Enfin, les recommandations faites dans l'tude de BGP {cf BGP ou d'une autre des extensions susmenfionnes. 5.1.4 tablissemen t de s LSP dans le rseau MPLS

chapitre 4) sont aussi

valables. Le protocole MP-BGP pourrait par exemple tre protg par l'utilisafion de S-

Une autre tape ncessaire la crafion de VPN est l'tablissement des LSP dans le rseau MPLS. Ceux-ci permettent de crer des chemins virtuels entre les PE. Ils sont crs soit la demande, lorsqu'un chemin doit tre tabli entre 2 PE, soit

119

automatiquement, pour permettre chaque PE de possder un chemin vers tous les autres PE. 5.1.4.1 Protocole s utilis s

Il y a plusieurs protocoles qui peuvent tre utiliss afin de crer les LSP. Le principal est LDP. Si l'ingnierie de trafic est active, CR-LDP, RSVP-TE peuvent aussi tre choisis.

Quand un PE tablit un LSP, il ufilis son protocole de signalisafion (par exemple LDP). Il indique l'adresse du PE rejoindre en tant que destination, et attache l'idenfificateur VPN li ce LSP (en plus d'un time stamp, et idalement d'une signature numrique via MD5 pour la scurit). 5.1.4.2 Faille s possible s

LDP est vulnrable des attaques de type mystification, les messages changs pouvant tre intercepts et supprims, et ne permet pas de garantir la confidentialit des tiquettes changes. Concemant le premier point, elles pourraient permettre un routeur espion de rcuprer des paquets IP et ainsi de les modifier puis de les racheminer ou de les supprimer. Il s'agit alors du mme type de problme que pour le routage du cur ou la cration des VPN : une attaque Man in the Middle. 5.1.4.3 Conseils Il est conseill d'utiliser MD5 (voire SHA-1) pour authentifier les messages changs par le protocole adopt (LDP, RSVP-TE, etc.). Les mises jour de ce protocole ne doivent tre acceptes que sur les interfaces qui possdent un routeur du cur l'autre extrmit.

120

Pour viter toute manipulation d'tiquettes, il faut d'une part empcher tout accs au cur, grce des listes d'accs (voir les conseils de la partie prcdente), et d'autre part ne pas accepter de paquet IP portant des tiquettes MPLS provenant de l'extrieur du cur. La seule exception cette rgle conceme les rseaux de topologie Carrier's Car-rier, o des paquets portant des tiquettes MPLS peuvent tre accepts sous certaines condifions {cf. partie 2.2.5.2). 5.1.5 Autre s considration s

Dans cette partie sont prsents quelques autres considrations intressantes comme la ncessit d'une authentificafion de CE CE, propose dans un brouillon en 2003, ainsi que quelques remarques au sujet de la cration de VPN dans MPLS/VPN. 5.1.5.1 Authentificatio n C E CE

Malgr les possibilits d'authentification d'un CE avec le PE auquel il est reli en utilisant MD5 ou l'authentificafion PPP {cf. secfion 5.1.2.3), rien ne garanfit qu'un client est bien reli son propre VPN au niveau du routeur PE (en cas de mauvaise configuration des interfaces par VRF par exemple). Autrement dit, rien ne garantit l'tanchit au client en cas de faute, dlibre ou non, du foumisseur de service.

C'est cette impossibilit de dtection d'ventuelles brches dans la configuration des VPN qui motive la cration d'un mcanisme permettant de s'assurer que tous les membres appartenant un VPN sont bien autoriss l'tre. L'authentification CE CE a t propose dans un brouillon (Bonica et al., 2003), il suggre le recours des jetons comme mthode d'authentification. Un jeton est mis par chaque site connect un VPN depuis le CE vers le PE qui lui est li. Ce demier ajoute le jeton aux annonces des routes apprises depuis ce site lors des mises jour MP-BGP. Les autres sites appartenant au mme VPN peuvent ainsi, la rception de ce jeton, vrifier l'appartenance du site au VPN. Si celui-ci n'est pas conforme, un signal d'alarme est lanc et le site en question

121

est ignor jusqu' ce que le problme soit rgl. Ce mcanisme ne permet toutefois que d'avertir d'un problme de configurafion, pas de l'empcher.

Concemant le transport des jetons, au sein du rseau MPLS ceux-ci font partie des annonces MP-BGP grce un nouvel attribut des communauts tendues. Si BGP est mis profit entre CE et PE, c'est ce mme attribut qui est exploit. Si un autre protocole est adopt comme protocole CE-PE, un nouveau protocole de distribution de jetons doit tre cr. Les auteurs proposent cet gard un protocole bas sur UDP permettant de propager le jeton entre CE et PE dans les deux directions.

Il est videmment possible d'utiliser un chiffrement IPsec de CE CE, permettant en outre de s'affranchir des considrations de confidentialit des donnes changes. Toutefois, la lourdeur apporte par cette solution ne la destine pas tous les usages, en particulier ceux lis au temps rel. Par ailleurs, avec cette solution se pose la question du fonctionnement d'une autorit de certification et de distribution de cl de scurit au sein du rseau MPLS, pas ncessairement vidente : comment les CE pourraient-ils recevoir de l'information provenant du cur du rseau alors qu'ils ne sont pas censs pouvoir communiquer avec celui-ci? 5.1.5.2 Problm e des Route Targets

Les route targets sont utilises pour dterminer les routes importer et exporter. Si dans le cas de VPN simples (un seul client, deux PE concems ou plus), cela ne pose pas de problme ; dans le cas de VPN partags (deux clients accdent un VPN partag, pour accder Intemet par exemple), le mcanisme des RT est tel qu'il peut tre possible de raliser une attaque d'un VPN vers un autre VPN {cf. partie 3.1).

Ce bris de l'tanchit n'est certes possible que sous certaines conditions mais montre qu'il n'y a que trs peu d'cart entre le fonctionnement normal de MPLS et un

122

fonctionnement erron. La recherche future pourrait offrir de nouvelles solutions permettant de ne pas rencontrer ce problme, ventuellement en imaginant une autre mthode permettant l'change des routes dans le rseau MPLS/VPN. 5.1.5.3 Recett e selon Cisc o

Afin de configurer correctement un rseau MPLS/VPN au niveau des routeurs PE, Cisco propose une marche suivre (Lewis, 2004) qui est prsente ci-dessous. Elle indique les tapes effectuer, sans donner plus d'informations ou de recommandations. Dans cette tude, nous avons considr la plupart de ces tapes pour en analyser les problmes et solufions possibles.

Tableau 5.1 Configuration d'un rseau MPLS scuritaire (Tir de Lewis, 2004) Step 1 Configure the loopback interface to be used as the BGP update source and LDP router ID. Step 2 Enable CEF. Step 3 Configure the label distribufion protocol. cf partie 5.1.4 Step 4 Configure the TDP/LDP router-id (optional). Step 5 Configure MPLS on core interfaces. Step 6 Configure the MPLS VPN backbone IGP. cf partie 5.1.1 Step 7 Configure global BGP parameters. Step 8 Configure MP-BGP neighbor relationships. cf. partie 5 J.3 Step 9 Configure the VRF instances, cf. partie 5.1.3 Step 1 0 Configure VRF interfaces, cf partie 5.1.3 Step 1 1 Configure PE-CE routing protocols / static routes, cf partie 5.1.2 Step 1 2 Redistribute customer routes into MP-BGP. cf partie 5.1.3

123

Le fait de suivre cette recette ne garantit pas la cration d'un rseau scuritaire. Il est ncessaire de porter une attention soutenue chacune des tapes afin de ne pas raliser d'erreur de configuration. 5.1.6 Bila n

Finalement, pour crer un rseau MPLS/VPN scuritaire, il est ncessaire de suivre des recommandations, dont quelques-unes ont t nonces dans cette tude, et de respecter quelques principes de scurit vidents, aussi simples parfois que de ne pas laisser les mots de passe par dfaut sur les routeurs.

Dans cette tude n'a t considr que le cas d'un rseau MPLS/VPN mono-cur. Une grande difficult au niveau de la scurit survient lorsque plusieurs rseaux MPLS sont relis, qui plus est lorsque ceux-ci appartiennent diffrents foumisseurs de service. Il existe trois mthodes d'interconnexion recommandes {cf partie 2.2.5.1), mais quelle que soit la mthode le dfi de rendre le tout fonctionnel, performant et scuritaire n'est pas vident.

Il ne faut pas toujours croire dlibrment un constructeur ou un foumisseur de service qui prtend que son produit est 100% sr. Les erreurs de configurations, mmes involontaires, sont possibles, et semblent mme suffisamment problmatiques pour avoir suscit la rflexion de plusieurs chercheurs sur l'authentification CE CE. Plus rcemment, des chercheurs chinois (Yi et Yaping, 2006) ont d'ailleurs repris l'ide d'authentification des VPN base sur les CE, permettant de dtecter les mauvaises configurations ou les interconnexions dlibres entre VPN. Toutefois, lors de l'criture de ce mmoire leur article n'tait toujours pas disponible la lecture.

124

L'attaque possible dans l'architecture Extranet/Intemet {cf parties 3.1 et 3.3) pose un problme supplmentaire en tant faiblement documente. De plus, mme en suivant les recommandafions nonces dans cette tude, elle ne peut pas tre systmatiquement empche. L'existence de VPN partags, pour un accs Extranet ou Intemet ncessite obligatoirement d'installer des pare-feux afin d'empcher toute intmsion inter-VPN. Gnralement, il est conseill d'ufiliser un VPN particulier uniquement pour l'accs Intemet, pour sparer le trafic intra-VPN du trafic Intemet. ventuellement, une mthode diffrente permettant l'change de routes VPN entre les diffrents sites en remplacement de l'import/export des route tar-gets pourrait tre dveloppe l'avenir afin de combler ce problme.

Finalement, concemant MP-BGP, ce qui est finalement le plus important est de s'assurer que la convergence du protocole MP-BGP est rapide, car mme si les changements dans un rseau MPLS/VPN ne sont pas aussi frquents que sur Intemet, il faut tout prix viter de relier diffrents VPN ensemble cause d'une tiquette qui n'aurait pas t mise jour parce que le protocole convergerait trop lentement dans un grand rseau. 5.2 Recommandation s gnrales

Cette partie prsente des recommandations gnrales visant garantir non pas une architecture MPLS/VPN absolument sans faille mais un fonctionnement scuritaire de celle-ci. 5.2.1 Respec t d'un modl e scuritair e

Le respect d'un modle de scurit est incontoumable pour concevoir un rseau sr. 11 existe diffrentes approches permettant de dvelopper un modle de scurit pour un rseau (Canavan, 2001) : la scurit par l'obscurit, qui part du principe qu'il n'est pas possible d'attaquer ce qui ne peut tre vu, masquant donc le contenu du rseau de l'extrieur.

125

la dfense primtrique, consistant protger les pourtours du rseau par des pare-feux, des listes d'accs sur les routeurs de bordure contre les intmsions de la mme faon que des douves protgeaient les chteaux forts des envahisseurs, la dfense en profondeur, qui repose sur diffrents niveaux ou couches de scurit, permettant de continuer garantir la scurit du rseau mme si un des systmes de dfense tombe.

La scurit par l'obscurit

vient naturellement

dans un rseau

MPLS/VPN.

L'inconvnient de cette approche est que toute la scurit ne repose que sur l'invisibilit du rseau. Le simple fait de deviner par essais successifs une adresse d'un lment du rseau peut la remettre en cause.

La dfense primtrique permet d'empcher les intmsions provenant de l'extrieur. Elle est fortement recommande mais non obligatoire dans l'architecture MPLS/VPN. Bien qu'empchant toute intmsion si correctement implante, elle n'est pas suffisante utilise seule car elle ne protge pas contre les attaques intemes, et dans le cas o une erreur de configuration permet par exemple une intmsion, une fois l'intrieur du rseau l'intrus est libre de toute acfion puisque la scurit n'est applique qu'en bordure.

La dfense en profondeur est l'approche la plus scuritaire, permettant de ne pas mettre tous ses ufs dans le mme panier. L'utilisation combine de diffrentes couches de scurit permet de ne pas faire reposer la scurit du rseau sur un seul systme de dfense, et donc se prmunir des failles, bugs ou mauvaises configurations. Cette approche peut se rvler plus difficile mettre en application que les prcdentes, mais le niveau de scurit offert vaut cette complexit supplmentaire. En se limitant aux standards, l'architecture MPLS/VPN n'applique que peu le principe de dfense en profondeur. Certes la sparafion de l'adressage, du routage et du trafic permet d'isoler les VPN entre eux, mais une simple erreur de configuration peut remettre toute la scurit en question, en connectant par exemple un site dans le mauvais VPN. Ceci

126

montre bien l'absence d'une complte dfense en profondeur. Des techniques avances pourraient tre utilises, telle que celle d'authentification de CE CE par jetons prsente dans la partie 5.1.5.1. Le chiffrement des communications reprsente aussi une couche supplmentaire de scurit pouvant tre considre, nanmoins celui-ci implique des diminutions de performances notables, non ncessairement compatibles avec les applications temps rel.

Enfin, le modle de scurit se doit d'tre dynamique et non passif L'ufilisation d'un systme de dtection d'intmsion ou IDS permet de ragir une attaque ds ses prmices et de la bloquer au lieu de simplement la dtecter et avertir l'administrateur rseau de la situation, une fois que le mal est fait. 5.2.2 Respec t d'un modl e de scurit utilisant la dfense e n profondeu r

L'approche de dfense en profondeur prsente prcdemment implique l'emploi de diffrentes couches de scurit. la scurit par l'obscurit, obtenue par le masquage de l'adressage du rseau MPLS, il est essentiel d'ajouter une dfense primtrique empchant quiconque de s'introduire dans le rseau. L'utilisation de pare-feux et de systmes de dtection d'intmsion est aussi fortement conseille.

II est primordial de protger le rseau cur en bloquant toute tentative d'accs. Un premier mcanisme empchant l'accs au cur ou aux autres VPN est l'utilisation d'espaces d'adressage distincts entre chaque VPN et avec le cur, rendant inefficace l'utilisation d'une adresse IP de desfination comme tant celle d'un routeur P du cur ou appartenant un autre VPN. Un second mcanisme consiste empcher de prendre le contrle du seul point d'accs au rseau cur, le routeur PE, afin de lancer une attaque vers le cur depuis celui-ci. Pour y parvenir, des listes d'accs doivent tre utilises sur l'interface du PE lie au CE afin d'viter les intrusions. Pour limiter les effets des attaques de dni de service, un filtrage tendu du trafic ainsi que la rpartition des

127

ressources par VRF peut tre ralis par les PE. Le filtrage du trafic doit aussi permettre de refuser tout paquet avec une tiquette provenant de l'extrieur du rseau MPLS, sauf dans le cas des architectures avances avec certaines restricfions (voir partie 2.2.5). Le document Secur-ity in cor-e netH'or-ks (Vyncke, 2003) donne de plus amples dtails et conseils afin de protger les routeurs PE et le rseau cur.

Concemant le routage entre PE et CE, le routage statique est conseill. Si un routage dynamique doit tre utilis, il doit au minimum tre scuris par MD5. Le protocole eBGP est privilgier si les liens PE-CE ne sont pas directs afin d'viter les attaques Man in the middle, sinon OSPF est prfrable. Des limites sur le nombre de prfixes par VRF et par site doivent tre fixes, des listes d'accs doivent limiter l'accs aux routeurs aux paquets de routage, les interfaces de configuration (console, SSH, telnet) ne doivent tre accessibles que par leurs ayant droits (le foumisseur de service pour le PE, le client pour le CE sauf cas particuliers). ce propos, l'accs par telnet devrait tre banni sauf si SSH n'est pas disponible, auquel cas des listes d'accs doivent aussi contrler l'accs telnet. Il en va de mme pour la diffusion de messages SNMP qu'il faut limiter par des ACL. Afin de dtecter toute tentative d'attaque, l'utilisation de joumaux d'vnements ou logs est essentielle.

Lorsque le lien CE-PE ne peut tre direct et traverse des quipements de niveau 2, il peut tre souhaitable de chiffrer les communications de CE CE en ufilisant IPsec. Cette mthode est plus lourde mais elle seule est capable de garantir la confidentialit des donnes entre CE et PE et vis--vis du foumisseur de service si les donnes transportes sont sensibles.

Si un systme de gesfion du rseau (NOC) est utilis, il doit lui aussi se trouver l'intrieur du rseau MPLS afin de ne pas crer une nouvelle cible attaquable l'extrieur du rseau. Il est toutefois recommand d'utiliser une couche supplmentaire de scurit pour celui-ci en effectuant les oprations de gestion non pas dans un VPN

128

particulier mais hors-bande, en utilisant une connexion diffrente depuis l'extrieur du rseau MPLS. La section 1.2.4.3 prsente les diffrentes techniques de gestion et les mesures qui doivent tre considres pour effectuer la gestion des lments du rseau MPLS.

CONCLUSION La conception d'une architecture scuritaire n'est pas une sincure. Pourtant, les rseaux privs fonctionnant sur MPLS, en ufilisant des technologies reconnues comme MPLS et BGP, proposent une scurit quivalente ATM/FR en offrant une bonne rsistance aux attaques condition de respecter quelques rgles et principes. Supportant de plus la qualit de service et les services diffrencis, ils offrent de nombreux bnfices l'utilisateur final comme la simplicit et le faible cot d'une solution performante.

La spcificafion des VPN utilisant MPLS et BGP, dcrite dans la RFC4364, permet de s'assurer de l'tanchit des VPN dans le cas simple d'un rseau MPLS mono-cur. II n'est pas possible un VPN de recevoir ou d'envoyer des informations dans un autre VPN, ni vers le cur, ni vers l'quipement de gestion. Le nuage MPLS est transparent pour le client du VPN. De mme, avec des mthodes de protection simples mettre en place (listes d'accs, policing/shaping, partage des ressources), il est possible

d'empcher les attaques de type dni de service sur le rseau MPLS en provenance d'un VPN ou d'un intms ayant russi se connecter sur le lien CE-PE. Le lien CE-PE doit tre protg tant au niveau du routage que concemant la confidentialit des donnes s'il n'est pas direct mais traverse des quipements de niveau 2.

Un des points les plus importants pour garanfir l'tanchit des VPN est l'assurance d'une bonne configurafion. Une simple erreur de configuration sur un routeur PE peut remettre en cause toute la scurit du rseau. Des outils de configuration automatique existent pour aider l'oprateur du rseau et viter les mauvaises configurations. Cependant l'erreur humaine est toujours possible. La rcente proposition de deux chercheurs d'une universit chinoise (Yi et Yaping, 2006) suggrant une mthode pour authentifier les membres des VPN, vrifier automatiquement la configuration du rseau et dtecter les erreurs ventuelles semble intressante pour compenser ces bvues humaines.

130

Certaines architectures labores comme la connectivit Extranet ou Intemet sont plus dlicates et ncessitent une attention particulire. Nos tests ont montr qu'il tait possible sous certaines conditions de raliser une attaque via le routeur CE de la ressource partage. L'utilisation de pare-feux est essenfielle dans ce type d'architecture. Il en est de mme lorsque plusieurs rseaux MPLS sont lis les uns aux autres, cause de l'change d'information entre diffrents foumisseurs de service. Ceux-ci doivent d'une part pouvoir se faire confiance, tout comme les clients doivent faire confiance tous les foumisseurs de service, et d'autre part protger les liaisons inter-rseaux MPLS, qui peuvent tre vulnrables. L'architecture Inter-AS suggre plusieurs mthodes de liaison entre nuages MPLS dont la complexit de mise en uvre et le niveau de scurit varient.

Parmi les rgles devant tre respectes, il convient de s'assurer que les routeurs PE n'acceptent jamais de paquets labliss sauf dans les architectures avances multi-curs, selon des conditions trs prcises et limites. Le routage doit lui aussi tre protg. Il s'agit en effet du seul type de trafic autoris voyager librement au sein du rseau MPLS et entre les routeurs CE et PE. L'authentification MD5, le champ TTL et ventuellement d'autres mthodes de scurisation doivent tre employs afin d'viter les attaques.

Les menaces inhrentes au niveau 2 qui pourraient permettre un intms de pntrer par exemple le lien CE-PE n'ont pas t dtailles dans ce mmoire. Si des quipements de niveau 2 sont utiliss sur les liens CE-PE ou entre les rseaux MPLS, les moyens de protection adquats de niveau 2 doivent tre utiliss.

Au-del de la scurit de la spcification, il est primordial que l'implmentation ralise par chaque constmcteur soit efficace et respecte bien la spcification. Or il est difficile de crer un systme d'exploitation toute preuve. De la mme manire que chaque

131

mois des mises jour sont disponibles pour combler les failles des produits Microsoft ou Apple, il n'est pas impossible que des bugs ou failles soient dcouverts dans les versions de n o s ufilises sur les routeurs du rseau MPLS. En consquence, le systme d'exploitation des routeurs doit tre tenu jour, et les bugs corrigs ds leur dcouverte.

La distinction qui existe entre un rseau scuritaire et un rseau compromis est parfois trs faible, surtout dans le cas d'architectures volues comme la connectivit Extranet et Intemet. Ceci montre la ncessit d'appliquer une scurit en profondeur lors de la conception d'une technologie, ou lors de son implmentation. L'utilisation de pare-feux ou d'IPsec est par exemple facultative dans une architecture simple mais devient primordiale dans une connectivit Extranet ou en prsence d'quipements de niveau 2 entre PE et CE.

Certains avantages des VPN sur MPLS peuvent tre source de dsagrments. L'absence de chiffrement implique que les clients doivent faire entirement confiance au foumisseur de service. Cela ne constituera en gnral pas un obstacle pour les clients dont les donnes transportes ne sont pas sensibles. Mais qu'en est-il rellement du respect du secret professionnel et de la vie prive, alors que de plus en plus les foumisseurs de service doivent lgalement garder des traces de tous les paquets transitant sur leur rseau? Font-ils rellement une distinction entre paquets changs avec Intemet et paquets appartenant aux VPN de leurs clients? Cette notion de confiance qui est devenue plus problmatique avec le Web 2.0 et des sites comme Google qui parcourent automatiquement les courriels reus et envoys via leur interface Gmail, ou comme Facebook, Myspace, etc. dans lesquels les gens exposent leur vie, leurs photos et leurs informations personnelles? Arrivera-t-il un jour o Google possdera des dossiers sur chaque intemaute contenant son profil, ses habitudes de navigation, etc.?

C'est pourquoi le chiffrement des donnes a toujours son utilit, dans le cadre des rseaux privs virtuels ou pour un usage personnel. Un rseau priv n'est plus priv

132

partir du moment o une seule personne extrieure a accs aux donnes et non lorsque tout le monde y a accs, car cet individu pourrait trs bien dupliquer l'infonnation pour la rendre disponible. En permettant au foumisseur de service de voir les donnes qui transitent dans les VPN, MPLS remet finalement en question la notion de VPN. Nanmoins, du point de vue du foumisseur de service, la quesfion ne se pose pas : la technologie est efficace et scuritaire, celui-ci doit simplement faire attenfion la configuration de son rseau et au respect des rgles nonces prcdemment.

Lors de la recherche exhaustive de mthodes d'attaques sur le rseau, une ide quelque peu farfelue a t considre. Toute l'impossibilit de raliser une attaque sur l'quipement du rseau cur est due la sparation du trafic par VPN en fonction de l'adresse de desfination. Cette sparafion est permise par l'ajout d'une fiquette VPN au paquet original. Mais qu'en serait-il s'il tait possible de changer en cours de route cette tiquette ou toute une partie de l'entte? Peut-on imaginer qu'il soit possible qu'une portion de l'entte se dsagrge lors du transport du paquet? Un virus dans un routeur du rseau pourrait y parvenir, mais serait-ce toujours possible sans aide extrieure?

Finalement, il n'est pas simple de dire si telle situation est scuritaire ou pas. Comme nous avons pu le voir, bien que la plupart le soient en thorie, des attaques peuvent tre ralisables sous certaines conditions. Ce sont ces conditions particulires qu'il faut viter pour rester dans un environnement scuritaire.

RECOMMANDATIONS Ce mmoire prsentait une tude de la scurit des VPN sur MPLS au niveau 3 et ne considrait pas les VPN utilisant MPLS au niveau 2 (VPLS ou VPWS, Virtual Private Wire Senice). Permettant des avantages attrayants comme l'mulation d'un rseau local unique malgr la sparation physique des sites, ceux-ci pourraient faire l'objet d'une recherche approfondie.

Lorsque le dtail de leur recherche sera disponible, il pourrait aussi tre intressant d'analyser la mthode retenue (Yi et Yaping, 2006) pour authenfifier les membres des VPN et vrifier la configuration du rseau. ventuellement, une nouvelle technique combinant les avantages de leur mthode et de la technique des jetons permettant l'authenfification PE PE pourrait tre dveloppe.

Par ailleurs, il serait important de vrifier les effets de l'ingnierie de trafic utilise conjointement avec les VPN. Bien que le concept des VPN dans ce cas ne change pas, les paramtres supplmentaires apports par la gestion du balancement de charge et des protocoles RSVP-TE par exemple pourraient rendre plus complexe la bonne configuration du rseau. Une tude statistique du nombre de configurations errones pour des VPN utiliss seuls et lors de l'association des VPN avec l'ingnierie de trafic constituerait un bon point de dpart cette tude. cet gard, l'outil QMA dvelopp rcemment (Tmong, 2006) pourrait avec quelques modifications raliser cette tude et surtout vrifier la configuration correcte du rseau. Le problme des route targets l'origine du bris de l'tanchit dans l'architecture Extranet et Intemet montre que bien que fonctionnel, le principe d'change de routes pourrait tre amlior ou remplac. La recherche future pourrait offrir de nouvelles solutions permettant de ne pas rencontrer ce problme, ventuellement en imaginant une autre mthode permettant l'change des routes dans le rseau MPLS/VPN.

134

Enfin, la technologie MPLS devrait tre optimise afin de ne plus imposer la condition de confiance qui doit tre faite aux foumisseurs de service pour assurer la confidentialit du contenu des rseaux privs virtuels. D'autres ides devraient ventuellement tre dveloppes pour permettre de garanfir la fois l'intgrit des VPN et la confidentialit des donnes transportes y compris vis--vis du foumisseur de service.

LISTE D E REFERENCE S

Aiello, W., J. loannidis et P. McDaniel. 2003. Origin authenfication in interdomain routing . In Proceedings of the lOth ACM confer-ence on Computer and communications security. Washington D.C., USA: ACM Press. Anderson, L., P. Doolan, N. Feldman, A. Fredette et B. Thomas. 2001. LDP Spcification . RFC 3036. <http://www.ietf org/rfc/rfc3036.txt>. Consult le 22 mai 2007. Awduche, D., L. Berger, D. Gan, T. Li, V. Srinivasan et G. Swallow. 2001. RSVP-TE: Extensions to RSVP for LSP Tunnels . RFC 3209. <http://www.ietf org/rfc/rfc3209.txt>. Consult le 22 mai 2007. Baker, F., et R. Atkinson. 1997. RIP-2 MD5 Authenticafion <http://www.ietf org/rfc/rfc2082.txt>. Consult le 23 mai 2007. . RFC 2082.

Btes, T., R. Chandra, D. Katz et Y. Rekhter. 2007. Mulfiprotocol Extensions for BGP-4 . RFC 4760. <http://www.ietf org/rfc/rfc4760.txt>. Consult le 22 mai 2007. Btes, T., E. Chen et R. Chandra. 2006. BGP Route Reflection : An Altemative to Full Mesh Intemal BGP (IBGP) . RFC 4456. <http://www.ietf org/rfc/rfc4456.txt>. Consult le 29 juin 2007. Behringer, Michael H. 2006. Analysis of the Security of BGP/MPLS IP Virtual Private Networks (VPNs) . RFC 4381. <http://www.ietf org/rfc/rfc4381 .txt>. Consult le 25 mai 2007. Behringer, Michael H., et Monique Morrow. 2005. MPLS VPN secur-ity. Indianapolis, Ind.: Cisco, xxi, 286 p. Berkowitz, H. 2003. L3VPN Tutorial . In Braindumps. En ligne. <http://www.braindumps.com/index.cfm?do=hardware&hardid=1371>. Consult le 12 juillet 2007. Bonica, R., Y. Rekhter, R. Raszuk, E. Rosen et D. Tappan. 2003. CE-to-CE Member Vrificafion for Layer 3 VPNs . Intemet Draft. <http://tools.ietforg/html/draftietf-ppvpn-13vpn-auth-03>. Consult le 10 juillet 2007. Bush, R., et T. G. Griffin. 2003. Integrity for virtual private routed networks . In. Vol. 2, p. 1467-1476 vol.2.

36

Canavan, J. E. 2001. Fundamentals of Network Security, Ist. Edition. Artech House Publishers, 319 p. Chau, Hang. 2004. Network Security - Dfense Against DoS/DDoS Attacks . En ligne. <http://www.infosecwriters.com/text_resources/pdf/Defense_DDoS.pdf>. Consult le 2 novembre 2007. Cisco. 2003. Advanced Concepts - Inter AS MPLS/VPN . En ligne. <www.cisco.com/warp/public/732/Tecli/i'npls/docs/interasadvanced.ppt>. Consult le 22 juin 2007. Cisco. 2004. Analysis of MPLS-based IP VPN security : Comparison to traditional L2VPNs such as ATM and Frame Relay, and deployment guidelines . Livre blanc. <http://www. cisco.com/warp/public/cc/so/neso/vpn/prodlit/mpvpn_wp.pdf^. Consult le 22 juin 2007. Cisco. 2006. Cisco IP Solufion Center MPLS VPN User Guide, 4.2 - IP Solufion Center MPLS VPN . In Cisco Systems, Irrc. En ligne. <http://www.cisco.com/en/US/products/sw/netn'igtsw/ps4748/products_user_gui de_chapter09186a008069aaad.html#wp 1039413 >. Consult le 12 juillet 2007. De Clercq, J., D. Ooms, M. Camgi et Franois Le Faucheur. 2006. BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN . RFC 4659. <http://www.ietf org/rfc/rfc4659.txt>. Consult le 29 juin 2007. Dierks, T., et C. Allen. 1999. The TLS Protocol Version 1.0 . RFC 2246. <http://www.ietf org/rfc/rfc2246.txt>. Consult le 22 mai 2007. Dobbertin, Hans. 1996. Cryptanalysis of MD5 Compress . En ligne. Vol. 96. <http://www.cs.ucsd.edu/users/bsv/dobbertin.ps>. Dubee, N. 2003. BGP et DNS: attaques sur les protocoles crifiques de l'Intemet . En ligne. <http://actes.ssfic.org/SSTlC03/BGP_et DNS/SSTlC03-article-DubeeBGP et DNS.pdf>. Consult le 11 juillet 2007. Dubois, N., M. Capelle, S. Chou et B. Fondeviole. 2004. The benefits of monitoring routing protocols in live networks . In., p. 9-15. Easttom, C. 2006. Network Dfense and Countermeasures: Principles ard Practices. Pearson Prentice Hall, 448 p. Everett, Bemard. 2007. Tapping into fibre optic cables . NetM'ork Security. vol. 2007, no 5, p. 13-16.

137

Gill, V., J. Heasley et D. Meyer. 2004. The Generalized TTL Security Mechanism (GTSM) . RFC 3682. <http://www.ietf onz/rfc/i-fc3682.txt>. Consult le 26 juin 2007. Goodell, G., W. Aiello, T. Griffin, J. loannidis, P. McDaniel et A. Rubin. 2003. Working around BGP: an incrmental approach to improving security and accuracy of interdomain routing . In., p. 11 pp. Coll. lOth Annual Network and Distributed System Security Symposium . San Diego, CA, USA: Intemet Soc. <http://www.isoc.Org/isoc/conferences/ndss/Q3/proceedings/papers/5.pdf>. Consult le 29 juin 2007. Hares, S., et C. Wittbrodt. 1994. Essenfial Tools for the OSI Intemet . RFC 1574. <http://www.faqs.org/rfcs/rfcl574.html>. Consult le 13 juillet 2007. Heffeman, A. 1998. Protection of BGP Sessions via the TCP MD5 Signature Option . RFC 2385. <http://www.ietf org/rfc/i-fc2385.txt>. Consult le 22 mai 2007. Hu, Yih-Chun, Adrian Perrig et Marvin Sirbu. 2004. SPV: Secure path vector roufing for securing BGP . In, 4. Vol. 34, p. 179-192. Coll. Computer Communication Review . Portland, OR, United States: Association for Compufing Machinery, New York, NY 10036-5701, United States. <http://dx.doi.org/10.1145/1030194.1015488>. Ixia. 2004. Multi-Protocol Label Switching (MPLS) Conformance and Performance Testing . In Ixia : Leader in IP perfor-mance testing. En ligne. <http://www.ixiacom.com/library/white_papers/displav?skev=mpls>. Consult le 12 juillet 2007. Kariin, J., S. Forrest et J. Rexford. 2006. Pretty Good BGP: Improving BGP by Caufiously Adopting Routes . In., p. 290-299. <http://www.ieeeicnp.org/2006/papers/s8a3.pdf>. Ke, Zhang, Zhao Xiaoliang et S. F. Wu. 2004. An analysis on slective dropping attack in BGP . In., p. 593-599. Kent, S., et R. Atkinson. 1998. Security Architecture for the Intemet Protocol . RFC 2401. <http://www.ietf org/rfc/rfc2401.txt>. Consult le 22 mai 2007. Kent, Stephen, Charles Lynn et Karen Seo. 2000. Secure Border Gateway Protocol (SBGP) . IEEE Jownal on Selected Areas in Communications, vol. 18, no 4, p. 582-592.

Kranakis, E., P.C. van Oorschot et T. Wan. 2005. Pretty Secure BGP . In 12th Annual Net. andDistr-ib. Sys. Sec. Symp. (Feb. 2005). San Diego, CA. Kmegel, C , D. Mutz, W. Robertson, F. Valeur, G. Vigna et E. Jonsson. 2003. Topology-based dtection of anomalous BGP messages . In Inter-national symposium on recerU advances in intr-usion dtection No6. p. 1-20. Pittsburgh PA: Springer, Berlin, Germany. Le Faucheur, Franois, L. Wu, B. Davie, S. Davari, P. Vaananen, R. Krishnan, P. Cheval et J. Heinanen. 2002. Multi-Protocol Label Switching (MPLS) Support of Differentiated Services . RFC 3270. <http://www.ietforg/rfc/rfc3270.txt>. Consult le 17 avril 2007. Lewis, M. 2004. Tr-oubleshooting Virtual Private Networks. Cisco Press, 840 p.

Lloyd, B., et W. Simpson. 1992. PPP Authenficafion Protocols . RFC 1334. <http://www.ietforg/rfc/rfcl334.txt>. Consult le 6 juillet 2007. McGehee, B. 2003. Security in IPv6 . En ligne. BrianMcGehee.pdf >. Consult le 31 mai 2007. <www.usipv6.com/ppt/lPsec-

Miercom. 2001. Cisco MPLS Based VPN: Equivalent to the Security of Frame Relay and ATM . Livre blanc. <http://www.paetec.com/downloads/mpls_compare_frame_atm.pdf>. Consult le 22 juin 2007. Mitnick, K. D., et W. L. Simon. 2002. The Art of Dception: Controlling the Human Elment of Security. John Wiley & Sons, Inc. New York, NY, USA, 366 p. Moy, J. 1998. OSPF Version 2 . RFC 2328. <http://ww-w.ietf org/rfc/rfc2328.txt>. Consult le 5 juillet 2007. Murphy, S., M. Badger et B. Wellington. 1997. OSPF with Digital Signatures . RFC 2154. <http://www.ietforg/rfc/rfc2154.txt>. Consult le 25 mai 2007. Murphy, Sandy. 2006. BGP Security Vulnerabilities Analysis . RFC 4272. <http://www.ietf org/rfc/rfc4272.txt>. Consult le 22 mai 2007. Palmieri, F. 2003. VPN scalability over high performance backbones Evaluafing MPLS VPN against traditional approaches . In Proceedings ofthe Eighth IEEE International Symposium on Computers and Communications, p. 975- 981. vol. 2. IEEE Computer Society.

139

Panko, R. R. 2004. Scurit des systmes d'information et des r-seaux. Pearson Education, 469 p. Rekhter, Y., T. Li et S. Hares. 2006. A Border Gateway Protocol 4 . RFC 4271. <http://www.ietf org/rfc/rfc4271 .txt>. Consult le 22 mai 2007. Rekhter, Y., et E. Rosen. 2001. Carrying label infonnafion in BGP-4 . RFC 3107. <http://www.ietf org/rfc/rfc3107.txt>. Consult le 22 mai 2007. Ren, R., D. G. Feng et K. Ma. 2004. A detailed implement and analysis of MPLS VPN based on IPSec . In Proceedings of 2004 Inter-national Confrence on Machine Learrring and Cybernetics. Vol. 5, p. 2779- 2783. Rey, Enno. 2006. MPLS and VPLS security . En ligne. <http://www.blackhat.com/presentations/bh-europe-06/bh-eu-06-Rev-up.pdf>. Consult le 18 juin 2007. R. 1992. The MD5 Message-Digest Algorithm . <http://www.ietf org/rfc/rfc 1321.txt>. Consult le 1 juin 2007. E. 2001. Multiprotocol Label Switching . <http://www.ietf org/rfc/rfc3031 .txt>. Consult le 17 avnl 2007. RFC 1321.

Rivest,

Rosen,

RFC

3031.

Rosen, E., P. Psenak et P. Pillay-Esnault. 2006. OSPF as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs) . RFC 4577. <http://www.ietf org/rfc/rfc4577.txt>. Consult le 18 juin 2007. Rosen, E., et Y. Rekhter. 1999. BGP/MPLS VPNs . <http://www.ietf org/rfc/rfc2547.txt>. Consult le 21 juin 2007. RFC 2547.

Rosen, E., et Y. Rekhter. 2006. BGP/MPLS IP Virtual Private Networks (VPNs) . RFC 4364. <http://www.ietf org/rfc/rfc4364.txt>. Consult le 17 avril 2007. Rosen, E., D. Tappan, G. Fedorkow, Y. Rekhter, D. Farinacci, T. Li et A. Conta. 2001. MPLS Label Stack Encoding . RFC 3032. <http://www.ietf org/rfc/rfc3032.txt>. Consult le 22 mai 2007. Seo, K., C. Lynn et S. Kent. 2001. Public-key infrastmcture for the Secure Border Gateway Protocol (S-BGP) . In DARPA Information Sur\ivability Confer-ence & Exposition H, 2001. DISCEX '01. Proceedings. Vol. 1, p. 239-253. Smith, B. R., et J. J. Garcia-Luna-Aceves. 1996. Securing the border gateway routing protocol . In., p. 81-5. Coll. IEEE GLOBECOM 1996. Communicafions: The Key to Global Prosperity. GLOBAL INTERNET'96. Confrence Record (Cat.

140

N0.96CH35942) . London, <http://dx.doi.org/10.1109/GLOCOM. 1996.586129 >.

UK:

IEEE.

Smith, P. 2007, 28 juin. BGP Routing Table Analysis. En ligne. <thyme.apnic.net>. Consult le 28 juin 2007. Subramanian, L., V. Roth, I. Stoica, S. Shenker et R. H. Katz. 2004. Listen and Whisper: security mechanisms for BGP . In First Symposium on Networked Systems Design and Implmentation (NSDI '04). p. 127-140. San Francisco, CA, USA: USENIX Assoc. Tmong, O. 2006. Etude et dveloppement d'outils d'optimisation de gestion de senices dans les rseaux MPLS. MG, 17. Qubec: cole de technologie suprieure. Consult le 21 juillet 2007. Venema, W. 1996. Murphy's Law and Computer Security . En ligne. <http://insecure.org/stf/wietse_murphy.html>. Consult le 1 juin 2007. Villamizar, C , C. Alaettinoglu, D. Meyer et S. Murphy. 1999. Routing Policy System Security . RFC 2725. <http://www.ietf org/rfc/rfc2725.t.xt>. Consult le 22 mai 2007. Vyncke, E. 2003. Security in core networks . En ligne. <http://www.cisco.com/global/HU/rendezvenyek/presentations/SecuritvinCoreN etworks.pdf>. Consult le 4 novembre 2007. Wang, Xiaoyun, Yiqun Eisa Yin et Hongbo Yu. 2005. Finding Collisions in the Full SHA-1 . In Advances in Cryptology - CRYPTO 2005. p. 17-36. <http://www.infbsec.sdu.edu.cn/paper/shal-crvpto-auth-new-2-vao.pdf>. Wang, Xiaoyun, et Hongbo Yu. 2005. How to Break MD5 and Other Hash Functions . In Advances in Cryptology - EUROCRYPT 2005. p. 19-35. <http://www.infosec.sdu.edu.cn/paper/md5-attack.pdf>. Wayne, C. Summers, et Bosworth Edward. 2004. Password policy: the good, the bad, and the ugly . In Proceedings of the winter international synposium on Information and communication technologies. Cancun, Mexico: Trinity Collge Dublin. White, R. 2003. Securing BGP through secure origin BGP (soBGP) . Business Communications Review, vol. 33, no 5, p. 47-8. Yi, Ji, et Deng Yaping. 2006. A scheme to enhance the security of BGP/MPLS VPN . In lET International Confrence on Wireless Mobile and Multimedia Networks

141

Proceedings, ICWMMN 2006, Nov 6-9 2006. Vol. 525, p. 404. Institution of Engineering and Technology, Stevenage, SGI 2AY, United Kingdom. <http://dx.doi.Org/10.1049/cp:20061569>. Zhao, M., S. W. Smith et D. M. Nicol. 2005. The performance impact of BGP security . NetMvrk IEEE. vol. 19, no 6, p. 42-48.