Port ICMP : pourquoi ce protocole n’a besoin d’aucun port et comment le gérer dans vos réseaux

Vous avez déjà cherché « port ICMP » en vous demandant quel numéro ouvrir pour que le ping passe ? Vous n’êtes pas seul. C’est une des questions les plus fréquentes chez les admins et les équipes qui mettent en place des pare-feux. Sauf que la réponse est simple et un peu déconcertante au début : il n’existe pas de port ICMP. Zéro. Aucun.

Le protocole ICMP (Internet Control Message Protocol) vit à la couche réseau, exactement au même niveau qu’IP. Les ports, eux, n’apparaissent qu’à la couche transport, avec TCP et UDP. Du coup, quand on parle de « port icmp », on est déjà dans une petite confusion de couches.

ICMP, le messager discret de la couche réseau

ICMP sert principalement à deux choses : signaler des erreurs de transmission et aider au diagnostic. Quand un routeur ne peut pas acheminer un paquet, il peut renvoyer un message ICMP à l’expéditeur pour l’en informer. Quand vous faites un ping, vous envoyez en réalité un message ICMP de type Echo Request (type 8) et vous attendez un Echo Reply (type 0).

C’est tout. Pas de connexion à établir, pas de handshake comme avec TCP, pas de port de destination à indiquer. Le paquet ICMP est simplement encapsulé dans un paquet IP dont le champ « protocole » vaut 1. C’est ce numéro 1 qui permet aux équipements de reconnaître qu’il s’agit d’ICMP et non d’un autre protocole.

Le format est assez minimaliste : un en-tête avec un type (8 bits), un code (8 bits) qui précise la sous-catégorie du message, une somme de contrôle, et ensuite des données qui varient selon le type. Pour un ping, on trouve par exemple un identifiant et un numéro de séquence. Rien qui ressemble de près ou de loin à un port.

Pourquoi tout le monde cherche le « port ICMP »

La confusion vient souvent des pare-feux et des règles de filtrage. On a l’habitude d’écrire des règles du style « autoriser le port 22 pour SSH » ou « ouvrir le 443 pour HTTPS ». Quand le ping ne répond pas, la première réaction est donc de se dire « il faut ouvrir le port ICMP ».

Sauf que dans un pare-feu moderne (iptables, nftables, firewalld, Windows Defender, groupes de sécurité cloud…), on ne filtre pas ICMP sur un numéro de port. On filtre sur le type de message ICMP. C’est complètement différent.

Le truc, c’est que beaucoup d’interfaces graphiques ou de documentations un peu anciennes parlent encore de « ping » ou d’« ICMP » sans préciser la nuance. Du coup on cherche un port qui n’existe pas et on perd du temps.

Comment autoriser ICMP dans un pare-feu (sans chercher de port)

Concrètement, voilà comment on procède sur les systèmes les plus courants.

Sur Linux avec iptables, pour autoriser les requêtes ping entrantes :

iptables -A INPUT -p icmp --icmp-type echo-request -j ACCEPT

Pour les réponses (echo-reply), on les laisse souvent passer via la règle ESTABLISHED,RELATED, mais on peut aussi les autoriser explicitement :

iptables -A INPUT -p icmp --icmp-type echo-reply -j ACCEPT

Important : autorisez aussi le type 3 (Destination Unreachable), et particulièrement le code 4 (Fragmentation Needed). Sans ça, la découverte automatique de MTU (Path MTU Discovery) peut casser et vous vous retrouvez avec des connexions qui se figent sur les gros paquets.

Avec firewalld, c’est encore plus simple :

firewall-cmd --permanent --add-icmp-block-inversion
firewall-cmd --permanent --add-icmp-block=echo-request
firewall-cmd --reload

(Le inversion permet ensuite de n’autoriser que ce que vous listez explicitement.)

Dans les environnements cloud (AWS Security Groups, Azure NSG, GCP Firewall), vous ajoutez une règle « ICMP » ou « All ICMP » en précisant éventuellement les types. La plupart du temps on autorise tout ICMP depuis les IP de supervision et on bloque ou rate-limite le reste.

Sur Windows, vous allez dans les règles de pare-feu avancées et vous créez (ou activez) une règle pour « ICMPv4 Echo Request » en entrée.

Le point important : vous ne mettez jamais de numéro de port dans ces règles. Si votre règle contient un champ « port », c’est que vous êtes sur la mauvaise règle.

Les messages ICMP qu’on croise vraiment tous les jours

• Type 0 / 8 : Echo Reply / Echo Request → le ping classique.
• Type 3 : Destination Unreachable (avec plein de codes utiles, dont le fameux code 4 pour « fragmentation needed »).
• Type 11 : Time Exceeded → c’est ce qui fait fonctionner traceroute (quand le TTL arrive à 0, le routeur renvoie ce message).
• Type 5 : Redirect → à bloquer la plupart du temps en entreprise, car il peut servir à détourner du trafic.

Il en existe d’autres (timestamp, mask request…), mais ils sont rarement utilisés aujourd’hui et souvent filtrés sans regret.

Faut-il tout bloquer ICMP pour des raisons de sécurité ?

Honnêtement, bloquer tout ICMP est une mauvaise idée dans la plupart des cas. Oui, les scans ping existent, et oui, il y a eu des attaques d’amplification par le passé (Smurf, ping de la mort…). Mais bloquer complètement ICMP casse aussi des choses utiles :

• La détection de MTU (Path MTU Discovery) s’appuie sur les messages « fragmentation needed ».
• Certains outils de supervision et de diagnostic deviennent muets.
• Traceroute ne fonctionne plus correctement.

La bonne pratique actuelle, c’est plutôt de rate-limiter les requêtes echo-request entrantes et d’autoriser sélectivement les types dont vous avez vraiment besoin. Depuis les IP de vos outils de monitoring, vous pouvez être plus permissif. Depuis internet, vous limitez fortement.

Les redirections (type 5) sont presque toujours à bloquer ou à ignorer sur les routeurs et les pare-feux.

En vrai, que faire quand le ping ne passe pas ?

Avant de vous arracher les cheveux sur un hypothétique « port ICMP », vérifiez d’abord :

1. Les règles du pare-feu des deux côtés (serveur ET client).
2. Les ACL sur les routeurs intermédiaires.
3. Si vous êtes derrière un NAT ou un cloud provider, les security groups / firewall rules associées.
4. Le fait que certains hébergeurs bloquent ICMP par défaut sur les instances « light » ou « free ».

Et testez avec d’autres outils : nc pour vérifier qu’un port TCP/UDP répond, ou hping3 si vous voulez vraiment jouer avec des paquets ICMP personnalisés.

Bref, le « port ICMP » n’existe pas parce que ICMP n’est pas un protocole de transport. C’est un protocole de contrôle et de diagnostic qui vit directement dans la couche IP. Une fois qu’on a compris ça, tout devient plus simple : on arrête de chercher un numéro de port et on commence à écrire des règles sur les types de messages.

Et franchement, c’est beaucoup plus logique comme ça.