|
SynFlood
par _SebF
1 -
Le concept
2 -
Le
Fonctionnement
2.1 -
Schéma
2.2 -
Envoi du SYN
2.3 -
Réception par la cible A
2.4 -
Réponse de la cible A
2.5 -
Réponse de la cible B
3 -
Les conseils et astuces
4 -
Les liens
5 -
Les outils
6 -
La conclusion
7 - Discussion autour de la
documentation
8 -
Suivi du document
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.
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.
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
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 4.70.04.
2003.09.23 - Capture Synflood - SnifferPro.cap
*
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.
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 4.70.04.
2003.09.23 - Capture
2 Synflood - SnifferPro.cap
*
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.
-
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.
-
L'information de « CERT Coordination Center
»
-
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é.
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é.
Vous pouvez poser toutes vos questions,
vos remarques et vos expériences à propos de l'attaque SynFlood. Pour cela,
rendez-vous sur le
Forum "Sécurité".
Le 30 septembre 2003, par _SebF, création du document.
|