Utilisation abusive et abus du serveur NTP – Bien choisir son serveur d impression

Utilisation abusive et abus du serveur NTP couvre un certain nombre de pratiques qui endommagent ou dégradent un serveur NTP (Network Time Protocol), allant de l'inonder de trafic (en réalité une attaque DDoS) ou de violer la stratégie d'accès du serveur ou les règles d'engagement NTP. Un incident a été marqué Vandalisme NTP dans une lettre ouverte de Poul-Henning Kamp au fabricant de routeur D-Link en 2006.^[1] Ce terme a ensuite été étendu par d’autres pour inclure rétroactivement d’autres incidents. Cependant, rien n'indique que ces problèmes constituent du vandalisme délibéré. Ils sont généralement causés par des configurations par défaut à courte vue ou mal choisies.

Une forme délibérée d'abus de serveur NTP a été constatée à la fin de 2013, lorsque des serveurs NTP étaient utilisés dans le cadre d'attaques par déni de service d'amplification. Certains serveurs NTP répondraient à un seul paquet de demande UDP "monlist", avec des paquets décrivant jusqu'à 600 associations. En utilisant une requête avec une adresse IP usurpée, les attaquants pourraient diriger un flux amplifié de paquets vers un réseau. Cela s'est traduit par l'une des plus grandes attaques de déni de service distribuées connues à ce moment-là.^[2][3]

Problèmes courants du client NTP[[[[modifier]

Les problèmes les plus problématiques concernent les adresses de serveur NTP codées en dur dans le micrologiciel des périphériques réseau grand public. Étant donné que les principaux fabricants et équipementiers ont produit des centaines de milliers de périphériques NTP et que leurs clients ne mettent jamais à jour le micrologiciel de ces périphériques, les problèmes de tempêtes de requêtes NTP persisteront tant que les périphériques seront en service.

Une erreur de logiciel NTP particulièrement courante consiste à générer des paquets de requête à des intervalles courts (moins de cinq secondes) jusqu'à la réception d'une réponse.

• Lorsque de telles implémentations se trouvaient derrière des pare-feu agressifs qui bloquaient les réponses du serveur. Cela a conduit à un flux sans fin de demandes de clients aux différents serveurs NTP bloqués.
• De tels clients trop enthousiastes (en particulier ceux interrogeant une fois par seconde) représentent généralement plus de 50% du trafic des serveurs NTP publics, bien qu’ils ne représentent qu’une fraction infime du nombre total de clients.

Bien qu’il soit techniquement raisonnable d’envoyer quelques paquets initiaux à intervalles rapprochés, il est essentiel pour la santé de tout réseau que les nouvelles tentatives de connexion des clients soient générées à des taux décroissant de façon logarithmique ou exponentielle afin d’empêcher le déni de service.

Ce en protocole Le backdown exponentiel ou logarithmique s’applique à n’importe quel protocole sans connexion et, par extension, à de nombreuses parties de protocoles basés sur la connexion. Vous trouverez des exemples de cette méthode de sauvegarde dans la spécification TCP pour l’établissement de connexion, la vérification à fenêtre nulle et les transmissions persistantes.

Cas notables[[[[modifier]

Tardis et Trinity College, Dublin[[[[modifier]

En octobre 2002, l’un des premiers cas connus d’utilisation abusive du serveur de temps a entraîné des problèmes pour un serveur Web situé au Trinity College, à Dublin. Le trafic a finalement été attribué à des copies défectueuses d'un programme appelé Tardis^[4] avec des milliers de copies dans le monde entier, contacter le serveur Web et obtenir un horodatage via HTTP. En fin de compte, la solution consistait à modifier la configuration du serveur Web afin de fournir une version personnalisée de la page d'accueil (taille considérablement réduite) et de renvoyer une valeur de temps fictive, ce qui a amené la plupart des clients à choisir un serveur de temps différent.^[5] Une version mise à jour de Tardis a été publiée ultérieurement pour corriger ce problème.^{[[[[citation requise]}

Netgear et l'Université du Wisconsin – Madison[[[[modifier]

Le premier cas largement connu de problèmes de serveur NTP a commencé en mai 2003, lorsque les produits matériels de Netgear ont inondé de demandes le serveur NTP de l'Université du Wisconsin – Madison.^[6] Le personnel de l'université a d'abord supposé qu'il s'agissait d'une attaque malveillante par déni de service distribué et a pris des mesures pour bloquer les inondations à la frontière de leur réseau. Plutôt que de ralentir (comme le font la plupart des attaques DDOS), le flux a augmenté pour atteindre 250 000 paquets par seconde (150 mégabits par seconde) en juin. Une enquête ultérieure a révélé que quatre modèles de routeurs Netgear étaient à l'origine du problème. Il a été constaté que le client SNTP (Simple NTP) dans les routeurs présente deux défauts graves. Premièrement, il repose sur un seul serveur NTP (à l'Université du Wisconsin – Madison) dont l'adresse IP était codée en dur dans le micrologiciel. Deuxièmement, il interroge le serveur à une seconde d'intervalle jusqu'à ce qu'il reçoive une réponse. Au total, 707 147 produits ont été produits avec le client défectueux.

Netgear a publié des mises à jour de microprogrammes pour les produits concernés (DG814, ​​HR314, MR814 et RP614), qui interrogent les serveurs de Netgear, n'interrogent qu'une fois toutes les dix minutes et abandonnent après cinq défaillances. Bien que cette mise à jour corrige les failles du client SNTP d'origine, elle ne résout pas le problème plus important. La plupart des consommateurs ne mettront jamais à jour le micrologiciel de leur routeur, en particulier si le périphérique semble fonctionner correctement. Le serveur NTP de l'Université du Wisconsin – Madison continue de recevoir un trafic important des routeurs Netgear, avec des inondations occasionnelles allant jusqu'à 100 000 paquets par seconde.^{[[[[citation requise]} Netgear a fait un don de 375 000 dollars à la division des technologies de l’information de l’Université du Wisconsin-Madison pour l’aider à identifier la faille.^{[[[[citation requise]}

SMC et CSIRO[[[[modifier]

En 2003 également, un autre cas a contraint les serveurs NTP du laboratoire national de mesure du CSIRO (Commonwealth Scientific Research & Industrial Research Association) à se rapprocher du public.^[7] Il a été démontré que le trafic provenait d’une mauvaise implémentation NTP dans certains modèles de routeur SMC dans lesquels l’adresse IP du serveur CSIRO était incorporée dans le microprogramme. SMC a publié des mises à jour du microprogramme des produits: les modèles 7004VBR et 7004VWBR sont connus pour être affectés.

D-Link et Poul-Henning Kamp[[[[modifier]

En 2005, Poul-Henning Kamp, gestionnaire du seul serveur NTP danois Stratum 1 disponible pour le grand public, a observé une forte augmentation du trafic et a découvert qu'entre 75 et 90% des connexions provenaient des routeurs D-Link. Les serveurs NTP de la strate 1 reçoivent leur signal horaire d'une source externe précise, telle qu'un récepteur GPS, une horloge radio ou une horloge atomique calibrée. Par convention, les serveurs de temps Stratum 1 ne doivent être utilisés que par des applications nécessitant des mesures de temps extrêmement précises, telles que les applications scientifiques ou les serveurs Stratum 2 avec un grand nombre de clients.^[8] Un routeur de réseau domestique ne répond à aucun de ces critères. De plus, la politique d'accès du serveur de Kamp limitait explicitement ce dernier aux serveurs directement connectés au Danish Internet Exchange (DIX). L'utilisation directe de ce serveur et d'autres serveurs de la strate 1 par les routeurs de D-Link s'est traduite par une augmentation considérable du trafic, des coûts de bande passante et une charge de serveur accrus.

Dans de nombreux pays, les services de chronométrage officiels sont fournis par un organisme gouvernemental (comme le NIST aux États-Unis). Comme il n'y a pas d'équivalent danois, Kamp fournit son service horaire "pro bono publico". En retour, DIX a accepté de fournir une connexion gratuite à son serveur de temps en supposant que la bande passante impliquée serait relativement faible, en raison du nombre limité de serveurs et de clients potentiels. Avec l'augmentation du trafic provoquée par les routeurs D-Link, DIX a demandé à payer des frais de connexion annuels de 54 000 DKK^{[[[[citation requise]} (environ 9 920 USD ou 7 230 €^[9][10]).

Kamp a contacté D-Link en novembre 2005, dans l'espoir de le résoudre et de le dédommager du temps et de l'argent qu'il a consacrés à la recherche du problème et des frais de bande passante générés par les produits D-Link. La société a nié tout problème, l’a accusé d’extorsion de fonds et lui a offert une indemnité qui, selon Kamp, ne couvrait pas ses frais. Le 7 avril 2006, Kamp a publié l'article sur son site Web. L'histoire a été reprise par Slashdot,^[11]Reddit et d'autres sites de nouvelles. Après être devenu public, Kamp a réalisé que les routeurs D-Link interrogeaient directement d'autres serveurs de temps de la strate 1, violant ainsi les règles d'accès d'au moins 43 d'entre eux. Le 27 avril 2006, D-Link et Kamp ont annoncé qu'ils avaient "résolu à l'amiable" leur différend.^[12]

Fournisseurs informatiques et swisstime.ethz.ch[[[[modifier]

Depuis plus de 20 ans, l'ETH Zurich fournit un accès ouvert au serveur de temps swisstime.ethz.ch pour la synchronisation de l'heure opérationnelle. En raison d'une utilisation excessive de la bande passante, atteignant en moyenne 20 Go / jour, il est devenu nécessaire de diriger l'utilisation externe vers des pools de serveurs de temps publics, tels que ch.pool.ntp.org. Une mauvaise utilisation, causée principalement par les fournisseurs informatiques qui synchronisent leurs infrastructures client, a imposé des exigences exceptionnellement élevées au trafic réseau, obligeant ainsi l'ETH à prendre des mesures efficaces. À l'automne 2012^[update], la disponibilité de swisstime.ethz.ch a été modifiée pour un accès fermé. Depuis début juillet 2013^[update], l'accès au serveur est entièrement bloqué pour le protocole NTP.

Snapchat sur iOS[[[[modifier]

En décembre 2016, la communauté d'opérateurs NTPPool.org a constaté une augmentation significative du trafic NTP à compter du 13 décembre.^[13]

L'enquête a montré que l'application Snapchat exécutée sur iOS était sujette à l'interrogation tout Les serveurs NTP qui ont été codés en dur dans une bibliothèque NTP iOS tierce et qu'une demande adressée à un domaine appartenant à Snapchat ont suivi l'inondation de demandes NTP.^[14]

Après avoir contacté Snap Inc.,^[15] leurs développeurs ont résolu le problème dans les 24 heures suivant la notification avec une mise à jour de leur application.^[16] À titre d'excuses et pour aider à faire face à la charge générée, Snap a également fourni des serveurs de temps aux pools de PNT d'Australie et d'Amérique du Sud.^[17]

En tant qu'effet secondaire positif, la bibliothèque NTP utilisée est open source et les paramètres par défaut sujets aux erreurs ont été améliorés.^[18] après les commentaires de la communauté NTP.^{[19][20][[[[citation complète nécessaire]}

Test de connectivité sur des extensions TP-Link Wi ‑ Fi[[[[modifier]

Micrologiciel pour les extensions TP ‑ Link Wi ‑ Fi en 2016 et 2017, cinq serveurs NTP codés en dur, dont l'Université Fukuoka au Japon et les pools de serveurs NTP d'Australie et de Nouvelle-Zélande, et émettait à plusieurs reprises une demande NTP et cinq demandes DNS toutes les cinq secondes, avec une consommation de 0,72 Go. par mois et par appareil.^[21] Les demandes excessives ont été utilisées à mauvais escient pour lancer un contrôle de connectivité Internet indiquant l'état de connectivité du périphérique dans son interface d'administration Web.^[21]

La branche japonaise de TP-Link a reconnu le problème et l'a incité à revoir la conception du test de connectivité et à publier des mises à jour du micrologiciel pour résoudre le problème des périphériques concernés.^[22] Il est peu probable que les périphériques concernés installent le nouveau micrologiciel, car les extensions WiFi de TP-Link n’installent pas automatiquement les mises à jour du micrologiciel et n’informent pas le propriétaire de la disponibilité de ces mises à jour.^[23] La disponibilité des mises à jour du micrologiciel TP-Link varie également selon les pays, même si le problème concerne tous les modules d'extension de portée WiFi vendus dans le monde.^[21][23]

Les serveurs de l'Université de Fukuoka auraient été arrêtés entre février et avril 2018 et devraient être supprimés des listes de serveurs de temps public NTP.^[24]

Solutions techniques[[[[modifier]

Après ces incidents, il est devenu clair que, outre la déclaration de la politique d'accès d'un serveur, un moyen technique de faire appliquer une politique était nécessaire. L’un de ces mécanismes a été fourni par l’extension de la sémantique d’un Champ Identifiant de référence dans un paquet NTP quand un Strate terrain est 0.

En janvier 2006, la norme RFC 4330 a été publiée. Elle actualisait les détails du protocole SNTP, mais clarifiait et étendait provisoirement le protocole NTP associé dans certaines zones. Les sections 8 à 11 de la RFC 4330 présentent un intérêt particulier pour ce sujet (Le paquet Kiss-o'-Death, Pour être un bon citoyen du réseau, Meilleures pratiques, Considérations de sécurité). La section 8 présente les paquets Kiss-o'-Death:

Dans NTPv4 et SNTPv4, les paquets de ce type sont appelés paquets Kiss-o'-Death (KoD) et les messages ASCII qu'ils véhiculent sont appelés codes kiss. Les paquets KoD ont reçu leur nom car une des premières utilisations consistait à demander aux clients de cesser d’envoyer des paquets violant les contrôles d’accès au serveur.

Les nouvelles exigences du protocole NTP ne fonctionnent pas de manière rétroactive, et les anciens clients et les implémentations de la version antérieure du protocole ne reconnaissent pas KoD et n'agissent pas en conséquence. Pour le moment, il n'existe aucun moyen technique efficace pour lutter contre l'utilisation abusive des serveurs NTP.

Références[[[[modifier]

Liens externes[[[[modifier]