3 A EIS App NE316 TP3 le protocole TFTP 1. Préparation Comme le client TFTP n est pas installé sur le PC, on commence par le télécharger. Pour la suite, nous avons perdu toutes nos traces. Pour les refaire, j ai installé un serveur TFTP sous Windows «TFTPDWIN» et j utilise le client TFTP intégré à la distribution BackTrack 2, le problème du client TFTP sous Windows XP est qu il ne marche pas exactement avec les mêmes commandes. 2. Mode de transfert : Notre client TFTP nous propose 2 modes de transfert : «binaire» ou «netascii». Par défaut c est le mode «NETASCII» qui est configuré. Sur le client, on active «TRACE» pour visualisé ce qui ce passe pendant le transfert. Ensuite pour choisir le mode, d après l aide, on écrit «ASCII» ou «BINARY». On commence par le mode «NETASCII» : Commande passé depuis le client TFTP : tftp> get tata.txt sent RRQ <file=tata.txt, mode=netascii> received DATA <block=1, 298 bytes> TFTP Read Request, File: tata.txt, Transfer type: netascii Puis on passe en mode «OCTET» : tftp> get tata.txt sent RRQ <file=tata.txt, mode=octet> received DATA <block=1, 298 bytes> TFTP Read Request, File: tata.txt, Transfer type: octet On remarque que le mode de transfert apparait dans la requête RRQ (Read Request) avec le nom du fichier à rapatrier. Le mode «NETASCII» est utilisé lorsque l on transfert des fichiers contenant du texte. Le mode «OCTET» est recommandé pour le transfert de fichiers image, car les images sont codées en binaire. Quand on transfert un fichier en «NETASCII», le fichier final est de plus grande taille que si il est transféré en «OCTET», et surtout si c est une image, elle n est plus ouvrable (corrompu).
3. Echanges simples : Comme expliqué précédemment, on utilise «TRACE». Rapatriement d un fichier inexistant : Capture depuis le client TFTP : tftp> get lilalilalou sent RRQ <file=lilalilalou, mode=netascii> received ERROR <code=1, msg=file not found> Error code 1: File not found RRQ : lilalilalou ASCII ERROR Le client envoi une requête RRQ (opcode 1) avec le nom du fichier au serveur, celui-ci retourne un message d erreur (opcode 5) avec le code erreur 1 comme quoi le fichier n a pas été trouvé. En fonction du serveur TFTP, on a remarqué que pour un fichier inexistant, soit le serveur renvoi le code erreur 1, soit le code erreur 0 qui indique d aller lire le message d erreur dans la chaine incluse à la requête. Dépôt d un fichier : Capture depuis le client TFTP : tftp> put test.txt sent WRQ <file=test.txt, mode=netascii> received <block=0> sent DATA <block=1, 140 bytes> received <block=1> WRQ : titi.txt SENT le client envoi une requête d écriture WRQ (opcode 2) au serveur avec le nom du fichier, celui-ci retourne un acknowledge comme quoi il a bien reçu la demande d écriture, ensuite le client envoi 1 bloc de donnée de 140 bytes avec la requête DATA (opcode 3). Pour conclure, le serveur répond qu il a bien reçu le Bloc n 1 et voila transfert est terminé.
Rapatriement du fichier fich1.txt : RRQ : ficher1.txt tftp> get fich1.txt sent RRQ <file=fich1.txt, mode=netascii> received DATA <block=1, 512 bytes> sent <block=1> received DATA <block=2, 512 bytes> sent <block=2> received DATA <block=3, 512 bytes> sent <block=3> received DATA <block=4, 512 bytes> sent <block=4> received DATA <block=5, 174 bytes> DATA 1 block=1, 512 DATA 2 block=2, 512 bytes DATA 3 block=3, 512 bytes DATA 4 block=4, 512 bytes DATA 5 block=5, 174 bytes On remarque que le serveur envoi «fich1.txt» avec 5 blocs DATA, les 4 premiers font 512 octets et le dernier 174, en regardant la taille final de «fich1.txt», elle est égale à la somme des paquets DATA (2222=512+512+512+512+174). Ce que l on ne voit pas sur le client TFTP, c est la requête quand le client a reçu le dernier paquet (capturé avec Wireshark). Rapatriement du fichier fich2.txt : tftp> get fich2.txt sent RRQ <file=fich2.txt, mode=netascii> received DATA <block=1, 512 bytes> sent <block=1> received DATA <block=2, 512 bytes> sent <block=2> received DATA <block=3, 506 bytes> RRQ : ficher2.txt DATA 1 block=1, 512 DATA 2 block=2, 512 DATA 3 block=3, 506 Comme précédemment, le fichier est décomposé en bloc de 512 octets sauf pour le dernier, et il y a un accusé de réception de la part du client pour chaque paquet reçu.
Envoi d un fichier de 5ko : tftp> put toto.txt sent WRQ <file=toto.txt, mode=netascii> received <block=0> sent DATA <block=1, 512 bytes> received <block=1> sent DATA <block=2, 512 bytes> received <block=2> sent DATA <block=3, 512 bytes> received <block=3> sent DATA <block=4, 512 bytes> received <block=4> sent DATA <block=5, 512 bytes> received <block=5> sent DATA <block=6, 512 bytes> received <block=6> sent DATA <block=7, 512 bytes> received <block=7> sent DATA <block=8, 512 bytes> received <block=8> sent DATA <block=9, 512 bytes> received <block=9> sent DATA <block=10, 222 bytes> received <block=10> RRQ : DATA 1 block=1, 512 DATA 2 block=2, 512 DATA 9 block=9, 512 DATA 10 block=10, 222 bytes Comme pour le rapatriement, le client lors de l envoi de fichier décompose celui-ci en plusieurs blocs de 512 octets maximum. Pour chaque bloc, le serveur renvoi un accusé de réception pour le bloc n, qui valide le bloc et permet l envoi du bloc n+1. On peut donc conclure que le protocole TFTP découpe les fichiers à envoyer ou recevoir en blocs de 512 octets maximum sauf pour le dernier qui peut être de 0 octet à 511. Chaque bloc est numéroté à partir de 1, le bloc numéro 0 est apparemment réservé pour la commande. De plus pour chaque bloc reçu, un accusé de réception est émit. Nombre maximum de blocs DATA Si les numéros de bloc sont codés sur 2 octets soit 16 bits, il y a donc 2^16 numéros de bloc. Or on sait que le bloc 0 est réservé pour la 1 requête, il y a donc 2^16-1 = 65535. On peut donc numéroter 65535 blocs DATA. Ensuite un bloc DATA = 512 octets max sauf pour le dernier de 511. Soit 65534*512+511=33553919 octets. Soit 33553919/2^10=32768 Koctets. Soit 33553919/2^20=32 Moctets.
Notre avis sur un fichier > 32Mo : Si on essaye de transférer un fichier supérieur à 32 Mo, le TFTP doit le permettre et lorsque que l on atteindra le 65 535 bloc il recommencera soit à 0 soit à 1 en fonction s il renvoi un paquet de commande. Vérification : Nous avons tenté le rapatriement d un fichier de 50 Mo. Voici le moment où l on atteint le 65535 paquet : On remarque que 65535 paquet fait 512 octets et que le suivant et un bloc DATA avec le numéro 0 et de taille 512 octets également. 4. Echanges avec retransmission On trouve dans l aide 2 paramètres de timeout pour les transmissions, «REXMT» et «TIMEOUT». En testant le script bloque, on remarque que la transmission est bloquée et que le client réémet un certain nombre de fois le bloc avant d arrêter le transfert.
Pour changer les paramètres de retransmissions, il suffit de les écrire suivi du paramètre temps en seconde. En jouant sur les valeurs de «REXMT», on remarque que c est le temps en entre chaque réémission de paquets. Pour le «TIMEOUT», le temps en seconde correspond au temps total de retransmission avant l arrêt du transfert. Avec la commande STATUS, on peut lire que les paramètres par défaut sont : BT ~ # tftp 192.168.0.2 tftp> status Connected to 192.168.0.2. Mode: netascii Verbose: off Tracing: off Literal: off Rexmt-interval: 5 seconds, Max-timeout: 25 seconds On peut conclure que sur un client TFTP, il y a 2 paramètres sur lesquelles on peut jouer, pour régler les retransmissions en cas de rupture de connexion, le temps entre chaque réémission de paquets et le temps total de retransmission. 5. Encapsulation Support Local : Pour nous c est la couche Ethernet, on y retrouve l adresse MAC du destinataire et de la source : Internet : Pour nous c est la couche TCP, on y retrouve l adresse IP de la source et du destinataire :
Datagramme : Ici c est la couche UDP, cette couche indique le port source et le port de destination : On peut remarquer que cette capture est dans le sens Client-> Serveur car le port de destination est le 69 qui est le port standard d un serveur TFTP. TFTP : C est la couche utilisateur, c est par cette couche que nos commande tapées sur le client sont transcris au format TFTP : Ici c est une requête de lecture (avec l Opcode 1) où l on retrouve le nom du fichier à rapatrier et le mode de transfert. Message\Couche ETHERNET TCP UDP TFTP TOTAL (Octets) RRQ 14 20 8 21 63 DATA 14 20 8 512 558 14 20 8 4 46 On peut donc remarquer que les 3 premières couches ont toujours la même taille. Il n y a que la couche TFTP qui varie, en fonction du type de message (RRQ DATA ) et de ce qui est écrit dedans (la longueur du nom de fichier pour RRQ, WRQ, la taille du paquet DATA (0à 512 octets)). Apparemment, il faudrait rajouter 4 octets pour l en-queues Ethernet qui contient le CRC Checksum Allure d un message d écriture ou de lecture. Transfert du fichier fich1.txt : Vers le client (Octets) Vers le serveur (Octets) RRQ 63 DATA 4 x 558 + 220= 2452 5 x 46 = 230 Total 2452 293 Tot Utile 4 x 512 + 174 = 2222 10 Rapport 2222 / 2452 = 90,6% 10 / 293 = 3,4% Rapport final (2222+10)/(2452 + 293) = 81% Pour les octets utiles vers le serveur, nous avons pris uniquement le nom du fichier dans la requête RRQ soit 10 octets (fich1.txt.) Vers le client, les octets utiles sont ceux contenus dans les blocs DATA. Pour le rapatriement d un fichier, le rapport de transmission est d environ 81%.
Les ports utilisés : Quand le client émet vers le serveur, il envoi les messages vers le port 69. On à testé plusieurs reconnexion et c est toujours vers le port 69. Le port 69 est le standard Serveur TFTP. A l inverse du serveur vers le client, le port d échange n est pas fixe. Il est choisit aléatoirement, il change à chaque connexion, mais il reste le même durant le transfert. Nous avons trouvé 32770, 32772, 32774. 6. Conclusion : Le protocole TFTP permet l échange de fichier assez facilement entre un serveur et un client. Ce protocole n est absolument pas sécurisé, aucune identification ni cryptage. Il suffit de connaitre le nom du fichier pour le rapatrier avec une requête de lecture, ou d un uploader un avec une commande d écriture. Le TFTP utilise 4 couches du modèle OSI, UDP pour les ports sources et destination, TCP pour les adresse IP et Ethernet pour les adresses MAC. Les messages TFTP sont de 5 types (lecture, écriture, données, accusée de réception et erreur) reconnaissable par leurs OPCODE (respectivement 1, 2, 3, 4, 5). Pour chaque message, on retrouve des informations complémentaires (numéro de paquet, les données, le code erreur, les noms de fichiers, les modes de transfert). Il a été très instructif de décrypter les paquets transmis, on a pu reconnaitre les différentes couches.