Vous êtes ici : Accueil > > Papers > > Notions de TCP/IP Page précédente ;
Papers
Autour du hacking
Articles techniques
Team SoH
Flux RSS
RSS Actualités
;
;
;
Introduction aux réseaux TCP/IP
Par BeRgA
Table des matières
- I - Introduction ;
- II - Modèles en couches ;
- III - Encapsulation ;
- IV - Protocole IP ;
- V - Protocole ARP ;
- VI - Protocole TCP ;
- VII - Protocole UDP ;
- VIII - Faiblesses du modèle TCP/IP ;
I Introduction
Un réseau informatique est un groupement de machines, reliées entre elles, directement ou non, et capable de communiquer, de s'échanger des données. Mais comme tout groupement, ces actions nécessitent la possiblité de pouvoir s'identifier (pour savoir quand une machine s'adresse à nous), de pouvoir identifier les autres membres du réseaux (pour savoir à qui on s'adresse), et de posséder un langage commun. Ce langage doit être compris et parlé par n'importe qu'elle machine présente sur le réseau.
Pour permettre le développement des réseaux informatiques, il a donc été nécessaire de mettre en place des protocoles d'échanges standard, des normes, afin que toute communication soit possible, et de les normaliser par écrit, afin que chaque développeur puisse faire en sorte que le fruit de son travail puisse communiquer. C'est ainsi qu'est né le modèle de référence OSIRM (pour Open System Interconnection Reference Model). Ce modèle est composé de sept couches virtuelles, permettant de classer et d'organiser chacun des protocoles du modèle. Nous reviendrons plus en détail sur ce modèle ultérieurement.
I..1 Standards matériels
Le principe d'une communication est simple : il s'agit de transmettre des données à l'aide d'un support. Par exemple, les communications orales transmettent vos pensées en utilisant les molécules présentes dans l'air, les communication écrites reposent sur du papier, et il en est de même pour tout type de communication. Dans un ordinateur, toutes les données sont codées physiquement à l'aide de deux états logiques d'un signal : 0 et 1. C'est ce qu'on appelle le langage binaire.
Pour mettre en place un système de communications entres machines, il a donc tout d'abord fallu développer des supports capables de transformer les données binaires à transmettre en un signal apte à se transmettre au sein du réseau. Les transmissions sont la plupart du temp permises par des supports tels que des ondes hertziennes, des fibres optiques, des câbles. Les adaptateur permettant la traduction données signal (en émission) et signal/données (en réception) sont le plus souvent des cartes Ethernet, dont les débits varient généralement entre 10Mb/s et 100Mb/s.
Le problème du support étant reglé, il a ensuite fallu que chaque carte puisse identifier les autres, pour transmettre les signaux à la bonne machine. Pour ça, on dote chaque carte d'un identifiant unique, appelée adresse MAC (pour Media Access Control). Cet identifiant est codé sur 6 octets, les trois premiers designant le constructeur. Cette adresse est le plus souvent representée en hexadécimal, chaque octet étant séparé par ":". Ainsi, une adresse MAC qui commence par 00:0a:24 désigne une carte fabriquée par 3COM.
Ceci achève de régler le problème de la transmission physique des données.
I..2 Standards logiciels
Maintenant que l'on est capable de transmettre physiquement des données d'une machine à une autre, il reste à développer une partie logicielle pour assurer un correct transport des données. Sans elle, la machine émettrice ne sait rien de ce qu'il advient des données émises, et la machine réceptrice ne peut savoir si elle a reçu l'intégralité de ces dernières, ou juste une partie, si elles ont été altérées durant le transport, etc...
La base des communications OSI est le fait que les données sont transmises par paquets, ou datagrammes, qui sont émis un par un en direction de la machine réceptrice. Cela permet un meilleur suivi des données, et un meilleur rapport qualité/rapidité. Nous reviendrons également sur ce système plus loin.
Pour assurer la fiabilité des transmissions, deux protocoles ont été développés :
- TCP (pour Transmission Control Protocol)
- UDP (pour User Datagram Protocol).
Ces deux protocoles de la couche transport du modèle OSI servent à parer les problèmes de fiabilité de transmission et de rapidité. TCP met l'accent sur la fiabilité, en assurant une ouverture de connexion en trois temps, en numérotant les paquets émis, et en réémettant les paquets non reçus. UDP quant à lui met l'accent sur la rapidité, en envoyant les paquets sans contrôle, ce qui fait de lui un protocole moins lourd que TCP.
Des modèles ont été développés pour permettre à chacun de faire communiquer son système avec d'autres. Les normes qui les régissent sont disponibles dans le monde entier, et chacun peut y avoir accès librement. Nous avons vu que le modèle OSI est composé de 7 couches. TCP/IP est basé sur le modèle OSI, mais n'en utilise pas les septs couches, ce qui fait de lui un modèle moins lourd à implémenter. Voilà un schéma représentant ces deux modèles :
- Modèle OSI
- Application : Services application (API)
- Présentation : Représentation des données
- Session : Service de session, point de synchro et gestion d'activité
- Transport : Intégrité des données de bout en bout
- Réseau : Informations de routage et d'aiguillage
- Liaison : Transmets l'information par groupe de bits
- Physique : Transmisssion de flots de bits sur le support
- Modèle TCP/IP
- Couche des services applications
- TCP : Couches de transport
- IP : Couche réseau
- Couche sous réseau : Couche d'accès au réseau (Ethernet, Token Ring...) (cuivre optique)
II Modèles en couches
Le principe des couches est simple :
- Chaque couche regroupe des protocoles de même ordre (qui gère les mêmes fonctionnalités : transmission, physique, etc...)
- Chaque couche est totalement indépendante des couches supérieures et inférieures.
- Chaque couche ne peut transmettre les paquets qu'à la couche inférieure (en émission) ou supérieure (en réception), à l'aide de ce qu'on appelle des SDU (Service Data Unit)
- Une couche ne peut envoyer des informations à une machine distante que vers une couche de même niveau. Ces échanges sont appelés PDU (Protocol Data Unit).
- Chacune des couches peut utiliser plusieurs protocoles, s'ils y appartiennent (par exemple, la couche transport peut utiliser TCP ou UDP), en fonction du type de transmission recherchée.
- La mise en place du protocole est effectuée par une entité protocolaire
III Encapsulation
Lorsqu'une information est émise par une couche, elle doit accéder à la couche physique pour pouvoir être envoyée sur le réseau. Elle doit donc pour cela traverser chacune des couches qui la sépare de la couche physique. Mais chaque couche doit ajouter ses informations aux paquets afin de permettre au destinataire de les faire remonter correctement, en suivant les bons protocoles. Elle y ajoute aussi les informations propres au protocole suivi, adresses, CRC, et informations diverses.
Ces informations sont ajoutées dans des entêtes, ajoutées au début du paquet. L'ajout successif des entêtes par chaque couche traversée est appelé encapsulation.
Lorsque le paquet arrive à son destinataire, il remonte les couches une part une, et chacune récupère les informations contenues dans l'entête la concernant, et retire cette dernière. Le paquet arrive donc à la couche visée dans le même état que celui dans lequel il a été émis.
Voici un petit schéma illustrant l'encapsulation d'un paquet émis par la couche applicative d'une machine :
IV Protocole IP
Le protocole IP est un protocole de la couche réseau (niveau 3). Sur internet, c'est lui qui gère l'adresse des machines (les fameuses adresses IP) permettant à un paquet de savoir où il va. Une entête IP est de cette forme (la largeur du tableau ci-dessous représente 32 bits) :
Voici le détail des différents champs de l'entête :
- Version (4bits) : Ce champ nous renseigne sur le format de l'entête IP, donc la version du protocole. Actuellement, la version la plus utilisée est l'IPv4, mais l'IPv6 commence à être utilisée, et sera le standard de demain.
- Type de Service (8bits) : Ce paramètre reste "abstrait". Il peut être utilisé pour "guider" les datagrammes transitant dans des réseau particulier.
- Longueur Totale (16bits) : Indique la longueur totale du datagramme, en comptant toutes les entêtes et les données.
- Identification (16bits) : L'émetteur assigne à chacun des paquets un numéro d'identification pour permettre au récépteur, qui les recevra dans le désordre, de les réordonner.
- Flags (3bits) : 3 bits donnant certaines informations : Bit 0 : réservé, doit être laissé à 0 Bit 1 (AF): 0=fragmentation possible 1=non fractionnable Bit 2 (DF) : 0=dernier fragment 1=fragment intermédiaire
- Fragment Offset (13bits) : Ce champ indique la position du premier octet de donnée par rapport au début du datagramme entier, pour isoler les entêtes des données. Cette position relative est mesurée en blocs de 8 octets (64bits). Le décalage du premier fragment vaut zéro.
- Durée de vie (Time To Live, 8bits) : Ce champ permet d'éviter une saturation du réseau. Chaque routeur ou autre module de traitement doit retirer au moins une unité à ce champ lorsqu'il traite le datagramme. Si ce champ prend la valeur zéro, le datagramme doit être détruit. Ainsi, les paquets qui ne peuvent atteindre leur destinataire sont détruits et n'encombrent pas le réseau.
- Protocole (8bits) : Ce champ indique quel protocole de niveau supérieur a été, ou sera, utilisé pour traiter le paquet après son passage à travers la couche réseau. Les différentes valeurs admises pour divers protocoles sont listées dans la RFC "Assigned Numbers" rfc 1060 => http://www.faqs.org/rfcs/rfc1060.html. br>
- CheckSum d'entête (16bits) : Un checksum calculé uniquement sur l'entête.
- Adresse source (32bits) : l'adresse IP de l'expéditeur
- Adresse destination (32bits) :l'adresse internet du destinataire
- Un sniffeur réseau, comme Ethereal par exemple, permet de voir les valeurs de tous ces champs :
V Protocole ARP
Nous venons de voir que dans un datagramme, l'adresse IP du destinataire n'est stipulée que dans l'entête IP. Par conséquent, chaque machine par laquelle va passer le paquet (routeurs par exemple) sera obligée de le faire remonter jusqu'au niveau 3, pour être capable de savoir si le paquet lui est adressé, et si non, de savoir vers qui le transmettre. Ca fait beaucoup de ressources et de temps perdus, non ? Il a donc fallu développer un protocole capable de traiter cette information sur la couche la plus basse, à savoir la couche physique.
Comment ?
Les seules adresses dont dispose cette couche étant les adresse MAC, il a donc fallu se baser dessus. C'est ainsi qu'est né le protocole ARP (pour Adress Resolution Protocol). Avant tout dialogue entre deux machines, ce protocole va se charger de trouver l'adresse physique de la machine destinataire, et va lui faire correspondre son adresse IP. De cette façon, à chaque passage à travers un routeur, ou autre module de traitement, le datagramme n'aura pas besoin de remonter au niveau 3.
Comment fonctionne-t-il ?
Supposons que la machine d'adresse IP 192.168.0.1 cherche à se connecter à 192.168.0.212. Elle va alors broadcaster (diffuser à l'ensemble du réseau) une requête ARP de cette forme :
- Station 192.168.0.1 d'adresse matérielle xx:xx:xx:xx:xx:xx cherche l'adresse matérielle de la staiton 192.168.0.212
Toutes les stations présentes sur le réseau où la requête a été diffusée vont alors la recevoir, mais seule 192.168.0.212 va y répondre, en renvoyant le message suivant en direction de 192.168.0.1 :
- Station 192.168.0.212 a pour adresse matérielle yy:yy:yy:yy:yy:yy
Les deux stations vont alors stocker le couple IP/MAC de l'autre machine dans leur cache ARP, et seront à même de faire transitant leurs paquets d'une machine à l'autre plus rapidement. Le couple stocké restera dans le cache pendant un intervalle de temps donné, pour ne pas avoir à réitérer la demande en cas d'une nouvelle connexion.
VI Protocole TCP
TCP (pour Transfert Control Protocol) est un protocole de niveau 4 (transport), qui permet un contrôle de la qualité de la communication entre deux machines : établissement en trois temps, numérotation des paquets, et réémission des paquets non reçus. Tout comme pour le protocole IP, un paquet qui traverse la couche transport en s'appuyant sur TCP se verra doté d'une entête spécifique, de cette forme :
- Port source (16bits) :
- Le numéro de port de l'émetteur
- Port destinataire (16bits) :
- numéro de port du destinataire
- Numéro de séquence (32bits) :
- Lors de l'établissement d'une connexion, TCP utilise un système de numérotation pour identifier l'ordre des paquets émis, ceux-ci arrivant dans le désordre au récepteur. Ce champ indique ce numéro, appelé numéro de séquence.
- Accusé de réception (32bits) :
- Si le flag ACK est activé, ce champ indique le numéro de séquence du prochain octet que le récepteur s'attend à recevoir.
- Réservé (6bits) : Réservé pour usage futur, ce champ doit toujours rester à 0 Flags (6bits) :
- URG : Pointeur de données urgentes significatives
- ACK : Accusé de réception significatif
- PSH : fonction Push
- RST : réinitialisation de la connexion
- SYN : Synchronisation des numéros de séquence.
- FIN : fin de transmission
- Fenêtre (16bits) :
- Le nombre d'octets maximal à partir de la position marqué dans l'accusé de réception que le récepteur est capable de recevoir
- Pointeur de données urgentes (16bits) :
- Si le datagramme contient une donnée urgente (qui doit être traitée en priorité), ce champ indique leur position en donnant son décalage par rapport au numéro de séquence. Si le flag URG est activé, ce champ n'est pas interprêté.
- Options (variable) :
- Les champs d'options peuvent occuper un espace de taille variable à la fin de l'entête TCP. Ils formeront toujours un multiple de 8bits. Toutes les options sont prises en compte par le checksum. Un paramètre d'option commence toujours sur un nouvel octet. Il est défini deux formats pour les options :
- - Cas 1 : option monooctet,
- - Cas 2 : octet de type d'option, octet de longueur d'option, octet de valeur d'option. La longueur d'option prend en compte l'octet de type, l'octet de longueur luimême et tous les octets de valeurs et est exprimée en octet.
Notez que la liste d'option peut être plus courte que ce que l'offset de données pourrait le faire supposer. Un octet de remplissage (padding) devra être, dans ce cas, rajouté après le code de fond d'option. Cet octet est nécessairement à 0. TCP doit implémenter toutes les options.
- Donnée d'option :
- Taille maximal de segment :
- 16bits. Si cette option est présente, elle communique à l'émetteur la taille maximale des segments qu'il pourra envoyer. Ce champ doit être envoyé dans la requête de connexion initiale (avec SYN activé). Si cette option est absente, le segment pourra être pris de n'importe qu'elle taille
- Bourrage (padding) :
- La taille de l'entête TCP doit toujours être multiple de 4 (en octets, soit 32bits). Les octets de bourrage servent donc à augmenter la taille du paquet pour réaliser ceci :
Pour assurer un transport correct des données, TCP doit s'assurer une transmission fiable, acceptée par l'émetteur et le récepteur. C'est pour cela que l'établissement d'une connexion TCP se fait en trois temps. On l'appelle "Three Way Handshake Connection". Bien entendu, ce système n'est pas totalement fiable, et est contournable grâce à certaines techniques utilisées pour les attaques par Spoofing d'IP. Mais bon, ne sortons pas du sujet.
En quoi consiste cette connexion ?
Eh bien, nous avons vu que TCP numérote chaque paquet, pour permettre au destinataire de les remettre dans l'ordre après réception. Cela nécessite donc une synchronisation des numéros de séquence avant leur envoi. C'est en partie à cela que sert la connexion trois temps. Mais elle permet aussi tout simplement de demander l'accord du destinataire avant l'établissement.
Petit schéma explicatif :
- En résumé, si A cherche à se connecter à B, l'établissement de la connexion se passe ainsi :
- - A envoie un paquet avec le flag SYN activé vers B ("Estce que je peux établir une connexion?")
- - B renvoie vers A un paquet avec les flags ACK ("Oui, tu peux établir une connexion") et SYN ("Estce que je peux établir une connexion?") activés.
- - A répond au SYN de B en renvoyant un paquet avec le flag ACK ("Oui, tu peux établir une connexion") activé.
Après l'envoi du paquet SYN/ACK, B va placer la connexion en attente dans son stack TCP/IP, où elle restera jusqu'à réception du ACK de confirmation. Dans le cas où B refuse la connexion, il répondra au premier SYN par un paquet avec le flag RST activé.
VII Protocole UDP
UDP (pour User Datagram Protocol) est beaucoup moins fiable que TCP, dans le sens où il ne contrôle absolument pas la réception des paquets, et n'assure pas non plus leur numérotation. Mais cela fait de lui un protocole beaucoup plus rapide, et beaucoup plus léger que son confrère, ce qui avantage son utilisation dans certains cas (les jeux par exemple). L'entête UDP est également très simplifiée :
VIII Faiblesses du modèle TCP/IP
Eh oui, bien entendu, le modèle TCP/IP que nous venons de détailler présente quelques faiblesses.
Tout d'abord, actuellement, aucune vérification n'est faite sur l'adresse IP de l'émetteur d'un paquet. Un paquet dont cette adresse aura été modifiée sera traité, même si l'adresse présentée n'est pas active au moment de la réception. Cela ouvre la porte à certaines méthode d'usurpation.
Il n'est pas non plus possible de contrôler le chemin qui sera emprunté par les paquets que l'on envoie. Cette faiblesse, due à l'organisation du réseau Internet, permet des attaques du type ManInTheMidlle.
Une autre faiblesse vient du fait que les connexions en attente sont stockées dans un stack, de taille finie. Une machine ne peut donc gérer qu'un nombre précis de connexions, au delà, déconnexion, incapacité de répondre aux demandes, etc.
Lire ou télécharger le document au format pdf, poids 665 ko : Introduction aux réseaux TCP/IP ;
BeRgA
Page précédente | Accueil | Allez Up ! ;