Architecture réseau : comment sécuriser un SI avec la segmentation et le filtrage ?

I. Présentation

Nous allons aborder le sujet de la sécurisation d'un système d'information grâce au cloisonnement de son architecture réseau. Nous définirons notamment les termes de segmentation et de filtrage et rappellerons la notion de surface d'attaque.

La sécurisation d’un système d’information (SI) repose en grande partie sur le cloisonnement de son architecture réseau, une approche combinant segmentation et filtrage. L’objectif : réduire la surface d’attaque en limitant les mouvements latéraux d’un attaquant. 

Cet article explique pourquoi et comment mettre en place ces bonnes pratiques, depuis la conception d’un réseau segmenté jusqu’à l’application de règles de filtrage efficaces. 

Mais, pour mieux comprendre les apports du cloisonnement réseau en termes de sécurité, faisons un bref rappel sur la notion de surface d'attaque.

II. La problématique de la surface d'attaque au sein d'un SI

A. Qu'est-ce que la surface d'attaque ?

La surface d'attaque d'un système (au sens large) est constituée de l'ensemble des points de contacts de celui-ci avec l'extérieur. Par exemple, la surface d'attaque d'une maison par rapport à un voleur est essentiellement composée des portes, des fenêtres, de l'entrée du garage, éventuellement de la cheminée, et dans les cas les plus extrêmes, des cloisons fines pouvant être percées.

Pour un système d'information, cette surface d'attaque est constituée de très nombreux éléments et est à mettre en lumière en fonction de ce que l'on défini comme étant l'extérieur : celle d'un poste utilisateur est constituée des ports et services qu'il expose sur le réseau, mais aussi des échanges provoqués par l'utilisateur (mail, navigation web) ou par le système d'exploitation (mises à jour). 

Pour aller plus loin sur cette notion de surface d'attaque, je vous recommande notre article dédié à ce sujet : 

• IT-Connect - Analyse et réduction de la surface d’attaque

B. Aborder la sécurité avec le point de vue de l’attaquant

Du point de vue d'un attaquant, la surface d'attaque représente l'ensemble des éléments sur lequel il pourrait avoir une opportunité d'attaque pour atteindre sa cible. Si l'attaquant passe par Internet, il pourra tenter d’attaquer une entreprise via la surface d'attaque classique : le site web vitrine, le service e-mail exposé sur Internet, les composants Cloud utilisés (Microsoft 365) mais aussi les interactions qu'il peut avoir avec les utilisateurs (e-mail, appel téléphonique, navigation web).

Si l'on se met maintenant dans la situation d'un attaquant qui a réussi à pénétrer à l'intérieur d'un système d'information, la situation est généralement bien plus complexe. La surface d'attaque peut grandir d'un facteur 100, 500 ou 1000 par rapport à une position externe (Internet). Car le nombre de réseaux, de systèmes et de services présents et accessibles est bien plus important. Mécaniquement, les chances de compromettre un système ou un compte sont donc plus grandes.

Pour rappel, l'intrusion d'un attaquant au sein d'un SI passe rarement par une intrusion physique. Bien souvent, il s'agit d'une intrusion distante, qui passe par un poste utilisateur compromis. Par exemple, via un e-mail ou une clé USB et lui offre un moyen persistant d'accès et de rebond vers l'intérieur du système d'information (porte dérobée, serveur de communication et de contrôle, etc.).

Ce qu'il faut retenir, c'est que plus la surface d'attaque est grande, plus l'attaquant à d'opportunités d'attaque, et donc de compromission. L'idée est alors de réduire autant que possible la surface d'attaque d'un système ou d'un réseau pour diminuer ses chances de compromissions. Cela est possible par le cloisonnement.

III. Segmentation et filtrage, quelles différences ?

A. Qu'est-ce qu'un réseau à plat ?

Un réseau dit "à plat" est une notion d'architecture qui défini un réseau dont l'ensemble des composants se situent dans le même réseau, sous-réseau, ou VLAN. On parle par exemple : 

• Des postes des utilisateurs ;
• Des postes de l'équipe informatique ;
• Des postes de l'équipe de direction ;
• Des serveurs métier ;
• Des serveurs "techniques" (e-mail, Active Directory, mise à jour, sauvegarde) ;
• Etc.

Dans le cas où un attaquant parvient à s'introduire au sein de ce réseau, il accède à la totalité des équipements, systèmes et leurs services sans restrictions ou contrôle. Nous pouvons dessiner un réseau de ce type comme suivant :

Techniquement parlant, j’ai ici représenté mon réseau à plat avec des systèmes différents, tous situés dans le même réseau physique et logique (192.168.1.0/24). Parmi les utilisateurs de ce système d’information, l’attaquant a réussi à obtenir un accès sur la machine Utilisateur01. L’attaquant dispose alors d’un accès direct, au niveau réseau, à l’ensemble des machines voisines. La surface d'attaque interne est donc grande.

La définition d'un réseau à plat peut aussi varier et s'appliquer dans le cas où une architecture réseau serait segmentée, mais non filtrée (nous allons creuser ces deux notions juste après).

Nous pouvons faire une analogie très parlante entre l'architecture réseau et la pandémie de COVID-19 à laquelle nous avons tous été confrontés. Si l'on parle d'un système compromis comme d'un patient infecté, on comprend bien que si 100 personnes (dont l'infecté) se trouvent au sein de la même grande pièce d'une maison, rien n'empêche une propagation de l'infection.

B. Segmentation : dessiner les pièces d'une maison

La segmentation réseau consiste, dans le domaine de l'architecture réseau, à créer différentes zones qui sont souvent matérialisées par des VLANs ou des sous-réseaux. Ces zones peuvent être créées et gérées en fonction de différentes caractéristiques :

• Des zones géographiques : siège, ville, région, pays
• Des zones par population : direction, utilisateurs, stagiaires, commerciaux, RH, informatique
• Des zones techniques : systèmes utilisateurs, serveurs, équipements Wi-Fi
• Des zones par criticités : serveurs métiers, serveurs RH, serveurs techniques (AD, mise à jour, sauvegarde)
• Etc.

Dans la réalité, les choix d'architecture et de conception réseau prennent en compte plusieurs de ces caractéristiques.

Il faut comprendre que la segmentation consiste à construire des murs au sein de notre maison avec le patient infecté. Ainsi, on retrouvera 25 personnes dans une pièce, 20 dans une autre, 30 dans la troisième et 25 dans la dernière. En cas d'infection d'un patient, il contaminera rapidement entre 20 et 30 personnes en fonction de la pièce dans laquelle il se trouve, mais il n'en contaminera plus 100. La surface d'attaque a été réduite !

Voici comment peut se matérialiser une segmentation sur notre système d’information de démonstration : 

Nous avons ici deux zones utilisateurs (les utilisateurs non privilégiés, et l’équipe de direction), une zone pour les serveurs et une dernière pour l’équipe informatique. Chaque zone est dans un sous-réseau distinct (le plus souvent gérés via des VLAN). Au milieu, un routeur permet de router les paquets d’un sous-réseau à un autre.

• Mais si je construis plusieurs zones et que tous les paquets de chaque zone sont bien acheminés vers les autres zones via mon routeur, quel intérêt ? 

Vous avez vu juste. Ici, la segmentation en place nous permet de délimiter des zones, mais nous n’avons encore rien fait pour empêcher notre attaquant (poste Utilisateur01) de tenter de compromettre nos serveurs ou un poste de la direction ! C’est ici que le filtrage, rendu possible par la segmentation, entre en jeu.

C. Filtrage : ajouter les portes et les fenêtres

Le filtrage des paquets réseau consiste à analyser plusieurs caractéristiques de chaque paquet et d’autoriser ou de bloquer leur passage en fonction des règles préétablies. Il s’agit donc de gérer, contrôler et autoriser/interdire les communications entre une zone et une autre. Les critères utilisés pour autoriser ou bloquer un paquet sont souvent :

• La source (adresse ou range IP) ;
• La destination (adresse ou range IP) ;
• Le protocole de transport (TCP/UDP/ICMP) ;
• Le protocole applicatif et ports (HTTP, HTTPS, SSH, RDP, etc.) ;
• Les ports (TCP/22, TCP/80, UDP/53, etc.).

C’est la segmentation en place qui nous permet déjà de définir et d'identifier la source et la destination des paquets. Elle nous permet donc de créer des ouvertures (de flux) en fonction de nos besoins. Mais, ces ouvertures doivent respecter le principe suivant : uniquement ce qui est strictement nécessaire, rien de plus !

L'essentiel étant que par défaut, la règle soit : non, ce flux n'est pas autorisé, communication interdite. 

Cependant, un réseau cloisonné dans laquelle personne ne communique avec personne est aussi utile et fonctionnel qu'une maison avec des pièces sans portes ni fenêtres. Il est mécaniquement nécessaire d'autoriser des communications entre les différentes zones pour pouvoir travailler, échanger des e-mails, des fichiers, s'authentifier, etc. Voici quelques exemples :

• Est-il nécessaire que mes utilisateurs non privilégiés aient accès au port SSH ou RDP de mes serveurs ? Non
• Est-il nécessaire que mes utilisateurs aient accès au port LDAP (389/636) de mon Active Directory ? Oui
• Est-il nécessaire que mes utilisateurs aient accès au port SMB (partage de fichier, TCP/445) de mes serveurs ? Oui
• Est-il nécessaire que mes utilisateurs aient accès à quelque port que ce soit des machines de l’équipe informatique ou direction ? Non
• Etc.

Bref, vous voyez l’idée. Ici, le principe de la liste blanche est à appliquer. Il s’agit d’une méthode de gestion qui interdit tout, sauf ce qui a été explicitement autorisé. Cela permet d’éviter les oublis, les erreurs, et de pouvoir justifier toutes les ouvertures de flux réalisées.

En fonction des critères choisis pour définir nos zones, ces règles de filtrages peuvent grandement changer, mais si l'on reprend notre schéma type, voici quelques principes parlants :

• Les administrateurs (SI d'administration) peuvent se connecter sur n'importe quel service de n'importe quel système, sauf Internet ;
• Aucune zone ne peut communiquer avec les postes des administrateurs ;
• Les utilisateurs peuvent aller sur Internet, et communiquer avec certains ports très limités des serveurs ;
• La DMZ peut communiquer avec Internet, mais aucun flux vers les zones internes n'est autorisé ;
• Etc.

Ce filtrage est réalisé à l'aide d’un pare-feu réseau situé physiquement entre les différentes zones à contrôler : 

Dans cet exemple, le routeur a été remplacé par un pare-feu interne. Avec un politique de filtrage efficace en place, les flux de la zone Utilisateurs vers la zone Informatique sont interdits. L'attaquant ne peut donc plus tenter de compromettre le poste Admin01.

Voici un exemple de politique de filtrage qui pourrait correspondre à notre SI de démonstration :

Source	Destination	Service (port destination)	Action	Description
Utilisateurs, Direction	Serveurs	SMB (TCP/445)	Autoriser	Accès aux partages de fichiers
Utilisateurs, Direction	Serveurs	Web (TCP/80, TCP/443)	Autoriser	Accès aux applications web
Utilisateurs, Direction	Serveurs	LDAP (TCP/389, TCP/636), Kerberos (88/TCP)	Autoriser	Accès aux services d’authentification centralisée
Utilisateurs, Direction	Internet	Web (TCP/80, TCP/443)	Autoriser	Accès des utilisateurs à Internet
Administration	ANY	Utilisateurs, Direction, Serveurs	Autoriser	Accès à tous les services de tous les réseaux
Tous	ANY	ANY	Bloquer	Bloquer tout trafic qui n’a pas été explicitement autorisé

Ce tableau ne représente pas les besoins réels de chaque catégorie, il schématise les principales idées. Mais l’idée est la suivante : tout ce qui n’a pas été explicitement autorisé est bloqué. Voici quelques exemples :

• Les administrateurs ont-ils accès à Internet ? Non, aucune règle explicite ne l’autorise. On tombe donc dans notre dernière règle qui interdit tout.
• Les utilisateurs ont-ils accès aux partages de fichiers des serveurs ? Oui (ligne 1)
• La direction a-t-elle accès aux postes de l’équipe informatique ? Non, même chose, aucune règle ne l’autorise, cela est donc bloqué.
• Etc.

L’idée du filtrage par liste blanche est qu’il est impossible de tomber dans un cas de figure qui n’a pas été prévu et qui serait trop permissif. Tout ce qui est autorisé l’est par une règle dédiée et explicite, le reste est refusé. À l’inverse, si nous étions dans une gestion en liste noire, nous aurions dû configurer tous les cas que nous souhaiterions bloquer. Au vu du nombre de ports TCP et UDP (65535 chacun), ainsi que du nombre de systèmes dans un SI, cela serait impossible et bien trop lourd à gérer.

Gardez toutefois à l’esprit que la réalité est bien plus complexe que ce petit tableau démonstratif. Il ne sert qu’à illustrer une base de ce qu’est une politique de filtrage par liste blanche.

L'ensemble de ces règles doivent être réunies au sein d'un document écrit qui se nomme la politique de filtrage. Cette politique de filtrage est ensuite appliquée sur nos pare-feu réseau. 

On ne parle par ici des pare-feu locaux de chaque machine, ce qui serait impossible à gérer de façon efficace sur un SI réel. Nous parlons bien d'équipements dédiés, généralement performants et couteux, qui voient passer et bloquent ou autorisent des milliers de paquets réseau par seconde. Sur un système d’information réel, la politique de filtre sera appliquée via des dizaines de pare-feu situés à des endroits différents et parfois avec des technologies différentes. Ceux-ci cumuleront plusieurs milliers de directives de filtrage, parfois contradictoires ou trop permissives, c'est un métier !

Ainsi, si un attaquant parvient à compromettre un poste utilisateur, ma politique de filtrage lui interdira l'accès direct aux postes d'administration. La surface d'attaque des postes d'administration est donc mécaniquement réduite. De même pour les serveurs, dont les services ne sont plus tous joignables par les utilisateurs (nous avons simplement autorisé les services web et de partage de fichier, et interdits les services d'administration).

L’intérêt majeur de l’application d’une segmentation et d’un filtrage stricts est que les machines de mon SI d'administration peuvent être en retard au niveau des mises à jour, tant que l'attaquant n'y accède pas, il ne pourra pas exploiter les vulnérabilités présentes ! (J'image ici le principe, je ne vous conseille par d'arrêter de mettre à jour vos systèmes même si votre cloisonnement est, d'après vous, efficace). Même chose pour les serveurs, l'attaquant pourrait trouver le mot de passe SSH root d'un de mes serveurs, s'il n'y a pas accès au niveau réseau, il ne pourra rien en faire (du moins, ce sera plus compliqué, et plus long).

Attention, dans la réalité, attaquants et pentesters utilisent des techniques permettant l'utilisation de machines et services de rebond. L'idée en cybersécurité est toujours de ralentir l'attaquant, d'augmenter ses chances de détection, de le décourager ou de faire en sorte que le succès de son attaque nécessite un coût trop élevé par rapport aux gains obtenus. Aucune protection n'est efficace à 100% contre les attaques.

Nous avons vu ce que sont la segmentation et le filtrage réseau. Ces deux principes sont généralement regroupés sous le terme "cloisonnement" dans les discussions courantes. Cependant, savoir que le cloisonnement passe d'abord par la segmentation et ensuite par le filtrage permet de mieux comprendre son application et son intérêt. La difficulté étant à présent de mettre en place ce cloisonnement.

IV. Passer d'un réseau "à plat" vers réseau cloisonné : les principales étapes

La conception d’une architecture réseau qui suit les bonnes pratiques de cloisonnement est généralement abordable. La complexité arrive lorsque l’on se trouve sur un SI existant, qui ne peut s’arrêter pour de gros chantiers, mais que nous devons quand même sécuriser. Pour sécuriser et cloisonner un réseau "à plat", les principales étapes à suivre sont généralement les suivantes :

Phase 1 : Segmenter le réseau en plusieurs zones

La première étape est bien sûr l’identification du besoin et la formation des équipes aux bonnes pratiques d’architecture réseau (segmentation, filtrage) et surtout à la maitrise des technologies en place. L’identification du besoin consistera à comprendre les besoins de l'organisation et identifier les différentes catégories de ressources et d'utilisateurs.

N’oubliez pas la zone d’administration ! Cela pourrait faire l’objet d’un article dédié, mais je vous oriente vers cette ressource de l’ANSSI : Recommandations relatives à l’administration sécurisée des systèmes d’information.

La seconde étape est la planification de la segmentation, d’un point de vue organisationnel et technique. Cela consiste à commencer à définir les frontières entre les différentes zones en fonction des besoins de sécurité et des exigences opérationnelles  (DMZ, zone administrative, zone utilisateurs, zone serveurs). Cette segmentation sera ensuite implémentée à l’aide d’équipements réseau (routeurs, pare-feu) pour créer les segments de réseau distincts. Il s’agit généralement d’une première étape complexe, car cela nécessite de changer de position et d’adresse IP des serveurs/équipements qui sont utilisés quotidiennement et parfois de revoir une large partie de l’organisation du SI.

Après cette première phase, la segmentation en place devra permettre d’avoir une vue plus organisée et structurée de l’architecture du système d’information. 

Phase 2 : Appliquer un filtrage réseau entre ces zones

Cette phase commence par la rédaction de la politique de filtrage sur papier. Celle-ci doit être basée sur les besoins de sécurité et métier de chaque zone, qui peuvent parfois être contradictoires. C’est à ce stade que nous décidons, par exemple, de bloquer tout le trafic entrant dans la zone d’administration, ainsi que les flux sortant de cette zone vers Internet, etc.

La deuxième étape consiste à mettre en place "virtuellement" notre politique de filtrage. La plupart des pare-feu réseau possèdent une fonctionnalité permettant de journaliser les paquets qui auraient été bloqués par une règle de filtrage, sans pour autant appliquer ce blocage (mode journalisation). Étant donné que nous souhaitons bloquer ce qui n’est pas nécessaire et utile, chaque occurrence d'un tel événement (blocage journalisé) doit être analysé pour déterminer s’il s’agit d’une exception, d’un flux réseau que nous souhaitions effectivement bloquer, ou d’un oubli dans notre politique de filtrage.

Cette phase d’analyse permet de limiter les erreurs et les interruptions involontaires du SI. Elle peut durer assez longtemps en fonction de la qualité du travail fait lors de sa conception et de la taille et complexité du SI. 

Lorsque ce travail de vérification et renforcement de notre politique de filtrage aura été fait, celle-ci pourra être appliquée de manière effective. La politique de filtrage virtuelle deviendra alors de véritables ACL (listes de contrôles d’accès) bloquants ou autorisant le trafic réseau entre nos zones.

Phase 3 : Maintien en conditions opérationnelles

Une fois en place, plusieurs actions régulières de maintenance et d’entretien devront être réalisées pour s’assurer que tout ce travail perdure dans le temps et reste utile  :

• Surveillance et gestion des règles de filtrage : mettre en place des outils de surveillance pour détecter et signaler toute tentative de violation des règles de filtrage.  Journaliser les modifications et accès réalisés sur les règles de filtrage.
• Réviser et mettre à jour régulièrement les règles de filtrage pour répondre aux changements dans les besoins de sécurité et métier.
• Tests et validation du filtrage : effectuer des tests d’intrusion et des audits de sécurité pour vérifier que les règles de filtrage sont efficaces et correctement implémentées.
• Documenter les règles de filtrage et les procédures de gestion pour assurer une maintenance et une mise à jour continues.

Il existe une différence majeure entre la théorie que nous voyons ici et la réalité. Dans la réalité, avoir un SI existant, fonctionnel et ne tolérant pas les interruptions complexifie grandement les opérations. Passer d'un réseau à plat (d'autant plus quand aucune segmentation n'est en place) à un réseau cloisonné peut être un chantier étalé sur plusieurs mois, voire années.

Si vous disposez déjà d’une segmentation et de pare-feu réseau déjà positionnés, mais que le filtrage est inefficient à cause d’un grand nombre de règles ou d’une mauvaise organisation, je vous oriente vers ce guide de l’ANSSI :  Recommandations et méthodologie pour le nettoyage d’une politique de filtrage réseau d’un pare-feu.

Dans les grandes lignes, ce guide détaille les bonnes pratiques de gestion des règles de pare-feu, mais aussi une méthodologie de nettoyage basée sur la documentation et la journalisation. Cette approche structurée est particulièrement pertinente en entreprise, car elle aborde également la nomenclature des règles, l’organisation par étape de nettoyage des règles ainsi que leur documentation.

V. Cartographie : évaluer le cloisonnement d'un système d'information

La conception et la mise en place technique d’une politique de filtrage dans un contexte réel est difficile, autant que sa maintenance quotidienne et son évolution dans le temps. J’ai croisé de nombreux cas dans lesquels la politique de filtrage (document écrit) était parfaite, mais très mal appliquée dans la réalité. Plusieurs facteurs peuvent en être la source :

• Négligences opérationnelles ;
• Politique de filtrage réparties sur plusieurs dizaines ou centaines de pare-feu ;
• Différences technologiques entre les équipements, manques de maitrise de l’équipe informatique ;
• Manque de temps ou de ressources humaines ;
• Persistance de règles temporaires trop permissives, oubliées et jamais supprimées ;
• Etc.

Pour qu’une politique de filtrage soit considérée comme sécurisée et conforme aux exigences, une phase de vérification technique est indispensable. Celle-ci consiste à se positionner au sein d’un réseau source, par exemple, celui des utilisateurs non privilégiés, et d’utiliser un outil de scan réseau vers les autres réseaux du SI. L’idée d’une cartographie réalisée à l’aide d’outils comme nmap est justement de dresser une liste exhaustive et complète des systèmes et services accessibles d’un réseau vers un autre. Constatant par la même occasion si ce qui est accessible est bien conforme à la politique de filtrage.

À titre d’exemple, voici la vue d’une sortie de l’outil de cartographie réseau nmap, qui détecte les systèmes accessibles et leurs services :

En réalisant ces cartographies à partir de chacun des réseaux, nous pourront constater que la politique de filtrage est bien en place ou incomplète. Ainsi, si une politique de filtrage a été mal conçue ou mal appliquée, cela se verra très facilement et rapidement. On pourra, par exemple, constater que les utilisateurs accèdent aux systèmes de l’équipe de direction ou aux services d’administration des serveurs. L’intérêt est donc de constater techniquement et de façon opérationnelle des non-conformités à la politique de filtrage ou aux bonnes pratiques de sécurité.

Attention, les outils de cartographies contiennent de nombreuses options, des subtilités et peuvent avoir des effets de bords non négligeables. Leur maitrise pour la réalisation de cartographies réseau est abordable pour tout informaticien, administrateur système, réseau, RSSI ou pentester, à condition d’être un minimum formé à leur usage. Pour maitriser l’outil nmap, la référence absolue des outils de cartographie réseau, je vous oriente vers mon livre/ebook des éditions IT-Connect à son sujet :

Il vous permettra au travers une approche pédagogique, concrète et illustrée de maitriser l’outil nmap pour la réalisation de cartographies complètes et la recherche de vulnérabilité au sein d’un SI. Il est le fruit de mon expérience de près de 10 ans d’utilisation de cet outil (et bien d’autres) en tant qu’auditeur cybersécurité et spécialiste en tests d’intrusion.

VI. Conclusion

La sécurisation d'un système d'information par le cloisonnement de son architecture réseau est une démarche qui vise à réduire la surface d'attaque et limiter les opportunités pour les attaquants. La segmentation et le filtrage sont des composants de cette stratégie, permettant de diviser le réseau en zones distinctes et de contrôler les communications entre ces zones de manière stricte et ciblée.

La mise en place d'un réseau cloisonné nécessite une planification et une approche méthodique, notamment en passant par les phases de segmentation et de filtrage. 

Cependant, il faut être conscient que la conception et la mise en œuvre d'une politique de filtrage efficace ne sont que le début. La maintenance continue, la surveillance et la révision régulière des règles de filtrage sont nécessaires pour garantir que le système d'information reste sécurisé.

Enfin, l'utilisation d'outils de cartographie réseau permet de vérifier techniquement que la politique de filtrage est bien appliquée et de détecter les non-conformités. Ces outils sont indispensables pour une évaluation précise et une amélioration continue de la sécurité du système d'information. Sans une telle démarche régulière, il est périlleux d’affirmer que le cloisonnement est efficace.

N’hésitez pas à partager votre avis et vos expériences sur ce sujet dans les commentaires !