Risque de sécurité de PING?
On m'a dit que PING présente un risque pour la sécurité, et c'est une bonne idée de le désactiver/bloquer sur les serveurs Web de production. Certains recherche me disent qu'il y a effectivement des risques de sécurité. Est-il courant de désactiver/bloquer PING sur des serveurs publiquement visibles? Et cela s'applique-t-il à d'autres membres de la famille ICMP, comme traceroute ( wikipedia sur la sécurité )?
Le ICMP Echo protocol (généralement connu sous le nom de "Ping") est principalement inoffensif. Ses principaux problèmes liés à la sécurité sont:
En présence de requêtes avec une fausse adresse source ("usurpation"), elles peuvent obliger 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, il n'y a donc pas d'effet multiplicateur: elle ne donnera pas de puissance supplémentaire à l'attaquant dans le contexte d'une attaque par déni de service. Cependant, cela pourrait protéger l'attaquant contre l'identification.
La requête Ping honorée peut fournir des informations sur la structure interne d'un réseau. Cela n'est cependant pas pertinent pour les serveurs visibles publiquement, car ceux-ci sont déjà visibles publiquement.
Il y avait des failles de sécurité dans certaines implémentations TCP/IP répandues, où une requête Ping malformée pouvait 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 une préoccupation.
Il est courant de désactiver ou de bloquer Ping sur des serveurs visibles publiquement - mais être commun n'est pas la même chose qu'être recommandé. www.google.com répond aux requêtes Ping; www.Microsoft.com ne 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 de celui-ci se casse découverte MTU du chemin , les symptômes étant que les utilisateurs DSL (derrière une couche PPPoE qui restreint MTU à 1492 octets) ne peuvent pas accéder aux sites Web qui bloquent ces paquets (à moins qu'ils n'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 différents comme faisant partie de malware toolkits. Sans oublier qu'il existe un howto proéminent sur ce sujet, sans parler du wiki , ou du 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 tunneling.
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 l'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 le C&C et l'exfiltration des chevaux de Troie: Network World
Il est vrai que ICMP peut être utilisé par des attaquants pour obtenir des informations, transporter des données secrètement, etc. Il est également vrai que 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 ICMP va le casser.
La question met en évidence l'équilibre classique entre sécurité et fonctionnalité, et c'est à vous de déterminer la quantité de fonctionnalités que 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.
# Allow incoming ICMP: ping, MTU discovery, TTL expired
/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 ACCEPT
/sbin/iptables -A INPUT -i eth0 -p icmp -d $YOURBOX --icmp-type 11/0 -j ACCEPT
Je pense que la réponse d'écho sortant est plus dangereuse que la demande d'écho entrant en raison de l'amplification ICMP (soit limiter la vitesse, 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 au trafic sortant potentiellement usurpé.
Le meilleur de tous les mondes est des routes nulles sur tout ce qui pourrait être avec état mais non désirées (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), tandis que suppression d'autres types de protocoles IP, car ils ne sont pas nécessaires. IPsec AH/ESP n'est pas nécessaire, utilisez plutôt OpenVPN (ou similaire).
Après avoir bloqué la traceroute ICMP, vous devez également faire face à la traceroute basée sur UDP, ainsi qu'aux concepts technologiques tels que ceux trouvés dans les outils 0trace, LFT et osstmm_afd.
Même si Nmap Les analyses de Noël ne sont pas détectées par Snort/Suricata, sans parler des attaques basées sur SQLi ou Javascript (dans toutes les directions), nous devons reconnaître l'importance des risques liés à la sécurité des réseaux et des applications. les attaques contre les infrastructures modernes. Nous devons 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 modernes et les outils de sécurité, il y en a très peu et à la limite des chances inexistantes que l'un ou l'autre protocole soit utilisé avec succès de manière malveillante.
En 1996, c'était certainement un problème, mais c'est maintenant 2015 presque 20 ans plus tard, et le blocage de ceux-ci ne fait que prolonger 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 avec les services réseau que vous fournissez.
Au lieu de répondre à la question principale de "quels sont les risques de sécurité du ping", je répondrai à votre sous-question de "Est-ce une bonne idée de bloquer/désactiver sur les serveurs Web de production"
Je pense que nous pouvons trouver un équilibre entre sécurité et utilité ici. Le personnel de support trouve généralement le ping utile lors de la vérification de la latence ou de 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 personnel d'assistance. Si votre audience principale se trouve dans une certaine région géographique, limitez la capacité de ping en fonction de allocation IP IANA
Après un accès initial à votre serveur, un logiciel malveillant peut utiliser le protocole ping comme moyen de communication avec son serveur de commande et de contrôle. À titre d'exemple, un shell inversé utilisant le protocole ping: https://github.com/inquisb/icmpsh