Network Time Protocol (NTP) : dé­fi­ni­tion et fonc­tion­ne­ment

Les horloges des systèmes in­for­ma­tiques cons­ti­tuent un outil précieux pour ceux qui sou­hai­tent connaître l’heure mais n’ont ni montre ni smart­phone à portée de main. L’utilité de l’heure du système pour l’uti­li­sa­teur est de notoriété publique, mais le fait que l’or­di­na­teur en ait lui-même besoin est re­la­ti­ve­ment peu connu. Les ho­ro­da­tages jouent en effet un rôle central pour tout ce qui a trait à la com­mu­ni­ca­tion entre deux systèmes ou plus, mais aussi et surtout pour assurer le bon dé­rou­le­ment des processus ou des services multi-réseaux. Le Network Time Protocol (NTP) a été édité en 1985 afin d’éviter les com­pli­ca­tions dans le système avec les heures non syn­chro­ni­sées.

Le Network Time Protocol (NTP) est le résultat des travaux de dé­ve­lop­pe­ment de David L. Mills, Pro­fes­seur à l’Uni­ver­sité du Delaware. La première spé­ci­fi­ca­tion of­fi­cielle du protocole, qui fait partie de la suite des pro­to­coles Internet, a été publiée en septembre 1985 dans la RFC 958. Le NTP y est défini comme un protocole de syn­chro­ni­sa­tion de plusieurs horloges d’un réseau à l’aide d’un ensemble de clients et de serveurs dis­tri­bués. Le Time Protocol ainsi que l’ICMP Timestamp message, dont les fonc­tion­na­li­tés ont été réunies dans le Network Time Protocol, sont con­si­dé­rés comme ses pré­cur­seurs. Le NTP est basé sur le User Datagram Protocol UDP qui permet un transport des données sans connexion. Le numéro de port UDP prévu à cet effet est 123.

Le NTP met à dis­po­si­tion des mé­ca­nismes de protocole fon­da­men­taux et né­ces­saires à la syn­chro­ni­sa­tion de l’heure de dif­fé­rents systèmes jusqu’à une précision de l’ordre de la na­no­se­conde. D’autre part, il contient des dis­po­si­tions visant à spécifier la précision et les sources d’erreur possibles de l’horloge système locale ainsi que les pro­prié­tés de l’heure de référence. Le protocole fixe toutefois uni­que­ment le type de pré­sen­ta­tion des données et les formats de messages, sans fournir per­son­nel­le­ment d’al­go­rithmes de syn­chro­ni­sa­tion et de filtrage.

Afin de syn­chro­ni­ser les horloges des or­di­na­teurs à la na­no­se­conde près, le Network Time Protocol utilise le Coor­di­na­ted Universal Time, appelé temps universel coordonné (UTC), ap­pli­cable uni­for­mé­ment depuis 1972. Ce dernier peut être déterminé par diverses méthodes, notamment à l’aide de systèmes radio et satellite. Les services im­por­tants tels que le Global Po­si­tio­ning System (GPS ; « système mondial de po­si­tion­ne­ment ») sont équipés de ré­cep­teurs spé­ci­fiques per­met­tant de capter les signaux cor­res­pon­dants. Étant donné qu’il ne serait ni rentable ni réa­li­sable d’équiper chaque or­di­na­teur de tels ré­cep­teurs, il existe par ailleurs des serveurs primaires (Primary Time Servers) disposant également d’un récepteur UTC. À travers des pro­to­coles comme le NTP, ces serveurs procèdent alors à la syn­chro­ni­sa­tion des horloges des or­di­na­teurs dans leur réseau.

Ce processus de syn­chro­ni­sa­tion dispose de dif­fé­rents niveaux hié­rar­chiques sym­bo­li­sant la distance par rapport à la source UTC, que l’on appelle également stratum (lat. pour « couches ») ou strate. L’ensemble des appareils tech­niques obtenant l’heure à partir d’un serveur primaire ou d’un système de na­vi­ga­tion par satellite sont classés dans la catégorie stratum 0. Les horloges atomiques ou ra­dio­pi­lo­tées en font notamment partie. Un or­di­na­teur obtenant l’UTC à partir d’une telle horloge atomique ou ra­dio­pi­lo­tée entre dans la catégorie stratum 1 et ainsi de suite. Chaque système est ainsi à la fois client du stratum précédent et serveur des systèmes du stratum suivant (tout du moins en théorie).

Les ca­rac­té­ris­tiques de base du Network Time Protocol, qui en est à sa quatrième version (NTPv4), peuvent être résumées comme suit :

• Le NTP prévoit une heure de référence qui sert de repère pour l’ensemble des processus de syn­chro­ni­sa­tion. Toutes les horloges sont donc alignées sur cette horloge/heure. Dès le départ, il a été décidé de baser le protocole sur le temps universel coordonné (UTC), reconnu comme base de temps uni­ver­selle.
• Le NTP est un protocole tolérant les défauts et re­cher­chant au­to­ma­ti­que­ment les meil­leures sources de temps pour la syn­chro­ni­sa­tion. Afin de diminuer les erreurs ac­cu­mu­lées, il est également possible de combiner plusieurs sources pour atteindre ce but. Dans la mesure du possible, le Network Time Protocol identifie et ignore les sources de temps four­nis­sant des valeurs nettement dif­fé­rentes, que ce soit de façon tem­po­raire ou durable.
• Le NTP est hautement évolutif : chaque réseau de syn­chro­ni­sa­tion peut comporter plusieurs heures de référence. D’autre part, chaque nœud de réseau est en mesure de diffuser les in­for­ma­tions tem­po­relles dans une structure hié­rar­chique de façon bi­di­rec­tion­nelle (de point à point) ou uni­di­rec­tion­nelle (dans une seule direction).
• Le NTP est ex­trê­me­ment précis. La pos­si­bi­lité de sé­lec­tion­ner le meilleur candidat pour la syn­chro­ni­sa­tion permet une ré­so­lu­tion de l’ordre de la na­no­se­conde (env. 2^-32 secondes).
• Le NTP peut combler les problèmes de connexion tem­po­raires du réseau : pour ce faire, le protocole utilise des valeurs de mesure an­té­rieures afin de dé­ter­mi­ner l’heure actuelle ou les écarts.

Ini­tia­le­ment, le Network Time Protocol a été développé spé­ci­fi­que­ment pour les systèmes UNIX dans lesquels ce protocole est toujours im­plé­menté sous la forme du processus d’arrière-plan (Daemons) NTPd. Ce dernier sert aussi bien de client pouvant syn­chro­ni­ser le système local que de serveur NTP pour d’autres systèmes. Pendant longtemps, ce service a par ailleurs été le premier choix parmi les dis­tri­bu­tions Linux pour l’im­plé­men­ta­tion du NTP. Pour la syn­chro­ni­sa­tion, les versions plus récentes se basent néanmoins de plus en plus sur l’ap­pli­ca­tion client timesyncd qui fait partie du ges­tion­naire de système. Aujourd’hui, les systèmes d’ex­ploi­ta­tion macOS et Windows ont également recours au Network Time Protocol afin d’obtenir l’UTC via Internet avec des processus système simples sans logiciel sup­plé­men­taire.

Bien que le NTP soit considéré comme le standard en matière de syn­chro­ni­sa­tion de l’heure dans le monde, il n’est pas in­fail­lible, notamment en ce qui concerne la sécurité. Étant basé sur un protocole UDP sans connexion, un hacker peut par exemple envoyer à un serveur NTP des paquets avec une fausse adresse d’ex­pé­di­teur (en usurpant une adresse IP. Ce faisant, l’adresse du système attaqué est choisie comme adresse d’ex­pé­di­teur. Le serveur renvoie sa réponse – nettement plus con­sé­quente que la demande envoyée par le hacker – à l’ex­pé­di­teur supposé, à savoir le système de la victime. Si le hacker procède de cette façon à grande échelle, en envoyant un nombre important de fausses requêtes de ce type, il peut sur­char­ger le système ciblé - voir également notre article DoS et DDoS : Pré­sen­ta­tion des types d’attaques.

En con­sé­quence, dif­fé­rents projets ont été consacrés au dé­ve­lop­pe­ment de solutions al­ter­na­tives plus sûres sus­cep­tibles d’être utilisées en rem­pla­ce­ment des ha­bi­tuelles solutions client/serveur NTP :

• tlsdate : tlsdate a été édité en 2012 par Jacob Appelbaum et publié sur GitHub. Pour le transport des données, tlsdate utilise le protocole TCP plutôt que UDP. Ce service procède au cryptage de la structure de connexion via TLS afin d’empêcher toute ma­ni­pu­la­tion des paquets de données. Par ailleurs, tlsdate utilise les fonc­tion­na­li­tés de TLS, « Ser­ve­rHello » et « Clien­tHello », afin de syn­chro­ni­ser l’heure. Cette al­ter­na­tive au NTP fonc­tionne toutefois uni­que­ment avec TLS 1.1 et 1.2.
• Ntimed : Ntimed est une im­plé­men­ta­tion du NTP qui se concentre spé­ci­fi­que­ment sur la sécurité et la per­for­mance. À cette fin, le code de programme de ntpd a été intégré à Ntimed dans une version épurée et optimisée. Le pack logiciel, composé des fichiers client, serveur et maître, est en libre accès dans le registre officiel Ntimed de GitHub.
• NTPsec : NTPsec est également une variante du service NTPd classique. Plus de 175 000 lignes de code ont toutefois été éco­no­mi­sées par rapport à l’original. L’équipe de dé­ve­lop­peurs a remplacé un grand nombre de fonctions string telles que « strcpy », « sprintf » ou « gets » par des équi­va­lents plus sûrs. Cette dif­fé­rence et d’autres sont dé­tail­lées sur le site Internet officiel du projet open source.

En plus des al­ter­na­tives lo­gi­cielles, on trouve également le Precision Time Protocol (PTP). Con­trai­re­ment au Network Time Protocol, ce protocole réseau pour les systèmes Linux se concentre ex­pli­ci­te­ment sur une précision par­ti­cu­liè­re­ment élevée de la syn­chro­ni­sa­tion. Dans le cas de PTP, cette précision est de l’ordre de la mi­cro­se­conde, dépassant même ainsi la précision de NTP. Ce protocole pose de plus des exigences minimales en termes de per­for­mance du pro­ces­seur et de bande passante du réseau, ce qui explique pourquoi il est des mieux adaptés aux appareils simples et peu coûteux.

Le projet pool.NTP.org initié par Adrian von Bidder et dirigé depuis juillet 2005 par Ask Bjørn Hansen porte sur un immense cluster virtuel composé de plus de 4 000 serveurs d'horloge NTP. La majeure partie des serveurs dis­tri­bués dans le monde et utilisés par plusieurs millions de systèmes se trouve en Europe. La crois­sance constante du pool de NTP au fil du temps est due aux efforts de la com­mu­nauté de ce projet réussi : toute personne disposant d’un serveur avec une adresse IP statique et connecté en per­ma­nence à Internet peut faire en­re­gis­trer ce serveur dans le cluster. Malgré une demande gran­dis­sante, le service peut donc être utilisé gra­tui­te­ment et sans res­tric­tions jusqu’à aujourd’hui.

Les personnes sou­hai­tant utiliser le pool de serveurs NTP afin de syn­chro­ni­ser l’heure de leurs appareils per­son­nels peuvent le faire sous UNIX ou Linux avec le service NTPd. Pour ce faire, il suffit de procéder aux réglages suivants dans le fichier de dérive NTP :

Le seul prérequis est que l’heure du système soit pa­ra­mé­trée au moins ap­proxi­ma­ti­ve­ment. Afin de consulter le statut du service NTPd, vous devrez saisir la commande suivante après quelques minutes :

Le client NTP affiche une liste des adresses IP de serveurs aléa­toires tirés du pool. Si l’un de ces serveurs est marqué d’une étoile (*), l’heure du système est à présent syn­chro­ni­sée de la façon désirée.