Wie die Zeitsynchronisation sicher wurde

Wie stellt man sicher, dass die Zeit nicht per se vergeht, wenn eine Million großer und kleiner Geräte über TCP/IP kommunizieren? Schließlich hat jeder von ihnen eine Uhr, und bei allen muss die Zeit stimmen. Dieses Problem kann ohne NTP nicht umgangen werden.

Stellen wir uns für einen Moment vor, dass es in einem Segment der industriellen IT-Infrastruktur Schwierigkeiten gibt, Dienste im Laufe der Zeit zu synchronisieren. Sofort beginnt der Cluster-Stack der Unternehmenssoftware auszufallen, Domänen lösen sich auf, Master- und Standby-Knoten versuchen erfolglos, den Status Quo wiederherzustellen.

Es ist auch möglich, dass ein Angreifer durch einen MiTM- oder DDOS-Angriff gezielt versucht, die Zeit zu stören. In einer solchen Situation kann alles passieren:

• Passwörter von Benutzerkonten laufen ab;
• X.509-Zertifikate laufen ab;
• Die TOTP-Zwei-Faktor-Authentifizierung funktioniert nicht mehr;
• Backups veralten und das System löscht sie;
• DNSSec wird kaputt gehen.

Es ist klar, dass jede IT-Abteilung am zuverlässigen Betrieb von Zeitsynchronisationsdiensten interessiert ist und es wäre schön, wenn diese im industriellen Betrieb zuverlässig und sicher wären.

Brechen Sie NTP in 25 Minuten

Netzwerkprotokolle – Millennials haben eine Besonderheit, und zwar schon immer veraltet und nützen nichts mehr, aber es ist nicht so einfach, sie zu ersetzen, selbst wenn eine kritische Masse an Enthusiasten und Geldern angesammelt ist.

Der Hauptkritikpunkt am klassischen NTP ist das Fehlen zuverlässiger Mechanismen zum Schutz vor Angriffen durch Eindringlinge. Es wurden verschiedene Versuche unternommen, dieses Problem zu lösen. Um dies zu erreichen, haben wir zunächst einen Pre-Shared-Key-Mechanismus (PSK) zum Austausch symmetrischer Schlüssel implementiert.

Leider hat sich diese Methode aus einem einfachen Grund nicht gelohnt: Sie lässt sich nicht gut skalieren. Je nach Server ist auf der Clientseite eine manuelle Konfiguration erforderlich. Das bedeutet, dass Sie einfach nicht einfach so einen weiteren Kunden hinzufügen können. Ändert sich etwas am NTP-Server, müssen alle Clients neu konfiguriert werden.

Dann entwickelten sie AutoKey, entdeckten jedoch sofort eine Reihe schwerwiegender Schwachstellen im Design des Algorithmus selbst und mussten ihn aufgeben. Die Sache ist, dass der Seed nur 32 Bit enthält, er ist zu klein und enthält nicht genug Rechenkomplexität für einen Frontalangriff.

• Schlüssel-ID – symmetrischer 32-Bit-Schlüssel;
• MAC (Nachrichtenauthentifizierungscode) – Prüfsumme des NTP-Pakets;

Autokey wird wie folgt berechnet.

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

Wobei H() eine kryptografische Hash-Funktion ist.

Die gleiche Funktion wird zur Berechnung der Prüfsumme von Paketen verwendet.

MAC=H(Autokey||NTP packet)

Es stellt sich heraus, dass die gesamte Integrität der Paketprüfungen von der Authentizität der Cookies abhängt. Sobald Sie sie haben, können Sie den Autokey wiederherstellen und dann den MAC fälschen. Allerdings verwendet der NTP-Server bei der Generierung einen Seed. Hier liegt der Haken.

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

Die Funktion MSB_32 schneidet die 5 höchstwertigen Bits aus dem MD32-Hash-Berechnungsergebnis ab. Das Client-Cookie ändert sich nicht, solange die Serverparameter unverändert bleiben. Dann kann der Angreifer nur noch die ursprüngliche Nummer wiederherstellen und selbstständig Cookies generieren.

Zunächst müssen Sie sich als Client mit dem NTP-Server verbinden und Cookies empfangen. Anschließend stellt der Angreifer mithilfe einer Brute-Force-Methode mithilfe eines einfachen Algorithmus die ursprüngliche Nummer wieder her.

Algorithmus zum Angriff auf die Berechnung der Anfangszahl mittels der Brute-Force-Methode.

   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

Da die IP-Adressen bekannt sind, müssen nur noch 2^32 Hashes erstellt werden, bis das erstellte Cookie mit dem vom NTP-Server empfangenen übereinstimmt. Auf einer normalen Heimstation mit Intel Core i5 dauert dies 25 Minuten.

NTS – neuer Autokey

Es war unmöglich, solche Sicherheitslücken in Autokey hinzunehmen, und im Jahr 2012 tauchten sie auf neue Version Protokoll. Um den Namen zu kompromittieren, entschieden sie sich für eine Umbenennung, sodass Autokey v.2 den Namen Network Time Security erhielt.

Das NTS-Protokoll ist eine Erweiterung der NTP-Sicherheit und unterstützt derzeit nur den Unicast-Modus. Es bietet einen starken kryptografischen Schutz gegen Paketmanipulation, verhindert Snooping, lässt sich gut skalieren, ist widerstandsfähig gegenüber Netzwerkpaketverlusten und führt zu den geringsten Präzisionsverlusten bei der Verbindungssicherheit.

Eine NTS-Verbindung besteht aus zwei Stufen, die Protokolle niedrigerer Schichten verwenden. An der erste In dieser Phase vereinbaren Client und Server verschiedene Verbindungsparameter und tauschen Cookies mit Schlüsseln mit dem gesamten zugehörigen Datensatz aus. An Sekunde In dieser Phase findet die eigentliche geschützte NTS-Sitzung zwischen dem Client und dem NTP-Server statt.

NTS besteht aus zwei Protokollen der unteren Schicht: Network Time Security Key Exchange (NTS-KE), das eine sichere Verbindung über TLS initiiert, und NTPv4, der neuesten Inkarnation des NTP-Protokolls. Mehr dazu weiter unten.

Erste Stufe - NTS KE

Zu diesem Zeitpunkt 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 fest AEAD Algorithmus für die zweite Stufe.
• Die Parteien definieren ein zweites Protokoll der unteren Schicht, derzeit wird jedoch nur NTPv4 unterstützt.
• Die Parteien legen die IP-Adresse und den Port des NTP-Servers fest.
• Der NTS KE-Server gibt Cookies unter NTPv4 aus.
• Die Parteien extrahieren ein Paar symmetrischer Schlüssel (C2S und S2C) aus dem Cookie-Material.

Dieser Ansatz hat den großen Vorteil, dass die gesamte Last der Übermittlung geheimer Informationen zu Verbindungsparametern auf das bewährte und zuverlässige TLS-Protokoll fällt. Dadurch entfällt die Notwendigkeit, das eigene Rad für einen sicheren NTP-Handshake neu zu erfinden.

Zweite Stufe – NTP unter NTS-Schutz

Im zweiten Schritt synchronisiert der Client die Uhrzeit sicher mit dem NTP-Server. Zu diesem Zweck übermittelt es vier spezielle Erweiterungen (Erweiterungsfelder) in der NTPv4-Paketstruktur.

• Die Unique Identifier Extension enthält eine zufällige Nonce, um Replay-Angriffe zu verhindern.
• Die NTS-Cookie-Erweiterung enthält eines der NTP-Cookies, die dem Client zur Verfügung stehen. Da nur der Client über die symmetrischen AAED C2S- und S2C-Schlüssel verfügt, muss der NTP-Server diese aus dem Cookie-Material extrahieren.
• Mit der NTS-Cookie-Platzhaltererweiterung kann ein Client zusätzliche Cookies vom Server anfordern. Diese Erweiterung ist notwendig, um sicherzustellen, dass die Antwort des NTP-Servers nicht viel länger als die Anfrage ist. Dies trägt dazu bei, Verstärkungsangriffe zu verhindern.
• NTS Authenticator und Encrypted Extension Fields Extension enthalten die AAED-Verschlüsselung mit dem C2S-Schlüssel, NTP-Header, Zeitstempeln und dem oben genannten EF als Begleitdaten. Ohne diese Erweiterung ist es möglich, Zeitstempel zu fälschen.

Beim Empfang einer Anfrage von einem Client überprüft der Server die Authentizität des NTP-Pakets. Dazu muss er die Cookies entschlüsseln, den AAED-Algorithmus und die Schlüssel extrahieren. Nach erfolgreicher Überprüfung des NTP-Pakets auf Gültigkeit antwortet der Server dem Client im folgenden Format.

• Unique Identifier Extension ist eine Spiegelkopie der Client-Anfrage, eine Maßnahme gegen Replay-Angriffe.
• NTS-Cookie-Erweiterung mehr Cookies, um die Sitzung fortzusetzen.
• NTS Authenticator und Encrypted Extension Fields Extension enthalten die AEAD-Verschlüsselung mit einem S2C-Schlüssel.

Der zweite Handshake kann unter Umgehung des ersten Schritts viele Male wiederholt werden, da jede Anfrage und Antwort dem Client zusätzliche Cookies gibt. Dies hat den Vorteil, dass die relativ ressourcenintensiven TLS-Vorgänge zur Berechnung und Übertragung von PKI-Daten durch die Anzahl der wiederholten Anfragen geteilt werden. Dies ist besonders praktisch für spezialisierte FPGA-Zeitnehmer, da die gesamte Hauptfunktionalität in mehrere Funktionen aus dem Bereich der symmetrischen Kryptographie gepackt werden kann und der gesamte TLS-Stack auf ein anderes Gerät übertragen wird.

NTPsec

Was ist das Besondere an NTP? Obwohl der Autor des Projekts, Dave Mills, versucht hat, seinen Code so gut wie möglich zu dokumentieren, ist es ein seltener Programmierer, der in der Lage ist, die Feinheiten der 35 Jahre alten Zeitsynchronisationsalgorithmen zu verstehen. Ein Teil des Codes wurde vor der POSIX-Ära geschrieben und die Unix-API unterschied sich damals stark von dem, was heute verwendet wird. Darüber hinaus sind statistische Kenntnisse erforderlich, um das Signal auf verrauschten Leitungen von Störungen zu befreien.

NTS war nicht der erste Versuch, NTP zu reparieren. Als Angreifer lernten, NTP-Schwachstellen auszunutzen, um DDoS-Angriffe zu verstärken, wurde klar, dass radikale Änderungen erforderlich waren. Und während die NTS-Entwürfe vorbereitet und finalisiert wurden, stellte die US-amerikanische National Science Foundation Ende 2014 dringend einen Zuschuss für die Modernisierung von NTP bereit.

An der Spitze der Arbeitsgruppe stand nicht irgendjemand, sondern Eric Steven Raymond – einer der Gründer und Stützen der Open-Source-Community und Autor des Buches Kathedrale und Basar. Das erste, was Eric und seine Freunde versuchten, war, den NTP-Code von der BitKeeper-Plattform nach Git zu verschieben, aber so funktionierte es nicht. Projektleiter Harlan Stenn war gegen diese Entscheidung und die Verhandlungen gerieten ins Stocken. Dann wurde beschlossen, den Projektcode zu forken, und NTPSec war geboren.

Solide Erfahrung, einschließlich der Arbeit an GPSD, ein mathematischer Hintergrund und die magische Fähigkeit, alten Code zu lesen – Eric Raymond war genau der Hacker, der ein solches Projekt auf die Beine stellen konnte. Das Team fand einen Code-Migrationsspezialisten und in nur 10 Wochen NTP sich niederlassenauf GitLab. Die Arbeiten waren in vollem Gange.

Das Team von Eric Raymond nahm die Aufgabe auf die gleiche Weise an wie Auguste Rodin mit einem Steinblock. Durch die Entfernung von 175 KLOC alten Codes konnten sie die Angriffsfläche erheblich reduzieren und viele Sicherheitslücken schließen.

Hier ist eine unvollständige Liste derjenigen, die in der Distribution enthalten sind:

• Undokumentierte, veraltete, veraltete oder defekte Refclock.
• Unbenutzte ICS-Bibliothek.
• libopts/autogen.
• Alter Code für Windows.
• ntpdc.
• Autokey.
• Der ntpq-C-Code wurde in Python neu geschrieben.
• Der sntp/ntpdig-C-Code wurde in Python neu geschrieben.

Neben der Bereinigung des Codes hatte das Projekt noch weitere Aufgaben. Hier ist eine unvollständige Liste der Erfolge:

• Der Codeschutz vor Pufferüberlauf wurde deutlich verbessert. Um Pufferüberläufe zu verhindern, wurden alle unsicheren String-Funktionen (strcpy/strcat/strtok/sprintf/vsprintf/gets) durch sichere Versionen ersetzt, die Puffergrößenbeschränkungen implementieren.
• NTS-Unterstützung hinzugefügt.
• Verbesserte Zeitschrittgenauigkeit um das Zehnfache durch die Verbindung physischer Hardware. Dies liegt daran, dass moderne Computeruhren viel genauer geworden sind als die Uhren, als NTP geboren wurde. Die größten Nutznießer davon waren GPSDO und spezielle Zeitradios.
• Die Anzahl der Programmiersprachen wurde auf zwei reduziert. Statt Perl, awk und sogar S-Skripten ist es jetzt alles Python. Dadurch gibt es mehr Möglichkeiten zur Wiederverwendung von Code.
• Anstelle von Nudeln aus Autotools-Skripten begann das Projekt, ein Software-Build-System zu verwenden waf.
• Aktualisierte und neu organisierte Projektdokumentation. Aus einer widersprüchlichen und teils archaischen Dokumentensammlung schufen sie eine durchaus passable Dokumentation. Jeder Befehlszeilenschalter und jede Konfigurationseinheit verfügt jetzt über eine einzige Version der Wahrheit. Darüber hinaus werden Manpages und Webdokumentation jetzt aus denselben Kerndateien erstellt.

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

(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]

Chronisch

Es gab einen weiteren Versuch, das alte NTP durch eine sicherere Alternative zu ersetzen. Chrony wird im Gegensatz zu NTPSec von Grund auf neu geschrieben und ist so konzipiert, dass es unter einer Vielzahl von Bedingungen zuverlässig funktioniert, einschließlich instabiler Netzwerkverbindungen, teilweiser Netzwerkverfügbarkeit oder -überlastung sowie Temperaturschwankungen. Darüber hinaus bietet Chrony weitere Vorteile:

• Chrony kann die Systemuhr schneller und genauer synchronisieren;
• Chrony ist kleiner, verbraucht weniger Speicher und greift nur bei Bedarf auf die CPU zu. Dies ist ein großes Plus für die Ressourcen- und Energieeinsparung;
• chrony unterstützt Hardware-Zeitstempel unter Linux und ermöglicht so eine äußerst genaue Synchronisierung in lokalen Netzwerken.

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

Um die Funktionalität des Servers und NTP-Anfragen an den chronyd-Prozess zu deaktivieren, schreiben Sie einfach Port 0 in die Datei chrony.conf. Dies geschieht in Fällen, in denen keine Zeit für NTP-Clients oder -Peers eingehalten werden muss. Seit Version 2.0 ist der NTP-Server-Port nur dann geöffnet, wenn der Zugriff durch eine Allow-Anweisung oder einen entsprechenden Befehl erlaubt ist, ein NTP-Peer konfiguriert ist oder eine Broadcast-Anweisung verwendet wird.

Das Programm besteht aus zwei Modulen.

• chronyd ist ein Dienst, der im Hintergrund läuft. Es erhält Informationen über die Differenz zwischen der Systemuhr und dem externen Zeitserver und passt die lokale Zeit an. Es implementiert außerdem das NTP-Protokoll und kann als Client oder Server fungieren.
• chronyc ist ein Befehlszeilenprogramm zur Programmüberwachung und -steuerung. Wird zur Feinabstimmung verschiedener Dienstparameter verwendet, sodass Sie beispielsweise NTP-Server hinzufügen oder entfernen können, während chronyd weiterhin ausgeführt wird.

Seit Version 7 von RedHat Linux verwendet chrony als Zeitsynchronisationsdienst. Das Paket ist auch für andere Linux-Distributionen verfügbar. Die neueste stabile Version ist 3.5 und bereitet die Veröffentlichung von v4.0 vor.

(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]

So richten Sie Ihren eigenen Remote-Chrony-Server im Internet ein, um die Zeit in einem Büronetzwerk zu synchronisieren. Nachfolgend finden Sie ein Beispiel für die Einrichtung eines VPS.

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

Lassen Sie uns nun ein wenig üben und unseren eigenen NTP-Server auf einem VPS einrichten. Es ist ganz einfach: Wählen Sie einfach den entsprechenden Tarif auf der RuVDS-Website aus, besorgen Sie sich einen fertigen Server und geben Sie ein Dutzend einfacher Befehle ein. Für unsere Zwecke ist diese Option durchaus geeignet.

Fahren wir mit der Einrichtung des Dienstes fort und installieren zunächst das Chrony-Paket.

[root@server ~]$ yum install chrony

RHEL 8 / CentOS 8 verwenden einen anderen Paketmanager.

[root@server ~]$ dnf install chrony

Nach der Installation von chrony müssen Sie den Dienst starten und aktivieren.

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

Bei Bedarf können Sie Änderungen an /etc/chrony.conf vornehmen und NPT-Server durch die nächstgelegenen lokalen Server ersetzen, um die Antwortzeit 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 richten wir die Synchronisierung des NTP-Servers mit Knoten aus dem angegebenen Pool ein.

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

Außerdem ist es 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 richtig einzustellen.

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

Die Datei /etc/chrony.conf gibt die IP-Adresse oder den Hostnamen unseres VPS-Servers an, auf dem der NTP-Server Chrony ausgeführt wird.

server my.vps.server

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

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

Das nächste Mal erzähle ich euch, welche Möglichkeiten es gibt, die Zeit ohne Internet zu synchronisieren.

Source: habr.com