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 Ardexia :
| 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 |
| Plateau technique | automates d'analyse, postes de pilotage | rien d'autre |
C'est le segment sur lequel commencer, pour deux raisons. Sa compromission arrête l'activité, puisque plus aucun résultat ne sort. Et il est le plus facile à isoler : les flux légitimes sont peu nombreux et tous connus, chaque automate ne parlant qu'au serveur qui collecte ses résultats.
C'est aussi le cas où la segmentation remplace une mise à jour qu'on ne peut pas faire. Quand une vulnérabilité ne peut pas être corrigée, il reste à réduire ce qui peut l'atteindre.
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.
Ce dernier trait est celui qui compte. Une DMZ n'est pas une zone coupée du reste : elle est reliée au réseau interne par un flux nommé, et c'est l'étroitesse de ce flux qui fait toute la protection.
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.
La troisième règle mérite d'être justifiée, parce que le lien entre « compromettre une machine » et « obtenir des identifiants » n'a rien d'évident. Un serveur membre d'un domaine conserve en mémoire vive des éléments secrets dérivés des comptes qui s'y connectent, à commencer par ceux des administrateurs venus en assurer la maintenance. Un attaquant qui obtient les droits les plus élevés sur cette machine extrait ces éléments de la mémoire, puis les présente au contrôleur de domaine à la place du mot de passe qu'il ne connaît pas. C'est le principe des attaques dites de rejeu d'empreinte, et il ne demande à aucun moment de casser le chiffrement.
La machine exposée devient ainsi un point d'entrée vers l'intérieur, et le pare-feu n'y peut rien : l'attaquant emprunte un flux légitime, avec des identifiants valides. Des contre-mesures existent sur les systèmes récents, mais la parade qui ne dépend d'aucune version reste celle de la règle : ne pas joindre au domaine ce qui est exposé, et ne jamais y ouvrir de session avec un compte à privilèges.
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 est un équipement ou un logiciel placé à la frontière de deux zones, qui examine chaque paquet et décide de le laisser passer ou de le rejeter, selon une liste de règles appelée politique de filtrage.
Une règle nomme au minimum une source, une destination, un port, et l'action à prendre. C'est le point de contrôle sans lequel la segmentation ne serait qu'un découpage sur le papier.
Un pare-feu applique ces 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.
L'ordre des deux dernières règles est décisif : 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.
Relire le jeu de règles, et non les paquets
Évaluer un paquet est facile, et c'est ce que fait le bloc ci-dessus. Relire le jeu de règles pour lui-même est une autre affaire, et personne ne le fait à la main : il faudrait comparer chaque règle à toutes celles qui la précèdent, sur chaque couple de zones et chaque port.
C'est pourtant là que se cachent les défauts les plus coûteux. Une règle placée après une autre qui couvre déjà tout son trafic ne se déclenchera jamais. Elle reste dans le fichier, elle se relit comme une intention, elle rassure lors d'un audit, et elle n'existe pas.
Paquets d'essai
internet > dmz : 443 · autoriser par la règle 1
lan > dmz : 22 · 3 règles traversées · autoriser par la règle 4
- La règle 5 dit refuser, et la règle 4 a déjà tranché l'inverse sur le même trafic. Quelqu'un a écrit une intention de sécurité que rien n'appliquera, et sa présence dans le fichier laisse croire qu'elle est en vigueur.
- Une règle est partiellement masquée : une exception posée plus haut leur retire une partie de leur portée. C'est la façon normale d'écrire une exception, et c'est aussi ce qui rend un jeu de règles difficile à relire quand les exceptions se multiplient.
- 3 règles laissent un champ à « tout ». Le moindre privilège demande de nommer le protocole, la destination et le port ; ce qui n'est pas nommé tombe de toute façon sous le refus par défaut.
La cinquième règle interdit l'accès en console depuis le réseau interne vers la zone démilitarisée. C'est une bonne idée, elle est écrite noir sur blanc, et elle ne s'applique pas : la quatrième autorise déjà tout ce trafic. Le paquet d'essai le confirme, il est autorisé par la règle 4, et la règle 5 n'est même pas atteinte.
C'est le défaut le plus dangereux d'une politique de filtrage, parce qu'il ne se manifeste par aucun symptôme. Rien ne tombe en panne, aucun journal ne s'alarme, et le fichier de règles atteste d'un contrôle qui n'existe pas.
Une règle partiellement masquée est normale : c'est ainsi qu'on écrit une exception. La septième règle de la figure refuse tout de la zone démilitarisée vers le réseau interne, sauf le port de la base de données que la sixième a déjà autorisé. C'est exactement ce qu'on veut, et le savoir évite de « corriger » une politique correcte.
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.
ANY de la colonne des ports et de la colonne des destinations. Une règle qui autorise « la DMZ vers le réseau interne, tous ports » n'est pas une règle, c'est l'absence de règle écrite sous forme de ligne.Une communication légitime se nomme entièrement : le protocole de transport, l'adresse de destination et le port, par exemple TCP/1433 vers le seul serveur de base de données. Tout ce qui n'a pas été nommé tombe alors sous le refus par défaut, sans qu'il soit nécessaire de l'énumérer.
C'est aussi ce qui rend un jeu de règles relisible : chaque ligne documente un besoin métier identifié, et une ligne dont personne ne sait plus à quoi elle sert peut être retirée.
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 d'Ardexia, et on ne la supprime pas.
Mot de passe faible : une vulnérabilité. Elle est chez Ardexia, 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. La règle précise devient alors morte, et l'analyse le montre sans qu'il faille jouer le moindre paquet.
Paquets d'essai
dmz > lan : 1433 · 2 règles traversées · refuser par la règle 3
- La règle 4 dit autoriser, et la règle 3 a déjà tranché l'inverse sur le même trafic. L'autorisation ne sera jamais accordée, et le service qu'elle devait ouvrir ne fonctionnera pas. C'est la panne dont la cause se cherche partout ailleurs que dans l'ordre des règles.
- 2 règles laissent un champ à « tout ». Le moindre privilège demande de nommer le protocole, la destination et le port ; ce qui n'est pas nommé tombe de toute façon sous le refus par défaut.
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.
Ardexia découvre une fuite de son fichier patients. 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.
Vérification
1.Par où une intrusion commence-t-elle le plus souvent ?
2.À quoi sert une zone démilitarisée ?
3.Une politique de pare-feu se lit dans quel ordre ?
4.Le délai de notification de 72 heures court à partir de quand ?
La méthode
- Séparer menace, vulnérabilité et impact avant toute proposition. On agit sur les deux dernières.
- Segmenter d'abord ce dont la compromission coûte le plus cher, en général le plateau technique et l'administration.
- Écrire 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.
- Ordonner du plus précis au plus général, et terminer par le refus par défaut.
- Vérifier qu'aucun serveur de DMZ n'est membre du domaine interne.
- Appliquer le moindre privilège aux comptes d'administration : deux comptes, poste dédié.
- Empiler des mesures indépendantes plutôt que de renforcer une seule barrière.
- Écrire la procédure de notification avant l'incident. Les 72 heures ne se découvrent pas le jour venu.
Synthèse
- 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.
Mettre en pratique
La première règle qui correspond décide, et ce que cela rend inutile.
Tous les exercices sur filtrage réseau