NTP : la synchronisation temporelle avec Chrony

I. Présentation

On a déjà mentionné l’utilisation d’une synchronisation temporelle de type NTP dans des tutoriels ou des cours. Mais, je veux aujourd’hui vous parler d’un petit utilitaire qui peut parfaitement effectuer le travail du protocole NTP : à savoir chrony et de ses outils, permettant de mettre en place une synchronisation temporelle efficace et sécurisée sur l’ensemble des serveurs d’une même infrastructure.

Son installation est des plus simples et son utilisation est vraiment basique, ce qui fait de ce logiciel un allié précieux pour ce qui touche à la synchronisation de l’horloge des machines d’un réseau. Chrony s’appuie sur une implémentation souple du protocole Network Time Protocol (abrégé en NTP). Il est utilisé pour synchroniser les horloges système de différents serveurs NTP, ou d’horloges de référence, ou encore pour être manipulé de façon manuelle.

L’outil Chrony est généralement installé avec deux programmes essentiels à son bon fonctionnement :

• chronyc offrant une interface en ligne de commande pour Chrony
• chronyd étant le daemon du service piloté au démarrage du système

II. Installation de chrony

Nous effectuerons cette installation sur une distribution CentOS7, aussi, la commande à exécuter est la suivante :

# yum -y install chrony

Bien évidemment, sur un système un tant soit peu sécurisé, il n’est pas nécessaire d’utiliser le compte root pour piloter Chrony. On peut parfaitement exécuter la commande depuis un compte avec délégation :

$ sudo yum -y install chrony

Après son installation, il convient de démarrer le service via la commande suivante :

$ sudo systemctl start chronyd

Il faut également vérifier son état afin de voir s’il n’y a eu aucune erreur au démarrage. Il suffit d’exécuter la commande ci-dessous :

$ sudo systemctl status chronyd

Il convient également d’activer le service dès le démarrage du système. Pour cela, on doit alors exécuter la commande suivante :

$ sudo systemctl enable chronyd

Normalement, on devrait voir l’affichage suivant :

III. Vérification de synchronisation

Afin de vérifier si le serveur est actuellement synchronisé il suffit d’utiliser la commande chronyc avec l’option tracking.

$ sudo chronyc tracking

Cette dernière fournit des informations précise sur l’état de la synchronisation temporelle :

Quelques explications concernant les différentes valeurs. On trouve en premier lieu, la référence temporelle Reference ID (à la fois sous forme d’une chaîne hexadécimale (5^E171485) et aussi sous la forme littérale correspondant au serveur de référence (ici, il s’agit du serveur ah.e-lista.pl), dont l’adresse est 94.23.20.133.

Ensuite, on trouve respectivement les valeurs suivantes :

• Stratum: nombre de sauts pour atteindre l’horloge de référence
• Ref time: représentant le temps UTC de la référence à la source
• System time: délai de synchronisation de l’horloge de référence
• Last offset: offset estimé depuis la dernière synchronisation
• RMS offset: moyenne à long terme de la valeur d’offset
• Frequency: taux d’erreur en cas de non-correction par chronyd
• Residual freq: différence entre la mesure source et la fréquence utilisée
• Skew: taux d’erreur estimé de la fréquence
• Root delay: délai total de parcours du réseau du serveur de stratum
• Leap status : peut avoir la valeur normal, insert second, delete second ou not synchronized.

Après quoi, on peut vérifier la ou les sources de synchronisation en interrogeant encore la commande chronyc avec l’option sources :

$ sudo chronyc sources

Cela permet de faire afficher l’ensemble des sources de synchronisation. Celle utilisée par défaut est marquée d’un caractère ‘*’ en début de ligne :

IV. Configuration de chrony

La configuration de Chrony se fait via le fichier /etc/chrony.conf pour une distribution CentOS. Dans le fichier on trouve généralement les lignes principales suivantes :

# NTP servers à utiliser pour la synchronisation
server 0.centos.pool.ntp.org iburst
server 1.centos.pool.ntp.org iburst
server 2.centos.pool.ntp.org iburst
server 3.centos.pool.ntp.org iburst

# Quelle distance doit être ajoutée par stratum à la synchronisation source
stratumweight 0

# localisation et nom du fichier contenant les données de drift
driftfile /var/lib/chrony/drift

# correction automatique graduelle en accélérant ou ralentissant l’horloge
makestep 10 3

# Fichier de traces et logs
logdir /var/log/chrony

REMARQUE : on peut également souhaiter fixer l’horloge système immédiatement et ignorer les ajustements de configuration. Pour cela, on doit exécuter la commande ci-dessous.

$ sudo chronyc makestep

Une modification importante consiste à forcer la synchronisation via des serveurs français pour être au plus près de notre infrastructure. Pour cela, il suffit de fixer les serveurs aux valeurs suivantes :

server 0.fr.pool.ntp.org iburst
server 1.fr.pool.ntp.org iburst
server 2.fr.pool.ntp.org iburst
server 3.fr.pool.ntp.org iburst

Si l’on souhaite limiter Chrony à la machine locale on doit indiquer dans le fichier de configuration les lignes suivantes :

allow 127/8
bindcmdaddress 127.0.0.1

Il est également possible de transformer le serveur Linux en serveur NTP. Pour se faire, le port UDP/123 réservé au protocole NTP doit être ouvert et il suffit ensuite d’ajouter les lignes ci-dessous au fichier de configuration :

allow 127/8
allow 10/8
allow 172.16/12
allow 192.168/16
bindcmdaddress 0.0.0.0

V. Sécurisation de chrony

Étant donné que l’accès via chronyc autorise à modifier le daemon chronyd à l’instar de la modification directe au travers du fichier de configuration, l’accès à chronyc doit être restreinte. On peut ainsi spécifier des mots de passe en ASCII ou hexadécimal, dans un fichier de clé afin de limiter l’utilisation de la commande chronyc.

Une directive est utilisée pour restreindre l’utilisation de commandes opérationnelles et est désignée comme étant la commande clé. Dans la configuration par défaut de chronyc, une commande clé de commande aléatoire est automatiquement générée à l’initialisation du service. On ne devrait donc pas à avoir à la spécifier ou à la modifier manuellement.

REMARQUE : il existe d’autres directives dans le fichier clé pouvant être utilisées comme clé NTP afin d’authentifier les paquets reçus de serveurs ou d’unités NTP distantes.

Les deux membres d’un échange NTP doivent partager une clé avec un identifiant (que l’on retrouve dans le champ Reference ID), un type de hachage et un mot de passe identique, au sein de leur fichier de clé. Cela nécessite alors la génération manuelle des clés. Il faut également les copier au moyen d’une méthode sécurisée telle que SSH.

En résumé, si l’identifiant clé est 25, alors les systèmes agissants en tant que client doivent disposer d’une ligne dans leur fichier de configuration sous le format suivant :

server A.B.C.D key 25
peer A.B.C.D key 25

L’emplacement du fichier de clé est généralement mentionné dans le fichier /etc/chrony.conf. L’entrée par défaut est spécifiée sous la forme :

keyfile /etc/chrony.keys

Le numéro de la clé de commande est également mentionné dans le fichier de configuration via la directive commandkey. Cela mentionne la clé que le daemon chronyd utilisera pour l’authentification des commandes utilisateurs :

commandkey 1

Voici un exemple du format que le fichier /etc/chrony.keys peut prendre :

En début de ligne on retrouve l’ID de la clé (ici 1), suivi du mode de hachage (SHA1) et du format de la clé en hexadécimal. Cette clé est générée aléatoirement lorsque le daemon a été initialisé pour la première fois. Une entrée manuelle dans le fichier de clé, utilisée pour authentifier les paquets de certains serveurs ou référence NTP peut être aussi simple que la ligne suivante :

25 MyKey

25 est bien sûr l’identifiant clé et ‘MyKey’ est la clé d’authentification secrète. Par défaut, le hachage utilisé est MD5 et le format de la clé est présenté sous forme ASCII.

De plus, par défaut, le daemon chronyd est configuré pour écouter les commandes en provenance de localhost (127.0.0.1 et/ou ::1 en IPv6), sur le port 323. Ainsi, pour accéder à chronyd à distance via la commande chronyc, toutes les directives bindcmdaddress devront être supprimées du fichier de configuration, afin de permettre l’écoute sur toutes les interfaces pour l’ensemble des interfaces.

Toutefois, la directive cmdallow devra être activée pour autoriser uniquement les commandes en provenance de l’adresse IP distante. On peut également sélectionner un réseau ou un sous-réseau distant. Bien sûr, le port 323 doit être ouvert au niveau des pare-feu pour autoriser les connexions d’un système distant.

REMARQUE : la directive allow permet l’accès NTP et la directive cmdallow active la réception des commandes distantes. Il ne faut les confondre. Toutefois, on peut activer une option via le mode interactif chronyc. Mais, pour rendre les modifications permanentes, il faut modifier le fichier /etc/chrony.conf et redémarrer le service.

L’utilisation de ce service doit être autorisé en exécutant les commandes authhash et password suivante :

chronyc> authhash SHA1
chronyc> password HEX:7A2A67C0DBC1F0F16651B233EAC17361E81EA765

Si la commande chronyc est utilisée pour configure le daemon local chronyd, ces commandes peuvent être passées directement via l’option -a.

VI. Conclusion

Voilà, cela fait un moyen supplémentaire sécurisé d’ajuster la synchronisation temporelle entre serveurs. Il s’agit là d’une technique simple et pratique. Le seul package à installer est celui de Chrony. De plus, cet utilitaire fournit une interface en ligne de commande permettant de dialoguer interactivement avec le système :

Rien de mieux pour interroger les différentes commandes et connaître les options à utiliser dans un script ou une tâche planifiée. Les communications entre le daemon chronyd et le mode commande chronyc s’effectue en UDP. Il convient évidemment de l’autoriser pour pouvoir exécuter des commandes opérationnelles.

Philippe PIERRE

A exercé de nombreuses années en tant qu'administrateur de base de données et comme administrateur Système Unix/Linux. Il a enseigné les réseaux au CNAM (Paris). Aujourd'hui, employé en tant qu'ingénieur infrastructure, au sein d'un laboratoire pharmaceutique et administrant un cluster de calculs HPC, il connaît parfaitement les environnements GNU/Linux dans le cadre d'une entreprise et des systèmes de haute disponibilité. Il aime partager son expérience.

See Full Bio