-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Fragment de Paquet TCP

Preface
Dans ce texte, je vais tenté de vous expliqué comment fonctionne 
la fragmentation des paquets TCP, et également comment vous en servir
pour en faire une attaque redoutable contre les firewalls et philtres de paquets.
La fragmentation fonctionne en permettant au datagram créer comme paquet 
simple à être changer en plusieurs petits paquets pour la transmission et ensuite
être réassemblé au host qui les reçoit.

Explication
La fragmentation de paquet est nécessaire car, mis à part le protocole IP, les autres
protocoles physiques ou logiques sont utilisés pour transporté des paquets au travers
des réseaux. Un bon exemple de ce phénomène serait la différence entre un paquet
Ethernet (limité à 1024 bytes) , un paquet ATM (limité à 56 bytes) et les paquet IP 
qui ont une grandeur variable d'à peu près un demi million de bytes.

La seule exception à cette règle est dans le cas d'un datagram marqué, qui ne vas pas 
se fragmenté donc. N'importe quel datagram internet marqué ne vas pas se fragmenté
peu importe la circonstance. Si un datagram internet marqué ne peut pas se rendre à
une destination sans être fragmenté, il vas être perdu.

Le comment de l'attaque
Le mécanisme de fragmentation de paquet fait une attaque qui contourne les Firewalls
Internet, mais la raison du pourquoi que l'attaque fonctionne n'est pas la manière que
la fragmentation est fait, mais plutôt de la manière que les datagrams sont réassemblés.

Les datagrams sont supposés être fragmenté en paquet qui laisse la portion du header du 
paquet intacte, excepté pour la modification du paquet et également le remplissage d'un champ 
de Offset dans le header IP qui indique aux datagrams ou commencer. Dans le 
réassemblement, le 
réassembleur IP créer un paquet temporaire qui contient la partie fragmentée du datagram et 
ajoute les fragments qui arrivent en plaçant leur champ de données au Offset spécifique avant 
que le datagram soit réassemblé. une fois le datagram réassemblé, c'est vu comme si c'était 
arrivé en un seul paquet.

S'accordant à la spécification IP, les paquets fragmentés doivent être rassemblé au host qui les 
reçoient. Ceci veut dire qu'ils ne sont pas supposés être réassemblé à un site intermédiare 
comme un routers ou un firewall. Cette décison fut prise pour éviter le réassemblage et la 
refragmentation dans les réseaux intermédiares.

La manière dont les Firewalls et les routers bloquent les services (comme telnet) ou en 
permetant d'autres (comme le HTTP) est en regardant dans le paquet IP pour déterminer 
quelle port Transfer Control Protocol (TCP) qui est désigné. Si le port 80 est désigné, le 
datagram est destiné pour les services HTTP, ou 23 pour les services Telnet. Dans les datagram 
normal cela fonctionne bien, mais supposons que nous n'avons pas suivit les règles de 
fragmentations du datagram et que l'on as modifier ce dernier, voici ce que ca donnerait et les 
étapes à suivre.

? Créer un paquet initiale qui dira qu'il est le premier paquet d'un datagram de multiple paquet. 
Spécifier le port TCP 80 dans le header TCP pour que ca ressemble à un datagram pour les 
services HTTP, et le firewall va le laisser passer.

? Le firewall laisse passer le paquet pour le host sous attaque et laisse également passer 
quelques fragments de paquets en ordre pour permettre au host de destination de les 
rassembler.

? Un de ces paquets en fragments as un Offset de 0 ce qui cause au réassembleur à 
overwriter la partie initiale du paquet IP. Ceci est la partie du paquet IP qui spécifie le port 
TCP. L'attaquant change la définition du port TCP de son paquet qui était 80 au début pour 
le nouveau port qui est 23 admettons, et viens d'avoir accès au port 23 du host sous attaque 
car le firewall va croire que ce dernier paquet est pour les services HTTP.

The FrHack Crew
Snowcrach