Menaces réseau, détection et réponse opérationnelle

Les attaques réseau se ressemblent plus qu’on ne le croit : une phase de reconnaissance, une usurpation d’identité au niveau local (adresse, serveur, point d’accès), un abus de protocole, ou une inondation qui vise la disponibilité. Cette fiche les présente du point de vue du défenseur, sans recette offensive : quels signaux elles laissent, comment les détecter en croisant plusieurs sources, et comment répondre dans un SOC (Security Operations Center) sans confondre alerte et incident, ni attaque par déni de service distribué (DDoS, Distributed Denial of Service) et simple panne applicative.

→ Lire l’explication complète de la marmotte

Panorama des menaces réseau

Reconnaissance

Avant d’agir, un attaquant observe. Le scan cherche quelles adresses répondent ; l’analyse de ports détermine, pour chaque machine, quels ports TCP (Transmission Control Protocol) ou UDP (User Datagram Protocol) sont ouverts ; le fingerprinting identifie le système et la version des services, à partir des bannières ou des particularités de la pile réseau. Sur Internet, cette activité est permanente : toute adresse publique reçoit des sondages plusieurs fois par heure, de la part de robots malveillants, de chercheurs et de moteurs de recensement. Un scan isolé depuis Internet est donc du bruit de fond. Un scan qui part d’un poste interne, en revanche, est un signal fort : peu de comptables ont l’habitude de cartographier le sous-réseau des serveurs.

Usurpations sur le réseau local

Sur un segment local, plusieurs mécanismes reposent sur la confiance. L’ARP spoofing (usurpation ARP, Address Resolution Protocol) consiste à annoncer sa propre adresse matérielle pour l’adresse IP de la passerelle, afin de recevoir le trafic des voisins : c’est une position d’écoute réseau et d’interception. Le DHCP rogue est un faux serveur DHCP (Dynamic Host Configuration Protocol) qui distribue une passerelle ou un serveur de noms malveillant. Le DNS spoofing fournit de fausses réponses aux résolutions de noms. L’evil twin est un point d’accès sans fil qui imite le nom d’un réseau légitime. Le VLAN hopping exploite des ports de commutateur mal configurés (négociation automatique de trunk, VLAN natif partagé) pour atteindre un VLAN (Virtual Local Area Network) qui devait rester inaccessible. Les contre-mesures sont connues et rarement toutes activées : DHCP snooping, inspection ARP dynamique, désactivation de la négociation de trunk, authentification 802.1X, Wi-Fi d’entreprise avec vérification du certificat serveur (voir Wi-Fi d’entreprise et VLAN, trunks et boucles).

Abus de protocoles

Le SYN flood envoie des demandes d’ouverture de connexion TCP sans jamais les terminer, pour remplir la file des connexions en attente d’un serveur ; les SYN cookies, qui évitent de réserver de la mémoire avant la fin de la poignée de main, le neutralisent largement. La RST injection consiste à forger un segment de réinitialisation pour couper une connexion établie entre deux tiers. Côté applicatif, Slowloris ouvre de nombreuses connexions HTTP (HyperText Transfer Protocol) et les maintient en envoyant les en-têtes au compte-gouttes, épuisant les connexions d’un serveur qui en accepte un nombre limité. La request smuggling (désynchronisation HTTP) exploite un désaccord entre un reverse proxy et le serveur placé derrière lui sur la longueur d’une requête, pour glisser une seconde requête dans la première. Le DNS tunneling encode des données dans des noms de domaine interrogés vers un serveur contrôlé par l’attaquant, ce qui fait du DNS un canal de sortie quand tout le reste est filtré.

À l’échelle d’Internet, le BGP hijack consiste à annoncer en BGP (Border Gateway Protocol) des préfixes qui appartiennent à un autre, pour attirer leur trafic. L’exemple classique reste février 2008, quand un opérateur pakistanais, voulant bloquer YouTube localement, a annoncé un préfixe plus spécifique qui s’est propagé mondialement et a rendu le site injoignable pendant environ deux heures. La validation d’origine par RPKI (Resource Public Key Infrastructure) réduit ce risque (voir BGP, Internet et anycast).

Déni de service distribué

Les DDoS se rangent en trois familles. Les attaques volumétriques saturent la bande passante, souvent par réflexion et amplification : l’attaquant envoie de petites requêtes UDP en usurpant l’adresse source de la victime vers des serveurs tiers (DNS, NTP, memcached) qui répondent par des messages bien plus gros, vers la victime. Le facteur d’amplification va de quelques dizaines pour le DNS à plusieurs dizaines de milliers pour memcached, utilisé en février 2018 contre GitHub avec un pic d’environ 1,35 Tbit/s. Les attaques protocolaires épuisent les tables d’état (SYN flood, fragments). Les attaques applicatives envoient des requêtes légitimes en apparence mais coûteuses (recherches, pages non mises en cache) depuis des botnets, réseaux de machines compromises, souvent des objets connectés mal protégés. Le détail se trouve dans DDoS volumétrique et applicatif.

Reconnaître les signaux faibles

Les signaux utiles sont souvent modestes : un poste qui contacte en quelques minutes des centaines d’adresses internes sur le port 445 ; un pic de requêtes DNS vers un même domaine avec des sous-domaines longs et aléatoires ; un flux sortant régulier, toutes les 60 secondes, vers une adresse jamais vue ; un serveur qui se met à parler sur un port qu’il n’a jamais utilisé ; une nouvelle adresse MAC (Media Access Control) qui répond pour l’adresse de la passerelle.

Le tri distingue trois cas. Le bruit Internet : sondages entrants sur l’adresse publique, refusés par le pare-feu, sans suite. L’erreur : un outil d’inventaire mal configuré, un script de sauvegarde qui scanne une plage entière. L’attaque probable : un comportement anormal pour cette machine, cohérent avec une progression. Pour trancher, il faut relier l’alerte réseau à l’identité de la machine : quel poste porte cette adresse à cet instant (baux DHCP, journaux NAC), qui y est connecté, est-il censé faire cela. Une adresse IP seule est un indice ; un nom de machine, un utilisateur et un rôle font un dossier.

Détecter avec plusieurs sources

IDS, IPS et NDR

Un IDS (Intrusion Detection System) analyse le trafic et génère des alertes ; un IPS (Intrusion Prevention System), placé en coupure, peut bloquer le trafic qui correspond à une règle. Le second protège davantage mais un faux positif y coupe un flux légitime, d’où l’usage fréquent du mode détection d’abord, blocage ensuite sur les règles éprouvées. Suricata est un moteur IDS/IPS libre fondé sur des signatures, qui produit aussi des journaux de protocoles. Zeek (anciennement Bro) adopte une autre approche : il transforme le trafic en journaux structurés par protocole (conn.log, dns.log, http.log, ssl.log) et laisse l’analyse au défenseur. Les outils de NDR (Network Detection and Response) cherchent des comportements anormaux plutôt que des signatures, et proposent des actions de réponse.

Croiser les sources

Aucune source ne voit tout. Les résumés de flux NetFlow, sFlow ou IPFIX (IP Flow Information Export) disent qui a parlé à qui, sans contenu, sur tout le réseau ; les journaux DNS montrent les intentions de connexion ; le proxy voit les destinations web ; le pare-feu voit les refus ; l’EDR (Endpoint Detection and Response), installé sur les postes, voit quel processus a ouvert la connexion. Le SIEM (Security Information and Event Management) centralise et corrèle ces sources (voir Théorie de la détection et SIEM). La surveillance doit couvrir l’intérieur : un IDS posé uniquement en sortie Internet ne verra jamais un déplacement latéral entre deux serveurs du même centre de données.

Construire des baselines

Une baseline décrit le comportement normal : volumes par heure, destinations habituelles, ports utilisés par chaque rôle. Le danger est d’apprendre l’anomalie comme normale : une baseline calculée sur un réseau déjà compromis intègre le flux de l’attaquant. On la construit donc par rôle (tous les postes comptables, tous les serveurs web) plutôt que machine par machine, on la revoit, et on garde des règles absolues qui ne dépendent d’aucun apprentissage (aucun poste ne parle SMB, Server Message Block, vers Internet).

Répondre et résister

Qualifier, contenir, rétablir

La réponse suit des étapes reconnues. La qualification transforme une alerte en incident confirmé, ou la clôt comme faux positif, avec une justification. Le confinement limite la propagation : isoler une machine dans un VLAN de quarantaine, bloquer une destination, désactiver un compte, en préservant les traces utiles à l’enquête. La coordination désigne un responsable d’incident, ouvre un canal dédié, prévient l’opérateur ou le prestataire si nécessaire. La communication informe direction, utilisateurs et, le cas échéant, autorités. Le rétablissement remet en service des systèmes nettoyés, sous surveillance renforcée. Le post-mortem, enfin, établit la chronologie, les causes et les mesures de durcissement, sans chercher de coupable à punir, faute de quoi le prochain incident sera caché plutôt que déclaré.

Tenir face au DDoS

Un DDoS volumétrique ne se traite pas au niveau du pare-feu de l’entreprise : quand le lien d’accès est saturé, filtrer derrière lui ne sert à rien. Les parades se situent en amont. Un CDN (Content Delivery Network) absorbe le trafic web sur ses nombreux points de présence. L’anycast annonce la même adresse depuis plusieurs sites, ce qui répartit l’attaque. Le scrubbing, nettoyage chez un prestataire spécialisé, détourne le trafic (par BGP ou DNS), filtre l’attaque et renvoie le trafic légitime. La dégradation contrôlée accepte de servir une version réduite (pages statiques, fonctions coûteuses désactivées) pour garder l’essentiel en ligne. Tout cela se contractualise avant : découvrir le numéro de l’équipe sécurité de son opérateur pendant l’attaque est une expérience pédagogique, mais coûteuse.

Exemples et ateliers

Lire un résultat Nmap côté défenseur. Un scan de ses propres serveurs, avec une autorisation écrite, donne la vue qu’un attaquant obtiendrait :

PORT     STATE    SERVICE  VERSION
22/tcp   open     ssh      OpenSSH 9.2p1
80/tcp   open     http     nginx
443/tcp  open     https    nginx
3306/tcp open     mysql    MySQL 8.0
8080/tcp filtered http-proxy

open signifie qu’un service répond, closed que la machine répond mais sans service, filtered qu’un filtre empêche de conclure. La lecture défensive pose trois questions : chaque port ouvert correspond-il à un besoin documenté ? Ici, une base de données joignable depuis l’extérieur ne l’est sûrement pas. Les versions affichées sont-elles à jour ? Le résultat est-il identique à celui du mois dernier ? Un port apparu sans changement déclaré mérite une enquête. Côté juridique, en France, l’accès ou le maintien frauduleux dans un système (article 323-1 du Code pénal) et la détention d’outils d’attaque sans motif légitime (article 323-3-1) sont réprimés : scanner des systèmes qui n’appartiennent pas à l’organisation, ou capturer du trafic contenant des données personnelles sans cadre, exige une autorisation explicite et une information préalable des personnes concernées.

Analyser une alerte Suricata simplifiée. Suricata écrit ses alertes au format JSON dans eve.json :

{"timestamp":"2026-10-03T09:14:22.418+0200","event_type":"alert",
 "src_ip":"10.10.4.57","src_port":51544,"dest_ip":"10.20.0.15","dest_port":445,
 "proto":"TCP","alert":{"action":"allowed","signature_id":1000001,
 "signature":"LOCAL poste vers SMB serveurs hors liste","severity":2}}

Une règle locale (la plage 1000000 à 1999999 est réservée par convention aux règles locales) a vu le poste 10.10.4.57 joindre un serveur sur SMB. action: allowed rappelle qu’il s’agit d’un IDS : rien n’a été bloqué. La qualification consiste à identifier le poste et son utilisateur, vérifier dans les flux si d’autres serveurs ont été contactés dans la même minute, consulter l’EDR pour connaître le processus, puis décider.

Runbook DDoS minimal. Une page suffit : critères de déclenchement (saturation du lien d’accès au-delà de 90 % pendant cinq minutes avec hausse des requêtes entrantes) ; contacts (opérateur, prestataire de scrubbing, avec numéros et identifiants de contrat) ; actions dans l’ordre (confirmer qu’il ne s’agit pas d’une panne applicative, activer la redirection vers le scrubbing, basculer le site en mode dégradé) ; communication (message aux utilisateurs, point toutes les 30 minutes) ; critères de fin et post-mortem.

Pièges classiques

Déployer un IDS sans réglage produit des milliers d’alertes par jour, que plus personne ne lit au bout d’une semaine. Ne surveiller que le périmètre laisse invisible tout ce qui se passe une fois l’attaquant entré, c’est-à-dire précisément la partie intéressante. Découvrir les contacts opérateurs pendant l’incident ajoute une heure de recherche à chaque heure de panne.

À ne pas confondre

La détection signale, la prévention bloque ; un IPS mal réglé fait de la prévention contre les utilisateurs. Une alerte est une hypothèse, un incident confirmé est une conclusion. Un DDoS et une panne applicative produisent le même symptôme, un service lent ou absent : les flux entrants (volume, sources, répartition géographique) permettent de les distinguer avant de déclencher une procédure coûteuse. Le NDR regarde le réseau, l’EDR regarde la machine ; le premier voit les échanges que le second ne relie pas, le second voit les processus que le premier ignore.

🐝 Ce qui arrive si on s’en passe

Sans détection ni procédure de réponse, une intrusion réseau se découvre par ses effets, bien après ses débuts : la période pendant laquelle l’attaquant a pu écouter, rediriger ou exfiltrer reste inconnue, alors que c’est elle qui détermine ce qu’il faut déclarer, réinitialiser ou reconstruire. Sans résumés de flux conservés, impossible de savoir après coup quelles machines ont dialogué avec la machine compromise, donc impossible de délimiter la propagation. Face à une inondation de trafic, l’absence de mode dégradé prévu ne laisse que deux options, aussi peu réjouissantes l’une que l’autre : tout couper ou tout subir.

🦫 Explication de la marmotte 🍫

Une attaque réseau commence souvent par une reconnaissance : l’attaquant cherche quelles machines répondent, quels services elles offrent et quels logiciels elles utilisent. Il peut ensuite écouter le trafic, se faire passer pour un équipement du réseau local, distribuer de fausses adresses ou de fausses réponses aux demandes de noms de domaine, ou créer un faux point d’accès sans fil. D’autres attaques visent la disponibilité : on inonde un service de demandes, directement ou en faisant répondre à sa place des milliers de machines tierces, pour le rendre inaccessible. Pour détecter ces actions, les défenseurs combinent plusieurs sources : des sondes qui analysent le trafic et le comparent à des signatures connues, des résumés de flux qui disent qui a parlé à qui et combien, les journaux des pare-feu, des serveurs de noms et des postes. Un outil central rassemble ces informations. Il faut d’abord établir ce qui est normal, sans y inclure par erreur une anomalie, puis régler les sondes, faute de quoi elles noient les équipes sous les alertes. Une alerte n’est pas un incident : il faut la qualifier. Si l’incident est confirmé, on le contient, on coordonne les équipes et l’opérateur, on communique, puis on rétablit le service. Contre les inondations, on répartit le trafic sur plusieurs sites et on le fait filtrer par des services spécialisés, en acceptant un fonctionnement réduit. L’analyse après incident sert enfin à durcir le réseau.

Pages voisines

La citent

Menaces réseau, détection et réponse opérationnelle

Elle cite

: les deux pages se citent l’une l’autre.

Menaces réseau, détection et réponse opérationnelle

Menaces réseau, détection et réponse opérationnelle

Panorama des menaces réseau

Reconnaissance

Usurpations sur le réseau local

Abus de protocoles

Déni de service distribué

Reconnaître les signaux faibles

Détecter avec plusieurs sources

IDS, IPS et NDR

Croiser les sources

Construire des baselines

Répondre et résister

Qualifier, contenir, rétablir

Tenir face au DDoS

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