PREMIER MINISTRE

Secrtariat gnral de la dfense et de la scurit nationale Agence nationale de la scurit des systmes dinformation

Paris, le 08 dcembre 2011 N 3248/ANSSI/ACE

GUIDE DE DEFINITION DUNE ARCHITECTURE DE PASSERELLE DINTERCONNEXION SECURISEE

Ce guide prsente les diffrents principes permettant de dfinir l'architecture d'une passerelle d'interconnexion scurise. Ne seront considres ici que les interconnexions entre un rseau priv (un LAN) hbergeant des informations sensibles mais non classifies de dfense 1 et un rseau ouvert (typiquement Internet). On prendra pour illustrer notre propos le cas d'cole d'une petite entreprise disposant d'un rseau interne et qui souhaite interconnecter ce rseau avec Internet pour permettre : d'une part ses utilisateurs d'accder internet depuis leur poste de travail; d'autre part aux internautes d'accder au site web de l'entreprise.

Ce document s'adresse en priorit aux architectes et administrateurs rseau de petites et moyennes entreprises ou de services de l'tat. Des connaissances basiques en matire d'architectures rseau sont par ailleurs ncessaires pour apprhender certains des concepts prsents ci-aprs. Ce document se veut un guide en matire dinterconnexion, il ndicte pas de rgle imprative, mais dcrit un ensemble de concepts ou de recommandations que chacun pourra adapter en fonction de ses contraintes et de ses enjeux. 1 1.1 Introduction Analyse succincte des menaces compromission (fuite) de donnes sensibles depuis le rseau de l'entreprise vers Internet ; dfiguration du serveur web. Un attaquant peut en effet chercher modifier le contenu du serveur web des fins de dsinformation, d'atteinte l'image de marque de l'entreprise ou de revendication.

Les menaces principales considres ici sont les suivantes :

Bien que le prsent document ne se focalise que sur la passerelle d'interconnexion, l'attention du lecteur est attire sur le fait que la prise en compte de la scurit sur le rseau interne (postes clients du rseau interne, serveurs, postes dadministration) est un prrequis primordial. En effet, sauf
1

Les questions de protection des informations classifies de dfense et les contraintes lgales ne sont pas abordes ici.
51, boulevard de La Tour-Maubourg - 75700 PARIS 07 SP - Tl 01.71.75.84.65 - Tlcopie 01.71.75.84.90

2 utiliser des mcanismes extrmement robustes et complexes (labellisation cryptographique de l'information notamment), il sera en rgle gnrale impossible pour une passerelle d'empcher seule la fuite d'information depuis un poste du rseau interne compromis par un attaquant. La passerelle ne pourra pas non plus empcher un utilisateur lgitime du systme de faire fuir volontairement des informations (via la passerelle elle-mme ou par support amovible). Les rgles lmentaires de scurit des postes utilisateurs sont donc imprativement respecter avant toute interconnexion du rseau interne avec Internet. Pour mmoire, on s'attachera notamment : maintenir jour lintgralit du parc des quipements ; n'octroyer aux utilisateurs que les privilges et les droits ncessaires leur activit (et dans tous les cas ne pas donner aux utilisateurs d'accs de niveau administrateur sur leur machine) ; dsactiver les services inutiles ; activer et configurer finement un pare-feu personnel sur chaque machine ; dfinir une politique de scurit pour le rseau qui dfinisse notamment une politique en matire de gestion de supports amovibles ; superviser le rseau, journaliser et dfinir une organisation de gestion dincidents ; sensibiliser les utilisateurs la menace. Principes gnraux et dmarche

1.2

La conception d'une passerelle d'interconnexion ne se limite pas au choix d'une appliance multiservices sur tagre. Elle ncessite en premier lieu l'identification des fonctions de scurit mettre en uvre sur l'interconnexion et de leur position dans l'architecture. Le choix de chaque quipement constituant la passerelle doit se faire sur la base de trois critres: a son apport sur le plan de la scurit; sa propre robustesse ; la capacit pour lquipe technique charge de le mettre en uvre de le matriser et de le maintenir dans un tat scuris. Apport pour la scurit

L'apport sur le plan de la scurit d'un produit correspond sa fonction de scurit principale, c'est dire celle pour laquelle on met en uvre le produit. Ainsi, par exemple, la fonction principale d'un pare-feu est de bloquer les flux rseau non autoriss. Toute autre service que le pare-feu est galement capable de rendre (dtection d'intrusion, routage avanc, traduction d'adresse) doit tre considr comme une fonction secondaire de l'quipement. L'efficacit de la fonction de scurit principale vis--vis des objectifs de scurit du produit peut tre vrifie par une valuation. C'est la raison d'tre d'un certain nombre des labels de l'ANSSI (certification, qualification). Les produits bnficiant de tels labels font l'objet d'une valuation de scurit indpendante dans un centre agr par l'ANSSI. Le schma de qualification permet par ailleurs de garantir que les produits ont t valus spcifiquement en vue d'tre mis en uvre au sein d'une administration ou d'une entreprise. L'ANSSI recommande donc vivement l'emploi de produits qualifis 2 .

http://www.ssi.gouv.fr/fr/produits.

3 b Robustesse

La robustesse d'un produit est sa propre rsistance aux attaques. Un quipement rseau ne doit pas lui-mme affaiblir la scurit de la passerelle laquelle il appartient. Certains quipements peuvent en effet disposer de fonctions auxiliaires (administration, mises jour) particulirement vulnrables et exploitables facilement par d'ventuels attaquants. La robustesse d'un produit peut tre estime notamment en suivant les alertes et les avis des diffrents CERT 3 et notamment du CERTA 4 . Lutilisation dun produit suivi par le CERTA et pour lequel des correctifs de scurit sont systmatiquement mis pour corriger les vulnrabilits mises en vidence sera bien sr prfrable lutilisation dun produit inconnu ou non suivi par le rseau des CERT. c Matrise par les administrateurs et maintenabilit

Labsence de matrise dun produit, quelles que soit ses qualits intrinsques, peut conduire remettre en cause sa scurit, par exemple suite une erreur dadministration, ou labsence dapplication des mises jour par crainte des pannes. La bonne matrise dans le temps dun produit repose naturellement sur ladquation entre son niveau de complexit (fonctionnalits, architecture) et les capacits (effectifs et comptences techniques) de lquipe charge de le mettre en uvre. Elle est de plus facilite par un certain nombre de facteurs intrinsques au produit, notamment la qualit de sa documentation et de ses interfaces de paramtrage (qui, idalement, ne doivent pas permettre la dfinition dune configuration non scurise), la disponibilit dun mcanisme de mise jour robuste et document, et celle doutils pertinents daide la rsolution de problmes (journaux, validation de configuration, etc.). d Dmarche

La dmarche retenue ici est de proposer une dmarche de construction d'une passerelle d'interconnexion en partant d'une architecture trs simple (mais peu rsistante aux attaques) pour aller vers une architecture plus robuste (mais plus complexe). Il est important de noter que les lments fournis ici n'ont aucun caractre impratif et doivent tre interprts comme un ensemble de conseils appliquer (ou non) au cas par cas. Les choix relatifs l'architecture finalement mise en place doivent tre faits en prenant en compte : e la scurit de la passerelle ; sa maintenabilit ; les ventuelles contraintes oprationnelles et budgtaires. Lgende des schmas LAN: il s'agit du rseau interne de l'entreprise, celui sur lequel se trouvent les donnes sensibles, que l'on cherche protger, mais aussi celui sur lequel on peut mettre en place des mcanismes de scurit ; WAN: il s'agit du rseau externe (typiquement Internet). C'est ici que se trouvent la majeure partie des attaquants (hors compromission d'un poste interne ou attaque interne). Il s'agit par ailleurs d'un rseau non-matris sur lequel il n'est pas possible a priori de mettre en place le moindre mcanisme de scurit ;

On retiendra la lgende suivante pour les schmas:

3 Computer Emergency Response Team. 4 http://www.certa.ssi.gouv.fr.

4 FW: il s'agit d'un filtre de paquet (pare-feu) en couches rseau et transport (couches 3, typiquement IP, et 4, typiquement TCP/UDP). Ce type d'quipement ne fait aucun traitement de niveau applicatif, et ne porte un jugement sur les paquets que sur la base des informations de ses couches basses (adresses IP de source et de destination, ports TCP et UDP). Il effectue par ailleurs le routage de paquets entre ses interfaces ; DMZ: Zone dmilitarise. Il s'agit d'une zone de service. Il peut s'agir de services applicatifs (serveur web, serveur de messagerie) ou de services de scurit (serveurs mandataires - proxy - ou reverse proxy). Cette zone tient son nom de sa position classique dans l'architecture d'une passerelle (voir plus bas).

On pourra noter que les quipements de niveau 2, c'est dire les concentrateurs (hub) et les commutateurs rseau (switch), ne sont pas, de manire systmatique, reprsents sur les schmas. En effet, il n'existe l'heure actuelle aucun quipement rseau de ce type qualifi par l'ANSSI. Il n'est donc pas possible de porter un jugement objectif sur le niveau et l'efficacit des mcanismes de scurit que peut proposer un tel quipement. Les mcanismes de scurit proposs peuvent toutefois tre mis en uvre au titre de la dfense en profondeur. Une fois l'architecture de la passerelle dfinie proprement au niveau IP et transport (TCP, UDP), il est possible d'activer, en plus, les mcanismes de scurit des niveaux infrieurs. En particulier, on prfrera, sauf cas trs spcifique, la mise en uvre d'un commutateur (switch) la place d'un concentrateur (hub). Par ailleurs, on veillera bien assurer un partitionnement physique clair des diffrentes zones rseau : les architectures prsentes ci-dessous ne sont valides quen labsence dinterconnexions supplmentaires. On prendra en particulier garde labsence de tout type daccs rseau complmentaire qui permettrait de relier le LAN au WAN sans passer par la passerelle (notamment par des communications sans fil : wifi, 3G, etc.). 2 2.1 tudes d'architecture Architecture basique

L'architecture la plus simple que l'on puisse proposer est prsente sur la Figure 1. L'interconnexion se rsume ici un simple pare-feu. Les serveurs applicatifs (y compris les serveurs web accessibles depuis internet) sont directement connects au LAN. Les flux applicatifs considrs ici sont reprsents par les schmas. Il s'agit ici: 1. des flux de consultation internet depuis le LAN ; 2. des flux de consultation du serveur Web par les internautes depuis internet ; 3. des flux de mise disposition de contenu sur le serveur Web depuis le LAN.

LAN
3

WAN

DMZ

Figure 1: architecture basique et identification des flux

Les flches reprsentes correspondent aux flux logiques. Il est vident que les changes rels sont bidirectionnels. Toutefois la flche indique quelle est l'entit l'origine de la cration du flux (point de dpart de la flche) et celle qui n'est pas l'initiative du flux mais qui en est destinataire (pointe par la flche). Identifier les flux et leur sens est primordial. La plupart des pare-feux modernes sont aujourd'hui contextuels (stateful). Ils sauront donc identifier les paquets provenant du WAN dont l'mission n'a pas t sollicite par une machine du LAN et les filtrer en consquence. Cette architecture souffre de plusieurs problmes de conception : Problme 1: les flux depuis Internet vers le serveur web traversent systmatiquement le LAN. Ce point est extrmement problmatique. La moindre erreur risque donc de permettre un internaute quelconque d'adresser un paquet initialement destin au serveur vers n'importe quelle machine du LAN. Un attaquant pourrait tirer parti d'une telle erreur pour adresser un paquet d'attaque l'une des machines du LAN. A partir de l'une des machines du LAN, il est gnralement relativement ais de prendre contrle de la majeure partie des composants du rseau interne. Mais surtout, en cas de compromission du serveur, le rebond vers les machines du LAN est quasi-trivial ; Problme 2: le pare-feu est un point nvralgique de l'architecture. Si l'attaquant parvient le compromettre o le rendre compltement traversant (il ne fait alors que router des paquets entre ses interfaces), il peut alors accder l'ensemble du rseau cible. Ici encore, la compromission multiple de machines s'avre relativement aise ; Problme 3: l'architecture ne propose aucune mesure de protection contre la dfiguration du site web. En effet, les flux en provenance d'Internet peuvent lgitimement atteindre le serveur web de l'entreprise. Si l'on suppose que l'attaquant connat une attaque non publique sur l'un des logiciels mis en uvre par le serveur web et accessible par internet, il peut alors prendre le contrle du serveur et en modifier le contenu. Architecture accs DMZ via le pare-feu

2.2

Le premier problme peut tre aisment corrig en connectant directement le serveur web de l'entreprise sur une des interfaces rseau du pare-feu. L'architecture obtenue est reprsente sur la Figure 2.

LAN
3

F
2

WAN

DMZ

Figure 2: architecture accs DMZ via le pare-feu

Note importante : dans ce cas, seuls sont dplacs les serveurs devant tre accessibles de l'extrieur. Les serveurs usage interne (serveurs de fichier, base de donnes par exemple) doivent rester quant eux connects directement au LAN et accessibles uniquement depuis ce dernier. Cela ncessite pour l'entreprise d'identifier clairement les donnes qui peuvent tre mises disposition du grand public sur le serveur web et celles qui ne doivent pas ltre.

6 Cette architecture corrige correctement le premier problme (les flux destination des serveurs Web ne circulent plus au travers du LAN) mais pas les deux autres dans la mesure o le pare-feu constitue toujours un point critique de l'architecture et o aucune protection spcifique n'est mise en place pour prendre en compte le risque de dfiguration du site web. 2.3 Architecture base sur deux pare-feux

Afin de prendre en compte le second problme, il convient de mettre en place deux pare-feux comme indiqu sur la Figure 3. L'un est plac en entre de LAN (pare-feu interne, FWi) et l'autre la frontire du WAN (pare-feu externe, FWe). Le nud entre DMZ, FWi et FWe est par exemple assur par un commutateur rseau.
1

LAN

Fwi
3

Fwe
2

WAN

DMZ

Figure 3: architecture base sur deux pare-feux

La mise en place de ces deux pare-feux rend chacun de ces quipements non critiques. La compromission de FWe ne permet pas un attaquant d'attaquer directement le LAN (FWi est toujours en coupure), et la compromission de FWi n'est pas aise car, sauf en cas de compromission de FWe, aucun paquet de l'attaquant n'est rout vers FWi. De plus, la configuration par un administrateur de FWi est relativement simple puisque ce dernier ne voit que des flux logiques sortants. Une erreur de configuration se remarque donc aisment. Toutefois, la mesure n'est rellement efficace que lorsque les pare-feux sont rellement diffrents. Si les deux pare-feux sont identiques, un attaquant ayant connaissance d'une vulnrabilit pourrait prendre le contrle successif de ces deux pare-feux sans rel problme. Il est donc important de mettre en place une diversification tous les niveaux: au niveau du systme d'exploitation (JunOS, IOS, OpenBSD, Linux, etc.); au niveau du moteur de filtrage (Packet Filter (PF), Netfilter); au niveau (si possible) du matriel.

Plus les quipements seront diffrents, plus le risque qu'un attaquant ait connaissance d'une vulnrabilit exploitable sur les deux pare-feux sera faible. Bien entendu, cette diversification technologique ne doit se faire que dans les limites de la maintenabilit du parc. Si la consquence d'une telle diversification technologique est que le parc n'est plus maintenable (par manque de moyens et de comptences), il est certainement prfrable de ne pas la mettre en uvre. Par ailleurs, il est fortement recommand d'ajouter sur la DMZ un serveur mandataire (proxy) en charge d'effectuer un filtrage applicatif des changes (dpollution, filtrage des contenus dangereux, maintien dune liste blanche des sites accessibles et/ou dune liste noire des sites interdits) entre les machines du LAN et les serveurs auxquels elles accdent sur Internet. Les flux deviennent alors tels que prsents sur la Figure 4.

LAN

Fwi
3

Fwe
2

WAN

DMZ

Figure 4: Flux lors de l'utilisation d'un serveur mandataire

Il est important de noter que, sur cette nouvelle architecture, la DMZ est en coupure sur l'ensemble des flux. Il est donc prfrable de la placer en coupure physique sur les flux selon le principe prsent sur la Figure 5. L'utilisation d'une coupure physique en lieu et place d'une coupure logique permet physiquement de garantir qu'aucune communication n'est possible entre les deux pare-feux sans passer par la DMZ. Sans cette coupure, il existe un risque quun flux sortant soit adress au WAN directement sans quil ne soit filtr au niveau applicatif.

LAN

Fwi

Fwe

WAN

DMZ

Figure 5: architecture DMZ en coupure physique

L'architecture obtenue est malheureusement encore imparfaite car elle ne fournit toujours aucun mcanisme permettant de protger le serveur web contre une ventuelle dfiguration. 2.4 Architecture en double DMZ une zone de service dite interne DMZi connecte directement FWi et destine recevoir un ensemble de services fonctionnels ; une zone de service dite externe DMZe connecte directement FWe et destine recevoir des services de scurit.

La prise en compte de cette dernire menace ncessite de mettre en place deux DMZ:

Les diffrents flux sont reprsents pour cette nouvelle architecture sur la Figure 6.

1 1,3 1

LAN

Fwi

Fwe
2

WAN

DMZi

DMZe

Figure 6: architecture avec deux DMZ

Ainsi, pour les flux entrants : la zone de service DMZi contient le serveur web proprement dit ; tandis que la zone DMZe contient un reverse proxy dont le rle est d'assurer un filtrage des requtes applicatives des internautes. Diffrents types de filtrage peuvent ainsi tre effectus (analyse de requtes suspectes avec des tailles d'URL trop grandes, contenant des mots clefs associs des bases de donnes, etc.). Contrairement au proxy qui analyse prioritairement les rponses des serveurs externes aux requtes, le reverse proxy analyse prioritairement les requtes manant de lextrieur. la zone DMZi fournit un proxy cache destin stocker temporairement les dernires pages ayant t consultes sur Internet. Ce service permet une acclration substantielle des requtes ultrieures vers cette mme page ; la zone DMZe fournit un proxy tel que celui dcrit dans les prcdentes architectures.

Pour les flux sortants: -

La protection du serveur web contre la dfiguration s'effectue essentiellement grce au reverse proxy de la DMZe. Cependant, il est important de comprendre que cette mesure seule ne permet pas de garantir la scurit du serveur web. En effet, il existe de nombreuses faons de dfigurer une page web : en compromettant le serveur web lui-mme par modification du contenu des supports de stockage de masse - disques durs - ou de la mmoire du serveur uniquement. Dans ce second cas, la modification ne subsiste pas aprs un redmarrage de la machine ; en compromettant l'un des quipements rseau de la passerelle qui se trouve sur le chemin logique des paquets (pare-feu externe, reverse-proxy). L'attaquant peut en effet simuler un serveur web sur ces quipements qui se substituera au serveur web lgitime ; en compromettant l'un des serveurs DNS utiliss successivement pour associer l'adresse IP du serveur web son nom de domaine. Dans ce cas, l'attaquant peut rediriger tout le trafic destin au serveur web vers la machine de son choix. Il est noter qu'un certain nombre de ces serveurs tant obligatoirement hors du champ de responsabilit de l'entreprise, il n'existe en ralit pas de moyen simple d'obtenir une confiance absolue dans leur fonctionnement.

L'utilisation d'un site HTTPS (plutt qu'un site HTTP) permet de rduire l'impact d'un dysfonctionnement des DNS externes ou d'une attaque sur ces dernires, en associant au serveur web une identit numrique rattache une racine dite de confiance . Cependant, les flux web sont alors encapsuls dans une session SSL/TLS chiffre sur laquelle il n'est plus possible d'effectuer de filtrage. Dans ce cas, l'utilisation d'acclrateurs SSL avant le reverse proxy peut constituer une solution satisfaisante.

9 2.5 Architecture avec 3 pare-feux

Les deux DMZ de la figure prcdente tant en coupure logique, il apparat nouveau sens de les placer en coupure physique. Si l'on effectue une telle modification, il est ncessaire de faire apparatre un troisime pare-feu entre ces deux DMZ (FWm pour filtre mdian ). Le rle de ce pare-feu est de permettre un cloisonnement physique entre les serveurs eux-mmes. En effet, par souci de simplification, nous avons considr jusqu'ici qu'il n'y avait qu'un seul et unique serveur accessible de l'extrieur. En ralit, il devra probablement exister plusieurs serveurs (courriel, web, DNS) accessibles depuis l'extrieur de l'entreprise et donc autant de reverse proxies. Le cloisonnement physique est ralis en associant chaque serveur une interface diffrente du pare-feu. Cette architecture permet de plus de limiter le risque de compromission de la passerelle en n'autorisant explicitement au niveau du filtre mdian que les flux autoriss entre serveurs et reverse proxy ayant besoin de communiquer. Si l'on suppose que par exemple, le reverse proxy de courriel utilis est faible sur le plan de la scurit et peut tre compromis par un attaquant, ce dernier peut tenter de rebondir sur ce reverse proxy pour court-circuiter le reverse proxy web et attaquer le serveur web. Ce flux n'tant pas prvu par la politique de scurit du filtre mdian, ce dernier pourra bloquer les flux d'attaque et lever une alerte. En d'autres termes, le cloisonnement effectu permet de rduire le risque d'exploitation successive de vulnrabilits dans des composants faibles qui n'ont pas imprativement besoin de communiquer.

LAN

Fwi

Fwm

Fwe

WAN

DMZi

DMZe

Figure 7: architecture avec deux DMZ en coupure physique

3 3.1

Problmes annexes Problmatique de ladressage IP

Il est bien entendu possible dutiliser le mme accs internet pour la gestion des flux entrants destination de la DMZ et des flux sortants. Cependant, il est prfrable dans la mesure du possible dutiliser au minimum des adresses IP distinctes pour ces deux types daccs. Idalement, ladresse IP associe aux flux sortants est dynamique et moins visiblement relie lentit concerne, ce qui permettra de limiter le risque en termes dimage (voire de service) dans le cas o un employ peu scrupuleux se livrerait des activits douteuses (consultation de sites pornographiques par exemple) depuis laccs internet professionnel. Ladresse IP utilise pour les flux entrants peut bien videmment tre fixe. Dupliquer les moyens daccs internet (accs nominal par le rseau dun oprateur, accs de secours par le rseau dun second oprateur) permet par ailleurs de garantir une meilleure disponibilit de laccs. Lintgration dune telle redondance sur les flux entrants ncessite toutefois un peu de travail car il est ncessaire de grer un routage dynamique (une AS 5 ) au niveau de linterconnexion pour garantir que lacheminement des flux puisse seffectuer correctement via lun ou lautre des rseaux oprateur. Grer une redondance uniquement pour le trafic sortant est plus ais.
5

Autonomous System.

10 3.2 Problmatique de la mutualisation des ressources

En fonction de l'architecture qui sera retenue, le nombre de machines logiques constitutives de l'interconnexion peut tre potentiellement lev. Aussi peut-il paratre intressant de regrouper les diffrents services sur une mme machine physique. Ce regroupement peut simplement se faire en faisant tourner diffrentes applications sur le mme systme d'exploitation ou en mettant en uvre des techniques de virtualisation plus ou moins lourdes. Les risques lis la mutualisation des ressources sont les suivantes : dni de service. Le dysfonctionnement d'une des applications installes sur une machine physique peut entraner une panne de la machine et donc une indisponibilit de l'ensemble des services s'excutant sur la machine ; compromission de services. Si un attaquant parvient prendre le contrle d'un service donn, il lui sera gnralement beaucoup plus facile de compromettre les diffrents services s'excutant sur la mme machine physique (par escalade locale de privilge par exemple),

En conclusion, l'opportunit de faire s'excuter sur une mme machine plusieurs services devra tre value en prenant en compte les recommandations suivantes : il est recommand de ne faire fonctionner sur une mme machine que des services de mme nature. Par exemple, il est risqu de faire tourner sur la mme machine un serveur web et un reverse proxy web ; il est recommand d'isoler sur une mme machine physique les services notoirement moins bien scuriss ; bien entendu, il n'est pas souhaitable de faire tourner sur une mme machine physique un serveur nominal et son ventuel serveur de secours.

Certaines limitations oprationnelles lies aux ventuelles adhrences des services un systme d'exploitation ou une architecture matrielle particulire viennent par ailleurs limiter les capacits en matire de mutualisation de services. Enfin, il est important de noter que certains serveurs sont interdpendants. Typiquement, si le serveur DNS de l'entreprise tombe, son serveur web ne sera plus accessible. Rciproquement, si le serveur web tombe, les clients n'auront peut-tre plus de raisons de faire des requtes au serveur DNS. Il est donc envisageable de regrouper ces deux services sur une mme machine, dans la mesure o leurs besoins en matire de disponibilit sont similaires. 3.3 Problmatique des postes nomades

Une question qui se pose ce stade est celle des utilisateurs nomades du systme d'information. Est-il possible d'autoriser des utilisateurs accder distance tout ou partie des informations disponibles sur le LAN ? Il sagira ici de faire un arbitrage entre le niveau de durcissement du poste nomade des oprateurs (et les contraintes ventuelles dutilisation qui en dcoulent) et les fonctions offertes via le terminal nomade. La rgle gnrale est que plus le terminal sera scuris, plus les fonctions offertes pourront tre nombreuses. En particulier, un facteur favorable est que les postes nomades soient grs comme les postes d'infrastructure du LAN : les utilisateurs ne doivent pas tre administrateurs de leur machine ; la politique de mise jour doit tre strictement identique celle des postes fixes, de mme que la politique d'authentification, qui peut mme tre renforce en raison du caractre nomade des postes ;

11 les flux web doivent tre vhiculs par la passerelle d'interconnexion (voir ci-dessous).

De plus, il est ncessaire de prendre en compte les usages spcifiques aux postes nomades, notamment : dsactiver dans la mesure du possible vulnrabilits ; les interfaces sans-fil, sources de nombreuses

chiffrer le disque dur avec un moyen qualifi 6 par l'ANSSI pour rduire l'impact de la perte ou du vol d'un poste nomade ; sensibiliser les utilisateurs la politique de scurit. En particulier, il doit tre explicitement interdit d'accder des informations sensibles dans des endroits publics (trains, mtro, parcs, cafs, etc.).

Au niveau de l'architecture de la passerelle, il est conseill de retenir une architecture telle que celle qui est dcrite ci-dessous.

LAN

Fwi

Fwm

Fwe

WAN

DMZi

DMZe

RAS

Fwm

VPN

Figure 8: accs nomade

L'architecture propose met en uvre une machine effectuant une authentification des postes distants et un dchiffrement des flux au niveau IP (protection de type IPsec) depuis et destination de ces postes (VPN). Le lien entre authentification et chiffrement doit tre fort pour garantir que seuls les postes rellement authentifis pourront adresser des paquets la passerelle 7 . Il est fortement conseill que la machine VPN soit situe sur une interface spcifique du pare-feu FWe. En effet, les flux chiffrs par IPsec sont difficilement filtrables par les pare-feux car leur contenu ne peut tre inspect et le protocole est sans tat (pas de filtrage contextuel possible). Les faire transiter via la passerelle principale annule donc tous les efforts faits pour matriser les diffrents changes au sein de la passerelle. Les flux dchiffrs par la machine VPN sont ensuite traits par un filtre mdian (FWm) charg d'effectuer un filtrage au niveau des couches rseau et ventuellement au niveau des couches applicatives. En effet, le fait qu'une machine soit authentifie ne garantit pas que les flux qu'elle met ne puissent pas tre vecteurs d'attaques. En d'autres termes, le fait que les flux soient authentifis ne garantit pas leur innocuit. Ensuite, les flux peuvent tre adresss un serveur d'accs distant (RAS). Ce serveur peut tre un simple serveur http, ou ftp. Il est possible de se passer de ce serveur et de connecter directement le filtre FWm' FWi pour permettre un accs distant au LAN. La dcision de se passer ou non de ce serveur dpend du niveau de confiance que l'on peut avoir dans les postes clients. Idalement, les flux internet des postes nomades passent systmatiquement par la passerelle (VPN, FWm', FWi, DMZi, FWm, DMZe, FWe) pour sortir sur Internet.

6 7

http://www.ssi.gouv.fr/fr/qualification. Il est fondamental que lauthentification permettant douvrir le tunnel soit relie au protocole utilis pour protger la confidentialit et lintgrit de la communication.

12 3.4 Problmatique de la supervision

La supervision, la mise jour et l'administration distance des quipements de la passerelle doivent tre effectues par un ensemble de stations ddies, connectes une interface ddie de chacune des machines de la passerelle. Les quipements ne routent aucun flux vers cette interface. La machine en charge de la supervision doit elle-mme tre protge par un pare-feu pour limiter le risque de rebond entre deux lments de la passerelle au travers de la machine de supervision. Il est noter que les flux d'administration ou de mise jour sont bien souvent chiffrs ce qui complique les capacits de filtrage sur ces flux. Il faut donc en principe viter de les faire transiter par les pare-feu de la passerelle.
S

LAN

Fi

Fm

Fe

WAN

DMZi

DMZe

Figure 9: supervision de la passerelle d'interconnexion

3.5

Question des interfaces rseau

Chacune des machines de la passerelle doit piloter un nombre potentiellement important d'interfaces rseau. Un certain nombre de cartes rseau sont commercialises avec plusieurs interfaces (par exemple 4 interfaces Ethernet sur la mme carte). Il est conseill d'avoir recours sur les pare-feux des cartes diffrentes (et non seulement des interfaces) pour les flux entrants, sortants et les flux d'administration. En effet, les cartes disposant d'interface multiples ne comprennent bien souvent qu'un unique composant rseau connect toutes les interfaces. Le cloisonnement physique n'est donc pas rellement assur en cas d'utilisation de telles technologies car tous les flux sont mlangs au sein d'un mme composant. 4 4.1 Rsum et conclusions Points importants retenir

Les points suivants sont particulirement critiques en matire de conception de passerelle d'interconnexion : disposer d'une politique de mise jour la plus efficace et rapide possible pour l'ensemble des composants de la passerelle ; superviser en temps rel la passerelle et analyser les alertes. Toute connexion non prvue entre deux quipements doit tre considre comme une possible tentative d'attaque ; l'utilisation du protocole DNS pour rsoudre les noms de machine au sein de la passerelle est proscrire. Les machines doivent communiquer au niveau IP par la seule connaissance de leurs adresses respectives. De mme il est possible de proscrire l'utilisation du protocole ARP dans la passerelle et de configurer les associations adresses Ethernet et adresses IP en dur.

13 Cette configuration vise limiter les risques d'usurpation d'identit depuis l'un ou l'autre des composants du rseau ; 4.2 utiliser un principe de diversification technologique dans la limite de la maintenabilit du parc. Conclusion

Les principes exposs ici visent dcrire les fonctions de scurit mettre en uvre dans une passerelle d'interconnexion face aux diffrentes menaces prendre en compte. Le choix de l'architecture retenue doit tre fait au cas par cas en fonction du niveau de scurit attendu et des contraintes oprationnelles (financires, gestion du parc, maintenabilit, etc.). 5 Pour en savoir plus

Le Centre de formation en scurit des systmes d'information de l'ANSSI propose des formations destines aux membres de l'administration. Notamment le stage 7b, organis plusieurs fois par an, permet de mettre en pratique ces concepts en installant et configurant une passerelle d'interconnexion telle que dcrite au point 2.3.

14 Diffusion Diffusion publique sur www.ssi.gouv.fr.