🥇Wie die Zeit-Synchronisation sicher wurde

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

Stellen wir uns für einen Moment vor, dass in einem Segment der industriellen IT-Infrastruktur Probleme mit der Zeitsynchronisierung der Dienste auftreten. Sofort beginnt das Cluster-Stack von Enterprise-Software zu schwanken, Domänen fallen auseinander, und Master- sowie Standby-Knoten versuchen vergeblich, den Status quo wiederherzustellen.

Es kann auch eine Situation eintreten, in der ein Angreifer absichtlich versucht, die Zeit über Man-in-the-Middle-Attacken oder DDoS-Attacken zu stören. In einem solchen Fall kann alles Mögliche geschehen:

die Gültigkeit von Benutzerpasswörtern läuft ab;
die Gültigkeit von X.509-Zertifikaten läuft ab;
die Zwei-Faktor-Authentifizierung TOTP funktioniert nicht mehr;
Backups werden ‚obsolet‘ und das System löscht sie;
DNSSec bricht zusammen.

Es ist klar, dass jeder IT-Department an einer zuverlässigen Funktion der Zeitsynchronisierungsdienste interessiert ist und es wünschenswert wäre, dass diese in der industriellen Nutzung zuverlässig und sicher sind.

NTP in 25 Minuten knacken

Netzwerkprotokolle – Millennials haben eine Eigenheit, die sich seit langem zeigt, veraltet und sie sind kaum noch zeitgemäß, doch ihre Ersetzung ist selbst dann nicht einfach, wenn sich genügend Enthusiasten und finanzielle Mittel finden.

Die Hauptkritik am klassischen NTP liegt in der fehlenden zuverlässigen Mechanismen zum Schutz vor Angriffen durch böswillige Akteure. Es wurden verschiedene Versuche unternommen, dieses Problem zu lösen. Zuerst wurde ein Mechanismus für vordefinierte Schlüssel (PSK) eingeführt, um symmetrische Schlüssel auszutauschen.

Leider hat sich dieser Ansatz aus einem einfachen Grund als ineffizient erwiesen – er skaliert schlecht. Eine manuelle Konfiguration auf der Client-Seite ist notwendig und abhängig vom jeweiligen Server. Das bedeutet, dass es nicht einfach ist, einen weiteren Client hinzuzufügen. Bei Änderungen am NTP-Server müssen alle Clients neu konfiguriert werden.

Daraufhin wurde AutoKey entwickelt, doch sofort stellte man eine Reihe gravierender Schwachstellen im Design des Algorithmus fest, was zu seiner Aufgabe führte. Der Grund dafür ist, dass die Ausgangszahl (Seed) lediglich 32 Bit umfasst, was viel zu gering ist und nicht ausreichend Rechenkomplexität für einen direkten Angriff enthält.

Key ID — 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 ist H() eine kryptografische Hashfunktion.

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

MAC=H(Autokey||NTP-Paket)

Somit hängt die gesamte Integrität der Paketprüfungen von der Authentizität der Cookies ab. Hat man diese erlangt, kann man Autokey wiederherstellen und dann das MAC fälschen. Der NTP-Server verwendet jedoch bei deren Generierung eine Zufallszahl (Seed). Genau hier liegt der Haken.

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

Die MSB_32-Funktion schneidet die 32 obersten Bits des Ergebnisses der MD5-Hashberechnung ab. Das Client-Cookie bleibt unverändert, solange die Serverparameter gleich bleiben. Danach muss der Angreifer nur noch die Zufallszahl wiederherstellen, um die Möglichkeit zu erhalten, selbst Cookies zu generieren.

Zunächst sollte man sich als Client mit dem NTP-Server verbinden und Cookies erhalten. Danach kann der Angreifer durch Brute-Force die Zufallszahl gemäß einem einfachen Algorithmus wiederherstellen.

Angriffsalgorithmus zur Berechnung der Zufallszahl mittels Brute-Force.

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

IP-Adressen sind bekannt, daher bleibt nur, bis zu 2^32 Hashes zu erstellen, bis das generierte Cookie mit dem vom NTP-Server erhaltenen übereinstimmt. Auf einem gewöhnlichen Heimcomputer mit Intel Core i5 dauert dies etwa 25 Minuten.

NTS — neue Autokey

Solche Sicherheitslücken in Autokey waren im Jahr 2012 nicht mehr tragbar. neue Version Um dem kompromittierten Namen gerecht zu werden, wurde ein Rebranding durchgeführt, sodass Autokey v.2 als Network Time Security bezeichnet wurde.

Das NTS-Protokoll ist eine Erweiterung der Sicherheit von NTP und unterstützt derzeit nur den Unicast-Modus. Es bietet einen zuverlässigen kryptografischen Schutz gegen Paketmanipulation, verhindert Tracking, ist gut skalierbar, widerstandsfähig gegen den Verlust von Netzwerkpaketen und führt zu minimalen Genauigkeitsverlusten, die während des Schutzes der Verbindung auftreten.

Die NTS-Verbindung besteht aus zwei Phasen, in denen Protokolle der unteren Ebene verwendet werden. In der ersten Phase vereinbaren der Client und der Server verschiedene Verbindungsparameter und tauschen Cookies aus, die Schlüssel sowie den entsprechenden Datensatz enthalten. In der zweiten In dieser Phase erfolgt die tatsächliche geschützte NTS-Sitzung zwischen dem Client und dem NTP-Server.

NTS besteht aus zwei unterliegenden Protokollen: Network Time Security Key Exchange (NTS-KE), das die sichere Verbindung über TLS initialisiert, und NTPv4 – der neuesten Version des NTP-Protokolls. Etwas ausführlicher dazu weiter unten.

Erster Schritt – NTS KE

In dieser Phase initiiert der NTP-Client eine TLS 1.2/1.3-Sitzung über eine separate TCP-Verbindung zum NTS KE-Server. Während dieser Sitzung erfolgt Folgendes.

Die Parteien legen die Parameter AEAD verwendet. des Algorithmus für die zweite Phase fest.
Die Parteien bestimmen das zweite unterliegende Protokoll, wobei derzeit nur NTPv4 unterstützt wird.
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 Vorteil, dass die gesamte Last beim Übertragen geheimer Verbindungsparameter auf das bewährte und zuverlässige Protokoll TLS gelegt wird. Damit entfällt die Notwendigkeit, für ein sicheres NTP-Handschlagverfahren das Rad neu zu erfinden.

Zweiter Schritt – NTP geschützt durch NTS

Im zweiten Schritt synchronisiert der Kunde sicher die Zeit mit dem NTP-Server. Zu diesem Zweck überträgt er vier spezielle Erweiterungen (extension field) im NTPv4-Paket.

Die Unique Identifier Extension enthält eine zufällige Nonce zur Verhinderung von Wiederholungsangriffen.
Die NTS Cookie Extension enthält eines der beim Kunden vorhandenen NTP-Cookies. Da nur der Kunde die symmetrischen AAED-Schlüssel C2S und S2C besitzt, muss der NTP-Server diese aus dem Cookie-Material extrahieren.
Die NTS Cookie Placeholder Extension ermöglicht es dem Kunden, zusätzliche Cookies vom Server anzufordern. Diese Erweiterung ist notwendig, um sicherzustellen, dass die Antwort des NTP-Servers nicht wesentlich länger ist als die Anfrage. Dies hilft, Verstärkungangriffe zu verhindern.
Die NTS Authenticator and Encrypted Extension Fields Extension enthält den Verschlüsselungsalgorithmus AAED mit dem C2S-Schlüssel, dem NTP-Header, Zeitstempeln und den oben genannten EF als Begleitdaten. Ohne diese Erweiterung könnten Zeitstempel gefälscht werden.

Nach Erhalt der Anfrage vom Kunden prüft der Server die Authentizität des NTP-Pakets. Hierzu muss er die Cookies entschlüsseln und den AAED-Algorithmus sowie die Schlüssel extrahieren. Nach erfolgreicher Validierung des NTP-Pakets antwortet der Server dem Kunden im folgenden Format.

Eindeutige Identifikatorerweiterung für die Spiegelkopie der Clientanfrage, Maßnahme gegen Angriffe durch Wiederholung.
NTS-Cookie-Erweiterung, mehr Cookies zur Fortsetzung der Sitzung.
NTS-Authenticator und verschlüsselte Erweiterungsfelder enthalten einen AEAD-Schlüssel mit S2C.

Das zweite Handshake kann mehrfach wiederholt werden, wobei die erste Phase umgangen wird, da jede Anfrage und Antwort dem Client zusätzliche Cookies bereitstellt. Dies bietet den Vorteil, dass die relativ ressourcenintensiven TLS-Berechnungen und die Übertragung von PKI-Daten auf die Anzahl der Wiederholungsanfragen verteilt werden. Dies ist besonders nützlich für spezialisierte FPGA-Taktgeber, bei denen die gesamte Funktionalität in mehreren Funktionen aus dem Bereich der symmetrischen Kryptographie verpackt werden kann, wobei der gesamte TLS-Stack auf ein anderes Gerät übertragen wird.

NTPSec

Was macht NTP besonders? Obwohl der Projektleiter Dave Mills bemüht war, seinen Code so gut wie möglich zu dokumentieren, wird es kaum einem Programmierer gelingen, die Komplexität der 35 Jahre alten Zeit-Synchronisationsalgorithmen vollständig zu verstehen. Ein Teil des Codes wurde vor der Ära von POSIX geschrieben und die Unix-API unterschied sich erheblich von dem, was heute verwendet wird. Zudem sind Kenntnisse in Statistik erforderlich, um das Signal von Störungen auf störanfälligen 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 ausgearbeitet wurden, gewährte die National Science Foundation der USA Ende 2014 dringend einen Zuschuss zur Modernisierung von NTP.

Die Arbeitsgruppe wurde von niemand anderem als Eric Steven Raymond — einem der Gründer und Säulen der Open-Source-Community sowie dem Autor des Buches Der Katedral und der Basar. Zuerst versuchten Eric und seine Kollegen, den NTP-Code von der BitKeeper-Plattform auf Git zu übertragen, doch das klappt nicht. Der Projektleiter Harlan Stenn war gegen diese Entscheidung, und die Verhandlungen kamen zum Stillstand. Daher wurde beschlossen, den Code des Projekts zu forken, wodurch NTPSec entstand.

Mit umfangreicher Erfahrung, einschließlich der Arbeit an GPSD, mathematischem Hintergrund und dem magischen Talent, alten Code zu lesen — Eric Raymond war genau der Hacker, der ein solches Projekt vorantreiben konnte. In der Gruppe fand sich ein Spezialist für die Migration von Code, und innerhalb von nur 10 Wochen wurde NTP auf GitLabgebracht. Die Arbeit nahm Fahrt auf.

Das Team von Eric Raymond ging mit der gleichen Entschlossenheit an die Sache heran wie Auguste Rodin bei der Arbeit an einem Block Stein. Durch die Entfernung von 175 KLOC altem Code konnten sie die Angriffsfläche erheblich verringern und viele Sicherheitslücken schließen.

Hier ist eine unvollständige Liste der Betroffenen:

Undokumentierte, veraltete oder fehlerhafte Refclock.
Unbenutzte ICS-Bibliothek.
libopts/autogen.
Alter Code für Windows.
ntpdc.
Autokey.
C-Code von ntpq wurde auf Python umgeschrieben.
C-Code von sntp/ntpdig wurde auf Python umgeschrieben.

Neben der Codebereinigung hatte das Projekt auch andere Aufgaben. Hier ist eine unvollständige Liste der Errungenschaften:

Der Schutz des Codes gegen Pufferüberläufe 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 Größenbegrenzung des Puffers implementieren.
Unterstützung für NTS hinzugefügt.
Die Genauigkeit des Zeitintervalls wurde durch die Bindung physischer Hardware um den Faktor zehn erhöht. Dies liegt daran, dass moderne Computeruhren wesentlich genauer geworden sind als die zu Beginn der Entwicklung von NTP. Besonders profitierten GPSDO und dedizierte Zeitstationen davon.
Die Anzahl der Programmiersprachen hat sich auf zwei reduziert. Anstelle von Perl, awk und sogar S dominieren jetzt durchgängig Python. Dadurch gibt es mehr Möglichkeiten zur Wiederverwendung von Code.
Statt der autotools-Skripte wird im Projekt nun ein Software-Bausystem verwendet. waf.
Wir haben die Projektdokumentation aktualisiert und neu strukturiert. Aus einer inkonsistenten und teilweise veralteten Sammlung von Dokumenten ist nun eine ansehnliche Dokumentation entstanden. Jede wichtige Kommandozeilenoption und jede Konfigurationseinheit hat jetzt eine eindeutige 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 in der folgenden Reihenfolge installiert:
Abhängigkeiten werden berechnet... 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 Neuinstallation), Größe der Downloads: 0 KiB
Möchten Sie diese Pakete installieren? [Ja/Nein]

Chrony

Es gab einen weiteren Versuch, den alten NTP durch einen sichereren Nachfolger zu ersetzen. Chrony wurde im Gegensatz zu NTPSec von Grund auf neu entwickelt und bietet eine zuverlässige Funktionalität unter einer Vielzahl von Bedingungen, einschließlich instabiler Netzwerkverbindungen, partieller Verfügbarkeit oder Netzüberlastungen sowie Temperaturschwankungen. Darüber hinaus hat chrony auch andere Vorteile:

Chrony kann die Systemuhr schneller und mit größerer Genauigkeit synchronisieren;
Chrony ist kleiner, verbraucht weniger Speicher und greift auf die CPU nur dann zu, wenn es erforderlich ist. Dies ist ein großer Vorteil für den Ressourcen- und Energieverbrauch;
Chrony unterstützt hardwarebasierte Zeitstempel in Linux, was eine äußerst präzise Synchronisation in lokalen Netzwerken gewährleistet.

Allerdings fehlen chrony einige Funktionen des alten NTP, wie Broadcast- und Multicast-Client/Server. Außerdem unterstützt das klassische NTP eine größere Anzahl von Betriebssystemen und Plattformen.

Um die Funktionalität des Servers und der NTP-Anfragen an den Prozess chronyd zu deaktivieren, genügt es, den Port 0 in die Datei chrony.conf einzutragen. Dies geschieht in Fällen, in denen es nicht notwendig ist, die Zeit für NTP-Clients oder Peernodes bereitzustellen. Ab Version 2.0 ist der NTP-Serverport nur dann geöffnet, wenn der Zugriff durch die Direktive allow oder den entsprechenden Befehl erlaubt ist, oder wenn ein Peernode für NTP konfiguriert oder die Direktive broadcast verwendet wird.

Das Programm besteht aus zwei Modulen.

chronyd ist ein im Hintergrund laufender Dienst. Er erhält Informationen über die Systemzeitabweichung von einem externen Zeitserver und korrigiert die lokale Zeit. Außerdem implementiert er das NTP-Protokoll und kann sowohl als Client als auch als Server fungieren.
chronyc ist ein Kommandozeilenwerkzeug zur Überwachung und Kontrolle 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 arbeitet.

Beginnend mit der 7. Version von RedHat Linux nutzt Chrony als Zeitabgleichdienst. 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 installiert werden:
Abhängigkeiten werden berechnet... fertig!
[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), Downloadgröße: 246 KiB
Möchten Sie diese Pakete installieren? [Ja/Nein]

Wie man einen eigenen Remote-Server mit Chrony im Internet einrichtet, um die Zeit im Büonetzwerk zu synchronisieren. Im Folgenden ein Beispiel zur Einrichtung auf einem VPS.

Beispiel für die Konfiguration von Chrony auf RHEL / CentOS auf einem VPS

Lassen Sie uns nun ein wenig üben und unseren eigenen NTP-Server auf einem VPS aufsetzen. Es ist ganz einfach, man muss lediglich einen passenden Tarif auf der Website RuVDS wählen, einen Server anfordern und ein Dutzend einfacher Befehle eingeben. Für unsere Zwecke ist diese Option völlig ausreichend.

Jetzt gehen wir zur Konfiguration des Dienstes über und installieren 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

Wenn gewünscht, können Sie Änderungen in /etc/chrony.conf vornehmen, indem Sie die NTP-Server durch die nächstgelegenen lokalen Server ersetzen, um die Antwortzeiten 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

Als Nächstes konfigurieren wir die Synchronisation des NTP-Servers mit 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 Client-Knoten 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-Adresse oder den Hostnamen unseres VPS-Servers an, auf dem der NTP-Server chrony läuft.

server my.vps.server

Und schließlich die Zeit-Synchronisation auf dem Client starten.

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

Beim nächsten Mal werde ich erläutern, welche Möglichkeiten zur Zeit-Synchronisation ohne Internet bestehen.

Quelle: habr.com

Wie die Zeitsynchronisierung sicher wurde