Recommandations darchitecture de rseau avec filtrages pour amliorer la scurit

en particulier pour mieux se protger des attaques venant de lInternet

Jean-Luc Archimbaud CNRS/UREC (http://www.urec.fr) 25 janvier 2000
Ce document est destin aux administrateurs de rseaux et de systmes, personnes qui doivent mettre en place ou faire voluer larchitecture des systmes dinformation (informatique et rseaux) dun campus, dun groupe de laboratoires ou dun laboratoire (dans ce qui suit le terme site dsignera ces 3 environnements). Un autre document plus didactique, moins dtaill et moins technique est disponible en ligne : http://www.urec.cnrs.fr/securite/articles/archi.reseau.court.pdf. Cet article nessaie pas de rsoudre tous les problmes de scurit, loin de l. Il se focalise sur les vulnrabilits lies au rseau, en particulier aux attaques provenant de lInternet et essaie de proposer un modle darchitecture associ des contrles daccs pour limiter ces vulnrabilits. Ce modle devrait tre acceptable par la communaut enseignement-recherche. Concrtement il ne demande pas dinvestissements lourds et peut-tre facilement adopt par les utilisateurs, voire transparent pour eux. Comme tout modle il est adapter chaque environnement. Les recommandations ci-dessous ne sont pas nouvelles, depuis de nombreuses annes nous les avons exprimes de diverses manires. Maintenant, il sagit de les gnraliser tous les sites car les risques et les attaques augmentent de jour en jour. Mais les fonctionnalits que lon recommande dutiliser sont prsent disponibles sur tous les produits installs sur les sites et les administrateurs ont acquis la comptence rseau suffisante pour comprendre et configurer ces mcanismes.

1. Situation
1.1 Le succs de lInternet ntait pas prvu
Nos sites sont connects lInternet depuis longtemps. Lors du choix de larchitecture des points daccs de ces sites lInternet, concrtement Renater, la scurit ntait pas un critre prioritaire. Le but principal tait alors que toutes les machines des sites, sans exception, puissent accder et tre accdes de lInternet avec le meilleur dbit possible. La connectivit totale (full connectivity) tait lobjectif. On pensait quil pourrait y avoir des problmes de scurit dans le futur mais ce ntait pas prioritaire dans les choix techniques. LInternet ntait quun ensemble de rseaux de recherche o tout le monde se connaissait . On navait pas dattaque de spam, scan, smurf, flood, spoofing, sniffer, (se rfrer aux articles de la presse informatique grand public). Maintenant lInternet est devenu un outil de communication mondial, utilis par des bons et mauvais citoyens et toutes les dviances courantes y sont prsentes. Mme le terme de village global, qui dsignait lInternet avec sa note de convivialit et de quitude, semble avoir disparu. LInternet nest pas plus noir que le monde mais il nest pas plus blanc non plus. On a pu voir rapidement que cette connectivit totale tait une aubaine pour les personnes mal intentionnes qui pouvaient ainsi essayer trs facilement de tester toutes les machines dun site et dcouvrir rapidement un maillon faible. Quand sont arrives les premires attaques que nous connaissons maintenant tous les jours, une raction extrmiste a t de prconiser linstallation dun garde -barrire en entre de chaque site. Mot magique, assurance tous risques ! Cet quipement qui au dpart dsignait un ensemble de relais dapplications allait rsoudre tous les problmes. Mais les gardes-barrires de lpoque se sont avrs trs contraignants. Ils ne supportaient (laissaient passer) que certaines applications, demandaient (et demandent toujours) une administration lourde, taient des goulots dtranglements en terme de dbit (ce qui est toujours vrai pour les relais dapplications), ... Nous navons pas recommand de gnraliser cette solution pour tous les sites. Une autre raison trs
Recommandations darchitecture de rseau avec filtrage pour amliorer la scurit JLA - CNRS/UREC 1

pragmatique est que nous navons pas les moyens financiers et humains pour installer et administrer ce type dquipement dans chaque laboratoire. Rapidement ces gardes-barrires relais dapplications ont volu pour devenir plus supportables . Aujourdhui, on serait bien en peine de dfinir ce quest un garde-barrire car il peut regrouper une ou plusieurs fonctions trs diffrentes telles que le filtrage de paquets, le filtrage (statique ou dynamique) de sessions, la translation dadresses, le relais dapplications, lauthentification des utilisateurs, la dtection dintrusions, Ces gardes-barrires se retrouvent dans des boites noires ddies ou dans des logiciels sur PC ou dans des routeurs ou Et il faut des comptences pour choisir un garde-barrire adapt ses besoins et le configurer. La scurit ne sest pas simplifie. Le garde-barrire au sens boite ou logiciel ddi nest pas une solution rejeter systmatiquement, dans certains environnements elle se justifie, mais elle nest pas gnraliser tous les laboratoires. Fermons la parenthse. Le choix du tout ouvert , au moment o il a t fait, ntait pas une erreur ; mais rester maintenant dans la mme logique en est une . Il faut absolument limiter les possibilits de communication entre lextrieur et lintrieur, non en restreignant les utilisateurs mais en ne laissant passer que ce qui est utile, ceci sur tous les sites. La mthode est expliqu dans ce document. De la mme manire que lon ferme cl son appartement ou sa voiture, que lon contrle laccs son btiment, il ne faut pas laisser compltement ouvert son accs Internet. Les socits commerciales qui se sont raccordes lInternet bien plus tard nont pas eu la mme dmarche que nous. Elles ont considr lInternet ds le dpart comme un monde externe, hostile. Elles ont construit un rseau interne priv pour connecter leurs sites, un Intranet, o circule toutes leurs communications (souvent confidentielles) intra-entreprise. Elles ne sont connectes avec lInternet quen un ou deux points par lesquels transitent principalement des informations publiques. Ces portes sont contrles par un quipement de type garde-barrire. Nous, nous utilisons Renater comme un Intranet, alors que Renater cest lInternet. Nous avons ainsi plusieurs centaines de points daccs lInternet do une situation totalement diffrente, beaucoup plus dangereuse. En interne sur les sites, lorsque les rseaux locaux ou de campus ont t mis en place, le but tait le mme que pour laccs Internet. Il fallait raccorder le maximum de postes, tous les postes devant pouvoir communiquer avec tous les autres, installer un service universel, le mme pour tous. Sur les petits sites, un seul rseau Ethernet suffisait, sur les grands sites plusieurs rseaux Ethernet taient construits connects par des routeurs, avec un dcoupage gographique pour rduire la charge et saffranchir des limites de distance dEthernet. Aucun critre de scurit na t pris en compte dans la conception des premiers rseaux de campus. Lusage du rseau se gnralisant on a pris conscience que sur un mme site, certains groupes comme les tudiants avaient de grandes chances de compter parmi eux un pirate, que certains laboratoires (avec de nombreux contrats industriels par exemple) avaient besoin de plus de scurit que dautres, que certaines machines de gestion contenaient des informations sensibles, ; et quEthernet tait un rseau diffusion o avec un simple logiciel dcoute install sur un PC utilisateur on pouvait rcuprer tous les mots de passe qui circulent sur le rseau (ceci nest quun exemple de vulnrabilit dune architecture non segmente). Dans la seconde vague de mise en place des rseaux de grands sites, la segmentation (dcoupage du rseau) a t mise en uvre, de manire physique dabord (une fibre pour lenseignement, une pour la recherche, une pour ladministration), logique ensuite avec les VLANs (Virtual LAN, Local Area Network) quand cette fonction a t disponible sur les quipements. Il sagit maintenant dessayer de gnraliser cette segmentation tous les moyens et grands sites .

1.2 Des systmes informatiques imparfaits

Quel est le risque de la connectivit totale, cest dire de la libert totale de communication entre les machines internes et lInternet ?

Recommandations darchitecture de rseau avec filtrage pour amliorer la scurit JLA - CNRS/UREC

1.2.1 Systmes avec des bogues

Si tous les systmes taient parfaits et si toutes les machines taient administres avec un suivi quotidien, il ny aurait aucun risque supplmentaire. Mais on est trs trs loin de cette image dEpinal. Presque quotidiennement un avis dun CERT (Computer Emergency Response Team) annonce un bogue dans un logiciel avec le correctif appropri . Gnralement cet avis fait suite la diffusion sur lInternet dun outil dattaque qui utilise ce bogue pour acqurir les droits dadministrateur de la machine vulnrable. Pour manier cette arme logicielle gratuite et disponible pour tous, inutile dtre un gnie, il suffit de lancer un programme. Heureusement pour nous la grande majorit des internautes a dautres objectifs que dessayer de pirater les machines de recherche. Autrement, quelle hcatombe dans les laboratoires ! Mais dans les dizaines de millions dinternautes, il y a une poigne de petits psychopathes ou dlinquants, et il y en aura toujours, qui pour montrer leur capacit, par jeu, par vengeance, prennent plaisir pntrer les systmes, les casser ... Les laboratoires ont aussi quelques concurrents scientifiques ou commerciaux qui nhsitent pas se servir de ces outils pour sapproprier leur travail. Plusieurs attaques dans des units taient cibles pour rcuprer des rsultats de recherche ou des dveloppements intressants. Ainsi au CNRS, en moyenne 2 attaques violentes par semaine nous sont remontes (sans compter les scans).

1.2.2 Systmes ouverts par dfaut

Lautre talon dAchille dun systme dinformation distribu en rseau tel quon la aujourdhui est le trs lourd travail dadministration des multiples systmes Unix et NT qui sont de base des serveurs. Or qui dit serveurs, dit logiciels serveurs rseau (dmons sous Unix, servic es sous NT), qui sont autant de fentres qui peuvent permettre dentrer par effraction dans un ordinateur. Le travail serait grandement simplifi si les ordinateurs livrs avaient toutes les fentres fermes et que ladministrateur nait qu ouvrir une une celles ncessaires. Il nen est rien ! La tendance dUnix et de NT est au contraire de lancer le maximum de services par dfaut, sans en informer ladministrateur. Celui-ci doit donc fermer ces ouvertures inutiles. Une premire tape consiste dcouvrir toutes les ouvertures, la seconde ne conserver que celles utiles, les services rseaux vraiment utiliss. Une simple commande suffit me direz vous. Que nenni ! Sur Unix, on commence avoir lexprience ncessaire et avec inetd.conf, les fichiers de dmarrage et les commandes ps et netstat on arrive faire linventaire et faire ce mnage. Sur NT, on peut arriver un rsultat similaire avec le menu Services dans Panneau de configuration et le Gestionnaire de tches mais lexprience manque cruellement et on ne sait mme pas avec certitude le numro des ports utiliss par tous les services NT. Ainsi sur la plupart des ordinateurs dun site, sont lancs des serveurs rseaux inutiles, pas ou mal configurs et qui sont autant de fentres grandes ouvertes ignores .

1.2.3 Systmes trop nombreux

Lorsquil y avait peu de machines (en particulier peu de serveurs) sur les sites, une recommandation forte a t de maintenir toutes les machines des sites dans un bon tat de scurit, bien configures avec les derniers correctifs. Mais cet objectif est irraliste maintenant. Un administrateur qui a essay dappliquer tous les correctifs des avis des CERTs sur lensemble de son parc htrogne et qui a essay de contrler les services rseaux sur tous les Unix ou NT de ses utilisateurs a vite compris que ctait une course perdue davance. Avec ces logiciels bogus modifier rgulirement et des serveurs livrs ouverts quil faut reconfigurer, tches qui se rajoutent leur travail quotidien, les administrateurs nont matriellement pas le temps de maintenir lensemble des systmes dun site dans un tat acceptable pour la scurit .

1.2.4 Alors ?
Il faut trouver une autre solution. Cest le but de ces recommandations qui proposent une architecture rseau avec les restrictions daccs ncessaires et qui permettent de restreindre une poigne le nombre de systmes configurer avec soin, mettre jour rgulirement et surveiller quotidiennement, en laissant la grande majorit des autres stations dans un tat plus laxiste sans trop de risques pour la scurit de lensemble.

Recommandations darchitecture de rseau avec filtrage pour amliorer la scurit JLA - CNRS/UREC

2. Larchitecture
2.1 Principes
On peut faire le constat que tous les systmes dun site nont pas besoin de la mme ouverture daccs vis vis de lInternet. Dans le sens sortant, du site vers lInternet, tous les postes doivent pouvoir accder des serveurs Web, changer des messages, Gnralement on limitera peu les communications dans ce sens. Nanmoins on peut considrer que certains groupes comme les tudiants peuvent se comporter en pirate pour lextrieur et limiter leurs actions dans ce sens sortant. Mais dans le sens entrant, de lInternet vers le site, sens qui permet daccder aux services rseau sur les stations locales, le besoin de connexion est gnralement trs faible : videmment le serveur WEB doit tre accessible par tout lInternet mais les serveurs locaux (de calcul par exemple) et les postes de travail utilisateur en ont rarement besoin. Si cest nanmoins le cas, le besoin est souvent temporaire (accs des fichiers lors de missions, depuis le domicile) et identifi (depuis certains sites). Or cest ce sens entrant qui prsente un danger. On va donc essayer de limiter autant que faire ce peut les flux dans cette direction. Partant de ce constat le principe de larchitecture est simple. Dans un premier temps il faut sparer les machines qui ont besoin dtre accdes de lInternet (les serveurs rseaux) des autres (les machines utilisateurs clientes et les serveurs locaux) et disposer les premires dans une zone semiouverte entre lInternet et le rseau purement local. Dans un second temps, sur le rseau local, il faut identifier les diffrentes communauts (units, laboratoires, coles, UFRs, services, serveurs gnraux internes, ). Les machines de ces groupes seront rpartie s dans diffrents sous-rseaux physiques ou logiques. On arrive ainsi a une architecture segmente. Les critres prendre en compte pour ce tri peuvent tre le rattachement administratif mais aussi les besoins rseau (connectivit complte avec lInternet ou non), les besoins de scurit (confidentialit de certains contrats, donnes, ), les types dutilisateurs (permanents ou de passage), le mode dadministration des machines (par le service informatique, un ITA ou sans administration reconnue).
Labo A WEB MAIL DNS

Internet R1
Base de donnes publique

R2

Labo N

Administration

Salle TP

Zone semi-ouverte Fig 1 : principe de larchitecture

Dans un troisime temps on installera des filtres dans les quipements de connexion (routeurs R1 et R2) pour isoler certaines machines sensibles ou certains groupes risque et nautoriser que les services utiles et contrls circuler. Le tri des machines tant fait, ces filtres seront simples crire.
Recommandations darchitecture de rseau avec filtrage pour amliorer la scurit JLA - CNRS/UREC 4

2.2 Les services dans la zone semi-ouverte

Dans la zone semi-ouverte, en entre de site, il faut installer toutes les machines qui assurent les services rseau avec lextrieur : DNS, messagerie, Web, FTP anonyme, News, serveur daccs commut, cache Web, bases de donnes publiques, et tout autre service qui a besoin de communication intensive avec lInternet. Cette zone sera typiquement un rseau Ethernet 10 ou 100 M, selon le dbit de la prise daccs lInternet. Inutile davoir du Gigabit si on na quun accs 2 M avec lInternet. Ce rseau sera connect lInternet par un routeur (R1 sur le schma) dans lequel on aura install un ensemble de filtres dcrits ci-aprs. Les services rseau pouront tre clats sur plusieurs machines ou concentrs sur une ou deux, selon la taille du site, le budget, le mode dadministration Lclatement conseill sur plusieurs machines permet de mieux limiter et surveiller les accs. Ces machines constituent la poigne de machines quil faut parfaitement grer. Chaque machine sera ddie sa ou ses fonctions , elle ne sera pas utilise comme station de travail classique et nhbergera pas dautres applications. Les systmes pourront tre Unix ou NT. Le critre de choix doit tre la comptence des administrateurs. Les services NT peuvent paratre plus simples installer mais NT est un systme complet quil faut matriser et connatre comme Unix si on veut assurer sa scurit et globalement son bon fonctionnement. Sur ces machines, les versions des systmes et des applications seront rgulirement mises niveau et les correctifs de scurit seront installs ds quils seront diffuss. Tous les services rseaux inutiles seront inhibs (mnage dans inetd.conf sur Unix ou dans Panneau de configuration Services sur NT). Un minimum dutilisateurs avec un accs interactif seront dclars, uniquement les administrateurs qui en ont besoin. Sur chacune sera install un outil de contrle et de trace des connexions tel que tcp_wrapper sur Unix. Dans ces serveurs, tous les messages de journalisation (logs) seront renvoys sur un serveur interne, appel Serveur logs sur le schma ci-aprs. Regardons quelques services qui demandent certaines adaptations : Sur le serveur de messagerie seront dclars tous les utilisateurs avec un compte de messagerie POP ou IMAP pour accder leur boite aux lettres mais sans possibilit de travail interactif (pas de shell, do le nom Mail sans sh ). Si pour lire leur courrier certains utilisent des commandes Unix (qui ncessitent un shell), leurs messages seront renvoys vers un serveur de messagerie interne, appel Mail avec sh dans le schma, o ces utilisateurs auront des comptes interactifs. Pour chaque utilisateur, le mot de passe utilis pour accder au serveur de messagerie de la zone semi-ouverte sera diffrent de tous les autres mots de passe utiliss pour accder aux autres systmes, en particulier de celui de leur machine de travail. Le serveur Web contiendra uniquement des pages publiques. Si le site dsire avoir des pages prives elles seront sur un serveur interne, appel Serveur Web interne sur le schma. De mme que pour les autres serveurs, il faut le minimum de compte interactif sur cette machine. Ainsi la construction des pages du serveur Web public qui ncessite ce type daccs sera faite sur le serveur Web interne. La mise jour du serveur public se fera par transfert de fichiers quotidien entre les deux serveurs, par montage NFS si les administrateurs matrisent parfaitement les mcanismes de protection de ce systme, ou tout autre systme similaire et bien matris. Si le site compte un ou des serveurs de bases de donnes publiques accdes depuis lInternet, on installera ces machines dans cette zone, et on appliquera les mmes recommandations dexploitation et de mise jour que pour le serveur Web. Si le site dispose dun service daccs commut (RTC), il se placera aussi dans cette zone. Dans ce serveur, on authentifiera tous les utilisateurs et on gardera une trace des appels, transmise au serveur logs . On appliquera les restrictions daccs par utilisateur, en particulier on ne permettra pas par dfaut une connexion lInternet via ces accs. Pour interdire laccs direct en telnet ou FTP depuis lInternet sur les machines du rseau interne, une machine relais pourra tre installe. Ainsi un utilisateur qui depuis lextrieur voudra accder en interactif avec telnet sur sa machine de laboratoire devra dabord se connecter sur ce relais puis ensuite faire un autre telnet. Sur ce relais seront dclars uniquement les utilisateurs qui auront besoin de ce service avec un mot de passe particulier. Une trace de tous les accs sur ce relais sera
Recommandations darchitecture de rseau avec filtrage pour amliorer la scurit JLA - CNRS/UREC 5

conserve. Un contrle trs fin des comptes utilisateurs (dure de vie des comptes, solidit des mots de passe, ) sera effectu. Ce passage oblig permet de concentrer toutes les bonnes mesures de scurit sur la gestion des comptes utilisateurs sur une seule station, ce qui est beaucoup plus facile faire que sur plusieurs dizaines voire centaines de machines en interne. Les nouveaux services rseau qui se gnraliseront, on peut le penser, comme lannuaire LDAP (Light Directory Access Protocol), pourront tre intgrs de la mme manire : un serveur LDAP avec des informations publiques (comme le numro de tlphone ou ladresse lectronique) dans la zone semi-ouverte, un autre dans la zone Services communs internes pour les informations prives (comme le mot de passe). En un point de cette zone on peut scruter tous les changes avec lInternet. Cest lendroit o installer un outil qui mesure lactivit et repre certains trafics anormaux, analyseur de trafic comme IPtrafic ou dtecteur dintrusions. Ce type dquipement peut tre trs utile pour dtecter des attaques et pour connatre lutilisation de lInternet faite par le site. Le seul problme est le temps ncessaire linstallation et lexploitation des rsultats de ce genre de produit.

Rseau administration IPtrafic ou Dtecteur dintrusions

Equipe de recherche / labo A Equipe de recherche / labo B

Internet

Routeur R1
Mail sans sh DNS WEB FTP anonyme Relais telnet et ftp

Backbone R2
RTC

Equipe de recherche / labo X

Cache Web

Salles de TP Portables Mail avec sh Services communs internes

News

Serveur Serveur Serveur WEB Serveur calcul ou sauvegardes interne logs dapplications Zone semi-ouverte

Fig 2 : architecture dtaille

2.3 Larchitecture interne

Sur le rseau interne, typiquement un rseau Ethernet 10-100-1000 Mbits/s, un dcoupage du rseau sera effectu. Lquipement appel Backbone R2 est un ensemble dlments qui font du routage (routeurs, commutateurs niveau 3 -4-5-6-7, ) avec des fonctions de filtrage. Chaque sousrseau connect R2 peut tre physique, un cble ddi par rseau, ou logique si les quipements ont des fonctions de rseaux virtuels (VLAN). Un des avantages des VLANs est de pouvoir faire voluer cette architecture, au gr des dmnagements et restructurations trs courants chez nous, sans intervention sur le cblage. Nanmoins, cela impose certaines contraintes comme la centralisation de ladministration et lhomognit presque obligatoire des quipements. Bien que la dfinition des groupes et la segmentation dpendent entirement du site, le schma donne un exemple dont on peut sinspirer. On trouve les sous-rseaux :
Recommandations darchitecture de rseau avec filtrage pour amliorer la scurit JLA - CNRS/UREC 6

Administration : il regroupe les stations de gestion, avec des donnes souvent confidentielles (courriers officiels, fichiers nominatifs, contrats, informations comptables, valuations des personnels et des tudiants, ). Les utilisateurs de ce groupe ont les besoins domestiques de lInternet, Mail et Web uniquement, pas vraiment de telnet ou de FTP. Il peut y avoir plusieurs sous-rseaux administration sur le site, quand plusieurs services administratifs sont prsents par exemple. Equipes de recherche ou laboratoires : un sous-rseau par quipe de recherche ou laboratoire ou entit administrative avec une autorit dcisionnelle propre. Ces rseaux auront souvent des besoins particuliers de connectivit : accs vers des serveurs de calcul ou des bases de donnes ou des gros quipements scientifiques nationaux ou internationaux, cooprations avec des quipes trangres, Salles de TP (Travaux pratiques) : rseaux o on contrle les ordinateurs mais mal les utilisateurs, jugs dangereux car attaquants potentiels, autant pour le site local que pour les sites distants. On voudra limiter leur utilisation de lInternet et leurs accs vers les autres groupes locaux. Portables et plus globalement les machines non administres : si ce type dquipement est courant, peut-tre faut-il envisager un sous-rseau (ou plusieurs) pour connecter les stations des personnes du site ou de passage qui ont leur ordinateur personnel que nadministre pas lquipe informatique. Ces machines peuvent tre mal configures, elles le sont certainement, et sont donc dangereuses. Il faudra certainement les isoler et les considrer comme des machines externes. Services communs internes : peuvent tre regroupes sur un ou plusieurs sous-rseaux les machines qui offrent des services lensemble du site ou plusieurs groupes du site. Les utilisateurs de ces services sont uniquement locaux, les stations nont donc pas besoin daccs depuis lextrieur (par opposition aux serveurs de la zone semi-ouverte). Ce peuvent tre des serveurs de calcul, de sauvegardes, de Web interne, si besoin serveurs de messagerie internes avec des utilisateurs interactifs (cf avant). Une machine de scurit qui centralise et rcupre les logs utiles des serveurs de la zone semi-ouverte et des routeurs est obligatoire. Cette machine pourra tre installe dans ce sousrseau.

2.4 Les filtres

Larchitecture mise en place ne devient vraiment utile pour la scurit que si lon installe des mcanismes qui limitent les trafics avec lInternet et entre les diffrents sous-rseaux. Sur les routeurs ou quipements quivalents cela peut tre ralis de diffrentes faons : Par contrle du routage : en effet il est trs simple de ne pas annoncer (faire connatre) un sous-rseau Renater par exemple, ainsi lensemble des machines du sous-rseau ne seront pas atteignables depuis lInternet car le numro IP du sous-rseau sera inconnu dans les tables de routage nationales et internationales. Par filtrage statique sur les adresses IP : on interdit tout trafic vers et depuis certaines machines, certains sous-rseaux. Par filtrage statique sur les numros de ports associs des adresses IP : on autorise ainsi lutilisation que de certaines applications depuis ou vers certaines stations ou sous-rseaux. Par filtrage dynamique pour des applications qui utilisent des numros de port dynamiques comme H323 pour la tlphonie sur IP. Les 3 premires manires sont couvertes par les fonctionnalits de presque tous les routeurs du march (pour les commutateurs-routeurs ou quipements hybrides de ce type il faut vrifier). Le filtrage dynamique relativement nouveau ncessite souvent un quipement ou un logiciel routeur spcifique, class comme garde-barrire.

2.4.1 Les filtres sur le routeur dentre R1

La politique de R1 sera de tout interdire dans le sens entrant sauf des services que lon connat et matrise vers certaines machines. Tous les autres accs seront rejets. Dans un premier temps, on installera les filtres habituels pour viter les problmes de mascarade IP et de broadcast IP. Ensuite le but de ces filtres pourra tre de : Interdire laccs depuis lInternet aux machines de ladministration (trop sensibles) et aux portables (pas administrs). On peut procder de plusieurs manires avec les 4 types de filtrages ci-dessus. La mthode la plus simple, laquelle on ne pense souvent pas, est de cacher les sousRecommandations darchitecture de rseau avec filtrage pour amliorer la scurit JLA - CNRS/UREC 7

rseaux Administration et Portables lInternet. En effet ces groupes ont pour seules demandes la messagerie et laccs Web (pas besoin de telnet par exemple). Dans ce cas, si le site possde un cache Web, les machines de ces sous-rseaux nont pas utilit dun accs IP direct avec lInternet, un accs vers la zone semi-ouverte suffit (o on trouve le serveur de messagerie et le cache Web). On pourra ainsi ne pas annoncer (faire connatre) ces sous-rseaux Renater ou plus simplement de numroter les machines avec des adresses prives (RFC1918). On peut appliquer le mme remde pour le sous-rseau Salle de TP avec un but diffrent : limiter les possibilits dattaques vers des sites externes depuis ce sous -rseau. En ne permettant pas une connectivit complte avec lInternet, les ventuels pirates internes ne pourront accder ni en telnet, ni en ftp aux sites externes. Cela limitera fortement leurs possibilits de nuire. Interdire tout trafic avec certaines machines sensibles et qui nont pas besoin de connexion Internet, comme la station IPtrafic, la station avec le logiciel de dtection dintrusions, le serveur logs, certaines machines utilises pour des contrats de recherche sensibles, et pourquoi pas les machines de service internes telles que le serveur de calcul Cela pourra tre ralise par filtrage sur les adresses IP. On interdit tout entre de paquet avec comme adresse de destination ladresse IP des machines sensibles Ne laisser entrer les services courants et connus (messagerie, Web, ) que vers les machines de la zone semi-ouverte , cest dire nautoriser le trafic mail entrant que vers le serveur Mail sans sh de la zone semi-ouverte, Web que vers le serveur Web de la zone semi-ouverte, et interdire ces services et tous les autres vers toutes les autres machines. Noublions pas la politique qui est dinterdire tout ce que lon autorise pas. Cela peut-tre ralis par du filtrage statique sur les numros de ports et adresses IP.

Rseau administration Salle TP Portables Equipe de recherche / labo X

I N T E R N E T

IPtrafic ou Dtecteur dintrusions

Service non reconnu

Mail

Mail sans sh

WEB

Backbone R2

WEB FTP

FTP anonyme Relais telnet et ftp

Telnet
Routeur R1
Zone semi-ouverte

Fig 3 : principe (simplifi) des filtres

Ces filtres offrent une trs grande protection mais pas 100 % comme on pourrait le penser en premire analyse. Deux vulnrabilits restent prsentes :

Recommandations darchitecture de rseau avec filtrage pour amliorer la scurit JLA - CNRS/UREC

. Le rebond : lorsque sur R1 on interdit telnet entrant vers une station interne S1 mais quon lautorise vers une autre station interne S2, un pirate pourra dabord se connecter sur S2 pour ensuite se connecter sur S1. Dans ce cas le filtre sur R1 aura aucun deffet. . Le dmarrage de dmons avec des ports non standard. Si un pirate est dj dans la place, administrateur sur une station, il pourra lancer un dmon telnetd sur un port diffrent de 23. Dans ce cas un accs telnet vers cette station risque de ne pas tre dtect par les filtres (cela dpend de lcriture des filtres), pour un routeur le service telnet est synonyme de port 23. Attention, ne nous mprenons pas sur les objectifs de ces restrictions daccs. Le but de ces filtres nest pas de brimer les utilisateurs mais de ne laisser passer que ce qui est vraiment utile. Les besoins particuliers par exemple peuvent et doivent tre pris en compte. Si une quipe de recherche une station de son rseau interne qui doit imprativement communiquer avec une autre station externe (interactif X, calcul distance, applications distribues, ) on ouvrira un filtre pour permettre le dialogue. Mais on le fera de manire la plus restrictive possible, cest dire quon autorisera uniquement lapplication utilise (repre par son numro de port) entre deux stations (repres par leur numro IP).

2.4.2 Les filtres sur le backbone R2

Ces filtres seront surtout destins protger les diffrentes entits internes entre elles. Pourquoi ? Parce quun groupe trop laxiste peut hberger des pirates en son sein ou avoir des machines si peu protges que des pirates extrieurs sy introduiront facilement sans tre dtects et pourront depuis cette base attaquer dautres machines du site (problme du rebond signal avant). Techniquement, lquipement backbone R2 peut avoir des fonctionnalits de scurit plus primaires que R1. Son rle est dabord de transporter (commuter ou router) le trafic le plus rapidement possible entre les diffrents sous-rseaux. Comme filtre on peut interdire tout ou partie des communications entre entits qui ne se font pas confiance : Administration versus Rseau de TP , quipes de recherche entre elles, On peut aussi reporter une partie du filtrage dcrit pour R1 sur R2 si il est trop difficile pour des raisons techniques ou dorganisation de concentrer tous les contrles sur R1. Lefficacit de ces filtres peut-tre vrifie avec des logiciels de simulation dintrusions comme Internet Scanner lancs depuis lextrieur du rseau, lInternet, vers les machines internes. Cest un trs bon test raliser rgulirement.

2.5 Et NAT ?
NAT comme Network Address Translation est un mcanisme plac gnralement dans un routeur qui modifie les adresses IP dans les datagrammes. Concrtement, en sortie de site, il affecte dynamiquement des adresses aux machines clientes du site lorsque celles-ci accdent lInternet. Il permet ainsi davoir un adressage priv quasi illimit sur le site et dutiliser une poigne de numros officiels pour les communications avec lextrieur. Cest la seule solution lorsque lon ne peut pas obtenir dadresses IP officielle s pour lensemble de ses machines. Cest une verrue non conforme aux principes de TCP/IP mais qui est maintenant incontournable pour certains sites vue la pnurie dadresses. Pour mettre en uvre cette fonction, il faut faire linventaire des serveurs du site, qui doivent eux avoir toujours la mme adresse statique non prive, attribuer des intervalles dadresses aux machines clientes, donc tout un travail de recensement et de classification des stations et des services. Avec NAT, une machine cliente du s ite a une adresse diffrente chaque fois quelle se connecte lInternet. Elle peut ainsi tre trs difficilement attaquable depuis lInternet. Cest pour ces raisons que certains classent NAT dans les mcanismes de scurit. De manire indirecte cest exact, car il oblige faire tout le travail de recensement des services utiliss Mais si on fait ce travail, que lon btit larchitecture dcrite avant avec les filtres recommands, NAT najoute pas vraiment de protection supplmentaire. Donc si vous avez un manque dadresses IP officielles pour votre site utilisez NAT mais ne linstallez pas uniquement pour des fonctions de scurit , suivez dabord ces recommandations .

Recommandations darchitecture de rseau avec filtrage pour amliorer la scurit JLA - CNRS/UREC

3. Bilan
3.1 Quelle est lutilit dune telle architecture ?
Actuellement, la technique la plus courante dattaque dun site Internet est de dcouvrir toutes les machines du site (par scan ), de dtecter tous les services rseaux installs sur ces machines, de tester les trous de scurit connus de ces logiciels serveurs et enfin dutiliser ces trous pour acqurir les privilges dadministrateur sur les machines. Inutile dtre un expert pour raliser ces attaques, de nombreux outils sont disponibles sur des serveurs connus et sont utilisables par nimporte quel utilisateur. Si vous navez pas de filtre en entre de votre site, sans effort, ces outils dtecteront des machines vulnrables chez vous et Par contre si vous avez les filtres recommands, les attaques natteindront que la poigne de machines de la zone semi-ouverte, machines correctement administres qui seront peu vulnrables. Toutes les autres attaques vers les machines internes seront arrtes par les filtres. Pour prendre un exemple, dbut 2000, le CERT Renater a publi des statistiques indiquant que les ports des applications Sendmail, rpc, DNS, NFS et http ainsi que les ports utiliss par les chevaux de Troie Back Orifice et NetBus avaient t les plus scanns en ce dbut danne. Avec les filtres installs au chapitre 2, ces attaques Sendmail, DNS et HTTP natteindront que les serveurs de messagerie, de noms et Web de la zone semi-ouverte, serveurs correctement administrs et trs surveills, les attaques rpc, NFS, Back Orifice et Netbus natteindront aucune machine car filtres sur R1. Ainsi si des stations de rseaux internes sont peu surveilles avec une mauvaise gestion des comptes utilisateurs (vieux comptes dormants, mots de passe faibles ) ou des logiciels sans correctif de scurit le risque dattaque russie depuis lextrieur sera trs faible. En effet, avec les filtres en place, il sera impossible depuis lextrieur datteindre directement ces stations. Le pirate pourra ventuellement passer par le relais telnet-FTP, mais il faudra quil franchisse cette barrire bien surveille et administre avec soin, donc trs peu vulnrable. Le problme des mots de passe sera aussi moins critique. Ainsi si un utilisateur divulgue, volontairement ou non, le mot de passe de sa station personnelle un tiers, celui-ci ne pourra pas accder cette station depuis lextrieur. Dans le mme registre, si un pirate installe un sniffer (logiciel dcoute sur un rseau) sur la zone semi-ouverte il ne dcouvrira pas les mots de passe des utilisateurs sur leur station de travail interne ou sur les serveurs internes. Si cest un tudiant fait la mme chose sur le sous-rseau Salle de TP il ne dcouvrira que les mots de passe des autres stations de cette salle. De nombreuses autres protections dcoulent de cette architecture et de ces filtres, mais il serait trop fastidieux de les numrer ici. Autre avantage, la mise en place dune telle architecture oblige connatre le rseau et les systmes de son site et lutilisation qui en est faite. Et ceci est un bon point et mme un pr-requis pour assurer la scurit : on ne protge bien que ce que lon connat. Enfin cette architecture permettra au fil du temps une intgration aise de protections supplmentaires pour certaines communauts comme des filtres dynamiques, gardes-barrires applicatifs, logiciels de dtection dintrusions, mcanismes dauthentification forte sans remise en cause de lexistant. On pourrait penser que la banalisation de lutilisation des produits de chiffrement rendra trs prochainement inutile ce type darchitecture et de filtres. Il nen sera rien. Dabord, il va scouler plusieurs annes avant que chaque utilisateur possde un certificat et que toutes les applications soient scurises. On peut mme penser que une grande partie des application resteront non scurises. Car le dploiement mondial dinfrastructures de gestion de cls risque dtre lent et coteux. Ceux qui ont commenc tudier et tester les ICP (Infrastructure Cls Publiques, alias PKI - Public Key Infrastructure, alias IGC - Infrastructure de Gestion de Cls) peuvent en tmoigner. Ensuite, mme si certaines de ces applications sont scurises, les stations auront toujours des dmons ou services rseau en attente qui auront des bogues et rpondront des attaques comme
Recommandations darchitecture de rseau avec filtrage pour amliorer la scurit JLA - CNRS/UREC 10

aujourdhui. Lutilisation du chiffrement ne va pas faire disparatre les vulnrabilits dcrites dans ce document.

3.2 O appliquer ce modle ?

Le modle propos est adapter chaque environnement. Nous avons choisi le terme vague site dans ce document volontairement. Il peut dsigner un campus, un groupe de laboratoires, un laboratoire, ... Sur un mme site on pourra avoir plusieurs zones semi-ouvertes. Si on prend comme exemple un campus, on pourra mettre en place une seule zone semi-ouverte pour lensemble du campus, ou plusieurs zones semi-ouvertes, une pour chaque gros laboratoire ou groupe de laboratoires (institut, universit, ). On pourra aussi avoir la runion des deux solutions, une zone semi-ouverte en entre de campus (serveurs pour les petites units dmunies) et autant de zones semi-ouvertes que de groupes de laboratoires qui ont leurs propres serveurs rseaux. Pour les services il faut effectuer la mme adaptation. Le but de cette architecture nest pas de forcer les sites centraliser tous les services rseau sur des machines de site. Sil est vrai que cette centralisation est bnfique pour la scurisation (limitation du nombre de stations surveiller, ) il faut aussi tenir compte de lexistant, des comptences dans chaque entit et de la volont de certains groupes avoir leur propre autonomie quand ceux-ci ont les informaticiens ncessaires pour administrer les services. Ainsi sur un campus, en prenant comme exemple la messagerie, un laboratoire peut vouloir administrer son propre serveur de messagerie diffrent du serveur gnral. Ce nest pas en contradiction avec nos recommandations si ce serveur est administr suivant les recommandations que lon a faites, si ce serveur est plac dans une zone semi-ouverte et si les filtres sont adapts. Dans le cas de la messagerie, une autre solution pour le laboratoire peut tre de mettre son serveur de messagerie dans le sous-rseau du laboratoire et de faire transiter les messages par le serveur mail de la zone semi-ouverte du site. Donc, il ne faut pas hsiter adapter. Par contre, il faut dans tous les cas bien discriminer pour chaque machine son type (station utilisateur, serveur rseau, serveur interne), le service quelle rend, la placer au bon endroit et le type dexploitation faire. Ces choix dpendent ainsi de la prsence ou non de services rseau communs tous les laboratoires du site mais aussi dadministrateurs ou non affects ces services communs, lun ne va sans lautre.

3.3 Comment lappliquer ?

Certains diront que les utilisateurs ne vont pas accepter ces changements. Sils sont correctement mis en uvre cela devrait tre transparent pour eux. Pour ce faire il faut dans une premire phase connatre lenvironnement, les entits, les serveurs, les services utiliss Un chef dorchestre doit avoir la vision globale de lensemble du site et de la scurit mettre en place. Mais il doit impliquer tous les administrateurs informatiques. Ainsi ds le dpart, pour effectuer ltat des lieux, il doit regrouper les administrateurs de tous les laboratoires, de manire trs officielle avec laval de la direction de chaque entit. Cela permettra aussi de sassurer de ladhsion de tous les administrateurs mais aussi des directions et en consquence des utilisateurs. Ce groupe pourra ensuite dfinir larchitecture mettre en place . Il faut un objectif a atteindre mais il sera certainement prfrable de procder pas pas pour y arriver lorsque cela est possible, par exemple service rseau par service rseau en terminant par le relais telnet-FTP qui implique un changement dhabitude pour les utilisateurs. La cration et linstallation des filtres pourront tre ralises par le chef dorchestre qui devra sengager ragir trs rapidement pour ouvrir ou fermer un service la demande dun laboratoire. Ce travail pourra ventuellement tre rparti entre plusieurs personnes si la comptence existe, mais avec une trs bonne coordination. Les filtres sont des outils puissants mais toute erreur ou incohrence peut bloquer certains services rseau. Je recommande les deux articles de Sophie Nicoud (GLM Marseille) et de Marie -Laure Minuissi (CNRS Sophia) cits dans les rfrences qui prsentent des exemples trs concrets de mise en place de filtres sur un campus.
Recommandations darchitecture de rseau avec filtrage pour amliorer la scurit JLA - CNRS/UREC 11

3.4 Quel suivi ?

En conclusion, cette architecture ne vous mettra pas labri de toutes les attaques, mais vous protgera disons de 98% des attaques courantes, ce qui nest pas ngligeable. Par contre, il faut rester vigilent. La lecture rgulire des avis CERTs et linstallation des correctifs permettront de maintenir les systmes et les applicatifs des serveurs de la zone semi-ouverte dans un tat scuris. Il sera bon dassurer une surveillance rgulire de ces serveurs suivant les modalits indiques ci-avant, mais aussi des journaux aliments par les rejets des paquets filtrs et les outils tels que IPtrafic.

4. Rfrences
Architecture

La scurit rseau du campus du GLM (Sophie Nicoud CNRS Marseille) : http://www.dr12.cnrs.fr/d12/si/sr/pub/securite/secu-info-court.htm Mise en place de filtre en entre de laboratoires (Marie -Laure Miniussi CNRS Sophia) : http://www.dr20.cnrs.fr/reseau_de_campus/filtres.pdf Contrle des accs au LMCP Politique et mise en oeuvre (Franois Mauris, Yves Epelboin, Laboratoire de Minralogie -Cristallographie) : http://www.csiesr.jussieu.fr/pole2/lmcp/index.htm Mise en place dun garde-barrire (Sylvaine Roy et Jean-Paul Eynard IBS) actes du congrs JRES99 (http://www.univ-montp2.fr/~jres99/) Du garde-barrire au cloisonnement de rseau (Herv Schauer HSC) : http://www.hsc.fr/ressources/presentations/jres99/jres99001.html Rseaux Virtuels VLANs (Jean-Paul Gautier CNRS/UREC) : http://www.urec.cnrs.fr/cours/Liaison/vlan/sld001.htm

Logiciels

Tcp_wrapper : http://www.urec.cnrs.fr/securite/outils/index.html IPtrafic : http://www.urec.cnrs.fr/iptrafic/ Simulation et dtection, un pas de plus dans la scurit informatique (Nicole Dausque CNRS/UREC) : http://www.urec.cnrs.fr/securite/articles/confRaid98.html Utilisation de produits de simulation dintrusions (Nicole Dausque CNRS/UREC) : http://www.urec.cnrs.fr/securite/articles/actes_ND_JRES99.pdf

Filtres

Filtres statiques (JL Archimbaud CNRS/UREC) : http://www.urec.cnrs.fr/cours/securite/commencer/3.0.0.filtres.html Filtres dynamiques (Gabrielle Feltin LORIA) : http://www.loria.fr/services/moyens-info/securite/CBAC-JRES.html

Adressage priv

RFC1918 - Address Allocation for Private Internets : http://www.pasteur.fr/cgi-bin/mfs/01/19xx/1918

NAT

RFC2663 - IP Network Address Translator (NAT) Terminology and Considerations : http://www.pasteur.fr/cgi-bin/mfs/01/26xx/2663 NAT lchelle dune universit (Didier Benza Univ Toulon) : http://www.univ-tln.fr/~benza/jres99/

Sans oublier les serveurs scurit de rfrence pour le milieu acadmique franais du CRU (http://www.cru.fr/Securite) et de lUREC (http://www.urec.cnrs.fr/securite)
Recommandations darchitecture de rseau avec filtrage pour amliorer la scurit JLA - CNRS/UREC 12