Souvent, les administrateurs réseaux et sécurité bloquent le passage du protocole ICMP au niveau du pare-feu argumentant que le protocole représente un risque de sécurité.

Certes, le protocole ICMP et comme tout autre protocole d’ailleurs, il offre quelques pistes d’attaques réseau mais cela ne justifie pas l’interdiction totale de ses fonctionnalités par notre pare-feu.

En tant qu’administrateur réseau, la première tâche que je réalise lorsqu’un utilisateur me contacte concernant un problème de connexion, c’est bien lancer une batterie de tests ping (ICMP- Echo request) vers la passerelle du PC, le DNS,Internet …Etc en attendant si ses équipements distants répondent à ma requête ( ICMP- Echo Reply) et si je ne reçois pas par exemple une réponse de la part de ma passerelle par défaut, je consacre mes efforts pour trouver le problème entre le PC et la passerelle pas plus. Imaginons que la passerelle par défaut n’est pas joignable à la base dû à une règle de sécurité, cela ne va pas m’aider à être efficace et je devrai sans doute passer plus de temps et d’énergie pour trouver la cause du problème.

Je ne suis pas en train de dire qu’il faut autoriser le ping de partout mais au moins au sein du réseau qu’est sous contrôle. Un bon compromis sera par exemple d’autoriser les messages Echo Request depuis mon réseau interne vers l’externe et seulement les Echo Reply depuis l’extérieur vers mon réseau interne.

Une deuxième fonctionnalité importante que le protocole ICMP nous offre, c’est bien la découverte de la taille MTU supportée dans le réseau. 

Le fonctionnement est simple, quand une source est une destination se mettent d’accord sur la taille maximale du paquet qu’elles peuvent échanger entre eux lors du TCP 3-way Handshake, elles ne prennent pas en considération la taille MTU des équipements intermédiaires, type routeur, pare-feu…. Par conséquent, ces équipements intermédiaires risquent de bloquer la circulation des paquets entre la source et la destination s’ils ne sont pas en capacité de le faire transiter à cause à leurs grande taille et qu’ils ne peuvent pas les fragmenter à cause du DF-bit. Normalement dans un monde idéal, les équipements intermédiaires dans ce cas-là informent la source du trafic via ICMP (Fragmentation Needed IPv4/ Packet too Big IPv6) de leurs incapacité de transiter ses données en lui demandant gentiment de réduire la taille MSS des paquets. 

Je vous assure que ce n’est pas un problème facile à découvrir si les messages ICMP ci-dessous sont bloqués par le pare-feu, Bref vous allez passer un sale moment avant de trouver donc bon courage.

Trace route !! hein, C’est sympa de pouvoir identifier facilement le chemin que ton trafic va emprunter avec une simple commande. Alors sachez que Trace route utilise aussi ICMP pour atteindre ses fins. Comment ça marche ? tout simplement la machine qui génère la trace route envoi un premier paquet ICMP avec un TTL =1 de façon à ce que le premier équipement dans le chemin répond avec un ICMP « Time Exceeded » en utilisant son adresse IP source qui sera affichée dans ton écran, Puis la source renvoie le packet avec un TTL = 2 pour détecter le deuxième équipement et ainsi de suite jusqu’ à l’arrivé à l’équipement final.

Si vous lancez une Trace route et que vous ne recevez pas de réponses au milieu du chemin, c’est tout simplement parce qu’il y a un équipement (Forcément un pare-feu) dans les parages.

Quand il n’y en a plus, il y en a encore 

Le protocole IPv6 repose lourdement sur ICMP que ce soit pour la la communication avec ses voisins (Neighbor Solicitation) (Neighbor Advertisement), l’annonce de la passerelle par défaut avec le mécanisme SLAAC….etc.

Vous n’êtes pas concernés pour le moment ? Dites merci au NAT 🙂

Un dernier mot, quand il y a un accident de voiture, on ne reproche ni la route ni la voiture mais plutôt le conducteur. C’est pareil ici, essayez de comprendre les attaques qui peuvent être conduites via ICMP et essayer de les bloquer mais surtout pas toutes les fonctionnalités ICMP.

C’est mon opinion sur le sujet et si vous n’êtes pas d’accord, je peux comprendre aussi. En fait, vous pouvez faire ce que vous voulez. Je m’en fous !!!   

Si vous avez des questions, des remarques ou vous avez besoin d’un complément d’informations, n’hésitez pas à laisser un message en commentaire de la page ou nous contacter directement à l’adresse : contact@mhd-experts.com.

Author

Driss JABBAR Un Architect réseaux avec plus de 10 ans d'expérience dans la conception et l'implémentation des architectures complexes LAN/WAN/DC. Pendant son parcours professionnelle, Driss a travaillé chez des intégrateurs et aussi des opérateurs. Driss possède actuellement trois certifications d'expertise Cisco CCIE RS & SP et CCDE. En dehors du travail, Driss consacre plus de temps pour sa famille mais il réserve toujours un petit créneau pour apprendre des nouvelles technologies ou pour regarder un match de foot de son club préféré. Driss est contributeur du blog MHD et joignable à l’adresse : driss.jabbar@mhd-experts.com

Write A Comment