Debian logo [inetdoc.LINUX]

7.6. Connexions ICMP

Les paquets ICMP sont loin d'être un flux véritable, car ils sont seulement utilisés pour le contrôle et n'établissent jamais aucun type de connexion. Il existe quatre types ICMP qui généreront cependant des paquets en retour, et qui possèdent deux états différents. Ces messages ICMP peuvent prendre les états NEW et ESTABLISHED. Les types ICMP dont nous parlons sont les requêtes et réponse Echo, les requêtes et réponses Timestamp, les requêtes et réponses Information, et enfin les requêtes et réponses de Masque d'Adresse. En dehors de ça, les requêtes d'horodatage et d'information sont obsolètes et seront probablement supprimées. Cependant, les messages Echo sont utilisés dans plusieurs cas comme le ping sur des hôtes. Les requêtes de masque d'adresse ne sont pas utilisées souvent, mais peuvent être utiles quelques fois. Pour en avoir une idée, voyons l'image suivante.

Comme vous pouvez le voir dans l'image ci-dessus, l'hôte envoie une requête écho vers la cible, laquelle est considérée comme NEW par le pare-feu. La cible répond alors avec un écho que le pare-feu considère dans l'état ESTABLISHED. Quand la première requête écho a été vue, les entrées état suivantes se dirigent vers le ip_conntrack. 

icmp     1 25 src=192.168.1.6 dst=192.168.1.10 type=8 code=0 \
     id=33029 [UNREPLIED] src=192.168.1.10 dst=192.168.1.6 \
     type=0 code=0 id=33029 use=1

Ces entrées semblent un peu différentes des états standards pour TCP et UDP. Le protocole est présent, et la temporisation, de même que les adresses source et destination. Le problème survient après. Nous avons maintenant trois nouveaux champs appelés type, code et id. Il n'y a rien de spécial, le champ type contient le type ICMP et le champ code contient le code ICMP. Toutes les variables sont présentées dans l'annexe Annexe C, Types ICMP. Le dernier champ id, contient l'ID ICMP. Chaque paquet ICMP obtient une ID quand il est envoyé, et lorsque le destinataire reçoit le message ICMP, il place la même ID dans le nouveau message ICMP, que l'expéditeur reconnaîtra dans la réponse et il pourra alors se connecter avec la requête ICMP correcte.

Dans le champ suivant, nous avons reconnu le fanion [UNREPLIED]. Ce fanion nous indique que nous observons une entrée de traçage de connexion, dont le trafic est dans une direction. Enfin, nous voyons la probabilité de réponse à un paquet ICMP, qui est l'inversion des adresses IP source et destination. Comme pour le type et le code, ils ont été modifiés en valeurs correctes pour le paquet de retour, ainsi une requête écho est changée en réponse écho et ainsi de suite. L'ID ICMP est préservée depuis le paquet requête.

Le paquet réponse est considéré comme ESTABLISHED, ainsi que nous l'avons déjà expliqué. Cependant, nous pouvons savoir avec certitude qu'après la réponse ICMP, il n'y aura plus de trafic régulier dans la même connexion. Pour cette raison, l'entrée de traçage de connexion est détruite une fois que la réponse ait traversé la structure de Netfilter.

Dans chacun des cas ci-dessus, la requête est considérée comme NEW, tandis que la réponse est considérée comme ESTABLISHED. Voyons cela de plus près. Quand le pare-feu voit un paquet requête, il le considère comme NEW. Quand l'hôte envoie un paquet en réponse à la requête il est considéré comme ESTABLISHED.

[Note] Note

Notez que cela indique que le paquet réponse doit apparier le critère donné par l'entrée de traçage de connexion pour être considéré comme établi, de la même façon que tous les autres types de trafic.

Les requêtes ICMP ont un délai par défaut de 30 secondes, que vous pouvez modifier dans l'entrée /proc/sys/net/ipv4/netfilter/ip_ct_icmp_timeout. C'est, en général, une bonne valeur de temps d'attente, car elle permet de capturer la plupart des paquets en transit.

Une autre partie très importante de ICMP est le fait qu'il est utilisé pour indiquer aux hôtes les événements au niveau des connexions spécifiques UDP et TCP ou des tentatives de connexion. Pour cette raison, les réponses ICMP seront très souvent reconnues comme RELATED. Un exemple simple est le ICMP Host unreachable ou ICMP Network unreachable. Ceci est toujours généré en retour vers notre hôte s'il tente une connexion vers quelque autre hôte, mais que le réseau ou l'hôte en question ne soit pas connecté, ainsi le dernier routeur essayant de joindre le site répondra par un message ICMP nous l'indiquant. Dans ce cas, la réponse ICMP est considérée comme un paquet RELATED. L'image suivante explique ceci.

Dans l'exemple ci-dessus, nous envoyons un paquet SYN vers une adresse spécifique. Ceci est considéré comme une connexion NEW par le pare-feu. Cependant, le réseau que le paquet essaie de joindre est injoignable, donc un routeur va nous renvoyer une erreur ICMP indiquant que le réseau est injoignable. Le code de traçage de connexion peut reconnaître ce paquet comme RELATED, ainsi la réponse ICMP est correctement envoyée au client. En attendant, le pare-feu a détruit l'entrée de traçage de connexion depuis qu'il a eu connaissance du message d'erreur.

Le même comportement que ci-dessus est observé pour les connexions UDP avec les problèmes identiques que précédemment. Tous les messages ICMP envoyés en réponse aux connexions UDP sont considérés comme RELATED. Voyons l'image suivante.

Un paquet UDP est envoyé à un hôte. Cette connexion UDP est considérée comme NEW. Cependant, le réseau est interdit d'accès administrativement par un pare-feu quelconque ou un routeur. Donc, notre pare-feu reçoit un "ICMP Network Prohibited" en retour. Le pare-feu sait que ce message d'erreur ICMP est en relation avec la connexion UDP déjà ouverte et envoie un paquet RELATED au client. À ce niveau, le pare-feu supprime les entrées de traçage de connexion, et le client reçoit le message ICMP.

Précédent  Niveau supérieur  Suivant
7.5. Connexions UDP  Sommaire  7.7. Connexions par défaut

Table des matières