Pünktlichkeit spielt nicht nur in zwischenmenschlichen Beziehungen eine wichtige Rolle. Auch Computer benötigen stets die genaue Uhrzeit. Mit dem NTP-Protokoll holen sie diese über das Netzwerk direkt oder indirekt von einer Atomuhr ab. Einige Programme umgehen dabei auch restriktive Firewalls.

Jede billige Armbanduhr zeigt die Zeit genauer an als die Chips, die in modernen Computern werkeln. Mit Tricks lässt sich die Genauigkeit zwar erhöhen, etwa indem Admins die Abweichung messen und daraus einen Korrekturfaktor errechnen. Die genaue Uhrzeit erhalten sie ohne Hilfsmittel aber nicht.

Üblicherweise holt sich ein Computer daher die Uhrzeit von einer guten Referenzuhr. Dazu gibt es viele Möglichkeiten. Mit einem DCF77-Empfänger – angeschlossen an den seriellen oder USB-Port – empfängt der Rechner die Uhrzeit von der Physikalisch-Technischen Bundesanstalt in Braunschweig (PTB), die für den Betrieb hochgenauer Atomuhren verantwortlich zeichnet (Abbildung 1).

Ohne Hardware

Wer keine derart genaue Uhrzeit benötigt und nicht in zusätzliche Hardware investieren will, kann sie auch aus dem Internet beziehen. Dazu dient in der Regel das Network Time Protocol (NTP, aktuelle Version 3, spezifiziert in RFC 1305, [1]), das sowohl über TCP als auch über UDP kommuniziert (jeweils Port 123). Unter Unix implementiert der »ntpd« dieses Protokoll.

Er vereint mehrere raffinierte Tricks, um eine möglichst genaue Synchronisation mit einer Referenzzeit zu erreichen. Diese Zeit heißt UTC (Universal Time/Coordonné). NTP gleicht also nicht die Uhrzeit mehrerer Rechner miteinander ab, sondern es synchronisiert die Uhrzeit mit der Weltzeit UTC.

Dabei kommt eine hierarchische Architektur zum Einsatz (Abbildung 2). Die Idee dahinter: Einige Computer verfügen über hochgenaue Zeitquellen, etwa eine Atomuhr wie die PTB. Rechner, die ihre Zeit direkt von ihr beziehen, gehören zur obersten Kategorie in dieser Hierarchie, genannt Stratum 1. Darunter geht es mit Stratum 2, 3, 4 weiter. Eine Liste von Stratum-1- und -2-Servern liefert [2]. Jeder Computer im System steht normalerweise mit mehreren Geräten eines niedrigeren (hier also besseren) Stratums in Verbindung.

Die Modi von NTP

Für die Weitergabe der Uhrzeit von einem Rechner zum nächsten kennt das NTP-Protokoll drei verschiedene Betriebsarten. Im klassischen Client-Server-Betrieb holt ein Computer die Zeit von einem Server ab. Der Client erhält dabei die Zeit vom Server, aber niemals umgekehrt.

Der zweite, symmetrische Modus funktioniert ähnlich dem Client-Server-Betrieb. Ein Computer empfängt die Uhrzeit vom anderen. Grundsätzlich lässt sich hier die Senderichtung aber umdrehen: Fällt die Zeitquelle des Servers aus, übernimmt der ehemalige Client die Funktion des Servers und versorgt nun den anderen Rechner. Daher spricht man hier auch von gleichberechtigten Peers.

Abbildung 3 zeigt eine Gruppe von drei Peer-Rechnern, die sich gegenseitig redundant mit der Uhrzeit versorgen. Geht die Verbindung zur Zeitquelle eines Servers verloren, bedient er sich an einem der anderen. Diese Gruppe dient dann als Backend für die Clients. In der Regel reicht es jedoch, auch für größere Netze, den asymmetrischen Modus zu benutzen und als Zeitquelle einfach mehrere Server im Internet anzugeben.

Beim dritten NTP-Betriebsmodus arbeitet ein Server im Broadcast-Betrieb. Er schickt in Intervallen ein Paket nach der Art von “Hier bin ich” ins Netzwerk. Clients erfahren so automatisch, an welche IP-Adresse sie NTP-Requests schicken müssen, was eine manuelle Konfiguration erspart.

Der Daemon

Viele Linux- und Unix-Distributionen enthalten bereits den klassischen »ntpd«. Seine Konfiguration erfolgt über die zentrale Datei »/etc/ntp.conf«. Im einfachsten Fall – der trifft bei den meisten Linux-Systemen zu – enthält diese Datei nur die Namen oder IP-Adressen der zu verwendenden Server.

Damit Admins sich nicht um die Pflege der NTP-Serverliste kümmern müssen, hat das NTP-Projekt [3] ein DNS-Alias namens »pool.ntp.org« aufgesetzt. Hinter ihm verbirgt sich eine Reihe von öffentlichen Servern. Listing 1 zeigt, wie simpel mit deren Hilfe eine Konfigurationsdatei aussieht. Aus den drei IP-Adressen, die der »ntpd« daraus erhält, sucht sich der Daemon einfach eine heraus.

Während des Bootens soll der Rechner möglichst früh die Uhrzeit einstellen, auch dann, wenn kein lokaler NTP-Daemon zum Einsatz kommt. Das erledigt der Aufruf »ntpd -q«. Er startet den Daemon vorübergehend und weist ihn dazu an, die Uhrzeit zu beziehen. Danach beendet er sich von selbst. Dieses Vorgehen benutzen einige Distributionen in ihren Bootskripten. Ein ähnliches Resultat liefert der Aufruf von »ntpdate«, das allerdings nicht alle Finessen des großen Bruders enthält.

Probleme mit der Uhrzeit

Probleme bei der Synchronisation der Uhrzeit umgeht der »ntpd« mit einigen Tricks. Liefert der Rechner eine falsche Uhrzeit, sollte das Programm sie nicht abrupt synchronisieren. Wenn nämlich zum Beispiel genau in dem Moment ein Cronjob läuft und »ntpd« die Uhrzeit zurückstellt, würde Cron den Job unter Umständen erneut starten.

Der Daemon muss also für Kontinuität sorgen, ein lineares Hochzählen der Uhrzeit ohne Vorwärts- oder Rückwärts-Sprünge sicherstellen. Er korrigiert daher die Uhr meist in winzigen Schritten – genauer gesagt verkürzt oder verlängert er die Systemsekunden um eine halbe Millisekunde pro Sekunde, das entspricht 0,05 Prozent. Das tut es so lange, bis die Uhr wieder ordnungsgemäß läuft.

Die Korrektur der Uhrzeit um eine einzige Sekunde dauert mit diesem Verfahren aber 2000 Sekunden (über eine halbe Stunde). Um die korrekte Uhrzeit möglichst schnell zu erreichen, schließt der »ntpd« einen Kompromiss: Sobald er eine Abweichung von mehr als 128 Millisekunden registriert, stellt er die Uhrzeit einmal kurz und schmerzlos um (Stepping). Die weiteren Feinjustierungen erfolgen mit den beschriebenen Mikroschritten (Slewing).

01 server pool.ntp.org
02 server pool.ntp.org
03 server pool.ntp.org
04 restrict default kod notrap nomodify nopeer noquery

Abbildung 1: Die Physikalisch-Technische Bundesanstalt betreibt in Braunschweig eine Reihe von Atomuhren. Sie unterliegen lediglich einer Abweichung von ein bis drei milliardstel Sekunden pro Tag, also etwa einer millionstel Sekunde im Jahr. Per Funk oder Internet benutzen Computer diese Uhren als Referenz.

Ob der Daemon lediglich die Systemzeit oder auch die Hardware-Uhr des Rechners einstellt, hängt übrigens von der Konfiguration und vom Betriebssystem ab. Unter FreeBSD wirkt sich eine Änderung der Systemzeit immer auch auf die CMOS-Uhr aus, unter Linux nicht.

Schlechte Zeitquellen

Wer die Uhr nach beliebigen Servern im Internet stellt, muss sich vor falschen Uhrzeiten hüten. Ein NTP-Client geht dieses Problem an, indem er mehrere Server miteinander vergleicht und herausfindet, welcher vermutlich am nächsten an die UTC herankommt. Nur diesen nutzt er dann zur Synchronisation.

Doch führt auch der beste Algorithmus mithin zu Fehlern. Etwa wenn mehrere Server sich widersprechen. Für diesen Fall existiert ein Notfallplan: Stellt der NTP-Daemon fest, dass ein bestimmter Zeitunterschied überschritten wird (per Default 1000 Sekunden), korrigiert er die Uhrzeit gar nicht.

Der NTP-Server kommt übrigens relativ gut damit zurecht, wenn die Netzwerkverbindung oder der konfigurierte Zeitserver für eine Weile ausfallen. Der Daemon misst nämlich die Gangungenauigkeit der Systemuhr und korrigiert diese auf Verdacht, selbst wenn vorübergehend keine Referenzzeit verfügbar ist.

Langsame Verbindungen

Ein weiteres Problem stellt sich, wenn die Latenz der Verbindung zum NTP-Server variiert. Eine nicht ausgelastete ISDN- oder DSL-Verbindung hat eine Latenz von etlichen Millisekunden. Läuft über diese Verbindung aber ein längerer Up- oder Download, dann steigt die Latenz in der jeweiligen Übertragungsrichtung teilweise sprunghaft auf mehrere Sekunden an.

Da der NTP-Server die Latenzverschiebungen nicht ohne weiteres mitbekommt, führt dies unter Umständen zu zwei rasch aufeinander folgenden Umstellungen der Systemuhr. Der »ntpd« enthält einen besonderen Filter für solche Situationen, der aber normalerweise nicht eingeschaltet ist. Wer dies Problem umgehen will, aktiviert den Filter über das Kommando »tinker huffpuff 7200« in der Datei »/etc/ntp.conf«.

Da Clients in einem Netzwerk nach Möglichkeit ohne aufwändige Konfigurationsarbeiten funktionieren sollten, ist eine automatische Konfiguration von NTP sehr wünschenswert. Dazu gibt es mehrere Ansätze. Die am wenigsten flexible Variante benutzt Apple auf den Mac-Rechnern. Aktiviert der Admin den NTP-Daemon, benutzt dieser einen fest vorgegebenen Zeitserver. Der bereits erwähnte Pool des NTP-Projekts ist dafür eine einfache und deutlich sinnvollere Alternative.

Das SNTP-Protokoll in Version 4 (RFC 2030, [1]) beherrscht darüber hinaus die Möglichkeit der autonomen Konfiguration. Per Anycast klappert der Daemon dabei alle Rechner im Netzwerk ab und findet automatisch einen passenden NTP-Server zur Synchronisation.

Sicherheit

Da Admins immer um die Sicherheit ihres Netzwerks besorgt sind, sollten sie sich über die möglichen Gefahren von NTP im Klaren sein. Grundsätzlich gibt es zwei verschiedene Angriffsszenarien: Angriffe innerhalb des Protokolls und solche außerhalb.

Ein Bösewicht könnte innerhalb des Protokolls eine falsche Uhrzeit liefern, um etwa Logdaten zu verbergen oder sogar Denial-of-Service-Angriffe zu fahren. Für die einfache Absicherung der Hosts sollten Administratoren immer eine »restrict«-Anweisung in der Konfigurationsdatei unterbringen, wie in Listing 1. Um sich direkt vor falschen Uhrzeiten zu schützen, helfen nur kryptographisch abgesicherte Methoden. Der »ntpd« enthält dazu eine ganze Reihe von Möglichkeiten, die [4] erläutert.

Da der »ntpd« in der Regel unter der Benutzer-ID 0 (Root) läuft, ist er auch außerhalb des eigentlichen Protokolls ein mögliches Angriffsziel. Ein Buffer Overflow würde reichen, um die Kontrolle über das System zu erlangen. Einzige Abhilfe ist es, den »ntpd« mit der Option »-q« per Cronjob zu starten, sodass er nicht permanent läuft.

Abbildung 2: Ein NTP-Netzwerk ordnet sich hierarchisch in mehrere Schichten, Strata genannt. Zeitquellen wie Atomuhren gehören zur Schicht 0, die Rechner, die an einer solchen Uhr hängen, befinden sich in Schicht 1. Sie versorgen die darunter liegenden Computer der Schicht 2 mit der korrekten Uhrzeit.

Alternativen zu NTP

NTP verhilft zu einer sehr genauen Systemzeit, der Daemon ist obendrein äußerst pflegeleicht. Allerdings gibt es noch eine Reihe von alternativen Protokollen mit ähnlicher Zielsetzung. Das »rdate«-Kommando etwa benutzt das Time-Protokoll aus RFC 868 [1]. Die Kommunikation läuft über den TCP- oder UDP-Port 37. Rdate überträgt die Uhrzeit stets binär, also in für Menschen nicht wirklich lesbarer Form. Daher gibt es neben Rdate auch das Daytime-Protokoll (RFC 867, [1]), das die Uhrzeit über den TCP- oder UDP-Port 13 im Klartext überträgt. Es eignet sich vor allem fürs Troubleshooting und Debugging, der Aufruf von »telnet Server 13« genügt.

Abbildung 3: Die drei NTP-Server (links) arbeiten im symmetrischen Modus, in dem sie sich gegenseitig redundant mit der richtigen Zeit versorgen. Der Client (rechts) holt sich dann einfach die richtige Zeit von einem der Server.

Sowohl Rdate als auch Daytime setzen allerdings voraus, dass eine bestehende Firewall die zugehörigen Ports nicht sperrt. Gibt es keine Möglichkeit, diese in der Firewall freizuschalten, bleibt als letzter Ausweg, einen der erlaubten Ports zu missbrauchen. Das Programm HTPDate ([5], [6]) etwa verbindet sich einfach mit einem Webserver über HTTP oder HTTPS und benutzt den Zeitstempel, den dieser in seiner HTTP-Antwort mitschickt als Referenz. Allerdings sollten Anwender hier nur solche Webserver verwenden, deren Uhrzeit sie voll und ganz vertrauen. (mwe)