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.
- 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.
- 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.
- 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.
Schauen wir uns dann die Konfiguration an, hat SEPPmail im Hintergrund 16 Zeitquellen des Pools abgefragt und in die Konfiguration eingetragen:
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 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.
NTP und die Zeit ist ein Thema, welches immer gerne zu wenig beachtet wird. Wie du geschrieben hast, braucht ein NTP Client zu jedem Zeitpunkt mindestens 3 funktionierende Server. Allerdings bringt es wenig, mehr als 5 NTP Server zu konfigurieren.
Beim Thema Zeit gibt es folgende Punkte, die gerne vergessen werden:
1.NTP kann, wie viele auf UDP basierende Protokolle, einfach spoofed werden. NTP Authentication ist definitiv etwas, was man sich unbedingt ansehen sollten.
2. Monitoring. Die wenigsten Unternehmen überwachen die Zeit ihrer Systeme. Ein abdriften eines Systems fällt meistens erst dann auf, wenn man ganz wundersame Effekte hat.
Bitte höre auf solche Unsinnigen Empfehlungen zu geben. Mehr als 3 Zeitserver bietet absolut keinen Mehrwert und verschwendet nur wertvolle Ressourcen. (Ausnahme: eigene Zeitserver die sich aus dem Pool bedienen. Hier wird bis 3-5 empfohlen, wobei auch hier 3 mehr als ausreichend sind).
Denn,
1. werden ALLE Server im NTP-Pool Projekt überwacht. Weicht ein Server ab wird er aus dem Pool geworfen und der Betreiber informiert
2. wird der Großteil der Zeitserver von ehrenamtlichen Personen gestellt, finanziert und verwaltet – deren Ressourcen verschwendest Du mit solchen Empfehlungen!
Jedes Jahr werden es mehr und mehr Clients/Geräte. Die Anzahl der Zeitserver jedoch steigt da nicht linear mit. Um genau zu sein fluktuiert die Anzahl der Server – großartig steigen tut da nichts mehr. Das heisst das die Last auf den Zeitpool von Jahr zu Jahr größer wird. Ich betreibe aktuell 2 öffentliche Zeitserver (Mitglied von (de|europe|global).pool.ntp.org) und kann dir sagen das ich vor etwa 1.5 Jahren noch ca. 1000 req/s hatte. Heute sind es ca. 1300 req/s – tendenz steigend.
Mittlerweile kommen vermehrt Server die sich Zeit via HTTP abholen (verschwendet Ressourcen in jeglicher Hinsicht!) oder sogar den NTP Pool Monitoren (warum auch immer die de**en das tun…) und ich kann nichts gegen diesen Unsinn tun (Ausser die Server aus dem Pool nehmen). Zu dem „Vorbild“ SEPPmail schreibe ich lieber nichts…
Wenn Du jetzt etwas von der anderen Seite der Medaille „gehört“ hast, dann überdenkst Du Deine Empfehlungen vielleicht noch einmal.
p.s.: Eine Statistik zur Anzahl der Zeitserver in den jeweiligen Zonen findest Du unter https://www.ntppool.org/zone/@