Les attaques réseau de la couche transport
La sécurité d’un réseau informatique représente un enjeu crucial, elle nécessite une vigilance constante ainsi qu’une connaissance approfondie des différentes menaces potentielles. Dans la couche réseau de l’architecture OSI, les attaques se focalisent sur la perturbation de la transmission des données entre les systèmes. Ces attaques sont conçues pour intercepter, altérer ou interrompre le flux d’informations normalement acheminées selon les protocoles IP.
Les attaques sur la couche réseau sont particulièrement sournoises, car elles peuvent prendre diverses formes et avoir des impacts significatifs. Parmi ces attaques, les plus connues exploitent les faiblesses des protocoles de communication comme TCP et UDP pour provoquer un déni de service ou pour accéder à des données sensibles. Le TCP Syn Flood, par exemple, submerge un serveur de requêtes de connexion, empêchant les utilisateurs légitimes d’accéder au service. Le TCP ACK Flood et le TCP FIN Flood, quant à eux, envoient un grand nombre de paquets pour perturber la connexion, tout en contournant les firewalls. De manière similaire, l’UDP Flood sature le réseau avec un nombre excessif de paquets UDP et fait déborder les files d’attentes, ce qui amène à un déni de service.
Il est primordial de comprendre que ces attaques ne sont pas des possibilités lointaines, mais des réalités imminentes. La question n’est donc pas de savoir si une attaque se produira, mais plutôt quand elle se produira et si l’infrastructure réseau est préparée pour y faire face. La préparation est la clé. Cela implique la mise en place de systèmes de détection et de réponse aux incidents, l’application de principes de défense en profondeur, l’entraînement régulier des équipes de sécurité à identifier et à réagir aux attaques, ainsi que l’adoption de politiques de sécurité robustes pour réduire les risques d’exposition aux vulnérabilités exploitables par les attaquants.
TCP Syn Flood
L’attaque par TCP-Syn Flood exploite une vulnérabilité dans le processus de connexion TCP, plus précisément lors de la phase de handshake en trois étapes. Normalement, cette négotiation implique l’envoi d’un paquet SYN par le client, auquel le serveur répond par un paquet SYN-ACK avant de recevoir un dernier paquet ACK du client pour établir la connexion. Dans une attaque par TCP-Syn Flood, un assaillant envoie un volume massif de paquets SYN à la cible sans jamais compléter la connexion avec le paquet ACK final.
Le serveur victime, en attendant la finalisation des connexions, alloue des ressources pour chacune des tentatives de connexion initiées. Ces ressources comprennent de la mémoire et d’autres capacités de traitement pour maintenir les sessions semi-ouvertes dans l’attente des paquets ACK. Avec l’afflux continu de paquets SYN frauduleux, le serveur s’épuise en ressources, ce qui entrave sa capacité à gérer des demandes de connexion légitimes. Finalement, cela peut conduire à un épuisement de la mémoire disponible et rendre le service inopérant pour les utilisateurs légitimes, réalisant ainsi un déni de service.
Les attaquants peuvent encore améliorer l’efficacité de cette attaque en utilisant la technique de l’IP spoofing, où les paquets SYN sont envoyés avec une adresse IP source falsifiée. Cela rend non seulement difficile la tâche de distinguer entre des requêtes légitimes et malicieuses, mais complique également la possibilité de tracer l’attaque jusqu’à sa source.
Une des techniques les plus ingénieuses pour contrer les attaques par TCP-Syn Flood est l’utilisation des TCP Syn Cookies. Cette méthode ne nécessite pas que le serveur conserve des ressources pour des connexions semi-ouvertes. Au lieu de cela, lorsqu’un paquet SYN est reçu, le serveur répond avec un paquet SYN-ACK, mais il n’alloue pas de ressources à la connexion. À la place, le serveur intègre dans le numéro de séquence TCP du paquet SYN-ACK une empreinte cryptographique générée à partir de l’adresse IP source et du numéro de port, ainsi que d’autres éléments distincts de la connexion entrante.


Ce numéro de séquence spécifique agit comme un « challenge » pour le client. Si le client est légitime et qu’il répond correctement avec un paquet ACK, le serveur est capable de reconstruire la connexion en utilisant les informations du numéro de séquence encodé. Cela permet de confirmer que la demande était authentique et de finaliser le processus de connexion sans avoir besoin de maintenir un état pour toutes les tentatives de connexion.
Le principal avantage de cette approche est que le serveur n’a pas à stocker l’état de la connexion dans une table, ce qui économise des ressources et minimise l’impact d’un TCP SYN Flood. En définitive, cela permet au serveur de rester fonctionnel même sous une charge élevée de requêtes non valides. C’est une technique de défense proactive qui permet aux serveurs de continuer à accepter des connexions entrantes légitimes tout en souscrivant au principe du moindre engagement, qui est essentiel pour survivre aux attaques par déni de service.
TCP RST Flood
L’attaque par TCP RST Flood vise à interrompre des connexions TCP établies en envoyant des paquets TCP avec le drapeau RST à l’une où aux deux extrémités d’une connexion TCP. Un paquet RST est normalement utilisé dans les communications TCP pour indiquer qu’une erreur s’est produite et que la connexion doit immédiatement être interrompue. Lorsque les hôtes reçoivent un paquet RST valide, ils terminent la connexion, ce qui interrompt tout échange de données en cours. Cette fonctionnalité peut être exploitée malicieusement.
Dans une attaque par TCP RST Flood, l’assaillant envoie un paquet RST forgé dans le but de forcer la fermeture de sessions TCP actives entre deux systèmes. Ces paquets peuvent être envoyés de manière aléatoire à divers ports sur l’hôte cible, ou bien de manière plus ciblée si l’assaillant a pu obtenir des informations sur des sessions TCP spécifiques à interrompre. La spécificité de cette attaque réside dans sa capacité à interrompre des connexions spécifiques avec peu de paquets, en contraste avec d’autres attaques DDoS qui nécessitent un grand volume de trafic pour submerger le système.
Pour se défendre contre une attaque par TCP-RST Flood, il est crucial d’avoir des numéros de séquence TCP imprévisibles. Une stratégie consiste à implémenter des algorithmes de génération de numéros de séquence plus complexes, rendant la tâche de l’attaquant considérablement plus difficile pour deviner ou prédire ces numéros. Les systèmes modernes utilisent généralement des techniques sophistiquées pour s’assurer que les numéros de séquence sont aléatoires et imprédictibles, conformément aux recommandations des standards de sécurité actuels. Les solutions de mitigation des DDoS modernes peuvent également analyser le trafic et bloquer les paquets RST suspects, en se basant sur leur fréquence, leur origine, et d’autres caractéristiques anormales.
TCP ACK Flood
Les pare-feu traditionnels sont souvent configurés pour filtrer et inspecter les paquets SYN, lesquels sont les premiers indicateurs d’une tentative de connexion TCP. En revanche, les paquets ACK sont habituellement associés à des connexions déjà établies et, par conséquent, sont moins susceptibles d’être examinés de manière approfondie. Les attaquants exploitent cette lacune en envoyant un grand nombre de paquets ACK qui semblent faire partie d’une session active. Le trafic excessif peut saturer les liaisons réseau et les processeurs de périphériques réseau, provoquant un ralentissement du service ou une indisponibilité complète pour les utilisateurs légitimes.
Pour se défendre contre les attaques exploitant les paquets ACK, il est crucial d’implémenter un système de détection d’intrusion qui examinent le contexte de la connexion plutôt que de se fier uniquement aux en-têtes de paquets. Ces systèmes peuvent tracer l’état des connexions TCP pour s’assurer que les paquets ACK correspondent à des sessions légitimes. En outre, l’utilisation de mécanismes de limitation de débit peut aider à identifier et à bloquer les paquets ACK malveillants qui tentent de simuler des connexions établies, évitant ainsi la saturation des ressources réseau et minimisant les risques.
UDP Flood
L’attaque par UDP Flood cible le réseau en saturant la bande passante avec un grand nombre de paquets UDP. Contrairement aux attaques qui exploitent les connexions, telles que TCP-Syn Flood, les attaques UDP Flood inondent simplement le réseau avec un débit de données écrasant. L’objectif est d’envoyer tellement de paquets vers la cible que la capacité du serveur à traiter le trafic est dépassée, provoquant un ralentissement ou même un arrêt complet du service pour les utilisateurs légitimes.
Lors de cette attaque, le serveur ciblé reçoit une quantité massive de paquets UDP sur différents ports, ce qui le force à vérifier constamment l’application correspondant à chaque port et, en l’absence d’application écoutant sur le port, à répondre avec un paquet de refus. Cette réponse utilise des ressources serveur supplémentaires. Cependant, même sans tenir compte de la vérification des ports et des réponses de refus, le simple volume de trafic entrant peut être suffisant pour saturer la connexion réseau.
La spécificité dévastatrice de l’attaque UDP Flood est qu’elle peut être amplifiée par le spoofing d’adresse IP. En forgeant les adresses IP sources des paquets UDP, l’attaquant rend le ratelimit inefficace, car chaque paquet semble provenir d’une source différente, rendant les contrôles basés sur la fréquence de trafic d’une source particulière inutiles. De plus, le spoofing d’IP complique la distinction entre le trafic légitime et malveillant, et rend la traçabilité de l’attaque plus difficile pour les défenseurs du réseau.
Par ailleurs, lorsqu’on associe l’IP spoofing avec l’UDP Flood, on peut réussir à mener des attaques UDP amplifiée, qui sont alors considérablement plus destructrices que les attaques par UDP Flood classiques. Dans une attaque d’amplification, comme celles ciblant les serveurs DNS ou les serveurs NTP, l’attaquant envoie des requêtes UDP à ces serveurs en utilisant l’adresse IP spoofée de la victime. Les serveurs, pensant qu’ils répondent à une requête légitime de la victime, envoient la réponse à cette dernière. Ces attaques d’amplification tirent parti de la différence de taille entre la requête initiale et la réponse: une petite requête envoyée par l’attaquant peut produire une réponse significativement plus grande. Ainsi, l’attaquant peut générer un volume de trafic de sortie bien plus important que le volume de trafic d’entrée, amplifiant l’effet de l’attaque.

Dans un tel scénario, un attaquant avec une capacité de bande passante, disons de 1 Gbps, peut abuser de ces services pour générer un flux de sortie qui dépasse largement sa propre capacité de transmission. Les retours amplifiés peuvent atteindre des tailles démesurées, excédant 100 Gbps, submergeant ainsi la capacité de la victime à gérer les données entrantes. Cela a pour effet de saturer non seulement la connexion Internet de la victime, mais également l’ensemble de son infrastructure réseau interne, ce qui peut entraîner des interruptions de service étendues et coûteuses. La mitigation de ces attaques nécessite une coopération entre les fournisseurs d’accès Internet.