I Notions Réseaux

 

Un réseau informatique est un groupement de machines, reliées entre elles, directement ou non, est 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 OSI-RM (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.


 
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 temps 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 Controm). 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 donées.

 
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) et 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.


II Les modèles OSI et TCP/IP

 
Ces 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.
1°) Système en couches
Le principe des couches est simple :
-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.
-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)

2°) Encapsulation

 
Les données émises le sont la plupart du temps par la couche application, la plus haute dans le modèle. Avant d'être émis sur le réseau par la couhce physique, chaque paquet va donc traverser chacune des couches intermédiaires, qui ajoutera une en-tête au paquet, correspondant au protocole utilisé. A la réception, chaque couche retirera son en-tête, et transmettra le paquet à la couche supérieure.
 
3°) Protocole IP

 
Le protocole IP (pour Internet Protocol) est un protocole de la couche réseau (niveau 3). C'est lui qui va permettre d'identifier les machines émetrices et réceptrices, grâce au système d'adressage IP (voir l'article dédié pour plus de détails). En traversant la couche réseau, les paquets vont donc recevoir une entête IP.
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 fractionnabme
 
- 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'en-tê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
 
          4°) 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 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 falu 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, à chque 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 staion 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.
5°) 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é-émissions 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.
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 reception (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) : Reservé 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 connection
 
-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 reception que le recepteur 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 chacksum. Un paramètre d'option commence toujours sur un nouvel octet. Il est défini deux formats pour les options : -Cas 1 : option mono-octet, -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 lui-mê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 comunique à l'émetteur la taille maximale des segments qu'il pourra envoyer. Ce champ doit être envoyé dans la requête de connection 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 augmenter la taille du paquet pour réaliser ceci.
 
Un des aspects les plus intéressants de TCP est certainement l'établissement d'une connexion en trois temps, ou "Three Way Handshake Connection". C'esdt en effet elle qui est à l'origine d'attaques comme le spoofing d'IP, par exemple. 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.
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 ("Est-ce que je peux établir une connexion?")
 
B renvoie vers A un paquet avec les flags ACK ("Oui, tu peux établir une connexion") et SYN ("Est-ce 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'envoie 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é.
6°) Protocole UDP

 
UDP (pour Use 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 celà fait de lui un protocole beaucoup plus rapide, et beaucoup plus léger que son confrère.
 
7°) 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.
Un autre faiblesse vient du fait que les connexions en attente sont stockés dans un stack, de taille finie. Une machine ne peut donc gérer qu'un nombre précis de connexions, au delà, deconnexion, incapacité de répondre aux demandes, etc..

Tout droit réservés BeRgA