Attaques réseau

Vous connaissez déjà TCP/IP : les couches, l'adressage, la poignée de main en trois temps, le DNS. Ce chapitre ne les réapprend pas. Il les relit à l'envers — non plus « comment faire communiquer deux machines », mais « qu'est-ce qu'un tiers peut observer, usurper ou interrompre ». La même poignée de main SYN / SYN-ACK / ACK que vous avez apprise à faire fonctionner devient, vue d'ici, une source d'information et un levier de déni de service.

Le fil conducteur tient en une phrase, et c'est l'hypothèse que tout le chapitre 6 s'emploiera à corriger :

Les protocoles fondateurs d'Internet ont été conçus entre machines qui se faisaient confiance. Presque aucun n'authentifie son correspondant.

Reconnaissance et balayage

Avant d'attaquer, on cartographie — c'est la phase 1 de la chaîne d'attaque, et elle est en grande partie passive, donc invisible.

La reconnaissance passive n'envoie rien à la cible : DNS et DNS inversé, enregistrements WHOIS, certificats publiés dans les journaux de transparence (chapitre 2), moteurs comme Shodan qui indexent en continu les services exposés, fuites de données, traces laissées sur les dépôts de code et les réseaux professionnels. On reconstitue ainsi une bonne part de la surface d'attaque sans qu'aucun journal de la cible n'en garde trace.

La reconnaissance active interroge la cible, et laisse donc des traces. Le balayage de ports établit quels services écoutent :

Vient ensuite l'empreinte des services : à partir des bannières et du comportement précis des piles réseau, on déduit les logiciels et leurs versions — donc les vulnérabilités connues associées. L'outil de référence est nmap, dont le seul balayage de versions fait le lien entre un port ouvert et une CVE exploitable.

La leçon défensive est double. On réduit ce qui est visible — un service qui n'écoute que sur 127.0.0.1 n'apparaît dans aucun balayage —, et on surveille le reste : un balayage est un signal précoce, souvent le premier événement détectable d'une attaque, comme le montrait le journal du chapitre 1.

Usurpation : ARP et DNS

Le cache ARP traduit une adresse IP en adresse MAC sur le réseau local. Le protocole n'authentifie rien : chaque machine croit la dernière réponse reçue, même non sollicitée. Un attaquant sur le même segment annonce « l'adresse de la passerelle, c'est ma MAC », et le trafic de la victime passe par lui. C'est l'empoisonnement ARP, et c'est le montage le plus courant d'un homme du milieu sur un réseau local — celui de l'exercice ci-dessous.

L'usurpation DNS vise le même effet un cran plus haut : faire résoudre un nom légitime vers une adresse contrôlée par l'attaquant. Plusieurs voies y mènent : réponse falsifiée sur un réseau local non protégé, empoisonnement du cache d'un résolveur, modification du serveur DHCP qui distribue le résolveur, compromission d'un enregistrement chez le registraire. Le résultat est toujours le même : la victime tape la bonne adresse et atterrit chez l'attaquant.

La contre-mesure de fond est cryptographique et non réseau. DNSSEC signe les réponses DNS, ce qui détecte la falsification ; DoH et DoT chiffrent la requête DNS, ce qui empêche l'observation et la falsification sur le chemin. Et, comme pour ARP, TLS avec vérification du certificat rend l'usurpation largement stérile : atterrir chez l'attaquant ne lui sert à rien s'il ne peut pas présenter un certificat valide pour le domaine.

L'homme du milieu

Toutes les usurpations précédentes convergent vers la même position : l'attaquant se place entre deux correspondants, relaie leurs échanges, et peut lire comme modifier. C'est l'homme du milieu, et sa force est qu'il ne casse rien — il s'installe sous la communication.

Il faut être précis sur ce qu'il peut et ne peut pas.

• Contre un trafic en clair — HTTP, FTP, Telnet, SMTP nu — il lit et modifie tout. Ces protocoles n'ont aucune défense ; leur seule réponse est de disparaître au profit de leurs variantes chiffrées.
• Contre un trafic en TLS correctement vérifié, il ne voit que du chiffré et ne peut rien altérer sans invalider la signature. Sa seule issue est de présenter un faux certificat — et c'est là que tout se joue.

Cette dernière porte se referme par la vérification du chapitre 2 : contrôle du nom, de la chaîne, de la révocation, et HSTS, qui interdit au navigateur de retomber en HTTP clair et neutralise le classique « déclassement » (SSL stripping) où l'attaquant force la connexion à rester non chiffrée. C'est pourquoi les erreurs de certificat ne doivent jamais être apprises aux utilisateurs comme « à cliquer pour passer » : c'est le dernier avertissement avant l'homme du milieu.

Déni de service

Toutes les attaques précédentes visent la confidentialité ou l'intégrité. Le déni de service vise la troisième propriété, la disponibilité : rendre un service indisponible pour ses utilisateurs légitimes. Trois mécanismes, de nature très différente :

• Épuisement de ressources. L'inondation SYN ouvre des connexions à demi et remplit la table d'états du serveur sans jamais les finir ; les SYN cookies la neutralisent en ne réservant aucun état avant confirmation. D'autres visent la mémoire, les descripteurs, les connexions à la base.
• Amplification. L'attaquant envoie une petite requête, avec l'adresse source usurpée de la victime, à un service qui répond beaucoup plus gros — DNS, NTP, memcached. La victime reçoit la réponse démultipliée : un facteur d'amplification de plusieurs milliers a déjà été observé. Cette attaque repose entièrement sur l'usurpation d'adresse source, que le filtrage en bordure de réseau (BCP 38) empêcherait s'il était universellement déployé.
• Couche applicative. Des requêtes en apparence légitimes mais coûteuses — une recherche lourde, un rendu complexe — épuisent le serveur avec très peu de trafic. Indiscernables du trafic normal, ce sont les plus difficiles à filtrer.

Le déni de service distribué ajoute l'échelle : des milliers de machines compromises — un botnet, souvent d'objets connectés mal sécurisés, à la manière de Mirai en 2016 — frappent ensemble. La défense ne peut plus être locale : elle repose sur des réseaux de diffusion et des services d'atténuation capables d'absorber et de trier le trafic en amont, avant qu'il n'atteigne la cible.

Une remarque de gouvernance, qui rejoint le chapitre 10 : le déni de service ne compromet généralement pas les données, mais il coûte cher en indisponibilité, et il sert de plus en plus de diversion — saturer la surveillance pendant qu'une intrusion discrète se déroule ailleurs.

Attaques sur le Wi-Fi

Le réseau sans fil ajoute une difficulté que le filaire n'a pas : le médium est partagé et accessible sans branchement physique. Quiconque est à portée capte les trames.

L'historique des protections est une leçon en soi. WEP est cassé depuis longtemps — clé récupérable en minutes. WPA2 a longtemps tenu, mais reste exposé à la capture de la poignée de main suivie d'une attaque hors ligne par dictionnaire : d'où l'importance d'une phrase de passe longue (chapitre 3). WPA3 corrige ce point précis avec un échange (Dragonfly/SAE) résistant à l'attaque hors ligne.

Deux attaques ne dépendent pas du chiffrement du Wi-Fi et méritent d'être connues :

• Le jumeau maléchant : un faux point d'accès qui reprend le nom d'un réseau de confiance. La victime s'y connecte, et l'attaquant est d'emblée l'homme du milieu — sans aucun empoisonnement, parce que c'est lui le réseau.
• Les trames de désauthentification en WPA2 : non authentifiées, elles permettent d'éjecter une victime pour la forcer à se reconnecter — et à rejouer une poignée de main capturable, ou à retomber sur le jumeau maléchant.

La conclusion rejoint tout le reste du chapitre : la sécurité d'une communication ne peut pas reposer sur la sécurité du transport. Sur un réseau qu'on ne maîtrise pas — et un Wi-Fi public en est le cas extrême — seule la sécurité de bout en bout (TLS vérifié, VPN du chapitre 6) protège réellement.

À vous

L'homme du milieu se comprend en le montant. L'exercice simule le cache ARP de trois machines : vous empoisonnez celui de la victime pour intercepter son trafic vers la passerelle, puis vous écrivez la correction — et surtout, vous identifiez ce qu'elle ne règle pas, et ce qui, en revanche, rend l'interception inutile.

C'est le raisonnement clé du chapitre : on ne cherche pas à rendre le réseau local digne de confiance — il ne le sera jamais —, on fait en sorte qu'il n'ait pas besoin de l'être.

// Un réseau local, trois machines. ARP traduit une adresse IP en adresse MAC
// pour livrer les trames. Le protocole n'a AUCUNE authentification : chaque
// machine croit la dernière réponse ARP reçue, même non sollicitée.

const MAC = {
  "192.168.1.1":   "aa:aa (passerelle)",
  "192.168.1.50":  "bb:bb (victime)",
  "192.168.1.66":  "cc:cc (ATTAQUANT)",
};

// Le cache ARP de la victime : IP -> MAC vers qui elle envoie ses trames.
const cacheVictime = {
  "192.168.1.1": "aa:aa (passerelle)",   // état sain : passerelle = aa:aa
};

// Livraison d'une trame : elle part vers la MAC inscrite au cache.
function envoyer(ipDest, donnee) {
  const macCible = cacheVictime[ipDest] ?? "(inconnue, résolution ARP)";
  console.log("victime -> " + ipDest + " via " + macCible + " : " + donnee);
  if (macCible.includes("ATTAQUANT")) {
    console.log("   ⚠ interceptée par l'attaquant, qui relaie vers " + MAC[ipDest]);
  }
}

// ── ATTAQUE — à vous ──────────────────────────────────────────────────────
// L'attaquant (cc:cc) veut lire tout le trafic que la victime envoie vers
// Internet, c'est-à-dire vers la passerelle 192.168.1.1.
// Envoyez UNE réponse ARP mensongère qui empoisonne le cache de la victime.
//
// empoisonner(ip, mac) écrit dans le cache de la victime, sans vérification.
function empoisonner(ip, mac) {
  cacheVictime[ip] = mac;
}

// (écrivez votre attaque ici)

// La victime consulte sa banque :
envoyer("192.168.1.1", "GET https://banque.example/comptes");

Ce que la suite en fait

Ce chapitre a montré ce qu'un attaquant fait du réseau : le cartographier, s'y insérer, le saturer. Le chapitre 6 construit la réponse — pare-feu, segmentation, VPN, détection d'intrusion, SIEM — autour du principe qui est ressorti de chaque section : ne jamais faire confiance au réseau lui-même.

Retenez le rôle transversal de TLS : il est réapparu à chaque section comme la défense qui neutralise l'interception. Ce n'est pas un hasard — c'est l'application, au niveau réseau, de la sécurité de bout en bout posée au chapitre 2.

À retenir