🥇Wie die Zeitsynchronisation sicher wurde

Wie kann man sicherstellen, dass die Zeit per se nicht lügt, wenn man Millionen von großen und kleinen Geräten hat, die über TCP/IP interagieren? Schließlich hat jedes von ihnen eine Uhr, und die Zeit muss auf allen korrekt sein. Dieses Problem lässt sich ohne NTP nicht umgehen.

Stellen wir uns einen Moment vor, dass in einem Segment der industriellen IT-Infrastruktur Probleme mit der Zeitsynchronisierung auftreten. Sofort beginnt der Clusterstack der Unternehmenssoftware zu straucheln, Domains zerfallen, Master- und Standby-Knoten versuchen vergeblich, den Status quo wiederherzustellen.

Es ist auch möglich, dass ein Angreifer absichtlich versucht, die Zeit durch MiTM- oder DDOS-Angriffe zu manipulieren. In einer solchen Situation kann alles Mögliche passieren:

Benutzerpasswörter laufen ab;
X.509-Zertifikate laufen ab;
Die Zwei-Faktor-Authentifizierung TOTP funktioniert nicht mehr;
Backups werden "veraltet" und das System löscht sie;
DNSSec bricht zusammen.

Es ist klar, dass jeder erste IT-Abteilung an einer zuverlässigen Funktionsweise von Zeit-Synchronisierungsdiensten interessiert ist, und es wäre gut, wenn sie in der industriellen Nutzung sowohl zuverlässig als auch sicher wären.

NTP in 25 Minuten hacken

Netzwerkprotokolle – Millennials haben eine Besonderheit, sie sind schon lange veraltet und sind nirgendwo mehr brauchbar, aber sie zu ersetzen ist nicht so einfach, selbst wenn sich eine kritische Masse von Enthusiasten und Finanzierung zusammenfindet.

Die Hauptbeschwerde gegen klassisches NTP ist das Fehlen zuverlässiger Schutzmechanismen gegen Angriffe von Angreifern. Es wurden verschiedene Versuche unternommen, dieses Problem zu lösen. Zunächst wurde ein Mechanismus für zuvor festgelegte Schlüssel (PSK) zum Austausch von symmetrischen Schlüsseln implementiert.

Leider hat sich diese Methode aus einem einfachen Grund nicht bewährt – sie skaliert schlecht. Es ist eine manuelle Konfiguration auf der Client-Seite erforderlich, je nach Server. Das bedeutet, dass man nicht einfach einen weiteren Client hinzufügen kann. Wenn sich auf dem NTP-Server etwas ändert, müssen alle Clients neu konfiguriert werden.

Dann wurde AutoKey entwickelt, aber sofort wurden mehrere schwerwiegende Schwachstellen im Design des Algorithmus entdeckt, und man musste es aufgeben. Das Problem ist, dass die Ausgangszahl (Seed) nur 32-Bit enthält, was zu wenig ist und nicht genügend rechnerische Komplexität für einen Brute-Force-Angriff aufweist.

Key ID – ein symmetrischer 32-Bit-Schlüssel;
MAC (Message Authentication Code) — Prüfziffer des NTP-Pakets;

Autokey wird wie folgt berechnet.

Autokey=H(Sender-IP||Receiver-IP||KeyID||Cookie)

Dabei steht H() für eine kryptografische Hash-Funktion.

Für die Berechnung der Prüfziffer wird dieselbe Funktion verwendet.

MAC=H(Autokey||NTP-Paket)

Es zeigt sich, dass die gesamte Integrität der Paketprüfungen auf der Authentizität der Cookies beruht. Wenn man sie erlangt, kann man das Autokey wiederherstellen und den MAC fälschen. Der NTP-Server verwendet jedoch eine Zufallszahl (Seed) bei deren Generierung. Hier liegt der Haken.

Cookie=MSB_32(H(Client IP||Server IP||0||Server Seed))

Die Funktion MSB_32 schneidet die 32 höchstwertigen Bits des Ergebnisses der Berechnung des md5-Hashes ab. Das Client-Cookie bleibt unverändert, solange die Serverparameter gleich bleiben. Danach bleibt dem Angreifer nur noch, die Zufallszahl wiederherzustellen und die Möglichkeit zu erhalten, selbst Cookies zu generieren.

Zunächst muss man sich als Client mit dem NTP-Server verbinden und Cookies erhalten. Danach stellt der Angreifer die Zufallszahl durch Ausprobieren mithilfe eines einfachen Algorithmus wieder her.

Angriffsalgorithmus zur Berechnung der Zufallszahl durch Ausprobieren.

   for i=0:2^32 − 1 do
        Ci=H(Server-IP||Client-IP||0||i)
        if Ci=Cookie then
            return i
        end if 
    end for

Die IP-Adressen sind bekannt, sodass man nur noch 2^32 Hashes erzeugen muss, bis das erzeugte Cookie mit dem vom NTP-Server erhaltenen übereinstimmt. Auf einer typischen Heimstation mit Intel Core i5 dauert dies 25 Minuten.

NTS — neues Autokey

Es war unmöglich, mit solchen Sicherheitslücken im Autokey zu leben, und 2012 erschien Neue Version das Protokoll. Um dem kompromittierten Namen entgegenzuwirken, entschied man sich für ein Rebranding, sodass Autokey v.2 als Network Time Security bezeichnet wurde.

Das NTS-Protokoll ist eine Sicherheitserweiterung des NTP und unterstützt derzeit nur den Unicast-Modus. Es bietet einen zuverlässigen kryptografischen Schutz vor Manipulationen von Paketen, verhindert das Tracking, ist gut skalierbar, robust gegen den Verlust von Netzpaketen und führt zu den geringsten Verlusten an Genauigkeit, die während des Schutzes der Verbindung entstehen.

Eine NTS-Verbindung besteht aus zwei Phasen, in denen Protokolle der unteren Ebene verwendet werden. In der ersten Phase einigen sich Client und Server auf verschiedene Verbindungsparameter und tauschen Cookies aus, die Schlüssel mit allen begleitenden Datensätzen enthalten. In der zweiten Phase findet dann tatsächlich die geschützte NTS-Sitzung zwischen Client und NTP-Server statt.

NTS besteht aus zwei unteren Protokollen: Network Time Security Key Exchange (NTS-KE), um eine sichere Verbindung über TLS zu initialisieren, und NTPv4 — der neuesten Inkarnation des NTP-Protokolls. Etwas ausführlicher dazu unten.

Der erste Schritt — NTS KE

In diesem Schritt initiiert der NTP-Client eine TLS 1.2/1.3-Sitzung über eine separate TCP-Verbindung mit dem NTS KE-Server. Während dieser Sitzung geschieht Folgendes.

Die Parteien legen die Parameter AEAD des Algorithmus für den zweiten Schritt fest.
Die Parteien bestimmen das zweite untere Protokoll, aber momentan wird nur NTPv4 unterstützt.
Die Parteien legen die IP-Adresse und den Port des NTP-Servers fest.
Der NTS KE-Server gibt Cookies für NTPv4 aus.
Die Parteien extrahieren aus den Cookies ein Paar symmetrischer Schlüssel (C2S und S2C).

Dieser Ansatz hat den großen Vorteil, dass die gesamte Last der Übertragung vertraulicher Informationen über die Verbindung auf ein bewährtes und sicheres Protokoll wie TLS verlagert wird. Damit entfällt die Notwendigkeit, ein eigenes Rad für ein sicheres NTP-Handschlag zu erfinden.

Der zweite Schritt — NTP geschützt durch NTS

Im zweiten Schritt synchronisiert der Client die Zeit sicher mit dem NTP-Server. Zu diesem Zweck überträgt er vier spezielle Erweiterungen (extension field) in der Struktur des NTPv4-Pakets.

Die Unique Identifier Extension enthält eine zufällige Nonce, um Wiederholungsangriffe zu verhindern.
Die NTS Cookie Extension enthält eines der verfügbaren NTP-Cookies des Clients. Da nur der Client über die symmetrischen AAED-Schlüssel C2S und S2C verfügt, muss der NTP-Server diese aus den Cookies extrahieren.
Die NTS Cookie Placeholder Extension ist ein Mittel für den Client, um zusätzliche Cookies vom Server anzufordern. Diese Erweiterung ist notwendig, damit die Antwort des NTP-Servers nicht viel länger ist als die Anfrage. So wird verhindert, dass Verstärkungsangriffe erfolgen.
Die NTS Authenticator and Encrypted Extension Fields Extension enthält die Verschlüsselung des AAED-Algorithmus mit dem C2S-Schlüssel, NTP-Header, Zeitstempeln und den oben erwähnten EFs als Begleitdaten. Ohne diese Erweiterung könnten Zeitstempel gefälscht werden.

Nachdem der Server die Anfrage vom Client erhalten hat, überprüft er die Authentizität des NTP-Pakets. Dazu muss er die Cookies entschlüsseln, den AAED-Algorithmus und die Schlüssel extrahieren. Nach erfolgreicher Validierung des NTP-Pakets antwortet der Server dem Client im folgenden Format.

Die Unique Identifier Extension ist eine Spiegelung der Client-Anfrage, um Wiederholungsangriffe zu vermeiden.
Die NTS Cookie Extension stellt mehr Cookies für die Fortsetzung der Sitzung bereit.
Der NTS Authenticator und die verschlüsselten Erweiterungsfelder enthalten eine AEAD-Verschlüsselung mit einem S2C-Schlüssel.

Das zweite Handshake kann viele Male wiederholt werden, wobei die erste Phase umgangen wird, da jede Anfrage und Antwort dem Client zusätzliche Cookies gibt. Dies hat den Vorteil, dass ressourcenintensive TLS-Operationen zur Berechnung und Übertragung von PKI-Daten auf die Anzahl der Wiederholungsanfragen verteilt werden. Dies ist besonders praktisch für spezialisierte FPGA-Taktgeber, wenn die gesamte Hauptfunktionalität in mehrere Funktionen der symmetrischen Kryptografie verpackt werden kann, wobei der gesamte TLS-Stack auf ein anderes Gerät übertragen wird.

NTPSec

Was ist das Besondere am NTP? Trotz der Bemühungen des Projektleiters Dave Mills, seinen Code so gut wie möglich zu dokumentieren, wird es für einen seltenen Programmierer einfach sein, die komplexen Algorithmen für die Zeitsynchronisation, die 35 Jahre alt sind, zu durchdringen. Teile des Codes wurden vor der POSIX-Ära geschrieben, und die Unix-API unterschied sich damals erheblich von dem, was heute verwendet wird. Zudem sind Kenntnisse in Statistik erforderlich, um das Signal von Störungen auf verrauschten Leitungen zu reinigen.

NTS war nicht der erste Versuch, NTP zu reparieren. Nachdem Angreifer gelernt hatten, NTP-Schwachstellen für verstärkte DDoS-Angriffe auszunutzen, wurde klar, dass radikale Veränderungen notwendig waren. Während die Entwürfe für NTS vorbereitet und verfeinert wurden, stellte die National Science Foundation der USA Ende 2014 dringend einen Zuschuss für die Modernisierung von NTP bereit.

Die Arbeitsgruppe wurde von niemand Geringerem als Eric Steven Raymond — einem der Gründer und Säulen der Open-Source-Community und Autor des Buches Der Hacker und sein Handwerk. Zunächst versuchte Eric mit seinen Kollegen, den NTP-Code von der BitKeeper-Plattform auf git zu portieren, doch das war nicht so einfach. Der Projektleiter Harlan Stenn war gegen diese Lösung und die Verhandlungen kamen ins Stocken. Daher wurde beschlossen, den Code des Projekts zu forken, was zur Entstehung von NTPSec führte.

Er bringt nicht nur umfangreiche Erfahrung mit, einschließlich seiner Arbeit an GPSD, sondern auch einen mathematischen Hintergrund und das magische Talent, alten Code zu lesen – Eric Raymond war genau der Hacker, der ein solches Projekt umsetzen konnte. Im Team fand sich ein Spezialist für die Migration des Codes und in nur 10 Wochen wurde NTP auf GitLab angesiedelt.Die Arbeit nahm Fahrt auf.

Das Team um Eric Raymond packte die Aufgabe ebenso an wie Auguste Rodin beim Arbeiten mit einem großen Steinblock. Durch die Entfernung von 175 KLOC altem Code gelang es ihnen, die Angriffsfläche erheblich zu reduzieren und zahlreiche Sicherheitslücken zu schließen.

Hier ist eine unvollständige Liste der betroffenen Punkte:

Undokumentierte, veraltete oder defekte Refclock.
Nicht verwendete ICS-Bibliothek.
libopts/autogen.
Alte Windows-Software.
ntpdc.
Autokey.
C-Code von ntpq wurde in Python umgeschrieben.
C-Code von sntp/ntpdig wurde in Python umgeschrieben.

Neben der Bereinigung des Codes gab es auch andere Aufgaben im Projekt. Hier ist eine unvollständige Liste der Errungenschaften:

Der Schutz des Codes vor Pufferüberläufen wurde erheblich verstärkt. Um Pufferüberläufe zu verhindern, wurden alle unsicheren String-Funktionen (strcpy / strcat / strtok / sprintf / vsprintf / gets) durch sichere Versionen ersetzt, die eine Begrenzung der Puffergröße implementieren.
Unterstützung für NTS hinzugefügt.
Die Genauigkeit des Zeitstempels wurde durch die Anbindung an physikalische Hardware verzehnfacht. Dies liegt daran, dass moderne Computeruhren viel genauer geworden sind als die, die zur Zeit der Entstehung von NTP existierten. Am meisten davon profitierten GPSDO und dedizierte Zeitstationen.
Die Anzahl der Programmiersprachen wurde auf zwei reduziert. Statt Perl, awk und sogar S-Skripten wird nun ausschließlich Python verwendet. Dadurch gibt es mehr Möglichkeiten zur Wiederverwendung von Code.
Statt eines wirren Skript-Chaos' verwendet das Projekt nun ein Software-Bausystem. waf.
Die Dokumentation des Projekts wurde aktualisiert und neu strukturiert. Aus einer widersprüchlichen und teils veralteten Sammlung von Dokumenten wurde eine annehmbare Dokumentation erstellt. Jede Schlüsselzeile und jede Konfigurationseinheit hat jetzt eine einheitliche Version der Wahrheit. Darüber hinaus werden die Handbuchseiten und die Webdokumentation jetzt aus denselben Grunddateien erstellt.

NTPSec ist für eine Reihe von Linux-Distributionen verfügbar. Derzeit ist die letzte stabile Version 1.1.8, für Gentoo Linux ist es die vorletzte.

(1:696)$ sudo emerge -av ntpsec
Diese Pakete würden zusammengeführt werden, in folgender Reihenfolge:
Abhängigkeitsberechnung… erledigt!
[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
Insgesamt: 1 Paket (1 erneute Installation), Größe der Downloads: 0 KiB
Möchten Sie diese Pakete zusammenführen? [Ja/Nein]

Chrony

Es gab einen weiteren Versuch, das alte NTP durch ein sichereres Äquivalent zu ersetzen. Chrony wurde im Gegensatz zu NTPSec von Grund auf neu geschrieben und ist für einen zuverlässigen Betrieb unter einer Vielzahl von Bedingungen, einschließlich instabiler Netzwerkverbindungen, teilweise Verfügbarkeit oder Netzwerküberlastungen und Temperaturschwankungen, konzipiert. Darüber hinaus bietet chrony weitere Vorteile:

chrony kann die Systemuhren schneller mit höherer Genauigkeit synchronisieren;
chrony ist kleiner, verbraucht weniger Speicher und verwendet den Prozessor nur dann, wenn dies erforderlich ist. Dies ist ein großer Vorteil für die Ressourcenschonung und Energieeinsparung;
chrony unterstützt hardwaregestützte Zeitstempel in Linux, was extrem präzise Synchronisation in lokalen Netzwerken gewährleistet.

Allerdings fehlen dem chrony einige Funktionen des alten NTP, wie z.B. der Broadcast- und der Multicast-Client/Server. Darüber hinaus unterstützt der klassische NTP eine größere Anzahl von Betriebssystemen und Plattformen.

Um die Serverfunktionalität und NTP-Anfragen des Prozesses chronyd zu deaktivieren, reicht es aus, port 0 in die Datei chrony.conf einzutragen. Dies geschieht in den Fällen, in denen keine Zeit für NTP-Clients oder Peer-Knoten bereitgestellt werden muss. Ab Version 2.0 ist der NTP-Serverport nur geöffnet, wenn der Zugriff durch die Direktive allow oder den entsprechenden Befehl erlaubt ist, oder wenn ein NTP-Peer-Knoten konfiguriert ist, oder die Direktive broadcast verwendet wird.

Das Programm besteht aus zwei Modulen.

chronyd ist ein Dienst, der im Hintergrund läuft. Er erhält Informationen über die Differenz der Systemuhr mit einem externen Zeitserver und korrigiert die lokale Zeit. Er implementiert auch das NTP-Protokoll und kann als Client oder Server fungieren.
chronyc ist ein Kommandozeilenwerkzeug zur Überwachung und Steuerung des Programms. Es wird verwendet, um verschiedene Parameter des Dienstes fein abzustimmen, zum Beispiel um NTP-Server hinzuzufügen oder zu entfernen, während chronyd weiterhin läuft.

Seit der 7. Version von RedHat Linux verwendet wird chrony als Zeit-Synchronisierungsdienst angeboten. Das Paket ist auch für andere Linux-Distributionen verfügbar. Die letzte stabile Version 3.5 bereitet sich auf die Veröffentlichung von v4.0 vor.

(1:712)$ sudo emerge -av chrony
Dies sind die Pakete, die in folgender Reihenfolge zusammengeführt werden:
Berechnung der Abhängigkeiten... abgeschlossen!
[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
Insgesamt: 1 Paket (1 neu, 1 binär), Größe der Downloads: 246 KiB
Möchten Sie diese Pakete zusammenführen? [Ja/Nein]

So richten Sie Ihren eigenen chrony-Server im Internet für die Zeitsynchronisierung in einem Büroumgebung ein. Hier ist ein Beispiel für die Konfiguration auf einem VPS.

Beispielkonfiguration von Chrony auf RHEL / CentOS auf einem VPS

Lassen Sie uns nun ein wenig üben und unseren eigenen NTP-Server auf einem VPS einrichten. Das ist ganz einfach, Sie müssen nur einen passenden Tarif auf der Website RuVDS auswählen, den fertigen Server erhalten und ein Dutzend einfacher Befehle eingeben. Für unsere Zwecke ist diese Variante durchaus geeignet.

Beginnen wir mit der Konfiguration des Dienstes und installieren wir zunächst das Paket chrony.

[root@server ~]$ yum install chrony

RHEL 8 / CentOS 8 verwenden einen anderen Paketmanager.

[root@server ~]$ dnf install chrony

Nach der Installation von chrony muss der Dienst gestartet und aktiviert werden.

[root@server ~]$ systemctl enable chrony --now

Falls gewünscht, können Änderungen in /etc/chrony.conf vorgenommen werden, indem die NPT-Server durch die nächstgelegenen lokalen ersetzt werden, um die Reaktionszeit zu verkürzen.

# 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

Dann konfigurieren wir die Synchronisation des NTP-Servers mit den Knoten aus dem angegebenen Pool.

[root@server ~]$ timedatectl set-ntp true
[root@server ~]$ systemctl restart chronyd.service

Es ist auch notwendig, den NTP-Port nach außen zu öffnen, da sonst die Firewall eingehende Verbindungen von den Clientknoten blockiert.

[root@server ~]$ firewall-cmd --add-service=ntp --permanent 
[root@server ~]$ firewall-cmd --reload

Auf der Client-Seite reicht es aus, die Zeitzone korrekt einzustellen.

[root@client ~]$ timedatectl set-timezone Europe/Moscow

In der Datei /etc/chrony.conf geben Sie die IP oder den Hostnamen unseres VPS-Servers an, auf dem der NTP-Server chrony läuft.

server my.vps.server

Und schließlich wird die Zeitsynchronisation auf dem Client gestartet.

[root@client ~]$ systemctl enable --now chronyd
[root@client ~]$ timedatectl set-ntp true

Nächstes Mal erzähle ich, welche Möglichkeiten es zur Zeitsynchronisation ohne Internet gibt.

Quelle: habr.com

Wie die Zeit Synchronisation sicher wurde