Lead-analytics

Sécurité du temps informatique | Sécurité
Lost Password?

A password will be emailed to you. You will be able to change your password and other profile details once you have logged in.

Sécurité du temps informatique

Stéphane REYTAN, BlueTrusty

Avis d'expert par Stéphane Reytan, BlueTrusty

L’importance du temps en informatique

Sans heure fiable, la plupart des systèmes informatiques vont défaillir : expiration de mots de passe, non validité erronée des certificats SSL (rendant la navigation sur Internet quasiment impossible), désynchronisation des clusters de calcul et de stockage, tâches planifiées lancées au mauvais moment ou pas du tout, gestion non fidèle de la rétention des sauvegardes et des logs…

Les recommandations de l’ANSSI concernant le temps informatique.

L’ANSSI a publié en 2013 des recommandations de sécurité pour la mise en œuvre d’un système de journalisation [1] qui s’appliquent évidemment aux Opérateurs d’Importance Vitale (OIV) et aux Opérateurs de Services Essentiels (OSE).

On y notera la recommandation n°3 :

Les horloges des équipements doivent être synchronisées sur plusieurs sources de temps internes cohérentes entre elles. Ces sources pourront elles-mêmes être synchronisées sur plusieurs sources fiables externes, sauf pour les réseaux isolés. [..] il est important d’adopter une logique de configuration adéquate afin d’assurer une cohérence temporelle des journaux au niveau des serveurs de collecte

Le protocole NTP est cité : on voit ainsi que la notion de cohérence est centrale, et que la précision absolue en est absente. En contrepartie l’accent est mis sur la fiabilité des sources externes.

Faiblesses de NTP dans son usage actuel

De nombreux systèmes d’exploitation s’appuient sur des “pools” de serveurs NTP (exemple pool.ntp.org ou encore time.windows.com) publiés sur Internet : ce sont des sources disponibles gratuitement et de façon pratique (souvent préconfigurées au niveau des systèmes d’exploitation) mais dont la fiabilité à l'émission et à la réception est difficile à évaluer.

En effet, le système étant souvent communautaire [V], l’identité de certains propriétaires de ces sources est inconnue ou non établie.

Supposons néanmoins que l’on dispose d’une source de confiance disponible sur Internet, est-il possible de sécuriser le transport du temps ?

A vrai dire, pas vraiment…

NTP est un protocole dont les spécifications datent de plus de 10 ans : la version n°4 fut publiée dans la RFC 5905 en 2010 [Z]. Sa sécurité est très difficile à assurer : la RFC 7634 [X] détaille de façon exhaustive les attaques (manipulation et/ou interception de paquets, spoofing, rejeu, attaques de type déni de service éventuellement distribué, attaques sur les ressources par calculs cryptographiques inutiles, serveur grandmaster “voyou”, etc.. ), leurs pré-requis (attaquant positionné en interne, externe, ou sur le chemin) et leurs impacts éventuels : inexactitude ou dérive du temps, déni de service.

Pour les implémentations actuelles, les bonnes pratiques de sécurisation du flux NTP sont décrites dans la RFC 8633 [X] datée de Juillet 2019. La principale mesure de sécurité utilisée est l’authentification des messages via l’utilisation d’un secret partagé : une clé de chiffrement symétrique (MD5 traditionnellement, AES-128-CMAC plus récemment) pour signer les messages. Cette clé est statique et devrait être renouvelée périodiquement.

Malheureusement, il n’existe pas de mécanisme de gestion du cycle de vie de cette clé (distribution, expiration). Plus exactement, l’extension de sécurité au protocole NTP nommée AutoKey [Y], dont le but était d’automatiser le renouvellement des clés d’authentification, comporte des vulnérabilités critiques et doit donc être désactivée [W].

NTS, une nouvelle extension qui permettra de mieux sécuriser NTP

Pour pallier à ces failles, un nouveau mécanisme additionnel est en cours d’approbation auprès de l’IETF : “Network Time Security (NTS) extension for NTPv4” [U], dans une RFC en révision n°28 à l’heure de l’écriture de ces lignes. En première approximation, c’est TLS 1.2+ qui permet de réaliser l’authentification et les échanges de clé, puis le flux NTPv4 “classique” se met en place.

Des implementation logicielles expérimentales sont en cours de finalisation et des essais d'interopérabilité sont réalisés régulièrement. Sur Linux, par exemple, le projet NTPSec [E] a “forké” le composant logiciel historique “ntpd” sous le nom “ntpsec” et propose des packages [D] pour la plupart des distributions récentes (la v1.1.8+ est nécessaire pour utiliser NTS). Il existe également le composant logiciel “chrony”[L] qui supporte NTS à partir de sa version non-stable 4.0 [K]. Si les binaires seront à mettre jour, peu de modifications seront à apporter aux fichiers de configuration NTP existants.

Des serveurs publiquement et gratuitement accessibles sur Internet proposent du temps NTS, les plus connus étant celui du service américain de CDN Cloudflare (nts.cloudflare.com:1234)et de celui de la Poste Suédoise (opéré par NetNod [F], qui vise à se conformer à la directive européenne NIS, nts.ntp.se:4443). Notez l’ajout de l’usage de TCP et les ports distincts, pour la négociation TLS, alors qu’historiquement seul UDP:123 était utilisé universellement.

Des vulnérabilités subsiteront

Cependant NTS ne résoudra pas toutes les problématiques dans le cas de réseaux cloisonnés -donc sans accès à Internet- ou bien de criticité de la disponibilité et de l’authentification du service de temps, contexte bien connu des OIV et OSE.

Dans ce cas, la meilleure alternative reste de s'équiper de “boîtiers” NTP qui récupèrent le temps via les ondes radios (idéalement via le “signal horaire” [G]) ou par GPS (système extra-européen, à moins d’utiliser explicitement GALILEO [H]) et de le distribuer ensuite localement sur les réseaux IP via NTP (éventuellement avec l’usage de l’extension NTS). Les ondes radio et les signaux satellitaires sont bien sûr vulnérables mais demandent des moyens plus conséquents qu’un simple DDoS sur une accès Internet.

Notons d’ailleurs, dans le contexte actuel de recherche de souveraineté, qu’il existe des sociétés françaises [I] qui conçoivent et fabriquent des solutions combinant matériel et logiciel permettant d’atteindre le meilleur niveau de sécurité dans la distribution du temps informatique.

Références

[1] ttps://www.ssi.gouv.fr/uploads/IMG/pdf/NP_Journalisation_NoteTech.pdf
[V] https://manage.ntppool.org/manage
[Z] https://tools.ietf.org/html/rfc5905
[X] https://tools.ietf.org/html/rfc7384
[Y] https://tools.ietf.org/html/rfc5906
[W] https://lists.ntp.org/pipermail/ntpwg/2011-August/001714.html
[J] https://tools.ietf.org/html/rfc8633
[U] https://tools.ietf.org/html/draft-ietf-ntp-using-nts-for-ntp-20
[D] https://repology.org/project/ntpsec/versions
[E] https://docs.ntpsec.org/latest/NTS-QuickStart.html
[F] https://www.netnod.se/about-netnod/netnod-history
[G]https://www.anfr.fr/gestion-des-frequences-sites/signal-horaire/quest-ce-que-le-signal-horaire/
[H]https://gssc.esa.int/navipedia/index.php/Time_References_in_GNSS#Galileo_System_Time_.28GST.29
[K] https://git.tuxfamily.org/chrony/chrony.git/tree/NEWS
[L] https://chrony.tuxfamily.org/
[I] https://www.bodet-time.com/fr/renforcez-la-securite-de-votre-reseau.html


Partager cet article




Sur le même sujet...

Aucun Commentaire