Défense périmétrique

Le chapitre 5 s'est terminé sur une phrase : ne jamais faire confiance au réseau lui-même. Ce chapitre construit la défense qui en découle. Mais il faut lever d'emblée un malentendu que le mot « périmétrique » entretient.

Le modèle historique — un intérieur de confiance, un extérieur hostile, un mur entre les deux — a une faiblesse fatale, illustrée par Colonial Pipeline (chapitre 3) : une fois le mur franchi, plus rien n'arrête l'attaquant. Un compte VPN volé, et tout l'intérieur était à portée. La sécurité moderne remplace donc le mur unique par une défense en profondeur — des barrières internes — et, à sa limite, par le modèle zéro confiance, où chaque accès est vérifié quel que soit l'endroit d'où il vient. Le périmètre reste utile ; il n'est plus suffisant.

Le pare-feu

Un pare-feu filtre le trafic selon une politique. Il en existe trois générations, qui se cumulent plus qu'elles ne se remplacent :

• Sans état : décide paquet par paquet, sur adresses et ports. Rapide, aveugle au contexte.
• À états : suit les connexions et n'autorise les réponses que si une requête les a précédées. C'est la base de tout pare-feu sérieux.
• Applicatif (nouvelle génération) : inspecte le contenu, identifie l'application réelle derrière un port, intègre parfois de la détection d'intrusion. Voit ce qu'un port seul cache — du trafic non-HTTP tunnelisé dans le port 443, par exemple.

Deux principes gouvernent l'écriture d'une politique, et ce sont eux qui font la différence entre une règle qui protège et une règle qui rassure :

1. Refus par défaut (liste blanche). On interdit tout, puis on ouvre le strict nécessaire. La liste noire — tout autoriser sauf l'interdit — échoue toujours : on ne peut pas énumérer ce qu'on ne connaît pas encore.
2. L'ordre des règles compte. L'évaluation s'arrête à la première correspondance : une règle large placée en tête annule toutes les règles fines qui la suivent. C'est la faute la plus fréquente, et celle de l'exercice de ce chapitre.

Un pare-feu filtre aussi bien en sortie qu'en entrée, et le filtrage sortant est sous-estimé : il gêne l'exfiltration et la communication d'un maliciel avec son serveur de commande (chapitre 4). Une machine compromise qui ne peut pas sortir a une valeur très réduite pour l'attaquant.

Segmentation et zone démilitarisée

Le pare-feu périmétrique ne protège que la frontière. La segmentation découpe l'intérieur en zones, avec un filtrage entre elles — de sorte qu'un attaquant qui compromet une zone ne gagne pas les autres. C'est la réponse directe au déplacement latéral du chapitre 5, et le mécanisme qui aurait limité Colonial Pipeline.

La zone démilitarisée (DMZ) en est le cas d'école. Les serveurs exposés à Internet — web, messagerie, DNS public — y sont placés, isolés du réseau interne. La logique est celle de la compromission assumée : ces serveurs sont les plus exposés, donc les plus susceptibles de tomber ; on les met là où leur chute ne donne pas l'accès à la base clients.

D'où la règle de flux qui structure l'exercice : Internet atteint la DMZ, la DMZ atteint certains services internes précis (le web parle à la base, sur le seul port de la base), et l'interne n'est jamais joignable directement depuis Internet. La micro-segmentation pousse l'idée jusqu'à isoler chaque charge de travail, ce qui rejoint le zéro confiance.

VPN et tunnels

Un VPN établit un tunnel chiffré et authentifié à travers un réseau non fiable : le trafic y circule comme s'il était sur un réseau privé. Il répond exactement au problème du chapitre 5 — se protéger sur un réseau qu'on ne maîtrise pas.

Deux usages à ne pas confondre : l'accès distant, où un utilisateur rejoint le réseau de son organisation depuis l'extérieur, et l'interconnexion de sites. Les technologies courantes sont IPsec (niveau réseau), WireGuard (moderne, simple, rapide) et le TLS/HTTPS (VPN applicatifs, qui traversent facilement les pare-feux).

Deux nuances, contre-intuitives et importantes.

Un VPN déplace la confiance, il ne la crée pas. Le trafic est protégé jusqu'au point de terminaison — au-delà, il vaut ce que vaut ce point. Un VPN grand public déplace simplement votre confiance du fournisseur d'accès vers l'opérateur du VPN ; ce n'est un gain que si le second est plus digne de confiance que le premier.

Surtout, le VPN d'accès distant incarne le vieux modèle périmétrique, avec son défaut : authentifié une fois, l'utilisateur est « à l'intérieur », et un compte volé donne large accès. C'est précisément la brèche de Colonial Pipeline, et la raison de la bascule vers un accès réseau zéro confiance (ZTNA), qui n'accorde l'accès qu'application par application, après vérification continue de l'identité et de l'état du poste.

Détecter : IDS, IPS, analyse de trafic

Le filtrage empêche ; la détection repère ce qui est passé. Un IDS observe et alerte ; un IPS est un IDS placé en coupure, qui peut bloquer. Deux approches, complémentaires :

• Par signatures : reconnaît des motifs d'attaque connus (Snort, Suricata). Précis sur le connu, aveugle au reste — c'est la limite déjà vue avec l'antivirus au chapitre 4.
• Par anomalie : apprend le trafic normal et signale les écarts. Capable de détecter l'inconnu, au prix de faux positifs qu'il faut savoir régler.

Le compromis entre les deux types d'erreurs est le cœur du métier de détection. Un IPS trop sensible bloque du trafic légitime — il devient lui-même une cause d'indisponibilité ; trop laxiste, il laisse passer. Un IDS qui génère mille alertes par jour ne sera plus lu, et l'attaque réelle se noiera dans le bruit — c'est ce qui explique, dans plus d'un incident réel, que l'alerte pertinente existait mais n'a pas été traitée.

L'analyse de trafic ne dépend même pas du déchiffrement, et c'est ce qui la rend précieuse à l'ère du tout-chiffré. Les métadonnées suffisent souvent : une machine interne qui contacte un domaine jamais vu, un volume sortant anormal la nuit, des connexions régulières évoquant un canal de commande (beaconing). C'est le prolongement défensif de la remarque du chapitre 5 — TLS cache le contenu, pas les métadonnées, et cela sert autant le défenseur que l'attaquant.

Journalisation centralisée et SIEM

Le chapitre 4 a posé la règle : centraliser les journaux, hors de portée de l'attaquant. Le SIEM (Security Information and Event Management) est l'outil qui les collecte, normalise, corrèle et alerte.

Sa vraie valeur est la corrélation : rapprocher des événements qui, isolés, ne disent rien. Une authentification échouée est banale ; cent échecs suivis d'une réussite, puis d'une création de compte, puis d'une connexion sortante inhabituelle, dessinent une intrusion — et c'est exactement la chaîne d'attaque du chapitre 1, reconstituée en temps réel. Le SIEM est l'infrastructure qui rend le chapitre 9 possible.

Trois limites de terrain, à connaître avant d'en promettre monts et merveilles :

• Il ne voit que ce qu'on lui envoie : une source de journaux oubliée est un angle mort.
• Il produit du bruit : sans réglage continu, ses alertes deviennent illisibles, et le SOC qui les surveille s'épuise.
• Il coûte — en licence, en stockage, et surtout en personnes. Un SIEM sans équipe pour le lire est une dépense, pas une défense.

À vous

L'exercice porte sur le cœur pratique du chapitre : écrire une politique de pare-feu correcte. On vous en donne une qui « marche » — tout fonctionne — mais qui laisse en réalité Internet joindre la base de données et le bureau à distance des postes. Trouvez les deux fautes, réécrivez la politique en refus par défaut, et dites ce que le pare-feu ne protégera pas même une fois corrigé.

Cette dernière question est la plus importante : elle fait le pont vers le chapitre 7. Un flux « web vers base » autorisé reste autorisé quand le serveur web est compromis par injection SQL — et c'est là que la défense périmétrique atteint sa limite.

// Un pare-feu évalue ses règles DE HAUT EN BAS et s'arrête à la PREMIÈRE qui
// correspond. Ce qu'aucune règle n'autorise tombe dans la règle par défaut.
//
// Architecture : Internet | DMZ (serveur web 10.0.1.10) | réseau interne
// (base de données 10.0.2.20, postes 10.0.2.0/24).

// Une politique écrite par un stagiaire pressé. Elle "marche" — tout
// fonctionne — et c'est bien le problème.
let POLITIQUE = [
  { action: "ALLOW", de: "any",        vers: "10.0.1.10",   port: 443, note: "web public" },
  { action: "ALLOW", de: "any",        vers: "any",         port: "any", note: "pour que tout marche" },
  { action: "ALLOW", de: "10.0.1.10",  vers: "10.0.2.20",   port: 5432, note: "web -> base" },
  { defaut: "ALLOW" },
];

// Le moteur : rend l'action de la première règle qui correspond.
function decider(flux) {
  for (const r of POLITIQUE) {
    if (r.defaut) return r.defaut + " (défaut)";
    const okDe   = r.de === "any"   || r.de === flux.de;
    const okVers = r.vers === "any" || r.vers === flux.vers;
    const okPort = r.port === "any" || r.port === flux.port;
    if (okDe && okVers && okPort) return r.action + " — " + r.note;
  }
}

// Les flux qu'on veut tester (les 3 premiers légitimes, les 2 derniers non).
const FLUX = [
  { de: "any",       vers: "10.0.1.10", port: 443,  attendu: "ALLOW", desc: "visiteur -> web" },
  { de: "10.0.1.10", vers: "10.0.2.20", port: 5432, attendu: "ALLOW", desc: "web -> base" },
  { de: "10.0.2.15", vers: "any",       port: 443,  attendu: "ALLOW", desc: "poste -> Internet" },
  { de: "any",       vers: "10.0.2.20", port: 5432, attendu: "DENY",  desc: "Internet -> base (!!)" },
  { de: "any",       vers: "10.0.2.15", port: 3389, attendu: "DENY",  desc: "Internet -> poste RDP (!!)" },
];

// ── À VOUS ────────────────────────────────────────────────────────────────
// Réécrivez POLITIQUE pour que chaque flux obtienne le résultat "attendu".
// Deux principes : refus par défaut, et n'autoriser QUE le nécessaire.

for (const f of FLUX) {
  const d = decider(f);
  const ok = d.startsWith(f.attendu) ? "  ok" : "  ✗ FAILLE";
  console.log(f.desc.padEnd(28) + "-> " + d.padEnd(26) + ok);
}

// La politique corrigée : refus par défaut, et une règle par flux légitime,
// aussi étroite que possible.
POLITIQUE = [
  // Internet n'atteint QUE le web, QUE en 443.
  { action: "ALLOW", de: "any",       vers: "10.0.1.10", port: 443,  note: "web public" },
  // Le web parle à la base, QUE sur le port PostgreSQL. Rien d'autre.
  { action: "ALLOW", de: "10.0.1.10", vers: "10.0.2.20", port: 5432, note: "web -> base" },
  // Les postes internes sortent vers Internet en HTTPS.
  { action: "ALLOW", de: "10.0.2.0/24", vers: "any",     port: 443,  note: "postes -> web" },
  // Tout le reste est refusé.
  { defaut: "DENY" },
];
// NB : notre moteur jouet compare 'de' par égalité stricte ; en réalité
// 10.0.2.0/24 englobe 10.0.2.15. On l'admet ici pour la lisibilité.

// ── Les deux fautes de la politique d'origine ──────────────────────────────
//
// 1. La règle « ALLOW any->any » en position 2. Placée AVANT les règles
//    fines, elle les rend inutiles : le pare-feu s'arrête à la première
//    correspondance. Internet atteignait donc la base et le RDP des postes.
//    C'est l'erreur d'ordre la plus commune — une règle large en haut annule
//    tout ce qui la suit.
//
// 2. Le défaut ALLOW. Un pare-feu se conçoit en LISTE BLANCHE : on refuse
//    tout, puis on ouvre le strict nécessaire. La liste noire — « on
//    autorise tout sauf ce qu'on interdit » — échoue toujours, parce qu'on
//    ne peut pas énumérer ce qu'on ne connaît pas encore.
//
// ── Ce que le pare-feu NE fait pas ─────────────────────────────────────────
// Même parfaite, cette politique autorise le flux « web -> base sur 5432 ».
// Si le serveur web est compromis par une injection SQL (chapitre 7), ce
// flux est LÉGITIME du point de vue du pare-feu : l'attaquant parle à la base
// exactement comme l'application le fait. Le pare-feu segmente les MACHINES ;
// il ne comprend pas ce qui circule dans un flux autorisé. D'où la défense
// en profondeur : segmentation ICI, requêtes préparées LÀ, détection
// au-dessus.

Ce que la suite en fait

Les blocs III (réseaux) et IV (applications) se lisent en parallèle, et l'exercice ci-dessus en explique la raison : le pare-feu segmente les machines, mais ne comprend pas ce qui circule dans un flux qu'il autorise. Un attaquant qui passe par une vulnérabilité applicative emprunte un chemin légitime du point de vue réseau.

C'est pourquoi le chapitre 7 descend dans l'application web — là où se trouve aujourd'hui la majorité de la surface exploitable, et là où le pare-feu ne peut rien. La défense en profondeur posée ici y trouve son complément indispensable : segmenter et valider les entrées, jamais l'un sans l'autre.

À retenir