Guide ICMP : ping, traceroute et diagnostics réseau

ICMP accompagne IP pour signaler les conditions du réseau. Un hôte, un routeur ou un pare-feu peut envoyer des messages ICMP lorsqu'une destination est inaccessible, qu'un paquet expire en transit, qu'une fragmentation est nécessaire ou qu'une demande d'écho de diagnostic nécessite une réponse.

Le flux de travail ICMP le plus connu est le ping. Un client envoie une demande d'écho et la cible répond par une réponse d'écho. Le temps d'aller-retour donne un signal rapide sur l'accessibilité et la latence, mais il ne prouve pas qu'un port d'application tel que 443 ou 22 est ouvert.

ICMP n'utilise pas de numéros de port TCP ou UDP. Il utilise des types et des codes de messages. C'est pourquoi un guide ICMP ne doit pas être traité comme un article normal sur les ports ouverts : vous décidez d'autoriser ou non des messages ICMP spécifiques, et non de savoir si un démon écoute sur un port numéroté.

Un vérificateur de port teste l'accessibilité du service TCP ou UDP. Ping teste l’accessibilité ICMP. Les deux sont utiles, mais ils répondent à des questions différentes. Un serveur peut bloquer le ping pendant que HTTPS fonctionne ou répondre au ping lorsque chaque port d'application est fermé.

Ping vérifie si une cible répond à l'écho ICMP et combien de temps prend l'aller-retour. Il est utile pour les contrôles rapides d’accessibilité, les sondes de surveillance et les lignes de base de latence.

Traceroute cartographie le chemin en envoyant des paquets avec des valeurs TTL croissantes et en lisant les messages ICMP de dépassement de temps des routeurs en cours de route. Certaines plates-formes utilisent des sondes UDP ou TCP pour traceroute, mais les messages ICMP restent essentiels au nombre de diagnostics de chemin signalant des sauts intermédiaires.

Autorisez ICMP lorsque les systèmes de surveillance, les équilibreurs de charge, les équipes réseau ou le personnel opérationnel ont besoin de signaux d'accessibilité et de latence. Pour les réseaux internes, autoriser le contrôle ICMP améliore souvent le dépannage et réduit les angles morts.

Pour les systèmes publics, de nombreuses équipes autorisent des réponses d'écho limitées provenant de sources de surveillance fiables et autorisent les messages d'erreur essentiels tels qu'une fragmentation nécessaire ou un comportement de destination inaccessible. La politique exacte doit correspondre à la périphérie de votre réseau, à la posture DDoS et aux besoins d'observabilité.

Avant de bloquer ou d'autoriser ICMP, décidez quels messages vous contrôlez. La demande d'écho, la réponse d'écho, le temps dépassé, la destination inaccessible et le comportement de paquet trop volumineux ont un impact opérationnel différent.

Évitez un blocage global à moins que vous ne compreniez le compromis. Le blocage de tous les ICMP peut interrompre la découverte du chemin MTU, masquer des erreurs de routage utiles, rendre la surveillance moins précise et forcer les équipes à déboguer avec des signaux plus faibles.

Sous Windows, le pare-feu Windows Defender dispose de règles d'écho ICMP prédéfinies qui peuvent être activées pour les profils et adresses sources sélectionnés. Étendez les règles aux réseaux de confiance lorsque cela est possible au lieu d'activer par défaut des réponses ping larges et publiques.

Sous Linux, les groupes de sécurité nftables, iptables, firewalld et cloud peuvent autoriser ou limiter ICMP par type. De nombreuses distributions exposent également les paramètres sysctl du noyau pour le comportement d'écho, mais la politique de pare-feu est généralement le point de contrôle le plus clair.

Sur les plateformes cloud, les groupes de sécurité traitent souvent ICMP séparément de TCP et UDP. Vérifiez les politiques entrantes et sortantes et n'oubliez pas que les équilibreurs de charge, les dispositifs Edge CDN et les contrôles DDoS des fournisseurs peuvent gérer ICMP différemment des pare-feu d'instance.

Utilisez ping pour tester la demande d'écho et la réponse. Utilisez traceroute ou tracert pour inspecter le chemin et identifier où les paquets s'arrêtent, en gardant à l'esprit que certains routeurs suppriment intentionnellement les réponses ICMP ou les limitent.

Si le ping échoue mais qu'une application fonctionne, ICMP peut être bloqué alors que TCP ou UDP sont autorisés. Si le ping fonctionne mais que l'application échoue, la cible est accessible au niveau de la couche réseau mais le port de service spécifique, la règle de pare-feu, l'écouteur ou l'application peuvent être interrompus.

Si le ping expire, la cible peut être en panne, une route peut être manquante, l'écho ICMP peut être bloqué ou un pare-feu intermédiaire peut supprimer le message. Les délais d'attente ne prouvent pas automatiquement que l'hôte est hors ligne.

Si traceroute s'arrête à un saut, ce saut peut filtrer les réponses dont la durée de vie a expiré ou les diagnostics de limitation de débit. Si des transferts volumineux échouent alors que de petites requêtes fonctionnent, vérifiez la découverte de la MTU du chemin et si les messages de paquets trop volumineux sont bloqués.

Autorisez ICMP délibérément plutôt que de tout bloquer par réflexe. Limitez le trafic d’écho, étendez la portée des réponses publiques le cas échéant et préservez les messages d’erreur importants nécessaires à un réseau stable.

Surveillez les volumes ICMP inhabituels, les sources usurpées et les modèles d'inondation en périphérie. Pour les réseaux sensibles, combinez la politique ICMP avec la segmentation et la surveillance fiable plutôt que de vous fier à la visibilité du ping comme limite de sécurité.