Pourquoi certains serveurs Web ne répondent-ils pas aux demandes ICMP?

Quel est le but de bloquer / supprimer le trafic ICMP entrant sur un serveur Web public? Est-il courant qu'il soit bloqué?

J'ai dû tester si un serveur était accessible depuis différents endroits (testé sur différents serveurs situés dans différents états / pays). Je compterais sur le ping comme méthode rapide et fiable pour déterminer si un serveur était en ligne / accessible au réseau. Après ne pas avoir reçu de réponse sur quelques boîtes, j'ai essayé d'utiliser lynx pour charger le site, et cela a fonctionné.

Il est assez courant de nos jours d'abandonner ICMP, car c'est une méthode générique à utiliser à des fins de déni de service. Un hôte à bande passante plus élevée ou plusieurs hôtes exécutant une commande ping répétée sur un seul serveur Web pourraient utiliser toute sa bande passante.

D'autres pourraient chuter pour réduire leur empreinte sur Internet, ce qui pourrait être négligé par le trafic de numérisation de masse.

Bien qu'il soit courant, je dirais qu'il offre peu de valeur et ne fait pas grand-chose pour minimiser le DoS et l'empreinte tout en limitant le potentiel de diagnostic.

Outre la protection douteuse du DoS et le profil réduit, il existe une raison courante mais négligée qu'une adresse IP donnée peut ne pas répondre aux pings: elle n'est pas réellement affectée à une interface.

La redirection (redirection de port) des tuples IP / protocole / port vers les différents services que vous souhaitez vous donne une plus grande densité de service sur un réseau plus petit.

Par exemple, supposons que votre FAI vous achemine 1.2.3.4/30. Vous avez trois choix:

• Acheminez-les normalement. Vous laisse deux IP utilisables, dont l'une doit être votre passerelle, donc un seul hôte.
• IP externe NAT vers IP interne. Vous laisse quatre hôtes.
• Redirigez le trafic vers les services internes selon vos besoins. SMTP (TCP 25), DNS (TCP / UDP 53) et votre site Web d'entreprise (TCP 80 443) peuvent tous exister sur une seule adresse externe.

La troisième voie est de plus en plus courante. La plupart des administrateurs (y compris moi-même), lors de la configuration, ne prennent pas la peine de rediriger ICMP, il tombe donc simplement sur le pare-feu.

Il n'y a pas de mal à bloquer le type ICMP 0 (réponse Echo), mais le blocage de tout le trafic ICMP interrompt les réponses au client si un lien dans le chemin de retour a un MTU inférieur à la taille maximale de segment d'envoi de la connexion TCP. Cela se produit car le serveur Web ne peut plus recevoir de paquets ICMP de type 3 de code 4 (destination inaccessible; fragmentation nécessaire et ensemble DF).

En pratique, ce n'est pas vraiment un problème car quiconque a besoin de tunneler le trafic doit également mettre en place un mécanisme pour gérer la multitude de serveurs Web dont les piles TCP sont gênées par des pare-feu mal configurés.

Aide aux attaques par déni de service. Aucune vraie raison d' avoir besoin que le site soit ouvert pour un ping du public.

De plus, il ne donne pas les statistiques du site Web; un hôte ou une adresse IP pourrait facilement répondre pour une batterie de serveurs d'équilibrage de charge sur le back-end (cingler un mysite.com ne vous dit pas si tous les serveurs fonctionnent correctement derrière le nom.)

Il peut s'agir simplement d'une politique de la société visant à supprimer le trafic inutile ou à autoriser uniquement le port 80 et le trafic SSL à être redirigés vers d'autres serveurs en interne.

Je suppose que l'autre question serait, pourquoi s'embêter à autoriser des systèmes externes à envoyer un ping à vos serveurs s'ils n'en ont vraiment pas besoin?