Didacticiel sur Iptables, version 1.2.0

Comme déja établi, TCP/IP est multi-couches. Ceci indique que nous avons une fonctionnalité sur un niveau, et une autre à un autre niveau, etc. La raison pour laquelle nous avons toutes ces couches est très simple.

La raison principale est que l'architecture globale est très extensible. Nous pouvons ajouter de nouvelles fonctionnalités aux couches application, par exemple, sans avoir a réimplémenter l'ensemble du code TCP/IP, ou inclure une pile TCP/IP complète dans l'application. Ainsi il est inutile de réécrire chaque programme chaque fois que nous installons une nouvelle carte d'interface réseau.

Quand nous parlons de code TCP/IP lequel est intégré dans le noyau, nous parlons souvent de pile TCP/IP. La pile TCP/IP indique toutes les sous-couches utilisées, depuis la couche réseau jusqu'à la couche application.

Il existe deux architectures de base lorsque nous parlons de couches. Une des deux est le modèle OSI (Open System Interconnect) et consiste en 7 couches. Nous les verrons superficiellement ici, nous nous intéressons plus particulièrement aux couches TCP/IP. Cependant, sur un plan historique il est intéressant de le connaître, en particulier si vous travaillez avec plusieurs types de réseaux différents. Voir la liste dans le OSI Reference Model.

1. Couche Application
2. Couche Présentation
3. Couche Session
4. Couche Transport
5. Couche Réseau
6. Couche Liaison
7. Couche Physique

Un paquet que nous envoyons, parcourt du sommet à la base cette liste, chaque couche ajoutant ses propres en-têtes au paquet, ce que nous appelons la phase d'encapsulation. Lorsque le paquet rejoint sa destination il parcourt en sens inverse la liste et les en-têtes sont supprimés du paquet, un à un, chaque en-tête donnant à l'hôte de destination toute l'information nécessaire jusqu'à ce que le paquet joigne l'application ou le programme pour lequel il était destiné.

Le second et plus intéressant standard est le protocole TCP/IP, comme indiqué dans la liste TCP/IP architecture. Il n'y a pas d'accord universel en ce qui concerne le nombre de couches dans l'architecture TCP/IP. Cependant, on considère généralement qu'il y a de 3 à 5 couches disponibles, nous en verrons 4 pour simplifier.

1. Couche Application
2. Couche Transport
3. Couche Internet
4. Couche Réseau

Comme vous pouvez le voir, l'architecture du protocole TCP/IP est très proche du modèle OSI. De même qu'avec le modèle OSI, nous ajoutons et soustrayons les en-têtes pour chaque couche.

Par exemple, utilisons une des analogies les plus communes pour les machines modernes en réseau, la lettre par courrier postal. Chaque chose est effectuée par étape, identique en TCP/IP.

Vous désirez envoyer une lettre à quelqu'un en lui demandant comment il va, et qu'est-ce qu'il fait. Pour celà, vous devez poser des questions. Les questions seront situées à l'intérieur de la couche Application.

Après ceci vous écrirez les questions sur une feuille de papier que vous mettrez dans une enveloppe sur laquelle vous écrirez l'adresse de destination. Peut-être quelque chose comme :

Attn: John Doe

C'est l'équivalent de la couche Transport en TCP/IP.

À ce niveau nous écrivons l'adresse sur l'enveloppe, comme ceci :

V. Andersgardsgatan 2

41715 Gothenburg

Ça se passe dans l'analogie comme dans la couche Internet. La couche Internet contient les informations indiquant comment joindre le destinataire, ou l'hôte, dans un réseau TCP/IP. De la même façon qu'une enveloppe avec une adresse.

L'étape finale est de poster l'enveloppe dans une boîte aux lettres. Ce qui équivaut à peu près à envoyer un paquet dans la couche Réseau. La couche Réseau contient les fonctions et les routines pour accéder au réseau physique par lequel le paquet sera transporté.

Quand finalement nous recevons la lettre, nous la retirerons de l'enveloppe (décapsulation). La lettre que nous recevons peut parfois demander une réponse ou non. Dans certains cas il peut y avoir une réponse du destinataire, alors le destinataire devient expéditeur, et l'expéditeur devient destinataire.

Il est très important de comprendre que Iptables est spécifiquement construit pour travailler à l'intérieur des en-têtes des couches Internet et Transport. Il est possible de créer quelques filtres très basiques avec Iptables dans les couches Application et Réseau, mais il n'a pas été conçu pour cela, ni approprié.

Par exemple, si nous utilisons une correspondance de chaîne et l'apparions pour une chaîne spécifique dans le paquet, disons get /index.html. Ceci fonctionnera ? Normalement oui. Cependant, si la taille du paquet est très petite, cela ne marchera pas. La raison en est que Iptables est construit pour fonctionner sur une base par paquet, qui indique que si la chaîne est divisée en plusieurs paquets séparés, Iptables ne verra pas l'ensemble de la chaîne. Pour cette raison, il est mieux d'utiliser un proxy pour filtrer au niveau de la couche Application. Nous verrons ces problèmes en détail plus tard dans Introduction au filtrage IP.

Étant donné que Iptables et Netfilter opèrent principalement sur les couches Internet et Transport, ce sont les couches sur lesquelles nous insisterons le plus dans ce chapitre. Sous la couche Internet, nous verrons presque exclusivement le protocole IP. Il existe quelques ajouts à ceci, comme, par exemple, le protocole GRE, mais ils sont très rares. À cause de tous ces facteurs nous nous concentrerons sur le protocole IP de la couche Internet, et TCP, UDP, ICMP de la couche Transport.

Le protocole ICMP est actuellement une sorte de mélange entre les deux couches. Il fonctionne dans la couche Internet, mais il possède exactement les mêmes en-têtes que le protocole IP, mais aussi quelques en-têtes supplémentaires. Nous verrons ceci plus en détail plus loin dans Caractéristiques ICMP.

Le protocole IP résides dans la couche Internet, comme nous l'avons déjà dit. Le protocole IP est le protocole dans la pile TCP/IP qui permet à votre machine, routeur, switch, etc. de savoir où un paquet spécifique est envoyé. Ce protocole est véritablement le coeur de toute la pile TCP/IP, et la base de tout sur Internet.

Le protocole IP encapsule le paquet de la couche Transport avec l'information du procole de la couche Transport, ainsi que d'autres informations utiles. Tout ceci, bien sûr, très précisément standardisé. Nous allons en parler dans ce chapitre.

Le protocole IP possède un couple de fonctionnalités de base qu'il doit être capable de traiter. Il doit être capable de définir le datagramme, lequel est le bloc de construction suivant créé par la couche Transport (ce qui en d'autres termes peut être TCP, UDP ou ICMP par esemple). Le Protocole IP définit aussi le système d'adressage Internet que nous utilisons aujourd'hui. Ceci indique que le protocole IP définit comment les hôtes peuvent se joindre entre eux, il indique aussi comment nous pouvons router les paquets, bien sûr. Les adresses dont nous parlons sont généralement appelées adresses IP. Usuellement, quand nous parlons d'adresses IP, nous parlons de chiffres avec des points (ex. 127.0.0.1). C'est principalement pour rendre l'adresse IP plus lisible pour l'oeil humain, car l'adresse IP est actuellement un champ de 32 bits de 1 et de 0 (127.0.0.1 pourrait désormais être lu comme 01111111000000000000000000000001 dans l'en-tête IP).

Le protocole IP doit aussi pouvoir décapsuler et encapsuler le datagramme IP (donnée IP) et envoyer ou recevoir le datagramme d'une couche Réseau, ou d'une couche Transport. Ceci peut sembler évident, mais parfois ce ne l'est pas. Au sommet de tout ça, il possède deux fonctions qu'il doit exécuter correctement, ce qui est particulièrement intéressant pour le pare-feu et le routage. Le protocole IP est responsable du routage des paquets depuis un hôte vers un autre. La plupart du temps sur des réseaux uniques, c'est un processus simple. Nous avons deux options différentes, soit le paquet est destiné au réseau local, soit passe par une passerelle. Mais lorsque vous commencez à travailler avec des pare-feux et des politiques de sécurité conjointement avec de multiples interfaces réseau et différentes routes, ce peut être casse-tête pour les administrateurs. La dernière des responsabilités du protocole IP est qu'il doit fragmenter et ré-assembler les datagrammes qui ont préalablement été fragmentés, ou qui nécessitent d'être fragmentés pour s'adapter à la taille du paquet pour la topologie du réseau où nous sommes connectés. Si ces fragments de paquet sont suffisamment petits, ils peuvent causer d'horribles maux de tête aux administrateurs réseau. Le problème est, qu'une fois qu'ils sont fragmentés, nous commençons à avoir des soucis pour lire même les en-têtes du paquet.

Dans les séries 2.4 du noyau Linux, et Iptables, ceci ne représente pas un problème pour la plupart des pare-feux Linux. Le système de traçage de connexion utilisé par Iptables pour la vérification d'état, la traduction d'adresse, etc. doit être capable de lire les paquets défragmentés. À cause de ça, conntrack défragmente automatiquement tous les paquets avant qu'ils rejoignent la structure netfilter/iptables dans le noyau.

Le protocole IP est aussi un protocole en mode datagramme, ce qui indique que IP ne "négocie" pas une connexion. Un protocole orienté-connexion, en d'autres termes, négocie une "connexion" (appelée poignée de main) et lorsque toutes les données ont été envoyées, stoppe la connexion. TCP est un exemple de ce genre de protocole, cependant, il est implémenté au sommet du protocole IP. Il y a plusieurs raisons pour lesquelles il n'est pas orienté-connexion, mais parmi d'autres, une poignée de main n'est pas nécessaire à ce moment ce qui ne ferait qu'ajouter du temps système. Comme vous pouvez le voir, envoyer une requête et ensuite attendre un moment pour la réponse est préférable à envoyer un paquet pour dire que nous voulons établir une connexion, ensuite recevoir le réponse nous disant que la connexion est ouverte, et finalement accuser réception que nous sommes au courant que la connexion est ouverte, et alors envoyer la requête, et après renvoyer un autre paquet pour couper la connexion et attendre une autre réponse.

IP est également connu comme un protocole incertain, c'est à dire, il ne permet pas de savoir si un paquet a été reçu ou non. Il reçoit simplement un paquet depuis la couche transport et le passe à la couche réseau, et ne fait rien de plus. il peut recevoir un paquet en retour, lequel passe de la couche réseau au protocole IP et ensuite à la couche transport. Cependant, il ne vérifie pas si c'est un paquet en réponse ou si le paquet a été reçu dans un autre but. La même chose s'applique en terme d'incertitude IP comme pour le mode datagramme, ce qui nécessitera l'envoi d'un paquet supplémentaire en retour pour chaque paquet envoyé. Par exemple, considérons une consultation de table DNS. Nous envoyons une requête DNS au serveur de nom. Si nous ne recevons pas de réponse, nous savons que quelque chose ne fonctionne pas et renvoyons une requête de consultation, mais dans l'usage normal nous envoyons une requête et obtenons une réponse en retour. Ajouter de la fiabilité à ce protocole signifierait que la requête nécessite deux paquets (une requête et une confirmation que le paquet a été reçu) et ensuite deux paquets pour la réponse (une réponse et un accusé-réception comme quoi le paquet a été reçu). En d'autres termes, nous doublons le nombre de paquets nécessaires, et bien sûr doublons le nombre de données à transmettre.

Comme vous avez pû le comprendre dans l'introduction sur le protocole IP, un paquet IP contient différentes parties dans l'en-tête. Celui-ci est méticuleusement divisé en plusieurs parties, et chaque partie de l'en-tête est aussi petite que possible pour faire ce travail, ceci pour limiter le temps système au minimum. Vous verrez la configuration exacte d'une en-tête IP dans l'image En-têtes IP.

Comprenez que les explications des différents en-têtes sont très brèves et que nous ne parlerons que des bases de ceux-ci. Pour chaque type d'en-tête dont nous parlons, nous indiquerons aussi sa RFC correspondante que vous devriez lire pour une meilleure compréhension et des explications techniques du protocole en question. En note marginale, les RFC (Request For Comments), ont aujourd'hui une signification totalement différente dans la communauté Internet. Elles définissent et standardisent l'ensemble de l'Internet, par rapport à ce pourquoi elles ont été écrites à l'origine. Au départ, il ne s'agissait que de simples RFC dont le but était de poser des questions pour avoir l'avis des autres chercheurs.

Le protocole IP est décrit principalement dans RFC 791 - Internet Protocol. Cependant, cette RFC est aussi mise à jour par la RFC 1349 - Type of Service in the Internet Protocol Suite, rendue obsolète par RFC 2474 - Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers, mise à jour par RFC 3168 - The Addition of Explicit Congestion Notification (ECN) to IP et RFC 3260 - New Terminology and Clarifications for Diffserv.

Comme vous pouvez le voir, tous ces standards peuvent être un peu difficiles à suivre. Un tuyau pour trouver les différentes RFC est d'utiliser les fonctions recherche disponibles sur RFC-editor.org. Dans le cas de IP, considérez que la RFC 791 est la RFC de base, toutes les autres sont simplement des mises à jour par rapport au standard. Nous parlerons de ceci plus en détail quand nous verrons les en-têtes spécifiques modifiés par ces nouvelles RFC.

Une chose à retenir est que, quelquefois, une RFC peut être obsolète (plus utilisée du tout). Normalement ceci signifie que la RFC a été si rigoureusement mise à jour, qu'il est mieux de tout revoir. Elle peut aussi devenir obsolète pour d'autres raisons. Quand une RFC devient obsolète, un champ est ajouté à la RFC d'origine qui pointe vers la nouvelle.

Version - bits 0-3. C'est le numéro de version du protocole IP en binaire. IPv4 est nommé par 0100, tandis que IPv6 par 0110. Ce champ n'est généralement pas très utilisé pour le filtrage. La version décrite dans la RFC 791 est IPv4.

IHL (Longueur d'en-tête Internet) - bits 4-7. Ce champ nous indique la longueur de l'en-tête IP en 32 bits. Comme vous pouvez le voir, nous avons partagé l'en-tête (32 bits par ligne) dans l'image. Le champ Options est de longueur variable, ainsi nous ne pouvons jamais être absolument sûrs de la longueur totale de l'en-tête sans ce champ.

Type de Service, DSCP, ECN - bits 8-15. C'est une des zones les plus complexes de l'en-tête IP pour la simple raison qu'elle a été mise à jour 3 fois. Elle a toujours eu la même utilisation de base, mais l'implémentation a changé plusieurs fois. En premier le champ fut appelé Type de Service. Le Bit 0-2 du champ fut appelé champ Précédence. Le Bit était de délai normal/bas, le Bit 4 de débit normal/haut, le Bit 5 de fiabilité normale/haute et le Bit 6-7 réservé pour un usage futur. Ceci est toujours en usage sur de nombreux sites qui ont du matériel ancien, ce qui cause toujours certains problèmes pour l'Internet. Parmi d'autres choses, le Bit 6-7 est spécifié pour être placé à 0. Dans les mises à jour ECN (RFC, nous partons du principe que ces bits réservés sont désormais placés à la valeur 0. Mais nombre de pare-feux et routeurs ont été programmés pour vérifier si ces bits sont placés à 1, et si les paquets le sont, le paquet est supprimé. Aujourd'hui, c'est clairement une violation de la RFC, mais vous ne pouvez pas faire grand chose, excepté vous plaindre.

La seconde itération fut lorsque le champ a été modifié dans le champ DS comme spécifié dans la RFC 2474. DS pour Differentiated Services. Selon ce standard les bits 8-14 sont Differentiated Services Code Point (DSCP) et les deux bits restants (15-16) sont toujours inutilisés. Le champ DSCP est à peu près utilisé comme le champ ToS avant, pour marquer pour quel type de service ce paquet serait traité comme si le routeur en question ne faisait pas de différence entre eux. Un gros changement est que le matériel doit ignorer les bits inutilisés pour être pleinement conforme à la RFC 2474, ce qui signifie que nous somme délivrés des disputes comme expliqué précédemment, aussi longtemps que les fabriquants de matériel suivent cette RFC.

Le troisième, et pratiquement dernier, changement du champ ToS a été quand les deux bits inutilisés furent utilisés par ECN (Explicit Congestion Notification), comme défini dans la RFC 3168. ECn est utilisé pour permettre de savoir s'il existe une congestion des routeurs, avant il démarre la suppression des paquets, ainsi le noeud final pourra ralentir la transmission des données. Précédemment, la suppression de données était le seul moyen qu'avait un routeur pour annoncer qu'il était en surcharge, et les noeuds terminaux devaient faire un redémarrage lent pour chaque paquet supprimé, et ensuite accélérer de nouveau. Les deux bits sont appelés ECT (ECN Capable Transport) et CE (Congestion Experienced).

L'itération finale de l'ensemble est la RFC 3260 qui apporte quelques terminologies et clarifications nouvelles pour l'utilisation du système DiffServ. Elle n'améliore pas énormément de choses, sauf la terminologie. La RFC est également utilisée pour clarifier certains points qui ont été discutés entre développeurs.

Longueur totale - bits 16 - 31. Ce champ nous renseigne sur la taille des paquets en octets, incluant les en-têtes. La taille maximum est 65535 octets. La taille minimum d'un paquet est de 576 octets, sans prendre en compte si le paquet arrive en fragments ou non. Il est recommandé d'envoyer des paquets plus gros que cette limite seulement si il est garanti que l'hôte puisse les recevoir, selon la RFC 791. Cependant, actuellement la plupart des réseaux fonctionnent avec des tailles de paquets de 1500 octets. Ceci inclut la majorité des connexions ethernet et Internet.

Identification - bits 32 - 46. Ce champ est utilisé pour aider a réassembler les paquets fragmentés.

Fanions - bits 47 - 49. Ce champ contient des fanions mélangés appartenant à la fragmentation. Le premier bit est réservé, mais toujours inutilisé, et doit être placé à 0. Le second bit est placé à 0 si le paquet peut être fragmenté, et à 1 s'il ne peut pas être fragmenté. Le troisième et dernier bit peut être placé à 0 si il était le dernier fragment, et à 1 s'il n'y a pas de fragments supplémentaires de ce même paquet.

Fragment décalé - bits 50 - 63. Le champ fragment décalé indique de quel datagramme le paquet dépend. Les fragments sont calculés sur 64 bits, et le premier fragment a un décalage zéro.

Durée de vie - bits 64 - 72. Le champ TTL (Time To Live) nous indique le durée de vie d'un paquet, ou combien de "sauts" (hops) il peut réaliser sur l'Internet. Chaque processus qui touche le paquet doit supprimer un point du champ TTL, et si le TTL atteint zéro, le paquet doit être détruit ou écarté. C'est un usage de base fonctionnant comme une sécurité car si le paquet n'est pas supprimé/écarté il peut se transformer en boucle incontrôlable entre un ou plusieurs hôtes. Pour la destruction l'hôte renverra un message ICMP "Destination Unreachable" à l'expéditeur.

Protocole - bits 73 - 80. Dans ce champ le protocole du niveau de la couche suivante est indiqué. Par exemple, ce peut être TCP, UDP ou ICMP parmi d'autres. Tous ces nombres sont définis par la Internet Assigned Numbers Authority (IANA). Ces nombres peuvent être retrouvés sur le siteInternet Assigned Numbers Authority.

Somme de contrôle d'en-tête - bits 81 - 96. C'est un contrôle de l'en-tête IP du paquet. Ce champ est recalculé au niveau de chaque hôte qui modifie l'en-tête, ce qui signifie à peu près chaque hôte que le paquet traverse, la modification se faisant le plus souvent au niveau du champ TTL.

Adresse de l'expéditeur - bits 97 - 128. C'est le champ adresse de la source. Elle est généralement écrite sur 4 octets, traduite du binaire en nombres décimaux avec des points entre eux. Par exemple, 127.0.0.1. Le champ permet au destinataire de connaître l'adresse d'expédition du paquet.

Adresse de destination - bits 129 - 160. Le champ adresse contient l'adresse de destination, et surprise, il est formaté de la même façon que l'adresse de l'expéditeur.

Options - bits 161 - 192 <> 478. Le champ options n'est pas optionnel, comme il pourrait le sembler. C'est un des champs les plus complexes dans les en-têtes IP. Le champ options contient divers réglages optionnels à placer dans l'en-tête, comme minuterie Internet, SACK ou enregistrement de route. Ces options sont toutes optionnelles, le champ options peut avoir des longueurs différentes, et donc l'en-tête IP complet. Cependant, nous calculons toujours l'en-tête IP sur 32 bits, nous devons toujours clore l'en-tête sur un même nombre, qui est un multiple de 32. Le champ peut contenir zéro ou plusieurs options.

Le champ options démarre avec un champ de 8 bits qui nous permet de savoir quelles options ont été utilisées dans le paquet. Les options sont toutes listées dans la table Options TCP, dans l'appendice Options TCP. Pour plus d'information sur les différentes options, lisez les RFC correspondantes. Pour une liste des options IP mises à jour, voir Internet Assigned Numbers Authority.

Remplissage - bits variables. C'est un champ de remplissage utilisé pour la fin de l'en-tête à la frontière des 32 bits. Le champ doit toujours être une ligne de zéros jusqu'à la fin.

le protocole TCP réside au sommet du protocole IP. C'est un protocole architecture qui possède des fonctions natives pour vérifier si les données sont reçues correctement par les hôtes destinataires. Les buts principaux du protocole TCP sont de vérifier que les données sont envoyées et reçues de façon fiable, que les données sont transportées entre la couche Internet et la couche Application correctement, et que les paquets joignent le bon programme dans la couche application, et dans le bon ordre. Tout ceci est possible grâce aux en-têtes TCP du paquet.

Le protocole TCP considère les données comme un flux continu avec un signal de début et de fin. Le signal qui indique qu'un nouveau flux est en attente d'ouverture est appelé une poignée de main SYN à trois voies dans TCP, et consiste en un paquet envoyé avec le bit SYN. Les réponses se font soit avec SYN/ACK soit avec SYN/RST pour permettre au client de savoir si la connexion a été acceptée ou refusée respectivement. Si le client reçoit un paquet SYN/ACK, il peut de nouveau répondre, cette fois avec un paquet ACK. À ce moment, la connexion est établie et les données peuvent être envoyées. Pendant la poignée de main (handshake) initiale, toutes les options spécifiques qui seront utilisées à travers la connexion TCP sont aussi négociées, comme ECN, SACK, etc.

Tandis que le flux de données est actif, nous avons d'autres mécanismes à voir. C'est la partie fiabilité de TCP. Ceci est réalisé de façon simple, en utilisant un numéro d'interclassement (sequence) dans le paquet. Chaque fois que nous envoyons un paquet, nous donnons une nouvelle valeur au numéro d'interclassement, et quand le destinataire reçoit le paquet, il envoie en retour un paquet ACK à l'expéditeur. Le paquet ACK accuse réception que le paquet a été reçu correctement. Le numéro d'interclassement vérifie aussi que le paquet inséré dans un flux de données est en bon ordre.

Ensuite la connexion est fermée, ce qui est fait en envoyant un paquet FIN comme point final. Le destinataire répond alors en envoyant un paquet FIN/ACK. Plus aucune donnée ne peut alors être envoyée, mais l'expéditeur ou le destinataire peuvent toujours finir d'envoyer leurs données. Une fois que l'expéditeur ou le destinataire désire clore la connexion complètement, il envoie un paquet FIN en retour, et le correspondant répond avec un paquet FIN/ACK. Une fois cette procédure complète effectuée, la connexion est coupée proprement.

Comme nous le verrons plus tard, les en-têtes TCP contiennent des sommes de contrôle. La somme de contrôle consiste en une simple empreinte numérique du paquet. Avec cette empreinte numérique, nous pouvons avec une grande exactitude voir si la paquet a été corrompu d'une façon ou d'une autre pendant le transit entre les hôtes.

Les en-têtes TCP doivent être capables d'exécuter toutes les tâches ci-dessus. Nous avons déjà expliqué quand et où certains de ces en-têtes sont utilisés, mais il y a encore d'autres zones que nous n'avons pas vu en détail. Ci-dessous vous avez une image de l'ensemble des en-têtes TCP. Il est formaté en mots de 32 bits par ligne, comme vous pouvez le voir.

Port expéditeur - bit 0 - 15. C'est le port source du paquet. Le port source était à l'origine lié directement au processus du système d'expédition. Aujourd'hui, nous utilisons une empreinte numérique entre les adresses IP, et les ports source et destination pour pouvoir les lier en une seule application ou programme.

Port destinataire - bit 16 - 31. C'est le port de destination du paquet TCP. Avec le port source, il était lié à l'origine directement au processus du système de réception. Aujourd'hui, une empreinte numérique est utilisée, qui nous permet d'avoir d'avantage de connexions ouvertes en même temps. Quand un paquet est reçu, les ports source et destination sont renversés dans la réponse à l'hôte d'origine, ainsi le port de destination est maintenant le port source, et le port source devient le port de destination.

Numéro d'interclassement - bit 32 - 63. le champ numéro d'interclassement est utilisé pour mettre en place un numéro sur chaque paquet TCP de façon que le flux TCP puisse être proprement ordonnancé (i.e. les paquets s'ordonnent dans le bon ordre). Le numéro d'interclassement est alors renvoyé dans le champ ACK pour accuser réception que le paquet a été correctement reçu.

Numéro d'accusé-reception - bit 64 - 95. Ce champ est utilisé quand nous accusons réception d'un paquet spécifique qu'un hôte a reçu. Par exemple, nous recevons un paquet avec un numéro d'interclassement, et si tout est ok avec le paquet, nous répondons avec un paquet ACK et le numéro d'interclassement identique au numéro d'interclassement d'origine.

Décalage de données - bit 96 - 99. Ce champ indique la longueur de l'en-tête TCP, et où la partie données du paquet démarre. Il est codé sur 4 bits, et mesure l'en-tête TCP en 32 bits. L'en-tête se termine toujours sur une limite de 32 bits, même avec différentes options.

Réservé - bit 100 - 103. Ces bits sont réservés pour un usage futur. Dans la RFC 793 les bits CWR et ECE sont également inclus. Selon la RFC 793 les bits 100-105 (i.e. ceci et les champs CWR et ECE) doivent être placés à zéro pour être pleinement compatibles. Plus tard, nous verrons cela quand nous commencerons l'introduction de ECN. Ceci a causé nombre de désagréments à cause de machines Internet comme des pare-feux et routeurs qui suppriment des paquets. C'est toujours vrai lors de la rédaction de ces lignes.

CWR - bit 104. ce bit a été rajouté dans la RFC 3268 et est utilisé par ECN. CWR pour Congestion Window Reduced, est utilisé par la partie des données envoyées au destinataire pour l'informer que la fenêtre d'encombrement a été réduite. Quand la fenêtre d'encombrement est réduite, nous envoyons moins de données par unité de temps, pour pouvoir assurer la charge totale du réseau.

ECE - bit 105. Ce bit a aussi été rajouté avec la RFC 3268 et il est utilisé par ECN. ECE pour ECN Echo. Il est utilisé par la pile TCP/IP sur l'hôte destinataire qui permet à l'expéditeur de savoir si un paquet CE a été reçu. La même chose s'applique ici, comme pour le bit CWR, qui était à l'origine une partie du champ réservé et à cause de ça, certains matériels réseau supprimaient les paquets si les champs contenaient autre chiose que des zéros. C'est actuellement toujours vrai pour beaucoup de matériels malheureusement.

URG - bit 106. Ce bit nous indique si nous utilisons le champ Urgent Pointer ou non. S'il est placé à 0, pas d'utilisation de Urgent Pointer, s'il est placé à 1, utilisation de Urgent Pointer.

ACK - bit 107. Ce bit est placé dans un paquet pour indiquer qu'il s'agit d'une réponse à un autre paquet que nous avons reçu, et qui contient des données. Un paquet accusé-réception est toujours envoyé pour indiquer que nous avons reçu le paquet, et qu'il ne contient pas d'erreurs. Si ce bit est placé, l'expéditeur des données d'origine vérifiera le numéro d'accusé-réception pour voir quel paquet est actuellement en accusé-réception, et ensuite videra les tampons.

PSH - bit 108. Le fanion PUSH est utilisé pour prévenir le protocole TCP sur des hôtes intermédiaires d'envoyer les données à l'utilisateur actuel, incluant l'implémentation TCP sur l'hôte destinataire. Ceci expédie toutes les données.

RST - bit 109. Le fanion RESET est placé pour indiquer à l'hôte de relancer la connexion TCP. Ceci est dû à divers scénarios, les principales raisons étant que la connexion a été coupée, la connexion n'existe pas, ou le paquet contient des erreurs.

SYN - bit 110. Le SYN (Synchronize Sequence Numbers) est utilisé pendant l'établissement initial de la connexion. Il est placé dans deux circonstances, le paquet initial qui ouvre la connexion, et le paquet SYN/ACK en réponse. Il ne doit jamais être utilisé en dehors de ces cas.

FIN - bit 111. Le bit FIN indique que l'hôte qui envoie le bit FIN n'a plus de données à expédier. Quand l'hôte voit le bit FIN, il répond avec un un FIN/ACK. Une fois cela fait, l'expéditeur du bit FIN ne peut plus envoyer de données. Cependant, l'hôte peut continuer à expédier les données jusqu'à ce qu'il ait fini, et ensuite enverra un paquet FIN en retour, et attendra le FIN/ACK final, après ça la connexion est en état CLOSED.

Window - bit 112 - 127. Le champ fenêtre est utilisé par l'hôte destinataire pour dire à l'expéditeur combien de données il autorise à cet instant. Ceci est fait en envoyant un ACK en retour, qui contient un numéro d'interclassement nécessaire pour l'accusé-réception, le champ fenêtre contient alors les numéros d'interclassement maximum acceptés que l'expéditeur peut utiliser avant de recevoir le prochain paquet ACK. Le paquet ACK suivant met à jour la fenêtre que l'expéditeur peut utiliser.

Checksum - bit 128 - 143. Ce champ contient la somme de contrôle de l'en-tête TCP complet. C'est un complément d'une somme de chaque mot de 16 bits dans l'en-tête. Si l'en-tête ne finit pas sur une limite de 16 bits, le bit additionnel est placé à zéro. Tandis que la somme de contrôle est calculée, le champ somme de contrôle est placé à zéro. La somme de contrôle couvre également une pseudo en-tête de 96 bits contenant la Destination, Adresse source, protocole, et longueur TCP. Ceci pour des raisons de sécurité.

Pointeur urgent - bit 144 - 159. Pointeur placé à la fin des données considérées comme urgentes. Si la connexion a d'importantes données qui doivent être exécutées le plus tôt possible par le destinataire, l'expéditeur peut placer un drapeau URG pour indiquer où les données urgentes finissent.

Options - bit 160 - **. le champ Options est un champ de longueur variable qui contient des en-têtes optionnels. De façon basique, ce champ contient 3 sous-champs chaque fois. Un champ initial nous indique la longueur du champ Options, un second indique quelles options sont utilisées, et quand nous obtenons les options. Une liste complète de toutes les options TCP se trouve dans Options TCP.

Padding - bit **. Le champ remplissage complète l'en-tête TCP jusqu'à ce que tout l'en-tête atteigne la limite de 32 bits. Ceci assure que la partie données du paquet débute sur une limite de 32 bits, et qu'aucune donnée n'est perdue dans le paquet. Le remplissage ne contient toujours que des zéros.

Le User Datagram protocol (UDP protocol) est un protocole très basique et simple au sommet du protocole IP. Il a été développé pour permettre une transmission de données très simple sans détection d'erreur d'aucune sorte. Cependant, il est très bien adapté pour les applications de type requête/réponse, comme par exemple DNS, etc. car nous savons qu'à moins d'obtenir une réponse du serveur DNS, la requête sera perdue quelque part. Parfois il peut être utile de se servir du protocole UDP au lieu de TCP, comme lorsque nous voulons seulement une détection d'erreurs/pertes mais sans faire attention à l'ordre d'interclassement des paquets. Ceci supprime quelques en-têtes présents dans le protocole TCP. Nous pouvons aussi faire d'autres choses, créer notre propre protocole au sommet de UDP qui ne contient que l'interclassement, mais pas d'erreur ni de perte.

Le protocole UDP est spécifié dans la RFC 768 - User Datagram Protocol. C'est une très brève RFC.

On peut dire que l'en-tête UDP est un en-tête TCP très basique et simplifié. Il contient la destination, le port source, la longueur d'en-tête et une somme de contrôle comme indiqué dans l'image ci-dessous.

Port source - bit 0-15. C'est le port source du paquet, décrivant où un paquet en réponse sera envoyé. Par exemple, quelquefois nous n'exigeons pas de paquet en réponse, le paquet peut alors être placé à zéro en port source. Dans la plupart des implémentations, il est placé à un nombre quelconque.

Port destination - bit 16-31. Le port de destination du paquet. Nécessaire pour tous les paquets, à l'opposé du port source d'un paquet.

Length - bit 32-47. Le champ longueur spécifie la taille de l'ensemble du paquet en octets, incluant les en-têtes et les données. Le plus petit paquet possible est de 8 octets.

Checksum - bit 48-63. La somme de contrôle est du même type que celle utilisée dans les en-têtes TCP, sauf qu'elle contient un ensemble de données différent. En d'autres termes, c'est un complément d'un complément de parties de l'en-tête IP, de l'ensemble de l'en-tête UDP, les données UDP et le remplissage avec des zéros lorsque nécessaire.

Les messages ICMP sont utilisés pour les types d'erreurs basiques rapportées entre hôtes, ou entre hôte et passerelle. Entre passerelles, un protocole appelé GGP (Gateway to gateway protocol) ou passerelle à passerelle doit normalement être utilisé pour le rapport d'erreur. Comme nous l'avons déjà vu, le protocole IP n'a pas été conçu pour parfaire le maniement d'erreur, mais les messages ICMP résolvent une partie de ces problèmes. Le gros problème de ce point de vue est que les en-têtes des messages ICMP sont plutôt compliqués, et diffèrent de message en message. Cependant, ce n'est pas un gros problème du point de vue filtrage la plupart du temps.

La forme de base du message contient l'en-tête IP standard, le type, le code et la somme de contrôle. Tous les messages ICMP contiennent ces champs. Le type spécifie le genre d'erreur du message de réponse, comme par exemple, destination injoignable, écho, réponse d'écho, ou message redirigé. Le code donne plus d'information si nécessaire. Si le paquet est de type destination injoignable, il y a plusieurs valeurs possibles comme réseau injoignable, hôte injoignable, ou port injoignable. La somme de contrôle est simplement une somme pour l'ensemble du paquet.

Comme vous avez pû le noter, j'ai mentionné explicitement l'en-tête IP pour la paquet ICMP. C'est dû au fait que l'en-tête IP actuel est une partie intégrale du paquet ICMP, et que le protocole ICMP est au même niveau, dans un sens, que le protocole IP. ICMP utilise le protocole IP comme s'il était à un niveau plus haut, mais en même temps ce n'est pas le cas. ICMP est une partie intégrale de IP, et ICMP doit être implémenté dans chaque implémentation de IP.

Comme déjà expliqué, les en-têtes de type ICMP diffèrent légèrement du type IP. La plupart des types ICMP permettent de les grouper par leurs en-têtes. À cause de cela, nous verrons en premier l'en-tête de base, et ensuite chaque groupe de type spécifique.

Tous les paquets contiennent des valeurs de base des en-têtes IP comme nous l'avons vu précédemment.

• Version - Doit toujours être placé à 4.
• Longueur en-tête Internet - Longueur de l'en-tête en mots de 32 bits.
• Type de Service - Voir au-dessus. Doit être placé à 0, seule légitimité selon la RFC 792 - Internet Control Message Protocol.
• Longueur totale - Longueur totale de l'en-tête et de la partie données du paquet, compté en octets.
• Décalages d'Identification, de fanions et fragments - Issu du protocole IP.
• Durée de vie - Nombre de sauts que le paquet peut effectuer.
• Protocole - Quelle version de ICMP est utilisée (doit toujours être à 1).
• En-tête somme de contrôle - Voir l'explication IP.
• Addresse source - L'adresse de la source qui a envoyé le paquet. Ce n'est pas entièrement vrai, car le paquet peut avoir une autre adresse source, que celle située sur la machine en question. Les types ICMP peuvent produire cet effet, ce sera noté si nécessaire.
• Addresse destination - L'adresse de destination du paquet.

Il existe aussi de nouvelles en-têtes utilisés par les types ICMP. Ce sont les suivantes :

• Type - Le champ type contient le type ICMP du paquet. Par exemple les paquets ICMP Destination Injoignable auront un type 3 placé. Pour une liste complète des différents types ICMP voir Types ICMP. Ce champ contient 8 bits au total.
• Code - Tous les types ICMP contiennent différents codes. Certains types ont un code unique, tandis que d'autres ont plusieurs codes qu'ils peuvent utiliser. Par exemple, le type ICMP Destination Injoignable peut avoir au moins les codes 0, 1, 2, 3, 4 ou 5. Chaque code aura un comportement différent selon le contexte. Pour une liste complète des différents codes, voir Types ICMP. Ce champ est de 8 bits de longueur totale. Nous verrons les différents codes un peu plus en détail plus tard dans cette section.
• Somme de contrôle - La somme de contrôle est un champ de 16 bits contenant un complément de complément des en-têtes démarrant avec le type ICMP. Tandis que le calcul de la somme de contrôle s'effectue, le champ de celle-ci sera placé à zéro.

À ce point les en-têtes peuvent présenter un visage différent. Nous décrirons les types ICMP les plus communs un par un, avec un bref apperçu de leurs différentes en-têtes et codes.

VI-I-1. Écho requête/réponse ICMP▲

VI-I-2. Destination Injoignable ICMP▲

VI-I-3. Coupure de source▲

VI-I-4. Redirection▲

VI-I-5. TTL égale 0▲

VI-I-6. Paramètre problème▲

VI-I-7. Horodatage requête/réponse▲

VI-I-8. Requête/réponse information▲

TCP/IP s'est accru en complexité quand il est devenu une partie du routage. Au début, la plupart des gens pensaient que la destination donnée par le routage était suffisante. Ces dernières années, c'est devenu de plus en plus complexe. Aujourd'hui, Linux peut router de façon basique chaque champ ou bit dans l'en-tête IP, et également les en-têtes basées sur TCP, UDP ou ICMP. Ceci est appelé gestion de réseau à base de règles, ou routage avancé.

Il ne s'agit ici que d'un survol du routage. Quand nous envoyons un paquet depuis un expéditeur, le paquet est créé. Après ça, l'ordinateur regarde l'adresse de destination du paquet et la compare à sa table de routage. Si l'adresse de destination est locale, le paquet est envoyé directement via l'adresse MAC du matériel (Ndt. interface réseau). Si le paquet est de l'autre côté de la passerelle il est envoyé via l'adresse MAC de la passerelle. Celle-ci regardera alors les en-têtes IP et verra l'adresse de destination du paquet. L'adresse de destination est consultée dans la table de routage, et le paquet envoyé à la passerelle suivante, etc. jusqu'à sa destination finale.

Comme vous pouvez le voir, ce routage est très basique. Avec le routage avancé, et la gestion de réseau à base de règles, ceci devient plus complexe. Nous pouvons router des paquets qui diffèrent dans leur adresse source par exemple, ou leur valeur TOS, etc.

Nous avons vu les points suivants :

• Structure TCP/IP
• Fonctionnalité du protocole IP et en-têtes.
• Fonctionnalité du protocole TCP et en-têtes.
• Fonctionnalité du protocole UDP et en-têtes.
• Fonctionnalité du protocole ICMP et en-têtes.
• Destination TCP/IP par routage.

Tout ceci sera revu plus tard quand nous aborderons les tables de règles des pare-feux. Toute ces informations s'imbriquent ensemble, pour permettre une meilleure configuration de pare-feu.