Sur cette page
À retenir
- Distinguer synchronisation et contrôleLes échanges horaires client/serveur et les requêtes d’administration n’ont pas le même rôle.
- Vérifier l’implémentation réelleLe comportement historique de monlist ne décrit pas tous les serveurs NTP actuels.
- Vérifier la synchronisation après filtrageUne application joignable ne prouve pas que ses sources de temps fonctionnent encore.
La réflexion repose sur une adresse source usurpée
Un réflecteur NTP répond à l’adresse source d’une requête. Si cette adresse est usurpée, une cible sans lien avec le service horaire peut recevoir les réponses. Il y a amplification lorsque la réponse est plus volumineuse que la requête initiale ; le trafic exact dépend de l’implémentation, de la requête et de la configuration.
L’abus historique de monlist concernait un ancien comportement de ntpd. Il ne faut pas le présenter comme une fonction active sur tous les déploiements NTP actuels. Identifiez l’implémentation et la version maintenue utilisées : les configurations de ntpd, NTPsec et chronyd ne sont pas interchangeables.
Chemin d’une réflexion NTP
- Requête usurpée
L’adresse source désigne la victime.
- Serveur de temps exposé
Une requête autorisée provoque une réponse.
- Entrée du réseau victime
Les réponses consomment de la capacité réseau et de traitement des paquets.
La synchronisation et les requêtes de contrôle sont distinctes
Dans l’échange client/serveur habituel, le mode NTP 3 correspond à une requête client et le mode 4 à une réponse serveur. Le mode 6 sert au contrôle ; le mode 7 est une catégorie privée propre à l’implémentation, associée à d’anciens outils. Tous les paquets provenant du port source UDP 123 ne représentent donc pas la même opération.
Une machine qui ne fournit pas de service horaire public peut avoir besoin de recevoir les réponses de ses propres sources de temps. Filtrer tous les paquets UDP/123 peut ainsi casser la synchronisation tout en semblant résoudre un pic de trafic. Relevez les pairs attendus et les échanges normaux avant de définir les exceptions.
Analyser l’incident en tenant compte du sens du trafic
Localiser la limite
Comparez les compteurs côté opérateur, tunnel et serveur aux pertes et aux échecs du service. Une capture en aval ne mesure pas les paquets déjà éliminés en amont. Distinguez la pression sur la bande passante de celle sur le traitement des paquets.
Examiner le contexte des paquets
Relevez les ports source et destination, le mode NTP lorsqu’il est décodable, le rôle de la destination et les tailles de paquets. Les réponses proviennent souvent du port source 123 ; ne regarder que le port de destination 123 peut manquer les réponses adressées à un autre port local du client.
Vérifier les requêtes réellement émises
Comparez les pairs horaires autorisés et l’activité récente du client. L’absence de requêtes dans une observation échantillonnée ou unidirectionnelle ne prouve pas une réflexion. Le chemin réseau peut être asymétrique et les relevés de flux ne contiennent pas forcément le mode NTP.
Mesurer les opérations légitimes
Vérifiez les transactions applicatives et l’état de synchronisation du service horaire. Surveillez l’écart de temps et la joignabilité des sources pendant une durée adaptée ; l’horloge système ne présente pas nécessairement d’erreur dès que les réponses cessent.
Restreindre le contrôle sans désactiver le service horaire
Maintenez le service horaire sur une version prise en charge et réservez les requêtes d’administration aux intervenants prévus. Un service horaire public n’exige pas un contrôle distant public. Appliquez les règles de l’implémentation réellement utilisée, en vérifiant l’exposition IPv4 et IPv6.
Dans les contrôles d’accès documentés pour ntpd 4.2.8, noquery interdit les requêtes ntpq/ntpdc sans interdire le service horaire. nomodify seul permet encore les requêtes en lecture. Ces explications décrivent les options ; elles ne constituent pas une configuration complète à copier dans une autre implémentation.
Examinez la liste d’accès effective, puis testez depuis un poste d’administration autorisé et un client horaire ordinaire. Préservez les pairs nécessaires, le fonctionnement des pools et la supervision. Planifiez redémarrage ou rechargement selon vos procédures ; affaiblir l’authentification ou supprimer toute supervision n’est pas une solution adaptée.
Filtrer avant la ressource saturée côté victime
Si la réflexion remplit le lien de livraison client, filtrer derrière ne rend pas la capacité perdue. Travaillez avec le réseau amont sur un motif de trafic vérifié et limité à la destination concernée. Si la bande passante reste disponible et que la pression est locale, une règle locale adaptée peut protéger le serveur.
Préservez les réponses horaires attendues et le trafic UDP sans rapport avec l’attaque. Une règle par port source n’inspecte pas tous les fragments et ne prouve pas qu’une réponse est non sollicitée. Vérifiez les critères de correspondance, les exceptions, le comportement de limitation et le retrait de la règle sur l’équipement récepteur.
En cas de détournement vers un chemin protégé, validez les routes et la livraison nettoyée autant que la règle. L’encapsulation n’ajoute pas de capacité de réception. Désignez un responsable de la politique temporaire et du retour au routage normal.
Exemple : un serveur de jeu également client NTP
Un serveur de jeu peut n’exposer aucun service horaire public alors que son système se synchronise avec des pairs distants. Pendant une suspicion de réflexion, bloquer globalement UDP/123 peut supprimer ensemble les réponses indésirables et les réponses horaires nécessaires. C’est un exemple de défaillance possible, pas un incident client mesuré.
La recette doit donc couvrir les connexions des joueurs, le trafic normal sur le chemin protégé et la joignabilité des sources de temps. Relevez le pair retenu, l’état de synchronisation et l’écart après filtrage, puis après retrait de la règle d’urgence. Un ping réussi ne suffit à valider ni l’application ni l’horloge.
Erreurs qui masquent un rétablissement incomplet
- Présenter l’amplification historique monlist comme le comportement de tous les services horaires modernes.
- Confondre ports source et destination ou supposer que toute réponse vise le port local 123.
- Appliquer la syntaxe d’un autre service horaire sans vérifier sa version et son modèle d’accès.
- Déclarer le service rétabli sur la seule baisse du graphique alors que la synchronisation reste rompue.
- Maintenir une règle d’urgence large après l’attaque sans retester le trafic légitime.
Questions fréquentes
La réflexion peut-elle viser un serveur qui ne fournit pas NTP ?
Oui. Les réponses peuvent être envoyées à son adresse usurpée. Il peut néanmoins avoir besoin de réponses NTP légitimes en tant que client.
noquery désactive-t-il la synchronisation horaire ?
Dans les contrôles d’accès ntpd 4.2.8 cités, cette option restreint les requêtes d’administration, pas le service horaire. Les autres règles et implémentations doivent être vérifiées séparément.
Comment démontrer que la mitigation fonctionne ?
Par une baisse du trafic indésirable, des transactions légitimes rétablies, des pertes acceptables et des sources de temps fonctionnelles sur le chemin réel de livraison. Aucun compteur de port isolé ne démontre tout cela.
