Guide des ports NTP : synchronisation horaire sur UDP 123

Un client NTP envoie périodiquement une requête à un ou plusieurs serveurs de temps via UDP 123. Le serveur renvoie des horodatages qui permettent au client d'estimer le décalage, le retard et la gigue, puis le client ajuste son horloge locale sans effectuer de sauts perturbateurs, sauf si la dérive est trop importante.

Les déploiements NTP sont souvent organisés en strates. La strate 0 est une horloge de référence telle qu'un GPS ou une source atomique. Les serveurs de strate 1 se connectent directement à ces références, et les serveurs de strate inférieure distribuent le temps plus loin dans le réseau. La plupart des organisations doivent utiliser des sources en amont fiables et fournir un NTP interne à leurs propres systèmes.

Un client NTP a besoin d'un accès sortant à UDP 123 vers ses sources de temps configurées. Un serveur NTP a besoin de l'UDP 123 entrant en provenance des clients qu'il est censé servir. Ce sont des questions de pare-feu différentes, et les mélanger est une source courante de synchronisation temporelle interrompue.

Les postes de travail et les serveurs d'applications agissent généralement uniquement en tant que clients. Les contrôleurs de domaine, les appareils de temps réseau, l'infrastructure de surveillance et les hubs de temps internes peuvent servir de serveurs pour le reste de la flotte.

Autoriser l'UDP 123 sortant à partir de systèmes qui doivent se synchroniser avec des sources horaires externes ou internes fiables. Autorisez UDP 123 entrant uniquement sur les serveurs qui fournissent intentionnellement NTP aux clients connus.

N'exposez pas largement un serveur NTP à Internet à moins qu'il ne soit intentionnellement exploité comme un service de temps public avec des contrôles de capacité, de limitation de débit, de surveillance et d'abus. Un NTP public mal configuré peut être utilisé à mauvais escient pour des attaques par réflexion et par amplification.

Avant d'autoriser UDP 123, décidez quels systèmes sont des clients, quels systèmes sont des serveurs et quelles sources de temps en amont sont fiables. Vérifiez si votre environnement utilise chrony, systemd-timesyncd, ntpd, Windows Time Service, une hiérarchie de domaines ou une appliance dédiée.

Un vérificateur de port peut aider à l'accessibilité, mais la synchronisation temporelle doit également être vérifiée au niveau du protocole et de l'horloge. Utilisez chronyc, ntpq, w32tm, timedatectl ou des données de surveillance pour confirmer le décalage, la strate, la sélection de source et la dérive.

Sur les domaines Windows, le service de temps Windows synchronise généralement les membres du domaine via la hiérarchie du domaine, avec l'émulateur PDC configuré par rapport aux sources en amont approuvées. Les serveurs Windows autonomes peuvent être configurés avec w32tm et des règles de pare-feu pour UDP 123 lorsqu'ils sont en service.

Sous Linux, chrony est courant sur les distributions modernes, tandis que ntpd et systemd-timesyncd apparaissent également. Configurez des pools de confiance ou des serveurs internes, autorisez UDP 123 uniquement lorsque l'hôte fournit du temps et surveillez le décalage et l'état de la source.

Sur les périphériques réseau, les commutateurs de point, les routeurs, les pare-feu et les appareils au niveau des sources NTP internes lorsque cela est possible. L'heure précise de l'appareil rend les journaux, les certificats, les VPN et les enquêtes sur les incidents beaucoup plus fiables.

Commencez par vérifier si UDP 123 est accessible entre le client et le serveur de temps prévu. Vérifiez ensuite la synchronisation réelle avec le suivi chronyc, les sources chronyc, ntpq -p, timedatectl timesync-status ou w32tm /query /status selon la plateforme.

Si vous utilisez un serveur NTP, testez à partir d'un réseau client connu et confirmez que les réseaux non autorisés ne peuvent pas l'interroger. Pour les services accessibles sur Internet, surveillez le volume des demandes et les modèles de réponse, car l’accessibilité à elle seule ne prouve pas une configuration sûre.

Si NTP ne se synchronise pas, le client peut être bloqué depuis UDP 123, en utilisant le mauvais serveur, en rejetant une source en raison d'un décalage élevé ou en étant incapable de résoudre le nom d'hôte du serveur de temps. Les machines virtuelles peuvent également dériver si l'heure de l'hôte, les outils invités et NTP s'affrontent.

Si un serveur est accessible mais que les clients dérivent toujours, inspectez la strate, l'état du saut, la sélection de la source, l'état du pare-feu, le comportement NAT et si plusieurs systèmes horaires sont configurés en même temps. Pour les domaines Windows, vérifiez la hiérarchie temporelle du domaine avant de modifier chaque hôte individuellement.

Limitez les personnes pouvant interroger vos serveurs NTP, désactivez les commandes obsolètes à forte amplification, maintenez les logiciels NTP corrigés et surveillez les pics de trafic inhabituels. Préférez la distribution de temps interne plutôt que de laisser chaque hôte interroger des serveurs publics aléatoires.

Pour les environnements importants, utilisez plusieurs sources horaires fiables, alertez en cas de décalage excessif, documentez le chemin temporel faisant autorité et incluez la synchronisation temporelle dans les contrôles de réponse aux incidents. Un mauvais moment peut interrompre les certificats, l'authentification, la corrélation des journaux et les tâches planifiées.