Sie mögen sich jetzt fragen: «Was haben meine Zeiteinstellungen zu meiner Security beizutragen?» Auch wenn Sie keine zeitkritischen Applikationen betreiben, ist NTP ein wichtiges Protokoll für die Integrität und Sicherheit Ihrer Daten.

Das Network Time Protocol (NTP) ist das am meisten verwendete Protokoll zum Einstellen und Beibehalten einer genauen Systemzeit. Neben dem NTP existiert auch noch das weniger bekannte Precision Time Protocol (PTP), dies kann die Zeit im Bereich von Nanosekunden genau bestimmen und wird vor allem im Bereich von industrieller Automatisierung wie beispielsweise im Zeitungsdruck oder in Finanztransaktionen und im Börsenhandel eingesetzt. Im Gegensatz zu NTP, wird die Zeit für PTP auf Hardwarelevel generiert und ist damit um ein Vielfaches genauer, benötigt jedoch zusätzliche Hardware – wie Netzwerkkarten – welche PTP unterstützt. Doch nun wieder zurück zum eigentlichen Thema, NTP.


NTP pool

Für über 90% der Fälle ist NTP mit der Genauigkeit von wenigen Mikrosekunden ausreichend präzise. Für viele Applikationen reicht gar eine Genauigkeit im Sekunden-Bereich aus, um korrekt zu funktionieren, dazu gehören unter anderem Proxy, Mail Gateways oder Firewalls.

Genau hier stossen wir an das eigentliche Problem. Da die Zeitgenauigkeit «π * Daumen» oft ausreicht, wird auf die NTP-Einstellung keinen Fokus mehr gelegt, da es so in den allermeisten Fällen funktioniert.  Der Grossteil der Geräte hat in der NTP-Konfiguration «pool.ntp.org» konfiguriert, damit wird die Zeit synchronisiert. Mit dieser Konfiguration sucht sich das System einen optimalen Server aus dem Pool aus und synchronisiert mit diesem die Zeit.

Aber was passiert nun, wenn der angepeilte Server nicht verfügbar ist oder unsinnige Zeitangaben zurückgibt? Je nach Einstellungen beginnt NTP der falschen Zeit zu glauben und die Uhr langsam danach auszurichten. Mit den richtigen Einstellungen dauert diese Umstellung einige Stunden oder gar mehrere Tage, wenn man davon ausgeht, dass dieser Zeitserver für jeden Poll (i.d.R. zwischen 1024 und 64 Sekunden) die gleiche falsche Zeit wiedergibt.


Alles halb so wild. Oder?

Das Network Time Protocol passt die Zeit also immer nur in Schritten von einigen Millisekunden an, somit kann die Uhr nicht plötzlich über mehrere Minuten oder Stunden abweichen. Zudem haben die meisten Systeme auch eine Hardware Clock, wo die Zeit auch im ausgesteckten Zustand mithilfe einer Batterie weiterläuft. Bei Systemen in Betrieb ist diese Problematik folglich nicht so gravierend. Es sei denn, die falschen Optionen sind gesetzt. Doch dazu mehr im zweiten Teil, der in einigen Wochen folgen wird.


Quorum

Über einen längeren Zeitraum kann die Zeit stark von der eigentlichen Zeit abweichen, was nur schon bei einer AD-Authentifizierung sehr bald zu Problemen führen wird. Dies verhindere ich, indem ich mindestens drei NTP-Server als Zeit-Source angebe. Folgend die Varianten im Vergleich, mit einem, zwei oder drei & mehr NTP-Server.

  1. Wenn Sie nur einen Server konfiguriert haben und dieser Server beginnt abzudriften, dann wird NTP diesem Drift folgen. Wenn dieser Server jeden Monat 5 Sekunden vorläuft, dann wird dies der Server übernehmen.
  2. Wenn Sie nur zwei Server konfiguriert haben, werden beide automatisch von NTP als „falsche Ticker“ zugewiesen. Wenn einer der Server anfängt abzudriften, wäre NTP nicht in der Lage zu sagen, welcher Upstream-Server korrekt ist, da es kein Quorum gäbe. Diese Option ist somit schlechter, als nur einen Zeitserver zu benutzen.
  3. Wenn Sie drei Server konfiguriert haben, dann können Sie „falsche Ticker“ unterstützen und haben trotzdem eine Vereinbarung über die genaue Uhrzeit. Bei vier Servern ist eine Redundanz enthalten. Wenn Sie fünf oder sechs Server haben, dann können Sie zwei falsche Ticker unterstützen. Wenn Sie sieben oder acht Server haben, können Sie drei falsche Ticker unterstützen, und … Sie verstehen, denke ich 🙂

Ein Blick über den Tellerrand hinaus

Wagen wir nun mal einen Blick etwas weiter in die Welt der zeitlich gesteuerten Dinge in der IT. Neben den klassischen Computern, Switches, Router, Proxy etc. gibt es immer mehr Geräte im Bereich Internet of Things, wovon viele keine Batterie besitzen und somit immer der Zeit der NTP-Server Glauben schenken müssen. Wird eines dieser Geräte neu gestartet, kann das Datum bei einer falschen Zeitquelle von vor dem Reboot 01.01.2019 zu nach dem Reboot 01.01.2023 sofort ändern. Ist bei dem Gerät nur ein Zeitserver hinterlegt, wird dieser Zeit Glaube geschenkt, weil es keine Alternative dafür gibt.


Ich wurde gespoofed. Und jetzt?

Gehen wir davon aus, jemand hat es geschafft die Zeit eines Ihrer Geräte zu spoofen, sodass die Zeit nun fünf Jahre in der Zukunft liegt. Was bringt das dem Angreifer?

  • Die meisten Ihrer Passwörter würden ablaufen.
  • Alle Ihre SSL-Zertifikate würden verfallen.
  • Alle Ihre IPSEC-Tunnel würden down gehen und sich weigern, neu zu starten.
  • Viele Ihrer Cron-Jobs würden möglicherweise alle «alten» Logs löschen.
  • Ein Großteil Ihres DNSSEC würde ablaufen.
  • Viele Ihrer Backups werden gelöscht, da sie „abgelaufen“ sind.

Best Practice

Es sollten immer Minimum (!) 4 verschiedene Zeitserver verwendet werden, dies kann erreicht werden indem verschiedene Server aus dem Pool angegeben werden. So kann sich das System einer Mehrheit bedienen. Sollte eines der Systeme eine grosse Ungenauigkeit aufweisen, wird dieses für den Moment auf «ignore» gestellt und eine glaubwürdige Zeitquelle als Referenz genommen.

Für die Schweiz empfiehlt es sich hierbei den Servern des NTP-Pool-Projektes zu bedienen: www.pool.ntp.org/zone/ch
Selbiges gilt auch für Deutschland, oder Österreich:
www.pool.ntp.org/zone/de
www.pool.ntp.org/zone/at

Will ich die Server einzeln angeben, kann ich diese durchnummerieren. Diese Hostnamen zeigen auf zufällig ausgewählte Zeitserver in diesem Pool, welche sich stündlich ändern.

server 0.ch.pool.ntp.org
server 1.ch.pool.ntp.org
server 2.ch.pool.ntp.org
server 3.ch.pool.ntp.org


Best Practice 2.0

Je mehr Netzwerkgeräte zwischen einem Client und einem Server sind, desto ungenauer wird die Zeit. Sinnvollerweise benutze ich im Optimalfall interne NTP-Server. Habe ich das Privileg, einen eigenen Stratum 1 Server im lokalen Netzwerk zu besitzen, bildet dies den bestmöglichen Fall ab. Diese «lokalen» NTP-Server verbinden sich – im Falle eines Stratum 1 Servers – regelmässig zu einem Stratum 0 Zeitserver, z.B. von Meinberg. Dies können unter anderem Atomuhren sein, welche zu den genausten Uhren der Welt gehören.

Wieso das besser ist und was das mit Jitter und Polling Intervals auf sich hat, schauen wir uns im 2. Teil genauer an.


Vorbilder

SEPPmail hat dies sehr vorbildlich gelöst, in der Konfiguration trägt man lediglich den präferierten Pool ein.

SEPPmail Konfiguration NTP-Server

Schauen wir uns dann die Konfiguration an, hat SEPPmail im Hintergrund 16 Zeitquellen des Pools abgefragt und in die Konfiguration eingetragen:

SEPPmail Konfiguration NTP-Server 2

Eine ausreichende Redundanz ist damit garantiert.


Schlusswort

Falls möglich sollten immer 4 oder mehr Zeitserver verwendet werden. Ist dies nicht möglich, gilt es sich an diese Reihenfolge zu halten:

Genügend:         3 Zeitquellen

Schlechter:         1 Zeitquelle

Schlecht:             2 Zeitquellen

Bei NTP ist mehr immer besser. Eine Ausnhame bildet die Verwendung von 2 Zeitserven.

Im 2. Teil widmen wir uns dem Spoofing und den einzelnen Optionen von NTP, Authentication, Stratum, eigenen NTP-Servern und anderen technischen Eigenschaften.



Chriesibaum

Chriesibaum

Chriesibaum ist Security Engineer und war vor der Zeit bei AVANTEC fast ein Jahrzehnt als System Engineer unter Linux und diversen Virtualisierungs-Lösungen tätig. Er interessiert sich für alles was Unix basiert und Unix-like ist und wo man sich in der Kommandozeile frei bewegen kann. Dazu gehören besonders RedHat basierende Produkte wie Check Point. Er ist ein Fan von der Open Source Philosophie und ein RedHat Fanboy.

Privacy Preference Center