Recommandations d’architecture de réseau avec filtrages pour améliorer la sécurité

Les services dans la zone semi-ouverte

Dans la zone semi-ouverte, en entrée de site, il faut installer toutes les machines qui assurent les services réseau avec l’extérieur : DNS, messagerie, Web, FTP anonyme, News, serveur d’accès commuté, cache Web, bases de données publiques, et tout autre service qui a besoin de communication intensive avec l’Internet. Cette zone sera typiquement un réseau Ethernet 10 ou 100 M, selon le débit de la prise d’accès à l’Internet. Inutile d’avoir du Gigabit si on n’a qu’un accès à 2 M avec l’Internet. Ce réseau sera connecté à l’Internet par un routeur (R1 sur le schéma) dans lequel on aura installé un ensemble de filtres décrits ci-après. Les services réseau pouront être éclatés sur plusieurs machines ou concentrés sur une ou deux, selon la taille du site, le budget, le mode d’administration … L’éclatement conseillé sur plusieurs machines permet de mieux limiter et surveiller les accès.
Ces machines constituent la poignée de machines qu’il faut parfaitement gérer.
Chaque machine sera dédiée à sa ou à ses fonctions , elle ne sera pas utilisée comme station  de travail « classique » et n’hébergera pas d’autres applications.
Les systèmes pourront être Unix ou NT. Le critère de choix doit être la compétence des administrateurs. Les services NT peuvent paraître plus simples à installer mais NT est un système complet qu’il faut maîtriser et connaître comme Unix si on veut assurer sa sécurité et globalement son bon fonctionnement.
Sur ces machines, les versions des systèmes et des applications seront régulièrement mises à niveau et les correctifs de sécurité seront installés dès qu’ils seront diffusés.
Tous les services réseaux inutiles seront inhibés (ménage dans inetd.conf sur Unix ou dans Panneau de configuration – Services sur NT). Un minimum d’utilisateurs avec un accès interactif seront déclarés, uniquement les administrateurs qui en ont besoin. Sur chacune sera installé un outil de contrôle et de trace des connexions tel que tcp_wrapper sur Unix. Dans ces serveurs, tous les messages de journalisation (logs) seront renvoyés sur un serveur interne, appelé « Serveur logs » sur le schéma ci-après.
Regardons quelques services qui demandent certaines adaptations :
• Sur le serveur de messagerie seront déclarés tous les utilisateurs avec un compte de messagerie POP ou IMAP pour accéder à leur boite aux lettres mais sans possibilité de travail interactif (pas de shell, d’où le nom « Mail sans sh »). Si pour lire leur courrier certains utilisent des commandes Unix (qui nécessitent un shell), leurs messages seront renvoyés vers un serveur de messagerie interne, appelé « Mail avec sh » dans le schéma, où ces utilisateurs auront des comptes interactifs. Pour chaque utilisateur, le mot de passe utilisé pour accéder au serveur de messagerie de la zone semi-ouverte sera
différent de tous les autres mots de passe utilisés pour accéder aux autres systèmes, en particulier de celui de leur machine de travail.
• Le serveur Web contiendra uniquement des pages publiques. Si le site désire avoir des pages privées elles seront sur un serveur interne, appelé « Serveur Web interne » sur le schéma. De même 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 nécessite ce type d’accès 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 maîtrisent parfaitement les mécanismes de protection de ce système, ou tout autre système similaire et bien maîtrisé.
• Si le site compte un ou des serveurs de bases de données publiques accédées depuis l’Internet, on installera ces machines dans cette zone, et on appliquera les mêmes recommandations d’exploitation et de mise à jour que pour le serveur Web.
• Si le site dispose d’un service d’accès 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 d’accès par utilisateur, en particulier on ne permettra pas par défaut une connexion à l’Internet via ces accès.
• Pour interdire l’accès direct en telnet ou FTP depuis l’Internet sur les machines du réseau interne, une machine relais pourra être installée. Ainsi un utilisateur qui depuis l’extérieur voudra  accéder en interactif avec telnet sur sa machine de laboratoire devra d’abord se connecter sur ce relais puis ensuite faire un autre telnet. Sur ce relais seront déclarés uniquement les utilisateurs qui auront besoin de ce service avec un mot de passe particulier. Une trace de tous les accès sur ce relais sera conservée. Un contrôle très fin des comptes utilisateurs (durée de vie des comptes, solidité des mots de passe, …) sera effectué. Ce passage obligé permet de concentrer toutes les bonnes mesures de sécurité 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 réseau qui se généraliseront, on peut le penser, comme l’annuaire LDAP (Light Directory Access Protocol), pourront être intégrés de la même manière : un serveur LDAP avec des informations « publiques » (comme le numéro de téléphone ou l’adresse électronique) dans la zone semi-ouverte, un autre dans la zone « Services communs internes » pour les informations  « privées » (comme le mot de passe).
En un point de cette zone on peut scruter tous les échanges avec l’Internet. C’est l’endroit où installer un outil qui mesure l’activité et repère certains trafics anormaux, analyseur de trafic comme IPtrafic ou détecteur d’intrusions. Ce type d’équipement peut être très utile pour détecter des attaques et pour connaître l’utilisation de l’Internet faite par le site. Le seul problème est le temps nécessaire à l’installation et l’exploitation des résultats de ce genre de produit.

Si le lien ne fonctionne pas correctement, veuillez nous contacter (mentionner le lien dans votre message)
Recommandations d’architecture de réseau (56,0 KO) (Cours PDF)
Recommandations d’architecture de réseau

Télécharger aussi :

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *