Comment s'assurer que le temps ne s'arrête pas si vous disposez d'un million d'appareils, petits et grands, communiquant via TCP/IP ? Après tout, chacun d’eux a une horloge, et l’heure doit être correcte pour chacun d’eux. Ce problème ne peut être contourné sans ntp.
Imaginons un instant que dans un segment de l’infrastructure informatique industrielle, il soit difficile de synchroniser les services au fil du temps. Immédiatement, la pile de clusters de logiciels d'entreprise commence à échouer, les domaines se désintègrent, les nœuds maîtres et de secours s'efforcent en vain de restaurer le statu quo.
Il est également possible qu'un attaquant tente délibérément de perturber l'heure via une attaque MiTM ou DDOS. Dans une telle situation, tout peut arriver :
- Les mots de passe des comptes utilisateur expireront ;
- Les certificats X.509 expireront ;
- L'authentification à deux facteurs TOTP cessera de fonctionner ;
- les sauvegardes deviendront obsolètes et le système les supprimera ;
- DNSSec va se briser.
Il est clair que chaque service informatique s'intéresse au fonctionnement fiable des services de synchronisation horaire, et ce serait bien s'ils étaient fiables et sûrs en exploitation industrielle.
Briser NTP en 25 minutes
Protocoles réseau : les millennials ont une particularité, ils ont été et ne servent plus à rien, mais les remplacer n'est pas si facile, même lorsqu'une masse critique de passionnés et de financements est accumulée.
Le principal reproche au NTP classique est le manque de mécanismes fiables de protection contre les attaques d’intrus. Diverses tentatives ont été faites pour résoudre ce problème. Pour y parvenir, nous avons d’abord implémenté un mécanisme de clé pré-partagée (PSK) pour échanger des clés symétriques.
Malheureusement, cette méthode n’a pas porté ses fruits pour une raison simple : elle n’est pas bien évolutive. Une configuration manuelle est requise côté client en fonction du serveur. Cela signifie que vous ne pouvez tout simplement pas ajouter un autre client comme ça. Si quelque chose change sur le serveur NTP, tous les clients doivent être reconfigurés.
Ensuite, ils ont proposé AutoKey, mais ils ont immédiatement découvert un certain nombre de vulnérabilités graves dans la conception de l'algorithme lui-même et ont dû l'abandonner. Le fait est que la graine ne contient que 32 bits, elle est trop petite et ne contient pas suffisamment de complexité informatique pour une attaque frontale.
- ID de clé - clé symétrique de 32 bits ;
- MAC (code d'authentification du message) - somme de contrôle du paquet NTP ;
La clé automatique est calculée comme suit.
Autokey=H(Sender-IP||Receiver-IP||KeyID||Cookie)Où H() est une fonction de hachage cryptographique.
La même fonction est utilisée pour calculer la somme de contrôle des paquets.
MAC=H(Autokey||NTP packet)Il s'avère que toute l'intégrité des contrôles de colis repose sur l'authenticité des cookies. Une fois que vous les avez, vous pouvez restaurer la clé automatique, puis usurper le MAC. Cependant, le serveur NTP utilise une graine lors de leur génération. C’est là que réside le problème.
Cookie=MSB_32(H(Client IP||Server IP||0||Server Seed))La fonction MSB_32 supprime les 5 bits les plus significatifs du résultat du calcul de hachage md32. Le cookie client ne change pas tant que les paramètres du serveur restent inchangés. L'attaquant ne peut alors que restaurer le numéro initial et pouvoir générer des cookies de manière indépendante.
Tout d'abord, vous devez vous connecter au serveur NTP en tant que client et recevoir des cookies. Après cela, en utilisant une méthode de force brute, l'attaquant restaure le numéro initial selon un algorithme simple.
Algorithme pour attaquer le calcul du nombre initial par la méthode de la force brute.
for i=0:2^32 − 1 do
Ci=H(Server-IP||Client-IP||0||i)
if Ci=Cookie then
return i
end if
end forLes adresses IP sont connues, il ne reste donc plus qu'à créer 2^32 hachages jusqu'à ce que le cookie créé corresponde à celui reçu du serveur NTP. Sur une station d'accueil classique équipée d'Intel Core i5, cela prendra 25 minutes.
NTS - nouvelle clé automatique
Il était impossible de supporter de telles failles de sécurité dans Autokey, et en 2012, il est apparu protocole. Afin de compromettre le nom, ils ont décidé de changer de nom, Autokey v.2 a donc été surnommé Network Time Security.
Le protocole NTS est une extension de la sécurité NTP et ne prend actuellement en charge que le mode unicast. Il offre une protection cryptographique solide contre la manipulation de paquets, empêche la surveillance, s'adapte bien, résiste à la perte de paquets réseau et entraîne le moins de perte de précision encourue lors de la sécurité de la connexion.
Une connexion NTS se compose de deux étapes qui utilisent des protocoles de couche inférieure. Sur le premier A ce stade, le client et le serveur conviennent de différents paramètres de connexion et échangent des cookies contenant des clés avec tous les ensembles de données qui les accompagnent. Sur seconde A ce stade, la session NTS réellement protégée a lieu entre le client et le serveur NTP.
NTS se compose de deux protocoles de couche inférieure : Network Time Security Key Exchange (NTS-KE), qui initie une connexion sécurisée via TLS, et NTPv4, la dernière incarnation du protocole NTP. Un peu plus à ce sujet ci-dessous.
Première étape - NTS KE
À ce stade, le client NTP initie une session TLS 1.2/1.3 sur une connexion TCP distincte avec le serveur NTS KE. Au cours de cette session, ce qui suit se produit.
- Les parties déterminent les paramètres algorithme pour la deuxième étape.
- Les parties définissent un deuxième protocole de couche inférieure, mais pour le moment, seul NTPv4 est pris en charge.
- Les parties déterminent l'adresse IP et le port du serveur NTP.
- Le serveur NTS KE émet des cookies sous NTPv4.
- Les parties extraient une paire de clés symétriques (C2S et S2C) du matériel cookie.
Cette approche présente le grand avantage que toute la charge de la transmission des informations secrètes concernant les paramètres de connexion repose sur le protocole TLS éprouvé et fiable. Cela élimine le besoin de réinventer votre propre roue pour une négociation NTP sécurisée.
Deuxième étape - NTP sous protection NTS
Dans la deuxième étape, le client synchronise l'heure en toute sécurité avec le serveur NTP. À cet effet, il transmet quatre extensions spéciales (champs d'extension) dans la structure des paquets NTPv4.
- L'extension d'identifiant unique contient un nom occasionnel aléatoire pour empêcher les attaques par relecture.
- L'extension de cookie NTS contient l'un des cookies NTP disponibles pour le client. Puisque seul le client possède les clés AAED symétriques C2S et S2C, le serveur NTP doit les extraire du matériel des cookies.
- L'extension NTS Cookie Placeholder est un moyen pour un client de demander des cookies supplémentaires au serveur. Cette extension est nécessaire pour garantir que la réponse du serveur NTP n'est pas beaucoup plus longue que la requête. Cela permet d’éviter les attaques par amplification.
- L'extension NTS Authenticator et Encrypted Extension Fields contient le chiffrement AAED avec la clé C2S, l'en-tête NTP, les horodatages et l'EF ci-dessus comme données d'accompagnement. Sans cette extension, il est possible d'usurper les horodatages.
Dès réception d'une requête d'un client, le serveur vérifie l'authenticité du paquet NTP. Pour ce faire, il doit décrypter les cookies, extraire l'algorithme AAED et les clés. Après avoir vérifié avec succès la validité du paquet NTP, le serveur répond au client dans le format suivant.
- Unique Identifier Extension est une copie miroir de la demande du client, une mesure contre les attaques par réexécution.
- NTS Cookie Extension plus de cookies pour continuer la session.
- L'extension NTS Authenticator et Encrypted Extension Fields contient le chiffrement AEAD avec une clé S2C.
La deuxième poignée de main peut être répétée plusieurs fois, en contournant la première étape, puisque chaque demande et réponse donne au client des cookies supplémentaires. Cela présente l'avantage que les opérations TLS relativement gourmandes en ressources pour le calcul et la transmission des données PKI sont divisées par le nombre de requêtes répétées. Ceci est particulièrement pratique pour les chronométreurs FPGA spécialisés, lorsque toutes les fonctionnalités principales peuvent être regroupées en plusieurs fonctions du domaine de la cryptographie symétrique, transférant ainsi l'intégralité de la pile TLS vers un autre appareil.
NTPSec
Quelle est la particularité du NTP ? Malgré le fait que l'auteur du projet, Dave Mills, ait essayé de documenter son code le mieux possible, il est rare qu'un programmeur soit capable de comprendre les subtilités des algorithmes de synchronisation temporelle vieux de 35 ans. Une partie du code a été écrite avant l’ère POSIX, et l’API Unix était alors très différente de ce qui est utilisé aujourd’hui. De plus, la connaissance des statistiques est nécessaire pour éliminer le signal des interférences sur les lignes bruyantes.
NTS n'était pas la première tentative de correction de NTP. Une fois que les attaquants ont appris à exploiter les vulnérabilités NTP pour amplifier les attaques DDoS, il est devenu évident que des changements radicaux étaient nécessaires. Et tandis que les projets du NTS étaient en cours de préparation et de finalisation, la National Science Foundation des États-Unis a alloué d'urgence fin 2014 une subvention pour la modernisation du NTP.
Le groupe de travail n'était pas dirigé par n'importe qui, mais - l'un des fondateurs et piliers de la communauté Open Source et auteur du livre . La première chose qu’Eric et ses amis ont essayé de faire a été de déplacer le code NTP de la plateforme BitKeeper vers git, mais cela n’a pas fonctionné. Le chef du projet, Harlan Stenn, s'est opposé à cette décision et les négociations sont au point mort. Ensuite, il a été décidé de bifurquer le code du projet et NTPSec est né.
Une solide expérience, comprenant des travaux sur le GPSD, une formation mathématique et la capacité magique de lire du code ancien - Eric Raymond était exactement le hacker capable de réaliser un tel projet. L'équipe a trouvé un spécialiste de la migration de code et en seulement 10 semaines, NTP sur GitLab. Les travaux battaient leur plein.
L'équipe d'Eric Raymond s'est attelée à la tâche à la manière d'Auguste Rodin avec un bloc de pierre. En supprimant 175 KLOC de l’ancien code, ils ont pu réduire considérablement la surface d’attaque en comblant de nombreuses failles de sécurité.
Voici une liste incomplète de ceux inclus dans la distribution :
- Refclock non documenté, obsolète, obsolète ou cassé.
- Bibliothèque ICS inutilisée.
- libopts/autogène.
- Ancien code pour Windows.
- ntpdc.
- Clé automatique.
- Le code ntpq C a été réécrit en Python.
- Le code C sntp/ntpdig a été réécrit en Python.
En plus de nettoyer le code, le projet avait d'autres tâches. Voici une liste partielle des réalisations :
- La protection du code contre le débordement de tampon a été considérablement améliorée. Pour éviter les débordements de tampon, toutes les fonctions de chaîne non sécurisées (strcpy/strcat/strtok/sprintf/vsprintf/gets) ont été remplacées par des versions sécurisées qui implémentent des limites de taille de tampon.
- Ajout du support NTS.
- Précision du pas de temps décuplée grâce à la liaison du matériel physique. Cela est dû au fait que les horloges informatiques modernes sont devenues beaucoup plus précises que celles de la naissance du NTP. Les plus grands bénéficiaires de cette mesure ont été le GPSDO et les radios horaires dédiées.
- Le nombre de langages de programmation a été réduit à deux. Au lieu des scripts Perl, awk et même S, tout est désormais Python. De ce fait, il existe davantage de possibilités de réutilisation du code.
- Au lieu de nouilles de scripts AutoTools, le projet a commencé à utiliser un système de construction de logiciels .
- Documentation du projet mise à jour et réorganisée. À partir d’un ensemble de documents contradictoires et parfois archaïques, ils ont créé une documentation tout à fait passable. Chaque commutateur de ligne de commande et chaque entité de configuration dispose désormais d’une version unique de la vérité. De plus, les pages de manuel et la documentation Web sont désormais créées à partir des mêmes fichiers principaux.
NTPSec est disponible pour un certain nombre de distributions Linux. Pour le moment, la dernière version stable est la 1.1.8, pour Gentoo Linux c'est l'avant-dernière.
(1:696)$ sudo emerge -av ntpsec
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild R ] net-misc/ntpsec-1.1.7-r1::gentoo USE="samba seccomp -debug -doc -early -gdb -heat -libbsd -nist -ntpviz -rclock_arbiter -rclock_generic -rclock_gpsd -rclock_hpgps -rclock_jjy -rclock_local -rclock_modem -rclock_neoclock -rclock_nmea -rclock_oncore -rclock_pps -rclock_shm -rclock_spectracom -rclock_trimble -rclock_truetime -rclock_zyfer -smear -tests" PYTHON_TARGETS="python3_6" 0 KiB
Total: 1 package (1 reinstall), Size of downloads: 0 KiB
Would you like to merge these packages? [Yes/No]
Chrony
Il y a eu une autre tentative pour remplacer l’ancien NTP par une alternative plus sécurisée. Chrony, contrairement à NTPSec, est écrit de A à Z et est conçu pour fonctionner de manière fiable dans un large éventail de conditions, notamment des connexions réseau instables, une disponibilité ou une congestion partielle du réseau et des changements de température. De plus, chrony présente d'autres avantages :
- chrony peut synchroniser l'horloge système plus rapidement avec une plus grande précision ;
- chrony est plus petit, consomme moins de mémoire et accède au processeur uniquement en cas de besoin. C'est un gros plus pour économiser les ressources et l'énergie ;
- chrony prend en charge les horodatages matériels sous Linux, permettant une synchronisation extrêmement précise sur les réseaux locaux.
Cependant, Chrony ne dispose pas de certaines fonctionnalités de l'ancien NTP, telles que la diffusion et la multidiffusion client/serveur. De plus, NTP classique prend en charge un plus grand nombre de systèmes d’exploitation et de plateformes.
Pour désactiver la fonctionnalité du serveur et les requêtes NTP adressées au processus chronyd, écrivez simplement le port 0 dans le fichier chrony.conf. Ceci est effectué dans les cas où il n'est pas nécessaire de maintenir du temps pour les clients ou les pairs NTP. Depuis la version 2.0, le port du serveur NTP est ouvert uniquement lorsque l'accès est autorisé par une directive d'autorisation ou une commande appropriée, ou lorsqu'un homologue NTP est configuré, ou qu'une directive de diffusion est utilisée.
Le programme se compose de deux modules.
- chronyd est un service qui s'exécute en arrière-plan. Il reçoit des informations sur la différence entre l'horloge système et le serveur de temps externe et ajuste l'heure locale. Il implémente également le protocole NTP et peut agir en tant que client ou serveur.
- chronyc est un utilitaire de ligne de commande pour la surveillance et le contrôle des programmes. Utilisé pour affiner divers paramètres de service, vous permettant par exemple d'ajouter ou de supprimer des serveurs NTP pendant que Chronyd continue de s'exécuter.
Depuis la version 7 de RedHat Linux chrony comme service de synchronisation horaire. Le package est également disponible pour d'autres distributions Linux. La dernière version stable est la 3.5, préparant la sortie de la v4.0.
(1:712)$ sudo emerge -av chrony
These are the packages that would be merged, in order:
Calculating dependencies... done!
[binary N ] net-misc/chrony-3.5-r2::gentoo USE="adns caps cmdmon ipv6 ntp phc readline refclock rtc seccomp (-html) -libedit -pps (-selinux)" 246 KiB
Total: 1 package (1 new, 1 binary), Size of downloads: 246 KiB
Would you like to merge these packages? [Yes/No]
Comment configurer votre propre serveur chrony distant sur Internet pour synchroniser l'heure sur un réseau de bureau. Vous trouverez ci-dessous un exemple de configuration d'un VPS.
Exemple de mise en place de Chrony sur RHEL / CentOS sur VPS
Pratiquons maintenant un peu et configurons notre propre serveur NTP sur un VPS. C'est très simple, il suffit de choisir le tarif approprié sur le site RuVDS, de vous procurer un serveur prêt à l'emploi et de taper une douzaine de commandes simples. Pour nos besoins, cette option est tout à fait appropriée.
Passons à la configuration du service et installons d'abord le package chrony.
[root@server ~]$ yum install chronyRHEL 8 / CentOS 8 utilisent un gestionnaire de packages différent.
[root@server ~]$ dnf install chronyAprès avoir installé Chrony, vous devez démarrer et activer le service.
[root@server ~]$ systemctl enable chrony --nowSi vous le souhaitez, vous pouvez apporter des modifications à /etc/chrony.conf, en remplaçant les serveurs NPT par les serveurs locaux les plus proches afin de réduire le temps de réponse.
# Use public servers from the pool.ntp.org project.
# Please consider joining the pool (http://www.pool.ntp.org/join.html).
server 0.ru.pool.ntp.org iburst
server 1.ru.pool.ntp.org iburst
server 2.ru.pool.ntp.org iburst
server 3.ru.pool.ntp.org iburst
Ensuite, nous configurons la synchronisation du serveur NTP avec les nœuds du pool spécifié.
[root@server ~]$ timedatectl set-ntp true
[root@server ~]$ systemctl restart chronyd.service
Il est également nécessaire d'ouvrir le port NTP vers l'extérieur, sinon le pare-feu bloquera les connexions entrantes des nœuds clients.
[root@server ~]$ firewall-cmd --add-service=ntp --permanent
[root@server ~]$ firewall-cmd --reload
Côté client, il suffit de régler correctement le fuseau horaire.
[root@client ~]$ timedatectl set-timezone Europe/MoscowLe fichier /etc/chrony.conf spécifie l'IP ou le nom d'hôte de notre serveur VPS exécutant le serveur NTP chrony.
server my.vps.serverEt enfin, démarrer la synchronisation de l'heure sur le client.
[root@client ~]$ systemctl enable --now chronyd
[root@client ~]$ timedatectl set-ntp true
La prochaine fois, je vous dirai quelles sont les options disponibles pour synchroniser l'heure sans Internet.
Source: habr.com
