SYN Flood

SYN Inondation

Une inondation SYN est une forme d'attaque DoS dans laquelle un attaquant envoie une succession de requêtes SYN au serveur d'une cible dans le but de consommer suffisamment de ressources du serveur pour rendre le système insensible au trafic légitime ^[1] .

Une requête SYN et un paquet SYN sont les mêmes choses

Comment fonctionne une attaque par inondation SYN ?

Les attaques par inondation SYN fonctionnent en exploitant le processus d'établissement de liaison d'une connexion TCP. Dans des conditions normales, TCP présente trois processus distincts pour établir une connexion (Figure 1a).

1. Le client demande une connexion en envoyant un paquet SYN ( sync ) au serveur.
2. Le serveur répond alors avec un paquet SYN-ACK , afin d' ACK ( accuser réception ) de la communication.
3. Le client envoie un paquet ACK pour accuser réception du paquet du serveur et la connexion est établie.

Après avoir terminé cette séquence d'envoi et de réception de paquets, la connexion TCP est ouverte et capable d'envoyer et de recevoir des données. C'est ce qu'on appelle la négociation à trois voies TCP. Cette technique constitue la base de toute connexion établie à l'aide de TCP.

Pour créer un DoS, un attaquant exploite le fait qu'après la réception d'un paquet SYN initial, le serveur répondra avec un ou plusieurs paquets SYN-ACK et attendra la dernière étape de la prise de contact. Cloudflare ^[2] décrit son fonctionnement (Figure 1b) :

1. L'attaquant envoie un volume élevé de paquets SYN au serveur ciblé, souvent avec des adresses IP usurpées.
2. Le serveur répond alors à chacune des demandes de connexion et laisse un port ouvert prêt à recevoir la réponse.
3. Pendant que le serveur attend le paquet ACK final, qui n'arrive jamais, l'attaquant continue d'envoyer d'autres paquets SYN . L'arrivée de chaque nouveau paquet SYN amène le serveur à maintenir temporairement une nouvelle connexion de port ouvert pendant un certain temps, et une fois que tous les ports disponibles ont été utilisés, le serveur est incapable de fonctionner normalement.

Configuration du réseau

L'attaque dans ce référentiel a été menée dans une VM. Trois machines sont nécessaires pour mener à bien l'attaque. Une machine est utilisée comme attaquant , une autre machine est utilisée comme victime (c'est-à-dire le serveur) et la troisième machine est utilisée comme observateur (c'est-à-dire le client).

Pour configurer l'attaque, trois machines virtuelles peuvent être configurées sur le même ordinateur hôte. Alternativement, deux machines virtuelles peuvent être configurées sur un ordinateur hôte, la machine hôte elle-même faisant office de troisième ordinateur.

Cette attaque a été mise en œuvre en supposant que les attaquants se trouvent sur le même réseau physique que les victimes, simplifiant ainsi la tâche de détermination des numéros de séquence TCP et des numéros de port source. Des outils Sniffer peuvent être utilisés pour collecter les informations nécessaires.

Attaque

L'attaque dans ce référentiel a été menée à l'aide de l'outil netwox . Ensuite, un outil de renifleur tel que Wireshark ^[3] a été utilisé pour capturer les paquets attaquants. Pendant que l'attaque était en cours, netstat -na a été exécuté sur la machine victime pour comparer le résultat avec celui d'avant l'attaque.

 # check the size of the queue for holding half-open connections
sudo sysctl -q net.ipv4.tcp_max_syn_backlog

# check the current usage of the queue;
# i.e., the number of half-open connections associated with some listening port
netstat -na

# one netwox tool that may be useful is tool number 76: synflood
netwox 76 --help

Contre-mesures

Cookie SYN :

L'attaque dans ce référentiel a été menée en manipulant des cookies SYN.

L'utilisation de cookies SYN permet à un serveur d'éviter d'interrompre les connexions lorsque la file d'attente SYN se remplit. Au lieu de stocker des connexions supplémentaires, l'entrée de la file d'attente SYN est codée dans le numéro de séquence envoyé dans la réponse SYN-ACK. Si le serveur reçoit ensuite une réponse ACK ultérieure du client avec le numéro de séquence incrémenté, le serveur est capable de reconstruire l'entrée de la file d'attente SYN en utilisant les informations codées dans le numéro de séquence TCP et de procéder comme d'habitude à la connexion.

Bien que cet effort d'atténuation perde certaines informations sur la connexion TCP, il est préférable de permettre au DoS de s'abattre sur des utilisateurs légitimes à la suite d'une attaque.

Les cookies SYN ont été créés par DJ Bernstein ^[4] en réponse directe aux inondations SYN.

Utilisez la commande sysctl pour activer/désactiver le mécanisme de cookie SYN :

sudo sysctl -a | grep cookie                 # Display the SYN cookie flag
sudo sysctl -w net.ipv4.tcp_syncookies=0     # turn off SYN cookie
sudo sysctl -w net.ipv4.tcp_syncookies=1     # turn on SYN cookie

Les cookies SYN sont l'une des nombreuses contre-mesures qui peuvent être mises en œuvre pour arrêter l'inondation SYN. D'autres mesures d'atténuation incluent l'augmentation de la taille maximale de la file d'attente, la réduction du temporisateur SYN-RECEIVED et le recyclage de la plus ancienne connexion TCP semi-ouverte.

---

Références

1. ^ "Avis CERT CA-1996-21 TCP SYN Flooding et attaques d'usurpation d'adresse IP" Université Carnegie Mellon

2. ^ "Attaque d'inondation SYN" Cloudflare

3. ^ "À propos de Wireshark" Fondation Wireshark

4. ^ "Cookies SYN" DJ Bernstein

---

Merci pour votre intérêt, ce projet était amusant et perspicace !