Non !! Non et Non ! Surtout pas.
Le problème
De nombreux administrateurs réseau estiment que le protocole ICMP représente un risque pour la sécurité et qu’il doit donc toujours être bloquée au niveau du pare-feu. Il est vrai que ICMP est associée à certains problèmes de sécurité et qu’un grand nombre d’entre eux devraient être bloqués. Mais ce n’est pas une raison pour bloquer tout le trafic ICMP !
En effet, ICMP a de nombreuses caractéristiques importantes ; certaines sont utiles pour le dépannage, tandis que d’autres sont essentielles pour le bon fonctionnement d’un réseau. Sans être exhaustif, voici les détails de certains des trafics ICMP importants que vous devriez connaître, et envisager d’autoriser à travers votre réseau.
Demande d’écho et réponse à l’écho
IPv4 – Demande d’écho (Type8, Code0) et réponse d’écho (Type0, Code0)
IPv6 – Demande d’écho (Type128, Code0) et réponse d’écho (Type129, Code0)
Nous connaissons tous ceux-là – ping est l’un des premiers outils de dépannage que nous apprenons tous. Oui, si vous l’activez, cela signifie que votre hôte est maintenant détectable. Et alors ? Ne l’était-il pas déjà ? votre serveur web n’écoutait-il pas déjà sur le port 80 ? Bien sûr, bloquez les pings si vous le voulez vraiment à votre frontière vers votre DMZ (et encore…) mais bloquer le ping à l’intérieur de votre réseau ne vous apportera pas grand-chose, sauf un dépannage plus difficile (« Pouvez-vous pinger votre passerelle par défaut ? », « Non, mais je ne peux jamais, donc cela ne me dit rien ! »). Par ailleurs, notez que pour une immence majorité d’administrateurs et de prestataires, une IP qui ne réponds pas au ping est réputée libre et affectable à quelqu’un d’autre…. Ne vous plaignez pas si des conflits d’adresses IP apparaissent.
N’oubliez pas que vous pouvez également autoriser cela avec une direction donnée à l’esprit ; vous pouvez décider de laisser les demandes d’écho sortir de votre réseau vers Internet, et les réponses d’écho d’Internet vers votre réseau, mais pas vice versa.
Fragmentation requise (IPv4) / paquet trop grand (IPv6)
IPv4 – (Type3, Code4)
IPv6 – (Type2, Code0)
Ceux là sont importants. TRÈS importants. VRAIMENT TRES importants. Ils sont un composant essentiel de Path MTU Discovery (PMTUD), qui est une partie essentielle de TCP qui permet à deux hôtes d’ajuster leur taille maximale de segment TCP (MSS) à une valeur qui s’adaptera dans le plus petit MTU le long du chemin des liens entre les deux hôtes. Si deux hôtes ont un MTU plus petit que leur propre lien local sur le chemin entre eux, et n’ont aucun moyen de le découvrir, le trafic est silencieusement occulté ; en d’autres termes, « ca va être la merde ».
Les paquets IPv4 avec le bit DF (c’est la plupart d’entre eux !), ou les paquets IPv6 qui sont trop grands pour qu’un routeur puisse les transmettre à travers une interface (rappelez-vous qu’il n’y a pas de fragmentation par les routeurs dans IPv6), auront pour résultat que le routeur drop le paquet et génère une erreur ICMP « Fragmentation Required / Packet Too Big » vers la source et qui contient aussi le MTU du lien trop petit. Si cette erreur ne parvient pas à l’expéditeur, l’expéditeur interprétera simplement l’absence de ACK du récepteur comme une congestion/perte et il fera une retransmission, qui sera bien sûr également perdue. Ce type de comportement est difficile à dépanner car bien sûr, les poignées de main TCP fonctionnent bien, car il s’agit de petits paquets, mais la session semble se bloquer dès qu’une transmission de données en masse a lieu.
RFC 4821 a été développé pour aider les hôtes à contourner ce problème en utilisant « Packetization Layer Path MTU Discovery » (PLPMTUD), qui découvre le chemin MTU en augmentant progressivement le MSS pour essayer de trouver une valeur appropriée pour ce chemin. Cela supprime la dépendance à ICMP, et est disponible dans la plupart des piles réseau d’OS, mais n’est pas aussi efficace que d’apprendre directement ce que le MTU maximum devrait être. Alors s’il vous plaît, laissez passer ces messages ICMP. C’est vraiment important.
Temps dépassé
IPv4 – (Type11, Code0)
IPv6 – (Type3, Code0)
Traceroute est un outil très utile pour dépanner les connexions réseau entre deux hôtes, détaillant chaque saut sur le chemin. Il le fait en envoyant un paquet avec un TTL de 1 pour que le premier saut renvoie un message Time Exceeded (incluant son propre IP source), puis en envoyant un paquet avec un TTL de 2, et ainsi de suite, pour découvrir chaque saut sur le chemin.
Rappelez-vous quand vous l’avez déjà lancé et que vous obtenez un ou deux sauts qui ne peuvent pas être découverts au milieu de votre trace ? Ou pire encore, vous essayez de tracer l’itinéraire jusqu’à un hôte et tous les sauts ne peuvent être découverts. C’est ennuyeux, n’est-ce pas ? C’est parce que la personne qui exécute ces routeurs (ou votre pare-feu local) a décidé de bloquer les messages ICMP Time Exceeded. Ne sois pas comme ça, d’accord ?
NPD et SLAAC (IPv6)
Sollicitation de routeur (RS) (Type133, Code0)
Publicité sur le routeur (RA) (Type134, Code0)
Sollicitation de voisins (N.-É.) (Type135, Code0)
Publicité de voisinage (NA) (Type136, Code0)
Rediriger (Type137, Code0)
Alors qu’IPv4 utilisait le protocole de résolution d’adresse (ARP) pour les mappages des couches 2 à 3, IPv6 adopte une approche différente, sous la forme du protocole de découverte des voisins (NDP). NDP offre de nombreuses fonctions, y compris la découverte de routeurs, la découverte de préfixes, la résolution d’adresses, et bien d’autres encore. En plus du NDP, l’AutoConfiguration d’adresse sans état (SLAAC) permet à un hôte d’être configuré dynamiquement sur le réseau, selon un concept similaire à DHCP (bien que DHCPv6 existe pour un contrôle plus fin)
Pour le reste, il n’est pas indispensable de les laisser passer et même souhaitable d’en bloquer une grande partie. Mais ces cinq types ICMP ci dessus devraient TOUJOURS être autorisés dans votre réseau pour qu’il puisse fonctionner correctement.
Un mot sur la limitation de trafic.
Bien que les messages ICMP comme ceux couverts sur cette page puissent être très utiles, rappelez-vous que la génération de tous ces messages prend du temps CPU sur vos routeurs, et génère du trafic. Vous attendez-vous vraiment à recevoir 1000 pings par seconde à travers votre pare-feu dans une situation normale ? Serait-ce considéré comme un trafic légitime si vous le voyiez ? Non, probablement pas. Limitez tous ces types de trafic ICMP comme bon vous semble pour votre réseau ; c’est une bonne ligne de défense qui ne doit pas être ignorée.
Lire, Rechercher, Comprendre
Étant donné que le fait que les discussions sur « bloquer ou de ne pas bloquer ICMP » semble toujours entraîner de la confusion, de la colère et des désaccords fanatiques, n’hésitez pas à lire vous-même sur le sujet. Prenez le temps de le comprendre le plus complètement possible ; il y a beaucoup de liens tout au long de cette page seulement. Vous pourrez ensuite vous faire votre propre opinion et faire un choix éclairé sur ce qui convient le mieux à votre réseau.
Article traduit et légèrement modifié d’un article en anglais provenant de http://shouldiblockicmp.com/