Sécurité du réseau : menaces, segmentation et pare-feu
Ce que ce chapitre apporte
- Distinguer menace, vulnérabilité et risque, et savoir les combiner.
- Reconnaître les principales familles d'attaques et leur mode opératoire.
- Expliquer l'intérêt de la segmentation du réseau.
- Décrire ce qu'est une zone démilitarisée et ce qu'on y place.
- Lire une politique de pare-feu et en dérouler l'évaluation.
- Appliquer le principe du moindre privilège et de la défense en profondeur.
- Citer les obligations du cadre légal en cas de violation de données.
Le vocabulaire du risque
Une menace est un événement ou une action susceptible de porter atteinte au système d'information : un attaquant, un logiciel malveillant, une erreur humaine, un incendie.
Une vulnérabilité est une faiblesse exploitable : un mot de passe faible, un logiciel non mis à jour, une configuration hasardeuse.
Un risque est la combinaison d'une menace qui exploite une vulnérabilité, et de l'impact que cela produit sur l'entreprise.
On corrige des vulnérabilités : mettre à jour, durcir une configuration, imposer des mots de passe robustes.
On réduit un impact : sauvegarder, segmenter, chiffrer.
Une politique de sécurité qui ne parle que de menaces reste un discours. Une politique qui liste des vulnérabilités et des impacts se traduit en actions datées.
Les familles d'attaques
Hameçonnage : tromper un utilisateur pour qu'il divulgue des informations sensibles. Faux site, faux support informatique, message urgent.
Logiciel malveillant : programme conçu pour compromettre un système. Virus, ver, cheval de Troie, logiciel espion.
Rançongiciel : logiciel malveillant qui chiffre les données et exige une rançon.
Déni de service : saturer un service pour le rendre indisponible.
Élévation de privilèges : obtenir des droits supérieurs à ceux accordés, souvent après une première intrusion sans privilège.
Conséquence pour l'administrateur : le pare-feu périmétrique ne protège pas de ce qui entre par la messagerie. C'est pourquoi la sécurité se conçoit en profondeur, et pas seulement en périphérie.
Segmenter
Segmenter consiste à découper le réseau en zones distinctes, de sorte que passer d'une zone à l'autre suppose de franchir un point de contrôle où l'on peut filtrer.
Un réseau plat, où toutes les machines se voient, a une propriété désagréable : un poste compromis peut atteindre tout le reste. C'est ce qu'on appelle le déplacement latéral, et c'est ce qui transforme un incident en catastrophe.
Le découpage courant chez une entreprise comme NeoLink :
| Zone | Ce qu'on y trouve | Ce qui doit pouvoir l'atteindre |
|---|---|---|
| Postes de travail | ordinateurs des salariés | rien depuis l'extérieur |
| Serveurs internes | annuaire, fichiers, applications | les postes, sur des ports précis |
| Zone démilitarisée | serveur web, relais de messagerie | Internet, sur des ports précis |
| Administration | consoles, sauvegardes | les seuls postes d'administration |
| Industriel | automates, supervision d'atelier | rien d'autre |
C'est le segment sur lequel commencer, parce que c'est celui dont la compromission arrête la production, et parce qu'il est en général le plus facile à isoler : peu de flux légitimes, tous connus.
La zone démilitarisée
Une zone démilitarisée (DMZ) est un segment intermédiaire qui héberge les services exposés à Internet, isolé à la fois de l'extérieur et du réseau interne.
Le raisonnement tient en une phrase : un serveur exposé à Internet finira par être compromis, et il faut que cela ne donne pas accès au reste.
Internet
|
[ pare-feu ]
|
+------+---------------------+
| |
DMZ Réseau interne
serveur web annuaire, fichiers, postes
relais de messagerie
| |
+------ flux precis ---------+
(base de donnees, port 1433)
Trois règles gouvernent une DMZ, et la troisième est celle qu'on oublie :
- Depuis Internet, on n'atteint que la DMZ, et seulement sur les ports publiés.
- Depuis la DMZ, on n'atteint le réseau interne que sur des flux précis et nommés, jamais en global.
- Un serveur de DMZ n'est pas membre du domaine interne. Sinon, le compromettre revient à obtenir des identifiants du domaine.
De même, autoriser « DMZ vers interne, tout » pour que ça marche revient à supprimer la séparation en gardant le schéma.
Lire une politique de pare-feu
Un pare-feu applique des règles dans l'ordre, et la première qui correspond décide. Ce qui n'est explicitement autorisé est refusé : c'est le refus par défaut, et c'est ce qui rend une politique lisible.
Remarque l'ordre des deux dernières règles : l'autorisation précise vers la base précède le refus global. Si on les inversait, le site ne pourrait plus travailler. Dans une politique de pare-feu, l'ordre est du code.
Deux principes qui gouvernent le reste
Chaque compte, chaque service, chaque flux ne dispose que des droits strictement nécessaires à sa fonction, et pas un de plus.
La sécurité ne repose sur aucune barrière unique. On empile des mesures indépendantes de sorte que la défaillance de l'une ne suffise pas.
Cinq mesures, aucune infaillible. Ce qui protège, c'est qu'elles doivent toutes échouer.
Le cadre légal
Une violation de données personnelles n'est pas qu'un incident technique. Deux textes cadrent l'obligation en France.
Le RGPD encadre le traitement des données personnelles. En cas de violation, il impose une notification à l'autorité de contrôle dans les 72 heures, et l'information des personnes concernées lorsque le risque est élevé.
La loi de programmation militaire impose des obligations renforcées aux opérateurs d'importance vitale et aux opérateurs de services essentiels.
Cela a une conséquence pratique directe : il faut savoir qui notifie et comment avant l'incident. C'est une procédure à écrire, comme la procédure de restauration.
Trois obligations pratiques en découlent, et elles concernent l'administrateur :
- Tenir un registre des traitements de données personnelles.
- Conserver des traces exploitables, sans quoi on ne peut ni établir l'étendue de la violation ni la dater. C'est l'audit du chapitre 3.
- Minimiser les données collectées et leur durée de conservation. Ce qu'on ne détient pas ne peut pas fuir.
Exercices type
Menace, vulnérabilité, risque : classer « mot de passe faible », « rançongiciel », « arrêt de production trois jours ».
Rançongiciel : une menace. Elle existe indépendamment de NeoLink, et on ne la supprime pas.
Mot de passe faible : une vulnérabilité. Elle est chez NeoLink, et elle se corrige.
Arrêt de production trois jours : l'impact, donc la mesure du risque. C'est ce chiffre qui permet d'arbitrer un budget.
L'exercice n'est pas scolaire : c'est sur cette grille qu'on décide où mettre l'argent. On ne finance pas une action contre une menace, on en finance une contre une vulnérabilité, et on la justifie par l'impact évité.
Pourquoi ne pas mettre le serveur web dans le réseau interne, avec une simple redirection de port ?
Parce que le serveur exposé finira par être compromis, et qu'il serait alors dans le réseau interne, avec la visibilité de n'importe quelle machine interne : partages, annuaire, postes.
La redirection de port ne crée aucune séparation. Elle ouvre un chemin vers l'intérieur en donnant l'illusion d'un filtrage.
La DMZ ne fait pas l'hypothèse que le serveur tiendra. Elle fait l'hypothèse inverse, et organise ce qui se passe ensuite. C'est ce changement d'hypothèse qui fait toute la valeur du dispositif.
Dans la politique du chapitre, que se passe-t-il si on place « dmz vers lan, refuser » avant la règle sur le port 1433 ?
Le site web ne peut plus interroger la base de données. Le service tombe.
La première règle qui correspond décide : le refus global attrape le trafic vers 1433 avant que la règle précise ne soit examinée.
Règle générale d'écriture d'une politique : du plus précis au plus général. Les autorisations ciblées d'abord, les refus larges ensuite, et le refus par défaut à la fin.
C'est aussi pour cela qu'une politique de pare-feu se relit comme du code, et qu'on ne réordonne pas ses règles sans les rejouer.
Un administrateur consulte ses courriels avec son compte administrateur du domaine. Quel risque ?
Qu'une pièce jointe piégée s'exécute avec les privilèges de la session, donc ceux d'administrateur du domaine. Le domaine entier est compromis en une exécution.
C'est la violation la plus directe du moindre privilège, et la plus fréquente parce qu'elle est confortable.
La pratique attendue : deux comptes. Un compte ordinaire pour la messagerie, la navigation et le travail courant ; un compte à privilèges réservé aux tâches d'administration, si possible depuis un poste dédié qui ne sort pas sur Internet.
NeoLink découvre une fuite de son fichier clients. Quelles obligations ?
Notifier l'autorité de contrôle dans les 72 heures suivant la prise de connaissance, même si l'analyse n'est pas terminée : le RGPD prévoit une notification en plusieurs temps.
Informer les personnes concernées si le risque pour leurs droits et libertés est élevé.
Documenter la violation, ses effets et les mesures prises, y compris si la notification n'est finalement pas requise.
Ce qui rend tout cela possible, ou impossible : la traçabilité. Sans journaux, l'entreprise ne peut ni dater la fuite, ni en établir l'étendue, ni dire quelles personnes sont concernées. Elle est alors contrainte de notifier au pire cas.
Le pare-feu périmétrique est bien configuré. L'entreprise est-elle protégée ?
Non, et le raisonnement compte plus que la réponse.
Le pare-feu périmétrique filtre ce qui traverse la frontière. Il ne voit rien de ce qui entre par la messagerie, de ce qu'apporte une clé USB, de ce que fait un poste déjà compromis, ni du déplacement latéral une fois à l'intérieur.
C'est le modèle du château fort : dur à l'extérieur, mou à l'intérieur. Il suppose que l'intérieur est sûr, hypothèse fausse dès qu'un poste est infecté ou qu'un prestataire se connecte.
D'où la défense en profondeur : segmentation interne, moindre privilège, mises à jour, journalisation, sauvegarde hors ligne. Aucune de ces mesures n'est suffisante ; leur empilement l'est raisonnablement.
La méthode
- Sépare menace, vulnérabilité et impact avant toute proposition. On agit sur les deux dernières.
- Segmente d'abord ce dont la compromission coûte le plus cher, en général l'industriel et l'administration.
- Écris les flux légitimes avant les règles de pare-feu. Une règle sans flux identifié est une règle qu'on n'osera jamais retirer.
- Ordonne du plus précis au plus général, et termine par le refus par défaut.
- Vérifie qu'aucun serveur de DMZ n'est membre du domaine interne.
- Applique le moindre privilège aux comptes d'administration : deux comptes, poste dédié.
- Empile des mesures indépendantes plutôt que de renforcer une seule barrière.
- Écris la procédure de notification avant l'incident. Les 72 heures ne se découvrent pas le jour venu.
En résumé
- Menace : subie. Vulnérabilité : corrigeable. Risque : menace fois vulnérabilité fois impact.
- L'entrée se fait presque toujours par l'utilisateur, pas par une prouesse technique.
- Segmenter empêche le déplacement latéral : un poste compromis ne voit plus tout.
- Une DMZ part de l'hypothèse que le serveur exposé sera compromis. Elle n'est jamais membre du domaine interne.
- Un pare-feu applique la première règle qui correspond, puis refuse par défaut. Du plus précis au plus général.
- Moindre privilège : rien de plus que le nécessaire. Défense en profondeur : plusieurs mesures indépendantes.
- RGPD : notification sous 72 heures à compter de la prise de connaissance, et traçabilité pour pouvoir établir les faits.
Et ensuite ? Les serveurs se multiplient, et chacun coûte une machine. Le chapitre suivant traite de la manière d'en héberger plusieurs sur un même matériel, et de savoir en permanence s'ils vont bien : virtualisation, conteneurs et supervision.