Synchronisation horaire des systèmes informatiques

De nombreuses applications nécessitent une synchronisation avec la date/l'heure absolue (expiration de certificats, de licences ou de comptes, autorisation d'accès, ….) ou avec celle d'autres ordinateurs (services collaboratifs, authentification, … ).

Dans un environnement distribué (client serveur, montage NFS), une désynchronisation des différents systèmes entraîne des comportements erratiques sur de nombreuses applications (gestion de configuration, "makefiles", …), mais elle peut aussi être utilisée afin de conduire des attaques contres ces systèmes.

L'exemple du protocole d'authentification par tickets Kerberos est particulièrement intéressant.

Dans ce protocole un client s'identifie par un ticket dont une partie, appelée "authenticator" est cryptée et horodatée. L'horodatage prouve que le message est récent et qu'il n'est pas une recopie d'un ancien message.

Le serveur contrôle que la date de l'"authenticator" est :

• dans une certaine fourchette autour de sa propre date courante,
• unique pour ce client.

Si ces deux conditions sont remplies, le serveur continue le processus d'authentification avec le client, sinon il rejette le ticket.

Une personne malveillante qui aurait la possibilité de changer la référence horaire des machines d'un réseau pourrait donc facilement :

• faire accepter par un serveur Kerberos un ticket dont la date est périmée, et accéder ainsi illégalement à certaines ressources,
• faire refuser des tickets valides par un serveur Kerberos et conduire ainsi une attaque de type déni de service,
• provoquer un important trafic de synchronisation en modifiant fréquemment la date, et conduire ainsi une attaque de type déni de service,

Cette liste d'actions nuisibles n'est pas exhaustive.

Protocoles NTP et SNTP

Pour synchroniser les différentes machines d'un réseau il faut un protocole adapté. C'est le protocole NTP ("Network Time Protocol") décrit par la RFC ("Request For Comments") 1305.

NTP est un protocole sophistiqué permettant la synchronisation permanente depuis plusieurs serveurs, avec une correction des délais de transmission et des dérives horaires. Ses principales caractéristiques sont les suivantes :

• il est organisé de façon arborescente: les serveurs de "strate 1" sont synchronisés sur une source de référence (horloge, récepteur de temps codé, récepteur GPS...), ceux de "strate 2" se synchronisant sur un ou plusieurs serveurs de "strate 1", etc. Les serveurs sont généralement configurés pour utiliser plusieurs serveurs de référence (redondance en cas de panne ou information incohérente d'un serveur, ou panne d'une liaison),
• Il repose sur le protocole UDP (port 123),
• l'heure délivrée par les serveurs NTP est l'heure universelle UTC ("Universal Time Coordinated"), il appartient donc au client de gérer les fuseaux horaires et les changements d'heure été/hiver.

Une version simplifiée de NTP a été définie dans la RFC ("Request For Comments") 2030, c'est la protocole SNTP ("Simple Network Time Protoco"l).

Implémentations sécurisée de NTP et SNTP

Pour sécuriser la communication reposant sur un service (UDP) non sécurisé les protocoles NTP/SNTP définissent un champ d'authentification permettant de signer les paquets échangés.

Cependant ce champ est facultatif et les mécanismes de signature ainsi que d'échange et de contrôle de clés ne sont pas définis.

Une première préconisation est donc d'utiliser ce champ d'authentification, ou à défaut de signer le trafic de synchronisation horaire en utilisant IPSec.

Remarque : comme ce trafic ne contient pas d'information confidentielle il est inutile de le chiffrer.

Un des paramètres configurables définis par le protocole est la correction de temps maximale autorisée. Une valeur trop petite peut conduire à une désynchronisation (en cas d'arrêt prolongé d'un serveur par exemple), une valeur trop élevée ouvre la porte à des attaques de désynchronisation.

Une seconde préconisation est donc d'attribuer à ce paramètre la valeur la plus adaptée au réseau concerné (en générale inférieure à 15 minutes).

Les protocoles NTP/SNTP ne définissent pas clairement comment le système doit réagir à un cas de double réponse.

Une troisième préconisation est donc d'ignorer les doubles réponses tout en les journalisant et en alertant l'administrateur du réseau.

Exemple de "Windows Active Directory"

Avec "Windows 2000" Microsoft propose trois modes de synchronisation horaire différents :

Mode non synchronisé :

pas de synchronisation horaire, chaque machine utilise son horloge interne qui est considérée comme fiable vis à vis du réseau.

Mode de synchronisation manuelle :

chaque machine du réseau se synchronise avec une source NTP externe.

Ce mode n'est pas du tout sécurisé. Il n'utilise ni champ d'authentification ni clé, ne limite pas la valeur de correction de temps, et n'est pas protégé contre les doubles réponses.

Il est alors possible d'attaquer toute une 'forêt' "Windows Active Directory" avec un seul paquet UDP

Mode de synchronisation d'après la hiérarchie des domaines :

la synchronisation du réseau suit la hiérarchie des domaines windows.

Chaque machine se synchronise avec la machine dont elle dépend hiérarchiquement, via le protocole SNTP. Le champ d'authentification SNTP est utilisé et chaque paquet SNTP est signé avec la clé de la machine émettrice.

Conclusion :

Les possibilités d'implémentation des protocoles NTP ou SNTP offrent de nombreuses solutions adaptées à différentes tailles et architectures de réseau. Elles permettent de répondre à des exigences de sécurité plus ou moins fortes.

La sécurisation d'une implémentation de ces protocoles demande d'être attentif sur deux points:

• la communication qui repose sur UDP qui un protocole non sécurisé.
  Il est donc recommandé de mettre en œuvre différentes techniques de sécurisation de communication : signer le trafic, détecter et refuser les doubles réponses, …
• la gestion de la synchronisation horaire : utiliser des sources fiables, limiter judicieusement les corrections horaires automatiques.

Pour plus d'information :

• "Network Time Protocol (Version 3)", RFC 1305 : http://ietf.org/rfc/rfc1305.txt
• "Simple Network Time Protocol (SNTP) Version 4", RFC 2030 : http://ietf.org/rfc/rfc2030.txt
• "The Windows Time Service" : http://www.microsoft.com/windows2000/docs/wintimeserv.doc
• "Security aspects of time synchronization infrastructure", article de 3APA3A : http://www.security.nnov.ru/advisories/timesync.asp