Accueil Recherche | Plan Technique | Liens | Actualités | Formation | Emploi | Forums | Base
logo CERIG NOTE TECHNIQUE cerig.efpg.inpg.fr 
Vous êtes ici : Accueil > Technique > Internet et le web > Serveur proxy, firewall et sécurité           Révision : 19 avril 2002
Note précédente Liste des notes     Serveur proxy, firewall et sécurité     Page technique Note suivante
 
Jean-Claude Sohm (CERIG / EFPG)
(28 février 2002)
 
Cette note constitue la refonte complète d'un document plus ancien (juillet 1999).

A l'origine, le serveur proxy a été conçu pour relayer vers Internet les requêtes des navigateurs. Aujourd'hui, cet rôle ancien a disparu au profit de nouvelles fonctionnalités : cache, enregistrement, filtre, navigation anonyme et sécurité du réseau local. Pour cette dernière fonction, le serveur proxy est avantageusement remplacé par le firewall.
 

Introduction

En savoir plus :

A l'époque héroïque du web, les réseaux locaux n'étaient pas reliés à Internet, ils n'utilisaient pas le protocole TCP/IP, et les navigateurs étaient des logiciels fort rudimentaires. On conçoit que le CERN (le Centre Européen de Recherche Nucléaire, à l'origine du web) ait éprouvé le besoin de créer (en 1994) un serveur destiné à relayer vers Internet les requêtes des navigateurs. Ce dispositif fut baptisé "proxy server", ce qui peut se traduire en français par "serveur mandataire" -- mais c'est le terme "serveur proxy" qui s'est imposé dans notre langue.

Aujourd'hui, les réseaux locaux sont de plus en plus souvent reliés à Internet via une passerelle ou un routeur, et ils utilisent de plus en plus fréquemment le protocole TCP/IP ; le rôle initial de relais joué par le serveur proxy est devenu obsolète. Pour continuer à vendre des serveurs proxy, les éditeurs de logiciel les ont dotés de nouvelles fonctions que nous allons examiner. On notera que l'on peut concevoir un serveur proxy pour chacun des services utilisant le réseau Internet (web, ftp, telnet, news...), mais qu'en pratique on rencontre surtout des serveurs proxy destinés au web.

Un serveur proxy peut offrir les cinq fonctions suivantes : 

    la fonction de cache (en anglais : caching). Le serveur proxy conserve en mémoire toutes les pages web demandées par les clients qu'il dessert ;
  la fonction d'enregistrement (en anglais : tracking ou logging). Le serveur proxy garde une trace détaillée de toutes les information qui le traversent ;
  la fonction de filtre (en anglais : filtering). On peut configurer un serveur proxy de telle sorte qu'il examine l'information qui le traverse, et qu'il refuse de délivrer les fichiers contenant une chaîne de caractères donnée. On peut également lui demander de gérer les droits de chaque client en ce qui concerne Internet ;
  la fonction d'anonymiseur (en anglais : anonymizing). On peut faire en sorte que les requêtes relayées par un serveur proxy ne contiennent pas l'adresse du navigateur client, de manière à protéger l'anonymat de l'internaute sur le web ;
  la fonction de sécurité. Le serveur proxy peut constituer une barrière entre Internet et le réseau local de l'entreprise ;
  enfin un proxy peut éventuellement remplacer un routeur à translation d'adresse (NAT).

 
1 - Le rôle de cache du serveur proxy

En jargon informatique, une mémoire cache sert à conserver localement des informations qui ont une certaine probabilité de servir à nouveau à court terme. Ainsi, on trouve une mémoire cache dans les micro-processeurs, dans les contrôleurs de disque dur, dans les navigateurs, dans les serveurs web, etc... Un serveur proxy stocke provisoirement les pages web que les utilisateurs vont chercher sur Internet. Si un internaute requiert une information qui se trouve déjà dans le cache, il sera servi plus rapidement. Dans le cas contraire, il sera servi un peu plus lentement, car la traversée du serveur proxy représente une étape supplémentaire dans le transport de l'information.

Le rôle de cache du serveur proxy pose en fait un double problème :

    l'internaute est-il, en moyenne, servi plus lentement ou plus rapidement grâce au cache ?
  l'information qui a séjourné dans le cache est-elle toujours valide ?

Le cache accélère-t-il les consultations ? Il existe de par le monde un peu plus de 38 millions de sites web régulièrement actifs. Ils mettent à notre disposition un peu plus de deux milliards de pages web. La probabilité pour que deux internautes, dont les besoins en information sont indépendants, demandent la même page, vaut donc 5.10-10. Si le proxy dessert cent utilisateurs, et si chacun d'eux télécharge 10 pages web, il existe moins d'une chance sur un million pour que le proxy joue son rôle de cache, et ce pour une seule page. Si les décideurs qui signent les bons de commande connaissaient mieux Internet et le calcul des probabilités, on ne vendrait pas beaucoup de serveurs proxy pour leur rôle de cache !

Le calcul précédent suppose que toutes les pages du web ont la même probabilité d'être consultées, et que tous les internautes ont des besoins distincts en information, ce qui est loin d'être le cas. Pour donner une chance au serveur proxy de servir à quelque chose, il faut se placer dans le cas favorable ou l'une au moins des conditions suivantes est remplie :

    le proxy dessert un grand nombre d'utilisateurs ;
  ces utilisateurs ont des besoins en information fortement corrélés ;
  les pages web qu'ils requièrent présentent un fort taux de consultation.

1 - Le nombre d'utilisateurs. Cette condition est difficile à remplir : si un proxy dessert mille utilisateurs, et si chacun d'eux décharge cent pages, il y a moins d'une chance sur mille pour que le cache fonctionne, et ce pour une page seulement. D'où l'idée d'installer un serveur proxy-cache au point d'interconnexion entre deux dorsales Internet, ou même à l'échelle de tout un pays. Ainsi, aux États-Unis, dix grands "web-caches" ont été installés, dans le cadre du projet IRCache, financé de 1995 à 2000 par le National Laboratory for Applied Network Research (NLANR). Bien que le projet soit arrêté, les caches sont maintenus en activité, à des fins de recherche essentiellement (ces caches utilisent un logiciel gratuit appelé Squid, qui fonctionne sous Unix).

Logo cache-nowEn France, le cache national du réseau Renater, mis en place en 1998 et complété par des caches régionaux, est arrêté depuis le 24 août 2000. Ces exemples montrent que les grands web-caches, qui coûtent cher en matériel et en maintenance, ne sont pas économiquement justifiés : il est moins onéreux d'augmenter la bande passante que de l'économiser à l'aide de caches. Tous les web-caches n'ont pas encore disparu, mais leurs jours sont probablement comptés. La campagne Cache Now! (logo ci-contre) en faveur du développement des web-caches est au point mort. Seuls les anglais gardent un moral de fer en ce qui concerne leur web-cache universitaire Janet.

En fait, le seul système de web-cache réellement efficace est celui des "Content Delivery Networks" ou CDN. Ce sont des ensembles de serveurs miroirs déployés à travers Internet, qui stockent l'information le plus près possible du client. Les CDN travaillent à façon pour les grands sites web (quelques milliers actuellement), qui leur confient la distribution de leurs fichiers les plus lourds : images de grande taille, animations, vidéos en différé ou en streaming. Un système de répartition de charge (load balancing) détermine quel est le serveur le mieux à même de satisfaire le client. Le CDN le plus connu est Akamai, mais il en existe de nombreux autres (consulter la liste de Web Caching, ou celle de WebReference). Les CDN sont aussi utilisés pour distribuer de simples pages HTML, en cas de très grosse pointe de trafic. Un nouveau langage de description de page, baptisé ESI (Edge Side Includes), a récemment été créé pour étendre le système CDN aux pages web dont une partie est générée de manière dynamique.

2 - Des besoins corrélés en information. Cette condition, par contre, peut être plus facile à satisfaire. Si un proxy dessert mille utilisateurs déchargeant chacun cent pages, et si dix pour cent d'entre eux ont les mêmes besoins, le cache va resservir environ dix mille pages. Où trouve-t-on des populations ayant des besoins communs en information ? Plutôt dans le grand public, dont les goûts ont été modelés et uniformisés par la publicité et les grands media. C'est pourquoi les FAI (Fournisseurs d'Accès à Internet), et plus particulièrement ceux dont la clientèle est constituée principalement de particuliers, utilisent un serveur proxy, dont le cache servira de nombreuses fois pour la météo, les nouvelles du jour, l'horoscope, ou la photo de la dernière actrice à la mode. Mais... comment il se fait-il que, malgré la présence de ces caches, les sites serveurs de nouvelles(ex : CNN) soient encore débordés lorsqu'un événement très médiatique se produit ?

En s'éloignant de plus en plus du client, on peut arriver à la conclusion qu'il faut mettre un cache... sur les serveurs web eux-mêmes. De fait, tous les logiciels de serveur web gèrent un cache en mémoire vive et, si l'on examine le fonctionnement d'un serveur à fort trafic, on s'aperçoit que son cache est effectivement très utilisé. On peut aller plus loin en installant les fichiers du site web en ramdisk (si la mémoire vive de la machine est suffisante). Cette technique est efficace lorsque le temps de réponse du serveur est limité par les accès au disque, ce qui n'est pas toujours le cas. Certains sites conseillent même de coupler serveur proxy et serveur web ; pour que ce dernier ne soit pas caché aux internautes, le proxy est monté à l'envers (reverse proxy). Pour peu que l'on s'y prenne mal, les internautes qui veulent accéder au site doivent reconfigurer leur navigateur... Une histoire de fou, direz-vous ? Et bien, je viens d'être témoin d'une pareille aberration, au début de l'année 2002, dans un établissement du campus dont je tairai le nom (par charité chrétienne, bien sûr). Étant donné qu'un serveur web gère son propre cache, on ne voit pas pourquoi il faudrait lui adjoindre un système de cache externe. A moins que le serveur ne soit protégé par un firewall, et que le système de cache ne soit installé devant le firewall -- une solution qui existe, mais dont on parle peu.

3 - Des pages web à forte consultation. Lorsqu'on examine les fichiers log d'un serveur proxy, on y trouve toujours le même type d'information. Elle est constituée des pages d'accueil des sites les plus fréquentés du web : moteurs de recherche réputés, portails renommés, sites météo, journaux et sites de nouvelles, agences de voyage, horaires des moyens de transport, jeux en ligne... Nombreux sont ceux qui vantent les mérites du cache des serveurs proxy, mais rares sont ceux qui ont l'honnêteté de publier le fichier journal correspondant. On pourra cependant consulter avec intérêt les fichiers log du proxy de l'Académie de Grenoble.

Prenons l'exemple d'un internaute qui pose une question à un moteur de recherche. Seule la page d'accueil dudit moteur sera mise en cache, car les autres pages sont spécifiques (elles sont générés par un script côté serveur, repérables par un point d'interrogation dans leur URL, et ne sont en principe jamais cachées par les serveurs proxy). Certes, l'internaute obtiendra la première page plus vite, mais on lui servira les autres plus lentement, car il faut le temps de traverser le proxy. Prétendre que, dans ces conditions, le serveur proxy accélère globalement la fourniture des pages demande une belle dose d'optimisme... ou de mauvaise foi. Le même raisonnement peut s'appliquer aux autres cas précités, car plus l'internaute s'enfonce dans un site, plus sa navigation devient spécifique, et la probabilité de trouver la même page en cache devient alors négligeable.

L'information cachée est-elle périmée ? En fait, tout dépend de la manière dont est configuré le serveur proxy. Plusieurs points doivent être respectés lors de la configuration d'un tel dispositif :

    le serveur doit lire l'en-tête du paquet pour décider si ce dernier doit être mis en cache ou non. Par exemple, on ne doit pas stocker un paquet dont la durée de validité est nulle ;
  on ne doit pas stocker des paquets dont le contenu est très spécifique, comme par exemple une page générée par un script côté serveur en réponse à la question précise d'un client ;
  on ne doit pas stocker des paquets qui ne contiennent pas d'information tangible, comme par exemple ceux qui ne contiennent qu'un code HTTP particulier(un code d'erreur par exemple) ;
  le proxy ne doit pas mettre en cache les paquets authentifiés ou sécurisés, sauf indication contraire dans l'en-tête du paquet ;
  le proxy doit appliquer des règles claires pour déterminer si l'information contenue dans un paquet caché est encore valide (fresh) ou si elle est périmée (out-of-date, stale), et
  en cas de doute, le proxy doit interroger le serveur web qui a fourni le paquet pour savoir si l'information a changé.

Pour plus de détails sur la manière de rédiger l'en-tête d'un paquet pour informer les serveurs proxy sur la conduite à tenir, on peut consulter le tutoriel (autre source du même document) consacré à cette question. Il est théoriquement possible de fournir les mêmes informations via l'en-tête de la page web, mais la plupart des serveurs proxy ne la consultent pas -- seuls les navigateurs en tiennent compte.

Ceci dit, les caches de serveurs proxy ne sont pas toujours configurés correctement. Un serveur proxy est souvent réglé de telle sorte qu'il ne vérifie pas ailleurs que dans son cache si la copie qu'il possède est suffisamment récente (TTL=Time To Live, temps que l'on peut fixer de manière arbitraire). Il est donc conseillé aux utilisateurs du web d'utiliser la fonction "actualiser" de leur navigateur chaque fois qu'ils ont le moindre doute sur la validité de la page affichée. Signalons que le problème peut venir du cache du navigateur lui-même, cache qu'il ne faut pas hésiter à purger. On notera que le navigateur de Netscape gère deux caches, dont un en mémoire vive, et qu'il peut être nécessaire d'utiliser une méthode brutale (arrêt et relance du navigateur) pour obtenir la version la plus récente d'une page donnée. On trouve sur le marché des logiciels censés améliorer le fonctionnement du cache des navigateurs (liste).

On peut se faire une opinion sur le rôle des caches en modifiant le nom de l'image de comptage (ou marqueur) incluse dans une page web donnée. Ce marqueur est constitué d'une image monopixel transparente, dont on déclare nulle la durée de validité. On regarde ensuite dans le fichier journal du serveur web à quelle vitesse la nouvelle image remplace l'ancienne dans les requêtes des internautes. L'expérience montre que :

    pour l'essentiel, les caches ne conservent pas l'information plus de 24 heures ;
  les caches des moteurs de recherche ne sont renouvelés qu'après plusieurs semaines. On conçoit qu'un moteur qui possède des dizaines (voire des centaines) de millions de pages cachées ne les renouvelle pas tous les jours ;
  quelques très rares caches sont gérés en dépit du bon sens. Nous venons de rencontrer un exemple où l'une des pages de notre site a été conservée en cache... plus de six mois !

 
2 - Le rôle d'enregistrement du serveur proxy

Comme tout serveur qui se respecte, un proxy génère un fichier journal (log file). On y trouve la trace de toutes les requêtes effectuées par tous les postes clients dépendant du serveur en question. Contrairement à ce qui se passe pour les serveurs web, il n'existe pas de format normalisé pour le fichier journal des serveurs proxy. Cependant, quelle que soit sa présentation, ce fichier journal contient pratiquement toujours :

    la date et l'heure ;
  l'identification du client, sous une forme qui dépend de la manière dont est géré le réseau local. Il peut s'agir d'un numéro ou d'un nom de machine, d'un nom d'utilisateur, etc. Les personnes qui utilisent un ordinateur portable (lequel reçoit un numéro IP à la volée lorsqu'on le branche) peuvent être difficiles à identifier ;
  l'URL de la ressource demandée ;
  la taille de la ressource ;
  le temps de téléchargement ;
  le résultat de l'opération, etc.

On peut analyser le fichier journal en l'important dans une base de données, et en s'adonnant au "data mining" à l'aide de requêtes. On trouve également dans le commerce des logiciels d'analyse (exemples). On peut ainsi savoir comment chacun utilise le web dans l'établissement.

On conçoit qu'un chef d'entreprise veille à ce qu'aucun employé n'abuse de la bande passante en écoutant la radio sur Internet, en jouant en ligne, ou en déchargeant interminablement des fichiers MP3. On conçoit également qu'il ne veuille pas que ses employés utilisent Internet à titre privé pendant les heures de travail. Mais le personnel doit être averti de l'existence du proxy et de l'exploitation de son fichier journal. Les règles d'utilisation d'Internet doivent être clairement définies, de même que les sanctions en cas de manquement. Malheureusement on croit souvent bon, lors de l'installation d'un proxy dans l'entreprise, de mettre en avant des raisons de sécurité informatique, alors que le véritable motif est le plus souvent la surveillance du personnel qui utilise le web. L'hypocrisie d'un tel comportement ne peut être cachée longtemps, et elle risque de créer dans l'entreprise un climat  empoisonné de suspicion et d'autocensure. L'un des logiciels dédiés à l'analyse des fichiers log du serveur proxy commercialisé par Microsoft ne s'appelle-t-il pas Webspy ?

Tous les fournisseurs d'accès à Internet (FAI), ou presque, utilisent un serveur proxy, ce qui les met dans une situation juridique quelque peu contradictoire. D'une part, un FAI doit garder la trace de ce que font ses clients, de manière à pouvoir réagir au cas où l'un de ces derniers contreviendrait à la loi (spamming, hacking, pédophilie, racisme, appel à la violence, affirmations calomnieuses, terrorisme -- on voit de tout) et à fournir tous les éléments nécessaires à la justice en cas d'enquête. D'autre part, l'enregistrement détaillé de ce que font les clients peut être considéré comme une atteinte à la vie privée, d'autant que certains FAI utilisent les fichiers log de leur proxy pour créer des listes de prospects à des fins de commercialisation. La déontologie des FAI n'est pas encore tout à fait au point, de même que la jurisprudence.
 

3 - Le rôle de filtre du serveur proxy

On peut configurer un serveur proxy de telle sorte qu'il examine le contenu des paquets qu'il reçoit pour le compte des clients, et qu'il refuse de transmettre ceux qui ne répondent pas à certains critères. On notera que l'on peut faire la même chose avec un navigateur tel que Internet Explorer, et que l'on peut protéger les niveaux définis (pour la langue, la nudité, le sexe et la violence) à l'aide d'un mot de passe.

Le problème du filtrage a été particulièrement débattu aux États-Unis, parce que de nombreuses bibliothèques et écoles mettent le web à la disposition de leur public, et qu'il faut éviter que les enfants accèdent à des contenus dont seuls des adultes doivent avoir connaissance. Mais le problème est insoluble, parce qu'un bon filtrage requiert de l'intelligence, et que les ordinateurs n'en ont pas. Filtrer sur des mots détachés de leur contexte -- et c'est bien ainsi que fonctionnent les filtres -- conduit aux pires sottises. De plus les ordinateurs ne savent pas analyser les images, et on ne peut pas leur demander de faire la différence entre un nu académique, un nu érotique et un nu pornographique -- à titre d'exemple. Le serveur proxy, comme tout autre système de filtre, est un censeur désastreux.

Bien que, dans l'entreprise, il n'y ait pas d'enfant à protéger, l'idée qu'il existe des sites "répréhensibles" et qu'il faut bloquer les informations "inappropriées" a fait son chemin. Cela signifie que l'on soulève un problème de gestion, et qu'on prétend le résoudre avec des moyens techniques. Une telle tentative est en grande partie vouée à l'échec, car ceux qui veulent contourner le filtre y arriveront toujours peu ou prou. D'ailleurs, fouille-t-on la serviette des employés qui arrivent le matin au travail, pour voir si elle contient des informations "inappropriées" ? L'auteur de ces lignes ne peut s'empêcher de sourire en pensant que, pendant que l'on dépense de l'argent et de l'énergie pour mettre en oeuvre un filtre, un hacker doué est peut-être en train de s'introduire dans le système informatique de l'entreprise et d'y faire des dégâts.

Le web est rempli d'histoires plaisantes relatant les bévues des systèmes filtrant Internet, et je ne résiste pas au plaisir de vous en rapporter une. Aux États-Unis l'Utah est, comme chacun sait, dominé par les mormons. Les filtres qui furent installés dans les écoles à titre d'essai étaient donc fort rigoureux. On rapporte qu'ils bloquaient de très nombreux sites, en particulier ceux contenant des citations de la bible -- un ouvrage sulfureux à ne pas mettre entre toutes les mains, comme chacun sait.

Le serveur proxy peut également être utilisé pour définir les droits de chaque client en ce qui concerne le web : personnes autorisées, heures permises, sites accessibles ou défendus, etc. Les gestionnaires de système informatique adorent ce genre de chose, et nul doute qu'un proxy bien doté en matière de gestion des droits leur plaise particulièrement.
 

4 - Le rôle d'anonymiseur

Il existe sur Internet des sites web "bidons" (parfois appelés "sites miel"), montés dans le seul but de savoir qui s'intéresse à un sujet donné. Cela va du sondage d'opinion à l'espionnage industriel. Bien sûr, une adresse internet n'est pas liée à un nom de personne, mais elle est liée à un nom d'organisme. Quand je parcours le web, les serveurs des sites que je visite ont connaissance du numéro IP de ma machine (195.220.30.95). A l'aide d'un annuaire DNS inverse (exemple : RIPE), les administrateurs de ces serveurs peuvent savoir que ma machine appartient au réseau de l'Institut National Polytechnique de Grenoble (faites l'expérience). De cette façon, on peut essayer savoir quelles sont les entreprises qui s'intéressent à tel ou tel procédé, par exemple.

Pour cette raison ou pour une autre (respect de la vie privée, par exemple), il peut être intéressant de rechercher de l'information sur le web de manière anonyme. Pour ce faire, on peut utiliser un poste client qui ne possède pas d'adresse Internet "en dur", mais qui reçoit une adresse à la volée du DHCP d'un fournisseur d'accès. Si je parcours le web via AOL par exemple, l'administrateur de serveur qui relève mon numéro IP et l'introduit dans un DNS inverse apprend que ce numéro appartient à AOL, et rien de plus (en fait, il n'a même pas besoin d'utiliser cette procédure, car le nom d'AOL s'inscrit dans le fichier journal du serveur). Remarque : pour plus de sûreté, il faut aussi configurer son navigateur de telle sorte qu'il n'accepte pas les cookies.

Une autre solution consiste à utiliser un serveur proxy public dénommé "anonymizer" (en français : anonymiseur -- mais le terme est peu employé). Un tel serveur doit remplir les trois conditions suivantes :

    ne pas retransmettre l'adresse IP du client ;
  supprimer tous les cookies ;
  ne pas enregistrer de fichier journal, ou le détruire dans les délais légaux sans l'avoir utilisé.

Les anonymiseurs ne sont pas sans défauts :

    il faut reconfigurer son navigateur pour se connecter au web via un proxy public ;
  le risque existe qu'un anonymiseur ne soit pas de bonne foi, et plus particulièrement lorsque le service est gratuit, la seule source de financement provenant alors de la publicité (voir la déclaration de confidentialité d'un anonymiseur connu) ;
  le passage par l'anonymiseur ralentit beaucoup l'accès au web ;
  les sites qui requièrent l'usage des cookies ne peuvent pas être atteints ;
  les anonymiseurs gratuits n'assurent pas les liaisons sécurisées par le protocole SSL.

Pour toutes les questions relatives aux anonymiseurs, consulter la FAQ mise en ligne par iNetPrivacy Software. Certains sites entretiennent des listes de serveurs proxy publics : AltaVista, Rosinstrument, Samair, etc. Un site russe fournit la liste de tous les serveurs proxy publics qu'il a pu trouver sur le web, et il n'est pas le seul.
 

5 - Sécurité et fire-wall

Comme nous l'avons signalé plus haut, la sécurité du réseau local constitue souvent l'argument massue de ceux qui installent un proxy dans une entreprise. Il est vrai que certains logiciels de serveur proxy incorporent des fonctions de sécurité. Mais comme dit le proverbe : "qui trop embrasse mal étreint". Pour une vraie sécurité, rien ne vaut un dispositif dédié, lequel s'appelle un coupe-feu (firewall). Il existe une foire aux questions très complète à ce sujet.

En fait, l'entreprise doit d'abord définir une politique de sécurité avant d'envisager le type de matériel qu'elle envisage d'acheter. Une telle politique doit résulter d'un compromis entre les desiderata du service informatique (qui veut réaliser un système très sûr, donc très restrictif), et les besoins des utilisateurs (qui désirent un système aussi permissif que possible, de manière à rester créatifs et à pouvoir travailler). C'est seulement lorsque la politique de sécurité est définie que l'on peut choisir les matériels qui permettront sa mise en oeuvre.

Une politique de sécurité complète doit tenir compte des agressions provenant de l'extérieur -- dont on parle beaucoup -- et de celles provenant de l'intérieur -- dont on parle fort peu, bien qu'elles représentent la majorité des cas. Bien entendu, proxy ou firewall ne sont utiles que vis à vis des attaques extérieures. Pour parer aux attaques internes à l'entreprise, il faut utiliser un système de détection d'intrusion (Intrusion Detection System). Ce dernier surveille le système informatique, et signale tout événement sortant de l'ordinaire. Nombre de ces événements, bien sûr, constituent de fausses alertes, si bien que la détection d'intrusion n'est pas chose facile.

Le coupe-feu est un système informatique (ordinateur + logiciel), que l'on intercale entre le réseau local de l'entreprise et le réseau mondial Internet, et qui surveille les échanges d'information, dans les deux sens, entre ces deux réseaux. On peut même être plus général, et définir le firewall comme l'interface entre deux réseaux, ou entre deux parties d'un même réseau. Le pare-feu examine chaque paquet d'information qui le traverse et décide, en application des règles définies lors de sa configuration, de le laisser passer ou de le détruire. La notion de coupe-feu est apparue pour la première fois en 1987, et la première réalisation pratique date de 1994. Depuis, les problèmes de sécurité n'ont fait que croître et embellir sur Internet, si bien que le coupe-feu fait une carrière commerciale plus qu'honorable.

Dans la taxonomie des firewalls, les puristes distinguent plusieurs types (de deux à quatre), suivant le niveau auquel le dispositif fonctionne dans le modèle OSI. Des querelles d'écoles ont bien sûr éclaté, pour savoir quel était le meilleur type -- discussions parfaitement stériles parce que les firewalls commercialement disponibles fonctionnent souvent sur plusieurs niveaux à la fois. Pour simplifier, on peut distinguer deux cas extrêmes :

    le pare-feu qui n'examine que l'en-tête des paquets. C'est souvent ainsi que fonctionne le pare-feu destiné à protéger un réseau local ;
  le pare-feu qui n'examine que l'information utile contenue dans les paquets. C'est souvent le cas du pare-feu destiné à protéger un serveur web.

Protection réseau localLe schéma classique de protection centralisée d'un réseau local comportant un serveur web est représenté sur la figure ci-contre. L'entreprise est reliée à Internet via un routeur, derrière lequel on place un coupe-feu. Ce dernier possède une entrée (vers le routeur), et deux sorties (l'une vers le réseau local, l'autre vers le serveur web). On configure de manière distincte les trois canaux de communication ainsi créés : entre Internet et le serveur web (tâche la plus difficile), entre Internet et le réseau local, entre le serveur web et le réseau local. Pour plus de sécurité encore, on peut transformer le routeur en "bastion", c'est à dire que l'on durcit ses protections au maximum (utilisation d'un système d'exploitation dédié, suppression de toutes les fonctions inutiles, application immédiate des patchs, etc.).

La protection peut également être décentralisée : un coupe-feu personnel peut être installé sur chaque ordinateur de l'entreprise (distributed firewall). De nombreux logiciels coupe-feu existent sur le marché, et Windows XP professionnel en comporte un en standard. Cette solution décentralisée présente plusieurs inconvénients :

    elle complique la tâche de l'administrateur du réseau ;
  elle ne permet pas de partager des fichiers ou des périphériques (ex : imprimante) ;
  elle est incompatible avec l'usage d'un serveur web personnel (Personnal Web Server).

Le coupe-feu personnel devrait donc être réservé aux ordinateurs des particuliers qui ont une liaison permanente avec internet (via le câble ou l'ADSL), mais qui ne sont pas reliés à un réseau local.

Un serveur web peut également être protégé à l'aide d'un logiciel coupe-feu. Lorsqu'on utilise le logiciel serveur web IIS (Internet Information Server) de l'éditeur Microsoft, on a le choix entre un produit gratuit (URLScan, de Microsoft), et un produit commercial (SecureIIS de eEye Digital Security, distribué en France par CoperNet). Le second est réputé être nettement plus convivial que le premier.

La protection d'un serveur web public est nettement plus difficile à assurer que celle d'un réseau local, et le firewall ne constitue pas la panacée universelle. De nombreux coupe-feu ont été traversés par les vers CodeRed et Nimda au cours de l'année 2001, si bien que certains webmestres préfèrent transformer leur serveur web en bastion, plutôt que de faire confiance à un firewall quel qu'il soit. On notera qu'un serveur web fonctionnant en simple serveur de fichiers est plus facile à protéger qu'une machine fonctionnant aussi en serveur d'applications. On notera également qu'il est extrêmement difficile de se protéger contre une attaque de type DoS (Deny of Service) bien conduite.
 

6 - Conclusion

L'installation d'un serveur proxy ne se justifie que dans la mesure où l'on veut enregistrer (ou plus encore, réglementer) l'accès d'une communauté d'internautes au web. Les autres arguments généralement invoqués -- l'accélération des accès grâce au cache, la sécurité -- ne sont le plus souvent que de faux-semblants. Il faut appeler un chat un chat, et reconnaître que l'intérêt du proxy provient des son fichier journal, dans lequel sont enregistrées toutes les opérations effectuées par les internautes.

Si le cache joue effectivement un rôle positif, que l'on rende donc l'usage du proxy facultatif. Ainsi, les internautes pourront faire leur propre expérience, et juger par eux-mêmes des avantages et des inconvénients du serveur proxy. En fait, il est rarissime que le service informatique d'une entreprise agisse de la sorte. Autoritarisme, ou crainte du résultat ?

Le rôle de sécurité du proxy est un leurre. Mieux vaut utiliser un firewall correctement configuré -- ce qui n'est pas une mince affaire. On a dit et répété que 300.000 serveurs avaient été compromis par le ver Nimda au cours de ces six derniers mois, mais on oublie d'ajouter que bon nombre d'entre eux étaient "protégés" par un firewall. Car les hackers savent eux aussi comment on configure un coupe-feu, et l'attaquant a toujours une longueur d'avance sur le défenseur. En matière de sécurité informatique, il n'y a ni recette miracle, ni solution définitive.

Note précédente Liste des notes Page technique  Note suivante 
 
Accueil | Technique | Liens | Actualités | Formation | Emploi | Forums | Base
 
Copyright © CERIG/EFPG 1996-2002
Mise en page : J.C. Sohm