1 – Le concept de l’attaque SynFlood

L’attaque SynFlood est basée sur l’envoi massif de demande d’ouverture de session TCP. Les buts recherchés peuvent être :

• Le Buffer Overflow du process écoutant le port TCP de destination.
• La saturation du nombre d’ouverture de session TCP en cours.

2 – Le fonctionnement de l’attaque SynFlood

2.1 – Schéma

2.2 – Envoi du SYN

Le fonctionnement est de générer une trame TCP de demande de synchronisation à destination de la cible. Cette demande de synchronisation SYN est la première étape d’une ouverture de session TCP. Voici le schéma de l’entête TCP avec ce fameux flag SYN basé sur 1 bit :

Les 5 autres flags doivent être positionnés à 0.

2.3 – Réception par la cible A

La cible recevant la synchronisation TCP mémorise cette demande nécessitant donc de la mémoire et du processeur. Voici l’état des connexions d’un Windows XP avant la réception d’un Synflood :

Et voici après la réception des demandes de SYN :

La cible passe les requêtes reçues en SYN_RECEIVED. Cet état est temporaire, le temps de durée de vie est variable en fonction de la pile IP.

Dans mon exemple, la cible tourne sur une station XP limitée en nombre de session simultanée. Ceci ayant pour conséquence l’indisponibilité temporaire du port ciblé.

* testé depuis la machine ayant effectuée le Synflood

2.4 – Réponse de la cible A

Après la réception d’une demande de SYN, la cible renvoi une réponse de type SYNACK en positionnant les flags SYN, ACK à 1 et les 4 autres à 0. Puis, elle attend l’accusé (ACK) finissant l’ouverture de session.

Voici une capture de trame effectuée à l’aide de Sniffer Pro.

* 10.10.101.4 – Correspond à la Cible A

Vous pourrez remarquer que les 11 premières réponses de la cible sont des SYNACK et que les suivantes sont des ACKRST ! De plus, dans cet exemple, on peut s’apercevoir que Windows n’ayant pas eu c’est 11 ACK finalisant les ouvertures de session, réémets ses 11 premiers SYNACK au cas où les trames n’auraient pas aboutis. Cela relève purement du fonctionnement normal de TCP, du mode connecté apportant la garantie de transfert. Mais cela peut servir dans le cadre d’une attaque spoofée à l’attention d’une seconde cible.

2.5 – Réponse de la cible B

Trois hypothèses en fonction de l’Ip source que vous aurez .

• Le premier cas, correspond à ne pas utiliser l’Ipspoofing et donc de faire correspondre la cible B à l’émetteur originel. Vous recevrez donc alors le SYNACK de la cible A et vous en ferrez ce que vous désirez.
• La seconde hypothèse est de spécifier une IP non attribuée. La réponse de la cible A n’aboutira donc pas et n’engendra donc pas de trafic supplémentaire. La durée en état d’attente d’établissement de session sur la cible sera au maximum. Excepté le cas où un routeur informe la cible A via ICMP du drop du paquet ou de l’Ip non routable.
• La troisième possibilité est de spécifier une correspondance à un Hôte. Alors celui-ci répondra certainement (cela est dépendant de la pile IP) un RST indiquant : « Je ne comprend pas ce que tu veux, je n’ai jamais rien demandé, alors ferme cette demande d’ouverture de session qui n’existe pas ! ». Intéressant, ce point de vue qui génère encore du trafic supplémentaire.

Voici une capture de trame effectuée à l’aide de Sniffer Pro.

* 10.10.101.254 – Correspond à la Cible A
* 10.10.101.4 – Correspond à la Cible B

Vous pourrez remarquer que l’on retrouve bien les trois trames qui sont le SYN spoofé en Ip source 10.10.101.4, la réponse SYNACK de la cible A et le RST de la cible B qui n’a pas émit le SYN.

3 – Les conseils et astuces

• Il n’y a pas d’intérêt à remplir la data de TCP, car la réponse ne la prendra pas en compte et ne figurera pas dans la trame retour. Laissez le champ data vide afin de vous permettre d’économiser de la bande passante pour générer plus de SYN.
• Testez cette attaque avec comme Ip source la cible A ou la 127.0.0.1 ou même 0.0.0.0. Certaine pile Ip n’apprécie pas du tout.
• Une combinaison avec le smurf amplifiera le débit vers la cible A afin de l’engorger. Tester de spécifier comme Ip source le broadcast du réseau cible!
• Un Synflood avec une Ip source aléatoire et changeante à chaque SYN risque de blacklister la planète sur l’IDS qui protège la cible A. Le résultat sera un serveur devenu inaccessible de tous à cause de son défenseur.

4 – Les outils

• SynFlood est un outil spécifique pour l’envoi massif de SYN. De plus, vous pourrez changer l’Ip source à volonté.
• Frameip vous permettra de générer tous type de paquet IP. Ainsi, vous pourrez émettre les SYN à volonté.

5 – La conclusion

Cette méthode à pour but de saturer le nombre de session de la cible. Il peut s’avérer sur certaine pile Ip que le résultat soit le crash du daemon écoutant le port ciblé.

6 – Les vidéos

• 6.1 - Présentation de Synflood en comédie ludique

  Cette vidéo en anglais vous présente de manière très ludique et orginale ce qu'est un Synflood.

  

• 6.2 - Preventing TCP Synflood Attacks

  Cette vidéo en anglais vous présente comment contrer les attaques de type Synflood TCP. This video will take a look at what exactly a syn-flood attack is, how to stop a syn-flood attack at the ASA firewall, and how to implement and test these techniques to verify they work.

  

• 6.3 - Spoofing d'adresse IP

  Cette vidéo présente le concept du spoofing d'adresse IP. A travers cet épisode, vous pourrez comprendre par quels moyens une personne lambda peut voler votre adresse IP en répondant plus rapidement que vous, grâce aux requêtes de type ARP.

  

7 – Suivi du document

Création et suivi de la documentation par _SebF

8 – Discussion autour de l’attaque SynFlood

Vous pouvez poser toutes vos questions, faire part de vos remarques et partager vos expériences à propos de l’ataque SynFlood. Pour cela, n’hésitez pas à laisser un commentaire ci-dessous :