Comprendre pourquoi les systèmes communiquent

Un réseau n’existe pas pour lui-même. Personne n’achète un commutateur pour le plaisir de regarder clignoter ses diodes, sauf peut-être quelques administrateurs qu’il vaut mieux ne pas déranger. Un réseau sert à relier des systèmes pour qu’ils partagent des ressources, distribuent des services et transportent des données. Ce chapitre d’ouverture pose ce socle, et ajoute dès le départ ce que les manuels réservent souvent au dernier chapitre : tout ce qui relie expose aussi.

→ Lire l’explication complète de la marmotte

Pourquoi relier des machines ?

Une machine isolée ne sait faire que ce qui tient sur son disque et dans sa mémoire. Dès qu’un document doit être partagé, qu’une imprimante doit servir à dix personnes ou qu’une base de données doit être consultée depuis plusieurs postes, il faut que les machines échangent. Communiquer, pour un système, c’est envoyer des octets selon des règles convenues, les protocoles, à un autre système capable de les comprendre et d’y répondre.

Le modèle le plus répandu est le modèle client-serveur. Un client émet une demande ; un serveur l’attend, la traite et répond. Le terme « serveur » désigne d’ailleurs deux choses qu’il vaut mieux distinguer : la machine physique ou virtuelle, et le logiciel qui rend le service. Une même machine héberge souvent plusieurs services, chacun à l’écoute sur un port différent : un serveur web sur le port 443, un service d’administration à distance SSH (Secure Shell) sur le port 22, une base de données sur le port 5432. Le service est l’unité qui compte, pour l’usage comme pour la sécurité.

À côté de ce modèle existe le pair-à-pair (peer-to-peer), où chaque participant est à la fois client et serveur. L’intérêt est l’absence de point central ; l’inconvénient, pour qui défend le réseau, est que chaque poste devient un serveur, donc une porte.

Les services qu’un réseau rend possibles se regroupent en grandes familles : partage de fichiers, bases de données, impression, messagerie, stockage et sauvegarde. Chacun a ses protocoles et ses habitudes, détaillés dans Services applicatifs et partage. Un réseau d’entreprise ordinaire en héberge des dizaines, dont une bonne partie n’a jamais été inventoriée.

Des machines isolées aux services distribués

L’histoire de l’informatique d’entreprise oscille entre centralisation et distribution. L’informatique centralisée concentrait le calcul sur un gros système, le mainframe, que des terminaux passifs interrogeaient. L’informatique distribuée a réparti le travail entre postes autonomes et serveurs spécialisés. La virtualisation a ensuite découplé les services du matériel : une machine physique fait tourner des dizaines de machines virtuelles, puis des conteneurs, ces environnements isolés qui partagent le noyau de l’hôte. Le cloud pousse la logique au bout : le service tourne chez un fournisseur, sur une infrastructure que le client ne voit jamais, et qu’il paie à la minute. Le mainframe est revenu, il a simplement changé de propriétaire.

Cette évolution produit trois catégories de services qu’il faut savoir distinguer. Un service local tourne sur la machine de l’utilisateur. Un service distant tourne sur un serveur que l’organisation administre, dans sa salle ou dans un centre de données loué. Un service managé est exploité par un tiers : messagerie hébergée, base de données fournie par un cloud public, stockage d’objets. La différence n’est pas cosmétique. Pour un service managé, l’organisation ne contrôle ni le système d’exploitation ni les correctifs, mais reste responsable de la configuration, des comptes et des données ; c’est le modèle de responsabilité partagée, décrit dans Réseaux cloud et VPC.

Le parc lui-même s’est diversifié. Postes de travail et serveurs côtoient des smartphones, des imprimantes, des caméras, des capteurs, des automates industriels et des conteneurs éphémères qui naissent et meurent en quelques secondes. Un réseau moderne est donc hétérogène : il mêle des systèmes d’âges, de constructeurs et de niveaux de maturité très différents, qui doivent pourtant se comprendre. C’est le rôle des protocoles normalisés, présentés dans Couches, normes et vocabulaire.

Reste à relier ces services aux gestes de l’utilisateur. Ouvrir l’intranet de l’entreprise semble être une action unique ; c’est en réalité une chaîne de flux. Le poste demande au DNS (Domain Name System) l’adresse du nom saisi. Il envoie ensuite sa requête vers la passerelle par défaut, le routeur qui fait sortir le trafic du réseau local. La requête atteint le serveur web, qui interroge à son tour une base de données, laquelle consulte peut-être un annuaire pour vérifier les droits. Un clic, cinq flux au moins. La page Suivre un flux de bout en bout déroule ce parcours en détail.

Familles de réseaux et périmètres

On classe traditionnellement les réseaux par étendue géographique. Le PAN (Personal Area Network) couvre l’espace autour d’une personne : une montre connectée en Bluetooth, un casque, un téléphone. Le LAN (Local Area Network) couvre un bâtiment ou un étage, en Ethernet filaire ou en Wi-Fi. Le MAN (Metropolitan Area Network) relie des sites à l’échelle d’une agglomération, souvent par fibre. Le WAN (Wide Area Network) relie des sites distants, entre villes ou pays, en s’appuyant sur les infrastructures d’opérateurs. Internet, enfin, n’est pas un réseau mais un réseau de réseaux : des dizaines de milliers de réseaux autonomes qui s’échangent des routes.

Cette classification géographique a vieilli. Deux familles s’y ajoutent sans entrer dans les cases. Le réseau cloud est un réseau virtuel défini par logiciel chez un fournisseur, dont l’étendue physique n’a aucun sens pour son client. Le réseau industriel relie automates, capteurs et supervision dans une usine ou une station d’épuration ; il privilégie la continuité et le temps réel, avec des protocoles parfois conçus à une époque où la menace se résumait à une coupure de courant. Ces cas sont développés dans Réseaux personnels et IoT et Réseaux spécialisés et sobriété.

Plus utile que la taille est la notion de frontière. Une frontière technique sépare deux domaines où le trafic change de traitement : un routeur entre deux sous-réseaux, un pare-feu entre deux zones, une passerelle entre le réseau industriel et le réseau bureautique. Une frontière administrative sépare deux responsabilités : le réseau de l’entreprise s’arrête à la box de l’opérateur, le réseau du fournisseur cloud commence au point de connexion. Les incidents naissent volontiers là où les deux ne coïncident pas, chacun pensant que l’autre surveille.

Pourquoi des technologies anciennes restent-elles visibles ? Parce qu’un réseau ne se remplace jamais d’un bloc. Un automate installé il y a vingt ans fonctionne, coûte cher à remplacer et parle toujours son protocole d’origine. Une imprimante n’accepte que de vieilles versions de partage de fichiers. Ces systèmes hérités ne sont pas des curiosités de musée : ils sont en production, et souvent sur le même réseau que le reste. Les reconnaître fait partie du métier. La page Topologies, composants et interconnexion montre comment ces morceaux s’assemblent.

Lire le réseau en sécurité dès le départ

Chaque flux autorisé est un chemin d’accès. Si le poste comptable peut joindre le serveur de fichiers, alors quiconque prend le contrôle du poste comptable peut aussi le joindre. Cette évidence a une conséquence lourde : la surface d’attaque d’un système est l’ensemble des services joignables, par qui et depuis où. Un service qui écoute sur toutes les interfaces, sans filtrage, est joignable par toutes les machines du réseau, y compris celles qu’on n’aurait pas invitées.

Quatre leviers structurent la réponse, et ils ne valent que combinés. L’exposition consiste à décider ce qui est joignable : un service qui n’écoute pas, ou qui n’est pas routé, ne peut pas être attaqué à distance. L’authentification vérifie qui parle, une fois la connexion établie. La segmentation découpe le réseau en zones pour que la compromission d’une machine ne donne pas accès à tout ; elle est détaillée dans Filtrage, segmentation et NAC. La journalisation enregistre qui a joint quoi, et permet de reconstituer après coup ce qu’on n’a pas su empêcher.

La disponibilité fait partie de la sécurité, au même titre que la confidentialité et l’intégrité. Un serveur de messagerie saturé, un DNS qui ne répond plus, une sauvegarde impossible parce que le lien est engorgé : rien n’a été volé, et pourtant l’organisation est à l’arrêt. Le déni de service n’a pas besoin de voler une donnée pour coûter cher. La supervision, présentée dans Gestion du réseau et supervision, et la continuité, traitée dans Continuité, sauvegardes et PRA, relèvent donc pleinement de la sécurité réseau.

Exemples et ateliers

Premier exercice, le schéma de base : dessiner un poste client, le serveur DNS, la passerelle, un serveur web et sa base de données, puis tracer chaque flux nécessaire à l’ouverture d’une page. Le résultat comporte toujours plus de flèches qu’attendu, et c’est le but. Pour chaque flèche, noter qui initie la connexion.

Deuxième exercice, le classement des flux. Prendre dix flux observés sur un réseau réel ou de laboratoire et les ranger en cinq catégories : usage utilisateur (consultation web, messagerie), administration (SSH, bureau à distance), sauvegarde (copie nocturne vers un stockage), supervision (collecte de métriques, remontée de journaux) et exposition (service publié vers Internet). Un flux d’administration ouvert depuis tout le réseau bureautique, ou un flux de sauvegarde qui traverse toutes les zones avec un compte omnipotent, apparaît vite comme la vraie priorité.

Troisième exercice, la fiche service. Pour chaque service, une ligne suffit : service, port, protocole, risque principal. Par exemple :

Service	Port	Protocole	Risque principal
Web public	443	HTTPS	vulnérabilité applicative exposée à Internet
Partage de fichiers	445	SMB	propagation latérale, rançongiciel
Administration distante	22	SSH	force brute, clé volée
Résolution de noms	53	DNS	empoisonnement, exfiltration par tunnel
Impression	9100	impression brute	équipement oublié, jamais mis à jour

Ce tableau, aussi modeste soit-il, vaut mieux que la plupart des inventaires officiels, qui ont le défaut de n’exister qu’en théorie.

Pièges classiques

Le premier piège est de croire qu’un réseau interne est fiable par nature. Le pare-feu périmétrique protège contre l’extérieur, mais un poste compromis par une pièce jointe se trouve déjà à l’intérieur, avec la confiance accordée à tous les autres. Le modèle de défense qui en découle, ne jamais présumer de la confiance sur la seule base de l’emplacement réseau, est développé dans Principes de sécurité et identité.

Le deuxième piège est de confondre accès réseau et droit applicatif. Qu’un flux soit autorisé par le pare-feu signifie qu’une connexion peut s’établir, pas que l’utilisateur au bout a le droit de lire les données. À l’inverse, une application protégée par mot de passe reste vulnérable si sa faille se déclenche avant l’authentification. Les deux contrôles sont nécessaires, aucun ne remplace l’autre.

Le troisième piège est d’oublier les flux techniques. Les schémas montrent volontiers les usagers et leurs applications ; ils oublient la sauvegarde qui lit tous les serveurs, la supervision qui interroge tous les équipements, l’imprimante qui renvoie les numérisations vers un partage, le stockage réseau monté par tout le monde. Ces flux sont larges, privilégiés et rarement surveillés : c’est exactement le profil que recherche un intrus.

À ne pas confondre

Internet et le Web ne sont pas synonymes. Internet est l’infrastructure qui interconnecte les réseaux ; le Web n’est qu’un service parmi d’autres qui l’utilise, au moyen du protocole HTTP (HyperText Transfer Protocol). La messagerie ou la voix sur IP circulent sur Internet sans être le Web.

Machine joignable et utilisateur autorisé sont deux questions distinctes. La première relève du réseau : un paquet peut-il arriver ? La seconde relève de l’identité et des droits : celui qui parle a-t-il le droit de faire ce qu’il demande ? Un audit qui ne répond qu’à l’une des deux laisse l’autre à l’attaquant.

Disponibilité et absence de vulnérabilité ne se confondent pas davantage. Un service qui répond parfaitement depuis cinq ans peut être truffé de failles ; il est simplement disponible pour tout le monde, y compris pour ceux qui l’exploitent. Qu’un système fonctionne prouve qu’il fonctionne, et rien d’autre.

🐝 Ce qui arrive si on s’en passe

Sans cette lecture des flux, l’inventaire réel des services exposés n’existe que dans les têtes, et encore. Les flux de sauvegarde, de supervision ou d’impression, jamais dessinés, traversent les zones avec des droits larges et sans journal : ce sont précisément ceux qu’un intrus emprunte pour circuler sans bruit. Quand un incident survient, impossible de dire quelles machines pouvaient joindre le service compromis, donc impossible de borner la propagation ; faute de carte, le confinement consiste à débrancher un peu au hasard et à espérer.

🦫 Explication de la marmotte 🍫

Un réseau relie des machines pour qu’elles échangent des données. Le plus souvent, une machine appelée client demande quelque chose, et une autre, le serveur, fournit un service en réponse : fichiers, base de données, impression, messagerie, stockage ou sauvegarde. Deux machines peuvent aussi échanger d’égal à égal. Les réseaux se classent par taille : réseau personnel autour d’une personne, réseau local dans un bâtiment, réseau à l’échelle d’une ville, réseau étendu entre sites éloignés, et enfin Internet, qui relie les réseaux entre eux. Ces réseaux mêlent souvent des technologies d’âges différents, parce qu’on ne remplace jamais tout d’un coup. Un service peut tourner sur une machine locale, sur un serveur de l’entreprise ou chez un fournisseur qui le gère, ce qu’on appelle le cloud. Chaque action d’un utilisateur, comme ouvrir un site, déclenche plusieurs flux : recherche de l’adresse du site, passage par une passerelle, dialogue avec un serveur, qui interroge lui-même une base de données. Du point de vue de la sécurité, chaque flux est un chemin d’accès, et chaque service joignable est une porte possible. Pouvoir joindre une machine ne donne pas le droit d’utiliser son service : il faut encore s’authentifier. Il faut donc limiter ce qui est exposé, séparer les zones, enregistrer les accès et surveiller la disponibilité, car un service en panne est aussi un problème de sécurité. Un réseau interne n’est jamais digne de confiance par nature.

Pages voisines

La citent

Comprendre pourquoi les systèmes communiquent

Elle cite

Comprendre pourquoi les systèmes communiquent

Comprendre pourquoi les systèmes communiquent

Pourquoi relier des machines ?

Des machines isolées aux services distribués

Familles de réseaux et périmètres

Lire le réseau en sécurité dès le départ

Exemples et ateliers

Pièges classiques

À ne pas confondre

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines