HSC
Network Security Consulting Agency Since 1989 - Specialized in Unix, Windows, TCP/IP and Internet
Text mode: access to the page content
Hervé Schauer Consultants
You are here: Home > Resources > Articles > Distributed Network Security - From the Firewall to Network Partitionning
Go to: HSC Trainings
Search:  
Version française
   Services   
o Skills & Expertise
o Consulting
o ISO 27001 services
o Audit & Assessment
o Penetration tests
o Vunerability assessment (TSAR)
o Forensics
o ARJEL
o Training courses
o E-learning
   Conferences   
o Agenda
o Past events
o Tutorials
   Resources   
o Thematic index
o Tips
o Lectures
o Courses
o Articles
o Tools (download)
o Vulnerability watch
   Company   
o Hervé Schauer
o Team
o Job opportunities
o Credentials
o History
o Partnerships
o Associations
   Press and
 communication
 
 
o HSC Newsletter
o Press review
o Press releases
o Publications
   Contacts   
o How to reach us
o Specific inquiries
o Directions to our office
o Hotels near our office
|>|Distributed Network Security
From the Firewall to Network Partitionning  
> Access to the content HTML Beginning of the article  
> Description The security of the perimeter was the first concern in network security. Many sites installed security mechanisms of the firewall type, or at least TCP/IP filters, on their Internet connection. It is now necessary to taker care of the security of the internal network, and to set up security between the various entities: students, laboratories, administration for example. For that, it is not necessary to add security devices, but simply to organize oneself to partition the network by using the existing hardware.  
> Context & Dates This document is the proceeding of the talk Distributed Network Security - From Firewall to Network Partitioning made at JRES99 on 30 November 1999.
Also published in Confidentiel Sécurité number 74 (January 2001) et 75 (February 2001).
30 November 1999 - Talk at JRES99
2 May 2000 - Publication on HSC's web site  
> Author Hervé Schauer (Herve.Schauer@hsc.fr) 
> Type  
> Abstract &
Table of content
I. Exemples

II. Cloisonnement de réseau
Est-ce que le cloisonnement de réseau satisfait ?
Quand utiliser le cloisonnement de réseau ?
Quels problèmes de performance pose le cloisonnement de réseau ?
Le cloisonnement de réseau est-il utilisable à une large échelle ?
Limites et futur du cloisonnement de réseau

III. Le processus de cloisonnement
1) Déterminer les domaines à cloisonner
2) Déterminer les flux
3) Appliquer la politique de sécurité sur les flux
4) Appliquer la flux sur les périphériques de filtrage
5) Auditer et valider les règles de filtrage dans les périphériques filtrants
6) Mettre à jour les schémas de flux

IV. Organisation

V. Outils

VI. Conclusion

Annexe : Références et ressources  

> Related documents
themeNetwork Partitionning
[Presentation]  Industrial control systems security. Scadastrophe... or not. [15 May 2012 - French]
[Presentation]  Deperimetrization or not ? [22 November 2007 - French]
[Presentation]  Network security stakes [14 October 2004 - French]
[Article]  Networks Security [25 July 2000 - French]
[Presentation]  Distributed Network Security [12 May 2000 - English]
[Presentation]  Distributed Network Security [15 December 1999 - English]
[Presentation]  Distributed Network Security - From Firewall to Network Partitioning [30 November 1999 - French]
[Presentation]  Le cloisonnement de réseaux [18 August 1999 - English]
[Article]  Network Partitioning [August 1997 - French]
[Presentation]  Private networks partitioning [8 July 1997 - French]
[Presentation]  Intranets partitioning [June 1997 - French]
> Copyright © 1999, Hervé Schauer Consultants, all rights reserved.

 


I. Exemples

Quelques exemples, tous réels, pour apprécier l'importance et les possibilités apportées par la sécurité réseau répartie :

  1. Une organisation prend un stagiaire : celui-ci écoute le réseau et voit passer les mots de passe de messagerie des employés ; il lit leurs messages.
  2. Une entreprise a des sous-traitants qui travaillent sur son réseau. L'un de ces sous-traitants n'a pas été payé : il est en conflit avec l'entreprise. Il utilise un déni de service bien connu de Windows NT pour arrêter les 300 Windows NT serveurs de l'entreprise.
  3. Un groupe international a des filiales dans de nombreux pays. Les employés de l'une de ces filiales se mettent en grève, après que leur responsable leur ait refusé les avantages acquis par leurs collègues dans un autre pays. Ils avaient suivi les négociations et les résultats sur le web interne du pays voisin.
  4. Une organisation possède une liaison directe avec sa banque pour les paiements des salaires. La base de données de son serveur bancaire est piratée et l'intrus réussit à provoquer des virements vers son propre compte.
  5. Un industriel coopère avec un concurrent étranger sur un projet en commun. En ayant accès à certains serveurs, le concurrent récupère toutes les informations sur le projet en cours, mais, en piratant les machines, il récupère aussi les informations sur le futur produit à venir.
  6. Ajoutez votre exemple personnel à cette liste.

Quelles solutions pour ces problèmes de sécurité ? Les solutions qui ont été suggérées sont :

  1. Pour éviter l'écoute du réseau, il faut migrer vers un environnement commuté ou avec des concentrateurs intelligents. C'est un bon conseil mais pas toujours possible avec son matériel actuel.
  2. Pour éviter les dénis de service sur Windows NT, mettre à jour son système et appliquer les hot-fixes. Le problème est que même en étant à jour, attaquer les systèmes Microsoft reste toujours facile.
  3. Pour éviter que toute l'entreprise ait accès aux serveurs internes d'une filiale, ajouter une authentification des utilisateurs sur chaque serveur. Mais comment gérer ainsi des dizaines de serveurs web ? Un filtrage en entrée sur chaque serveur est plus simple mais demande également le bon vouloir de chaque gestionnaire de serveur web.
  4. Couper l'accès réseau au serveur de base de données. Il est coupé du réseau interne mais reste connecté à la banque. Les problèmes d'exploitation qui en résultent limitent l'intérêt de cette solution.
  5. Pour éviter le piratage des serveurs, mettre en oeuvre une meilleure utilisation de la sécurité au niveau du système d'exploitation, avec des groupes, un chroot des utilisateurs externes, etc. Sur un gros serveur, c'est réalisable, mais sur des dizaines de serveurs répartis, cela ne l'est pas.

L'analyse de ces cas montre les éléments suivants :

  1. Le stagiaire n'avait pas besoin d'avoir accès au serveur de messagerie.
  2. Le sous-traitant n'avait besoin que de l'accès à 6 serveurs Windows NT pour travailler, accéder à ses fichiers, aux fichiers partagés, à la messagerie, à l'imprimante, etc.
  3. Les salariés dans un pays n'ont pas besoin de l'accès aux serveurs web internes des autres pays.
  4. De là où se trouvait le pirate, il n'aurait jamais du pouvoir attaquer et se connecter sur le serveur de base de données relié à la banque.
  5. Le concurrent n'aurait jamais du pouvoir ne serait-ce que voir l'existence des données des autres projets et surtout celles du futur produit.

La solution pour gérer l'accès à de nombreux serveurs, les sécuriser, sécuriser les applicatifs comme les serveurs web, contrôler les accès dans le réseau, est pour beaucoup "mettre des firewalls partout".

Au sens rajouter un ordinateur de plus, c'est évidemment irréaliste, mais, c'est la solution : avoir une sorte de firewalls distribués partout dans le réseau. Or, le réseau est construit avec des équipements capables de réaliser cette sécurité distribuée. C'est typiquement le cas des routeurs.

La sécurité est déployée au niveau réseau, en réutilisant les périphériques existants. Cette solution permet un contrôle des flux global, minimise les risques et élimine toutes les attaques vues dans les exemples. C'est le cloisonnement de réseau.


II. Cloisonnement de réseau

Pour cloisonner un réseau il suffit de le découper en ensembles de sous-réseaux, les domaines, puis de mettre des filtres sur les routeurs ou les commutateurs qui interconnectent ces sous-réseaux. Les périphériques qui font du filtrage dans le réseau deviennent des SPEP (Security Policy Enforcement Points). Les périphériques filtrants ne laissent passer que les flux nécessaires entre les domaines, en utilisant des ACL (access-control-lists) classiques.

Le cloisonnement de réseau est aussi appelé le partitionnement de réseau (network partitioning en anglais).

Fig. 1 : exemple de cloisonnement de réseau

Les applications du cloisonnement de réseaux sont nombreuses : dès que plusieurs systèmes de filtrage sont nécessaires, le cloisonnement de réseau est intéressant. Cela peut être la sécurisation au sein d'un intranet entre les différents services et projets, la gestion d'accès complexes à Internet, les plates-formes de commerce électronique, les extranets ou les réseaux en étoile.

Voici quelques exemples :

Fig. 2 : accès Internet et Partenaires

Fig. 3 : plate-forme de commerce électronique

Fig. 4 : accès Internet, dialup, plate-forme de commerce électronique, cloisonnement du réseau privé et filtrage des agences

Fig. 5 : accès Internet et cloisonnement du réseau interne

Fig. 6 : Plate-forme de commerce électronique

Fig. 7 : accès Internet multiples

Les solutions de sécurité réseau disponibles jusqu'à présent présentent des difficultés.

La sécurité distribuée, basée sur Kerberos, OSF/DCE en version commerciale, est complexe à mettre en oeuvre, à administrer et à déployer. Même si Microsoft annonce un dérivé de Kerberos pour Windows 2000, l'intégration des certificats X509 dans Active Directory semble être la base de la sécurité distribuée de Windows 2000.

La détection d'intrusion est très utile dans certains cas précis : pour détecter des erreurs de configuration, pour détecter des signatures dans le contenu de certains protocoles de manière différente des firewalls et détecter par exemple Backorifice, ou pour pallier la journalisation incomplète des firewalls. Cependant, la détection d'intrusion est facile à contourner en utilisant la fragmentation, et ce dans tous les cas. La détection d'intrusion, sans sous-estimer son utilité dans certains cas précis, est une sécurité passive dont l'utilité est très largement surestimée par un marketing puissant des fournisseurs de solutions commerciales.

L'usage courant des RPC (Remote Procedure Calls), du code mobile et le développement des technologies objet et des architectures n-tiers, bouleverse les modèles de sécurité existants. L'infrastructure d'une entreprise n'est plus caractérisée par les applicatifs et les données, mais par les flux dans son réseau. Au lieu de se focaliser sur une application de la sécurité à des niveaux élevés (système d'exploitation, applications et données), il est devenu beaucoup plus efficace et réaliste de déployer la sécurité au niveau du réseau dans les flux d'information.

L'ensemble des techniques de sécurité existantes demeurent indispensables, mais la sécurité réseau répartie par le cloisonnement de réseau est le concept d'avenir. Le cloisonnement réseau peut-être vu comme la distribution dans le réseau de nombreux firewalls, avec une gestion et vision globale.

Si cette notion était encore nouvelle lorsqu'elle a été présentée à Infosec en 1997 [HS1], elle est désormais universellement reconnue par les figures du domaine [SB1] [JF1].

Est-ce que le cloisonnement de réseau satisfait ?

Le cloisonnement de réseau n'est pas une solution qui fait plaisir aux gestionnaires de réseaux : centres de supervision, architectes, etc. Dans la majorité des cas, les gestionnaires de réseaux, et particulièrement en France, ne souhaitent pas voir de la sécurité sur leur réseau.

Le réseau est parfois récent dans son étendue actuelle, ils en sont fiers et fiers que l'on puisse communiquer de n'importe quel point à n'importe quel point d'un bout à l'autre de la planète. L'époque n'est pourtant plus à ces banalités mais bel et bien à la maîtrise des flux sur le réseau.

Les gestionnaires de réseaux ne sont généralement pas les plus motivés par la sécurité : ils ne veulent pas voir de filtrage IP sur leur routeurs et commutateurs, et prennent encore plus peur s'ils entrevoient les possibilités d'appliquer une politique de sécurité sur les utilisateurs par le biais du réseau.

Cependant, ils doivent s'adapter. Ils doivent déjà maîtriser les ACL pour faire du routage. Ils vont devoir intégrer la qualité de service, indispensable aux nouveaux services de téléphonie, visiophonie, etc. Or, la qualité de service consiste quelle que soit la technique à sélectionner un flux avec une ACL, pour prioritiser le flux, lui affecter une classe de service, etc. La sécurité, sur chaque flux, se contente d'autoriser ou d'interdire, parfois de demander du chiffrement.

Les autres métiers sont plutôt très satisfaits d'une sécurité réseau distribuée par le cloisonnement du réseau.

Le cloisonnement de réseau est transparent pour les utilisateurs qui n'ont pas de mot de passe supplémentaire à taper.

Le cloisonnement de réseau n'affecte pas les administrateurs systèmes, au contraire, la sécurité est désormais assurée au niveau du réseau : ils ne devraient plus avoir autant de problèmes sur leurs serveurs qu'auparavant. Ils n'ont rien à changer, rien à implémenter.

Le cloisonnement de réseau répond aux besoins du responsable sécurité, et ce sont pour les responsables sécurité que cette technique a été développée à l'origine : en effet, le cloisonnement de réseau apporte une vision globale de la politique de sécurité et une centralisation du contrôle et de la gestion de la sécurité. En cela, il se rapproche de la sécurité des mainframes. Le cloisonnement de réseau est aisé à comprendre, ainsi il facilite la communication avec la hiérarchie.

Quand utiliser le cloisonnement de réseau ?

Le cloisonnement de réseaux s'utilise idéalement quand le périmètre du réseau est difficile à établir. Beaucoup d'organisations ont un périmètre ingérable, pas toujours très clair ou poreux : les laboratoires ou filiales moitié d'un côté, moitié d'un autre ; l'utilisation de l'Internet pour son réseau privé ; les utilisateurs mobiles, qui utilisent le même PC tantôt sur Internet, tantôt sur le réseau privé ; les VPN ou liens spécialisés avec les partenaires et sous-traitants ; les plates-formes de commerce électronique qui multiplient les liens avec l'Internet, etc. Dans tous ces cas, le déploiement d'une sécurité distribuée dans le réseau permet efficacement de réduire les risques d'intrusion.

Le cloisonnement de réseau est également nécessaire quand il y a des entités à séparer  : si le réseau s'est étendu de manière très large, si les antennes régionales n'appliquent pas la sécurité du siège, où lorsque les métiers sont différents. Les services financiers, du personnel ou une direction générale, sont souvent des métiers qui justifient un cloisonnement. Cela est également le cas pour une large variété de départements en fonctions des cas : recherche vs marketing, enseignement vs administration, etc. C'est aussi typiquement le cas dans une organisation internationale entre les réseaux des différents pays.

Quels problèmes de performance pose le cloisonnement de réseau ?

La performance du filtrage IP est un problème quotidien. De très nombreux périphériques utilisés sont d'entrée de gamme. Plutôt que de bénéficier d'un meilleur routeur pour le même prix, le routeur le moins cher sera toujours choisi. Des équipements conçus pour un usage individuel et ne permettant pas de filtrage important, sont ainsi souvent trouvés dans des établissements publics de soixante personnes, nécessitant pourtant une sécurité importante. Les routeurs d'entrée de gamme n'ont généralement pas assez de mémoire pour tenir des filtres exhaustifs. Les routeurs peu coûteux ont un filtrage minimaliste et de mauvaise qualité : ils ne savent pas grouper des services où des adresses par exemple, et souvent ils n'optimisent pas le filtrage IP.

Il est nécessaire d'intégrer la sécurité dans la conception du réseau et ainsi choisir des équipements correctement dimensionnés.

Il existe des solutions pratiques à la taille des filtres, comme la suppression des commentaires, la compression du fichier des filtres ou la simplification de la politique, en se contentant des adresses IP.

Cependant, à terme la performance du filtrage IP sera de moins en moins un problème. Le fond de panier d'un routeur devient un commutateur. Les commutateurs appliquent désormais le filtrage IP au niveau matériel, dans des ASIC. Ils sont aussi appelés par les fournisseurs des commutateurs de niveau 4 pour montrer qu'ils savent faire de la commutation de flux port source/port destination. Ce n'est pas la sécurité qui tire cette évolution technologique, mais la qualité de service pour la téléphonie sur IP. Dans ces commutateurs, le temps de traitement d'un datagramme avec du filtrage IP, n'est plus dépendant de la longueur des ACL.

Il est enfin possible d'optimiser le filtrage IP globalement. Si un logiciel qui a la connaissance globale du réseau est utilisé pour générer ses ACL, il est possible de ne générer que des ACL précises et exhaustives que sur le premier, le dernier et le meilleur filtre. Sur les autres routeurs, on peut se contenter des adresses IP par exemple, sans les numéros de ports. De plus, le concept de cloisonnement de réseau élimine le trafic non souhaité au plus près de là où il est généré.

Fig. 8 : optimisation globale du filtrage IP

Le cloisonnement de réseau est-il utilisable à une large échelle ?

Les éditeurs de logiciels propriétaires proposent des outils permettant de cloisonner globalement un réseau, outils basés sur deux principes : un tableau de règles comme Check Point FW-1 ou une vue visuelle et topologique avec des règles globales comme Solsoft Net Partitioner.

Il n'existe pas encore d'outils libres dans ce domaine.

Les outils proposant des tableaux n'ont pas de connaissance du réseau et imposent à l'administrateur de calculer lui-même sur quels routeurs il faut appliquer chaque règle. Il n'existe encore que Net Partitioner de Solsoft qui soit capable d'avoir la compréhension de la topologie du réseau et de calculer par lui-même où chaque règle doit être appliquée ; mais il est probable que tous les outils vont s'orienter dans cette voie.

Sans connaissance de la topologie, il est réaliste, d'après les administrateurs expérimentés, de pouvoir gérer jusqu'à 5 SPEP (périphériques sur lesquels la sécurité est appliquée) dans un réseau maillé.

Pour un réseau en étoile où des centaines de branches auraient la même politique de sécurité, cette limite disparaît.

Avec la connaissance de la topologie et une vision visuelle, la limite devient graphique et l'expérience montre qu'au-delà de 50 SPEP dans un réseau maillé, un grand écran arrive à ses limites.

Avec un réseau en étoile toutes les entités ayant la même politique ne sont représentées qu'une fois.

En terme de nombre de règles, une vue en tableau devient difficile au-delà de 70 règles et les erreurs deviennent trop faciles. Un ensemble de vues de règles topologiques n'a pas de limite.

Ainsi le cloisonnement de réseau est tout à fait utilisable à une large échelle et aucun réseau jusqu'à présent n'a pas pu intégrer cette technique.

Limites et futur du cloisonnement de réseau

Le cloisonnement de réseau repose sur le filtrage IP et donc sur les adresses IP. Il est couramment admis qu'il faut accorder une confiance limitée dans une adresse IP, car celle-ci peut-être facilement usurpée. Cependant, si cette assertion est vraie sur Internet, le cloisonnement de réseau s'applique dans un réseau privé, où le plan d'adressage et le routage sont maîtrisés. Ainsi, une adresse ne pourra être usurpée que sur un réseau local sans sécurité. L'évolution vers les environnements commutés, avec des VLAN et DHCP utilisant les adresses MAC (Ethernet) et les ports physiques du commutateur, permettent d'accorder une confiance de plus en plus grande à une adresse IP sur son réseau privé, et justifient son usage comme base de contrôle dans les réseaux.

Par ailleurs, l'évolution des réseaux va vers une association dynamique des adresses IP aux utilisateurs et à leur authentification, et vers l'authentification de ces derniers comme des équipements par des certificats X.509. Certains fournisseurs proposent d'ores et déjà une telle mise en oeuvre avec les équipements et logiciels actuels - mais cela reste propriétaire.

Ainsi, la sécurité des utilisateurs va se faire globalement, par le cloisonnement de réseau, dans les composants réseau (routeurs, commutateurs), et non plus uniquement dans les serveurs et les applications.


III. Le processus de cloisonnement

Les tâches lors du cloisonnement d'un réseau sont les suivantes :

  1. Déterminer les domaines à cloisonner et les périphériques filtrants (SPEP),
  2. Déterminer les flux entre ces domaines et les dessiner,
  3. Appliquer la politique de sécurité sur ces flux,
  4. Appliquer les flux sur les périphériques de filtrage,
  5. Auditer et valider les règles de filtrage dans les périphériques filtrants (SPEP),
  6. Mettre à jour les schémas de flux.

Le cycle opérationnel répète les phases 3 à 6 régulièrement pour mettre à jour la politique de sécurité et prendre en compte les évolutions des besoins. Les flux doivent être mis à jour en conséquence.

Le service sécurité est généralement maître d'ouvrage de l'ensemble du projet.

Pour les phases 1, 3 et 5, il réalise les travaux.

Les phases 2, 4 et 6 sont généralement réalisées par les télécoms. Le service télécom est au sens large : il peut être réparti entre un service étude, un centre d'exploitation opérationnel du réseau, des centres régionaux, etc.

Le service sécurité ne peut être maître d'oeuvre que sur une sécurité sur le périmètre, à la limite entre le réseau interne et l'extérieur. La sécurité au sein du réseau, appliquée sur des boites distinctes des boites constituant déjà le réseau, s'avère plus complexe à gérer, et le moindre problème sur le réseau est imputé par les télécoms à la sécurité et vis-versa. C'est pourquoi il est nécessaire d'appliquer la sécurité sur les composants du réseau et que le maître d'oeuvre soit le service réseau.

Le service sécurité et le service réseau ont besoin de se partager la même base de données contenant la politique de sécurité. Actuellement, ils doivent nécessairement utiliser le même outil. La normalisation dans ce domaine débute seulement et il n'existe pas de format d'échange normalisé.

Dans le cas d'un réseau infogéré à l'extérieur, le découpage entre les tâches réalisées par le client et celles réalisées par le fournisseur de service correspondent également : le client va assurer les phases 1, 3 et 5 là où la société d'infogérance du réseau devra assurer les phases 2, 4 et 6. Les échanges entre le client et le fournisseur de service doivent être formalisés afin d'éviter toute contestation : le client définit sa politique de sécurité, le fournisseur de service est chargé de l'appliquer.

1) Déterminer les domaines à cloisonner

La détermination des domaines à cloisonner doit appliquer les besoins de l'organisation ou de l'entreprise, par rapport à ses métiers, aux politiques de sécurité : celle globale et les particularités locales, les types d'échanges entre les entités, etc.

Il peut falloir adapter le réseau pour se simplifier la vie : homogénéiser les protocoles vers IP si ce n'est pas déjà fait, rationaliser les connexions entre les domaines, re-préciser son périmètre externe même si cela est de plus en plus difficile, c'est nécessaire pour délimiter les domaines.

Enfin, il faut coller à la réalité et bâtir des domaines correspondant à des entités existantes et cohérentes : un projet, un service, avec une personne responsable.

Les routeurs qui sont aux interconnexions entre domaines, deviennent les points de contrôle de la politique de sécurité dans le réseau (Security Policy Enforcement Points : SPEP).

2) Déterminer les flux

La cartographie exhaustive des flux est déterminée par plusieurs techniques utilisées en parallèles :

  • Interview du service sécurité,
  • Interview des utilisateurs,
  • Récupération des configurations existantes de filtrage,
  • écoutes du réseau.

Le service sécurité possède parfois des éléments permettant de voir quelles sont les limites que les flux de dépassent pas. En tant que maître d'ouvrage, il est le premier concerné.

Les interviews permettent de synthétiser les besoins tels qu'ils sont exprimés par les métiers et les utilisateurs. Les résultats des interviews sont limités mais cela aide à la sensibilisation et demeure utile pour informer les utilisateurs que l'on est en train de bâtir une sécurité globale sur le réseau. Le résultat est une première vision globale.

La récupération des configurations existantes de routeurs et firewalls, permet de voir quelles sont les listes de contrôle d'accès existantes, et donc de se faire une idée de la politique de sécurité déjà en place. Lorsque les ACL sont très importantes et complexes, il faut procéder par un audit : dans la majorité des cas, ces ACL révèlent beaucoup d'incohérences et de contradictions. Souvent des lignes sont là pour des raisons historiques : il est parfois difficile voire impossible de récupérer ainsi la politique de sécurité de l'entreprise. Il est moins coûteux de tout reprendre depuis le début.

Les écoutes sur le réseau restent la seule méthode pertinente pour réaliser une cartographie des flux fiable. Il faut se placer aux bons endroits, sur les brins d'interconnexion, dans les routeurs, sur les commutateurs, sur les liaisons spécialisées. Des écoutes durant une semaine permettent d'avoir une bonne idée de ce qui est utilisé comme protocoles et services.

Cette phase d'écoute aboutit à un premier schéma de flux. à partir de cette cartographie des flux, une première configuration de filtrage est générée. Celle-ci est bâtie sur le principe de l'ouverture exhaustive de tout ce qui a été vu. Pour découvrir les flux non encore découverts, à la fin de ces premiers filtres, il veut mieux terminer par une autorisation de tout le reste, avec journalisation, plutôt qu'une interdiction. Cela permet de voir quels sont les flux manquants sur une durée plus longue. Ensuite, cette autorisation du reste devient une interdiction, et le filtre est bien une autorisation exhaustive de tout ce qui a été vu et une interdiction du reste. Cette technique demande une bonne collaboration des services télécom et réseau.

La synthèse de toutes ces techniques permettra de dessiner la cartographie exhaustive des flux dans le réseau, en appliquant le principe de base : "tout ce qui n'est pas expressément autorisé est interdit".

Représentation des flux :

Les flux peuvent être représentés sous forme de tableau, où en dessin sur un schéma reprenant une vue topologique de haut niveau du réseau, avec juste les domaines et les périphériques filtrants.

Les tableaux sont très rapidement incompréhensibles. Seul un diagramme de flux avec une vue topologique donne une vue globale, avec plusieurs périphériques filtrants. Un diagramme de flux est accessible à tous, et, à défaut de bénéficier d'un outil pour le faire, c'est indispensable de le dessiner à la main.

Pour y voir clair, il convient de ne mettre qu'un seul service par diagramme de flux. Dans certains cas, quelques services sur chaque diagramme de flux sont plus pratiques : par exemple les services HTTP, HTTPS et HTTP pour un relais HTTP Squid peuvent être regroupés sur un diagramme ou bien POP et IMAP. Les flux représentent ce qui est souhaité, donc ce qui est autorisé. Des interdictions explicites sont aussi utiles : par exemple tout l'Internet peut accéder en SMTP au serveur de messagerie mais les grands émetteurs de courrier non sollicité seront explicitement interdits. Cela donne plusieurs diagrammes, mais un Intranet classique possède une vingtaine de services sur le réseau, et le record actuel dans un grand établissement bancaire est à 54 services, ce qui reste très réaliste.

3) Appliquer la politique de sécurité sur les flux

Le responsable sécurité doit valider les flux et les approuver.

Pour chaque service et chaque flux, il faut vérifier que le flux n'est pas dangereux, ne contredit pas les objectifs de sécurité, et qu'il est véritablement nécessaire. Il faut également vérifier que les flux de services nécessaires à l'exploitation du réseau et à la sécurité elle-même, sont présents. Pour chaque flux posant problème, il faut rechercher à quel applicatif il correspond et le propriétaire de l'applicatif, et alors discuter et rechercher le compromis entre la politique de sécurité et les besoins des utilisateurs.

Lorsque tous les flux sont approuvés par le responsable sécurité, il les signe comme "bon pour application".

Les responsables de chaque entité avec laquelle il a fallu négocier en font autant.

4) Appliquer les flux sur les périphériques de filtrage

Le service d'exploitation du réseau (NOC) doit distribuer les filtres sur les périphériques de filtrage dans le cadre de la gestion de réseau. Les procédures de tests, d'homologations, de gestions des versions, de capacité de retour arrière, de journalisation des exploitants, doivent être celles qui sont déjà utilisées par le service réseau.

Les périphériques de filtrage sont aussi les équipements de construction du réseau.

Le filtrage fait partie des fonctionnalités nécessaires pour construire un réseau. Il est donc logique que la responsabilité opérationnelle de ces équipements soit unique et incombe doncpleinement au service d'exploitation du réseau.

Les outils utilisés pour la distribution des configurations de filtrage sont généralement les outils habituels de distribution des configurations des équipements : HP-OpenView, CiscoWorks 2000, Spectrum, Tivoli, etc. Certains outils de gestion de politique de sécurité comme SOLsoft NetPartitioner ou Cisco Secure Policy Manager intègrent une fonction de téléchargement des filtres : celle-ci est utile dans les petites configurations de quelques routeurs mais déconseillée pour les grands réseaux.

Le service réseau est responsable de la cohérence entre la politique de sécurité qu'il reçoit et le routage, l'ordonnancement du téléchargement des filtres, et les accès aux périphériques eux-mêmes.

5) Auditer et valider les règles de filtrage dans les périphériques filtrants (SPEP)

Le service sécurité doit contrôler la sécurité déployée dans les périphériques de filtrage par le service réseau. Pour ce faire, il faut utiliser plusieurs possibilités complémentaires à partir des périphériques de filtrage et de manière indépendante de ceux-ci.

Le service sécurité reçoit la journalisation issue des périphériques de filtrage, et peut à tout moment, demander une relecture de la configuration de filtrage. Par ailleurs, des tests peuvent être réalisés, sous la forme d'audits intrusifs internes, afin de valider ce qui traverse ou pas.

HSC a développé un outil, FilterRules , pour réaliser ce type de vérification.

Le service sécurité est responsable de l'exploitation et l'archivage des journaux, et de la détection d'intrusion.

Il peut éventuellement aussi archiver les configurations de filtrage et sera l'interlocuteur en cas d'enquête.

6) Mettre à jour les schémas de flux

Les utilisateurs, via un service mis en place pour l'occasion ou le centre d'appel, vont demander des nouveaux services. De même les journaux permettront de détecter des tentatives correspondant aux nouveaux services. Les mises à jour régulières sont donc nécessaires, avec une procédure formelle. Cette phase remplace les phases 1 et 2, plus rarement refaites, mais devant l'être à chaque évolution majeure du réseau.

Reprendre ensuite à la phase 3) où le service sécurité re-validera régulièrement tous les filtres, d'autant plus qu'il est généralement le seul à demander la suppression d'un flux autorisé.

Les utilisateurs pensent toujours à tout ce dont ils ont besoin mais pas à ce dont ils n'ont plus besoin. Pour réaliser ce travail, des statistiques sur l'usage de chaque flux sont très utiles.


IV. Organisation

Un cloisonnement réussi repose sur une bonne organisation, avec un centre de gestion de réseau (NOC) et une cellule sécurité. Les équipements implémentant la sécurité étant ceux qui composent le réseau. Ils sont gérés par le NOC ; les tâches entre ce dernier et la sécurité sont donc partagées : la sécurité définit la politique de sécurité et le NOC l'implémente dans les périphériques.


V. Outils

De nombreux outils peuvent aider aux cloisonnements de réseau.

Pour la configuration initiale, HSC a développé les outils nstreams et filterrules , qui facilitent la modélisation des flux, en écoutant le réseau d'une part, et en analysant la configuration existante des filtres d'autre part.

Pour la génération des filtres, HSC utilise le logiciel Net Partitioner de Solsoft , qui a l'avantage de supporter de nombreux systèmes de filtrage, notamment les gratuits, d'offrir une vision globale avec une intelligence dans le calcul des filtres, ce qu'aucun autre outil ne permet.


VI. Conclusion

Le cloisonnement de réseau permet d'aborder globalement la sécurité des entreprises.

En appliquant la sécurité dans le réseau, le cloisonnement est réaliste car déployer la sécurité au niveau système d'exploitation et dans les applicatifs a un coût trop élevé.

Le cloisonnement de réseau permet de distribuer le concept de "firewall" dans le réseau, de manière simple et peu coûteuse.

La sécurité, une fonction à part entière du réseau, le réseau devient le firewall.


Annexe : Références et ressources

[HS1] An Internet Gatekeeper, Hervé Schauer & Christophe Wolfhugel, HSC, Usenix Security, septembre 1992

[HS2] Intranets partitioning , Hervé Schauer, HSC, Infosec juin 1997.

[HS3] The future of the firewall , Hervé Schauer, HSC, Infosec juin 1999.

[SB1] Distributed Firewalls, Steve Bellovin, ATT Research, septembre 1999.

[JF1] Thinking beyond firewalls and intrusion detection systems : the network sentry, John Flowers et Tom Stracener, Hiverworld,SANS Network Security, octobre 1999.

[TB1] VPN Information on the web, Tina Bird, Secnetgroup.

[GL1] Documents Documents on IPsec @hsc.fr , Ghislaine Labouret, HSC, novembre 1998.

Last modified on 6 November 2007 at 16:41:42 CET - webmaster@hsc.fr
Information on this server - © 1989-2013 Hervé Schauer Consultants