Le protocole ICMP Echo (généralement appelé "Ping") est généralement inoffensif. Ses principaux problèmes liés à la sécurité sont:

• En présence de requêtes avec une fausse adresse source ("spoofing"), ils peuvent amener une machine cible à envoyer des paquets relativement volumineux à un autre hôte . Notez qu'une réponse Ping n'est pas sensiblement plus grande que la requête correspondante, donc il n'y a pas d'effet multiplicateur là-bas: cela ne donnera pas de puissance supplémentaire à l'attaquant dans le cadre d'une attaque par déni de service. Cela pourrait cependant protéger l'attaquant contre l'identification.

• Une requête Ping honorée peut fournir des informations sur la structure interne d'un réseau. Ceci n'est pas pertinent pour les serveurs visibles publiquement, car ils sont déjà visibles publiquement.

• Il y avait des failles de sécurité dans certaines implémentations TCP / IP répandues, où un ping malformé demande pourrait planter une machine (le "ping de la mort"). Mais ceux-ci ont été dûment corrigés au cours du siècle précédent et ne sont plus un problème.

Il est courant de désactiver ou de bloquer Ping sur des serveurs visibles publiquement - mais en étant common n'est pas la même chose qu'être recommandé . www.google.com répond aux demandes Ping; www.microsoft.com ne le fait pas. Personnellement, je recommanderais de laisser passer tous les ICMP pour les serveurs visibles publiquement.

Certains types de paquets ICMP NE DOIVENT PAS être bloqués, en particulier le message ICMP "destination inaccessible", car le blocage on rompt la découverte du chemin MTU, les symptômes étant que les utilisateurs DSL (derrière une couche PPPoE qui limite la MTU à 1492 octets) ne peuvent pas accéder aux sites Web qui bloquent ces paquets (sauf s'ils utilisent le proxy Web fourni par leur FAI) .

ICMP a un composant de données. Il peut être utilisé pour construire des tunnels, et ce n'est pas seulement une chose théorique, il est disponible dans la nature. Il a été découvert par plusieurs chercheurs dans le cadre de boîtes à outils de logiciels malveillants. Sans oublier qu'il existe un guide pratique sur ce sujet, sans oublier le wiki, ou le hackaday

ICMPTX utilise l'écho ICMP et la réponse ICMP . ICMP echo n'est pas toujours inoffensif, car il contient un composant de données, il peut exfiltrer des données ou être utilisé comme canal de contrôle, ou être utilisé (dans le cas d'ICMPTX) comme protocole de tunnel.

Implémentation actuelle dans la distribution, avec howto, (ICMPTX): http://thomer.com/icmptx/

Scénario d'attaque réel utilisant la transmission de données ICMP pour injection de charge utile: Open Packet Capture

Utilisation d'un protocole de transmission de données ICMP via des méthodes similaires à ICMPTX (2006) pour les chevaux de Troie C&C et Exfiltration: Network World

Il est vrai qu'ICMP peut être utilisé par des attaquants pour obtenir des informations, transporter des données secrètement, etc. Il est également vrai qu'ICMP est extrêmement utile et que sa désactivation peut souvent causer des problèmes. Traceroute utilise en fait ICMP, donc interdire certains types d'ICMP le brisera.

La question met en évidence l'équilibre classique entre sécurité et fonctionnalité, et c'est à vous de déterminer combien de fonctionnalités vous êtes prêt à perdre pour gagner x niveau de sécurité.

Une recommandation est de n'autoriser que certains types (les plus couramment utilisés), et de désactiver tous les autres. Voici mes règles iptables. Gardez à l'esprit que ceux-ci sont autorisés car tout le reste est interdit par défaut.

  # Autoriser ICMP entrant: ping, découverte MTU, TTL expiré / sbin / iptables -A INPUT -i eth0 -p icmp -d $ YOURBOX --icmp-type 8/0 -j ACCEPT / sbin / iptables -A INPUT -i eth0 -p icmp -d $ YOURBOX --icmp-type 3/4 -j ACCEPTER / sbin / iptables -A INPUT -i eth0 -p icmp -d $ YOURBOX --icmp-type 11/0 -j ACCEPTER  

Je pense que la réponse d'écho sortante est plus dangereuse que la demande d'écho entrante en raison de l'amplification ICMP (soit limiter le débit, soit refuser ce trafic). Cependant, après des décennies de réflexion sur ce sujet, j'ai conclu que ICMP est plus dangereux qu'utile, et qu'il devrait donc être bloqué dans les deux sens, avec une connexion sur le trafic sortant potentiellement usurpé.

Le meilleur de tous les mondes sont des routes nulles sur tout ce qui pourrait être avec état mais indésirable (connexions TCP) et des ACL réflexives (axées sur les performances) pour tout ce qui est avec état mais autorisé et / ou pas entièrement avec état (datagrammes UDP), tout en supprimant d'autres Types de protocoles IP, car ils ne sont pas nécessaires. IPsec AH / ESP n'est pas nécessaire, utilisez OpenVPN (ou similaire) à la place.

Après avoir bloqué le traceroute ICMP, vous devez également faire face au traceroute basé sur UDP, ainsi que des concepts technologiques tels que ceux trouvés dans le 0trace, LFT et osstmm_afd.

Même si les scans Nmap Xmas ne sont pas captés par Snort / Suricata, et encore moins par les attaques SQLi ou Javascript (dans n'importe quelle direction), nous devons reconnaître l'importance des risques liées aux attaques de sécurité des réseaux et des applications contre les infrastructures modernes. Nous devrions refuser, tester et vérifier toute sorte de trafic d'empreinte - et je ne vois pas pourquoi cela n'inclurait pas ICMP, mais en réalité cela ne démarre ni ne s'arrête là.

Ping et Traceroute sont nécessaires pour dépanner les réseaux. Avec les pare-feu et les outils de sécurité modernes, il y a très peu de chances, et presque inexistantes, que l'un ou l'autre des protocoles soit utilisé avec succès de manière malveillante.

En 1996, c'était bien sûr un problème, mais nous sommes maintenant en 2015 près de 20 ans plus tard, et le blocage de ces derniers ne fait qu'accroître considérablement les délais pour résoudre la connectivité et les performances. Réduire la capacité des équipes de niveau 1/2 à identifier et à résoudre les problèmes simples de routage et de réseau est un problème de prestation de services qui a un impact sur la satisfaction du client à l'égard des services réseau que vous fournissez.

Au lieu de répondre à la question principale "Quels sont les risques de sécurité du ping", je répondrai à votre sous-question "Est-ce une bonne idée de bloquer / désactiver sur les serveurs Web de production"

Je pense que nous pouvons trouver ici un équilibre entre sécurité et utilité. Le personnel d'assistance trouve généralement le ping utile pour vérifier la latence ou la disponibilité d'un certain nœud. Le personnel de sécurité est préoccupé par de nombreux problèmes de sécurité décrits dans cette page, et sont souvent les "méchants".

Pourquoi ne pas envisager de désactiver Ping dans un format de liste blanche / liste noire, et faites-le savoir à votre assistance Personnel. Si votre public cible se trouve dans une certaine région géographique, limitez la capacité de ping en fonction de l ' allocation IP IANA

Après un premier accès à votre serveur, un logiciel malveillant peut utiliser le protocole ping comme moyen de communication avec son serveur de commande et de contrôle. A titre d'exemple, un shell inversé utilisant le protocole ping: https://github.com/inquisb/icmpsh

Dans "Exigence pour les hôtes Internet", une autorité respectée responsable de la normalisation des protocoles ICMP, TCP, IP et autres, l'IETF, spécifie que les hôtes doivent répondre aux requêtes ICMP. Donc non seulement la pratique est sûre, mais elle est considérée comme obligatoire pour se conformer à leurs normes:

Chaque hôte DOIT implémenter une fonction de serveur ICMP Echo qui reçoit les demandes d'écho et envoie les réponses d'écho correspondantes. Un hôte DEVRAIT également implémenter une interface de couche application pour envoyer une demande d'écho et recevoir une réponse d'écho, à des fins de diagnostic.

Dans le langage IETF standard, DOIT signifie que "l'élément est un absolu exigence de la spécification. " Alors que DEVRAIT signifie qu'il "peut exister des raisons valables dans des circonstances particulières d'ignorer cet élément, mais que toutes les implications doivent être comprises"

Cela signifie qu'un serveur doit répondre à une requête d'écho ICMP, mais ne peut pas leur fournir une interface utilisateur.

Le document fait référence à un vaste débat qui a eu lieu avant la date de la rédaction 1989:

"Cette disposition neutre résulte d'un passionné débat entre ceux qui estiment que l'écho ICMP à une adresse de diffusion fournit une capacité de diagnostic précieuse et ceux qui pensent qu'une mauvaise utilisation de cette fonctionnalité peut trop facilement créer des tempêtes de paquets. "

Même après des ( 2010) sur les attaques théoriques via ICMP sur RFC 5927, l'IETF n'a toujours pas rétrogradé les réponses ICMP ECHO d'un MUST à un DEVRAIT. La cible de cette RFC sont les fournisseurs et les implémenteurs d'ICMP et TCP, pas les consommateurs. Les pires scénarios décrits sont la dégradation du service.

En bref, ICMP est sûr. La désactivation n'est pas recommandée.

Si vous respectez les épaules des géants sur lesquels vous vous tenez, vous respecterez leur décision et éviterez de dévier des conventions.