Ein neuer adminForge Service kann ab sofort genutzt werden. Eine geographische Nähe zu einem Zeitserver ist wichtig um die höchstmögliche Genauigkeit der Zeitsynchronisation zu bekommen. Du kannst jeden unserer Server in deiner NTP-Konfiguration verwenden....
by adminForge.
In diesem dritten Teil meiner Serie über RHEL System Roles nutze ich die Rolle timesync, um die NTP-Pool-Zone de.pool.ntp.org für meine Hosts zu konfigurieren.
Ich möchte mit diesem Artikel zeigen, wie einfach die Nutzung der RHEL System Roles ist, um eine Gruppe von RHEL-Servern zu konfigurieren. Dabei muss ich mich nicht um Details wie die Frage kümmern, ob auf meinen Zielhosts ntpd oder chronyd für die Zeitsynchronisierung genutzt wird. Diese Aufgabe löst die Ansible-Rolle für mich.
Bevor ich fortfahre, habe ich eine Warnung: Diese Rolle ersetzt die Konfiguration auf den Zielsystemen. Alle zuvor dort getroffenen Einstellungen werden verloren gehen.
Man muss sich also entscheiden, ob man die Zeitsynchronisation komplett über diese Rolle steuern möchte oder gar nicht.
Auf dem Ansible-Controller müssen die Pakete ansible-core und rhel-system-roles installiert sein.
Ich möchte mehrere NTP-Server konfigurieren. Für diesen Anwendungsfall liefert die Rolle timesync bereits ein Beispiel mit, welches ich mittels Copy-Paste-and-Modify in mein Playbook übernehme.
Anmelden
[root@ansible-ctrl ]# cp /usr/share/doc/rhel-system-roles/timesync/example-multiple-ntp-servers-playbook.yml ansible/use_de_ntp_servers.ymlDas Playbook sieht nach der Anpassung wie folgt aus:
- hosts: all
vars:
timesync_ntp_servers:
- hostname: 0.de.pool.ntp.org
iburst: yes
- hostname: 1.de.pool.ntp.org
iburst: yes
- hostname: 2.de.pool.ntp.org
iburst: yes
- hostname: 3.de.pool.ntp.org
iburst: yes
roles:
- rhel-system-roles.timesyncUm zu sehen, wie die Datei /etc/chrony.conf vor und nach dem Playbook-Lauf aussieht, lasse ich das Playbook zuerst mit den Optionen -C (aktiviert Check-Mode) und -D (zeigt die Änderungen an) laufen. So kann ich vorab prüfen, welche Änderungen vorgenommen werden, bevor es ernst wird. Die Ausgabe ist über 500 Zeilen lang. Ich habe sie auf Gist gepostet und hier eingebunden. Wer sich für die Ausgabe nicht interessiert, kann direkt zur Zusammenfassung springen.
Anschließend habe ich das Playbook ohne die Optionen -C und -D ausgeführt und meine Hosts wie gewünscht konfiguriert.
Mit der RHEL System Role timesync kann die Zeitsynchronisation verschiedener RHEL-Releases schnell und einfach konfiguriert werden, ohne Kenntnis über die konkrete Implementierung auf den Zielsystemen zu besitzen.
Gleichzeitig kann ein Blick in die Struktur der Rolle und den Inhalt der dazugehörigen Dateien Aufschluss darüber geben, wie Ansible-Rollen für mehrere RHEL-Major-Releases erstellt werden können. Man kann dies für die Erstellung eigener Rollen mit ein wenig Transferleistung wiederverwenden.
Viele der Technologien, die wir heutzutage einsetzen, haben eine lange Geschichte hinter sich. Moderne Ansätze, sie nachzurüsten, können in bestimmten Szenarien jedoch unangenehme Auswirkungen haben. Ein kleines Beispiel möchte ich euch heute vorstellen.
Craig Younkins hat in seinem Blog auf Medium ein kurzes Szenario beschrieben, das verschlüsseltes DNS (DoH/DoT) und NTP involviert. Normalerweise gibt es bei so einem Setup wenig Probleme: der Client synchronisiert seine Zeit über NTP, kann Abweichungen ausgleichen und seine DNS-Anfragen über TLS-verschlüsselte Verbindungen abwickeln. Dabei hat der Client jederzeit seine vertrauenswürdigen Zertifikate lokal gespeichert, ebenso die Standardserver für NTP, die üblicherweise durch einen Hostname nach dem Muster *.pool.ntp.org adressiert werden.
Der Fallstrick: vergisst der Client die Zeit komplett, kann er in einem Deadlock landen und gegebenenfalls die Zeit nicht mehr synchronisieren. So ein Szenario kann auftreten, wenn ein System ausgeschaltet wurde und keine Real-Time-Clock in der Hardware verbaut wurde, die über eine eigene Batterieversorgung (i. d. R. Knopfzelle) verfügt. Bei einigen günstigen Routern bzw. IoT-Geräten wie dem Raspberry Pi ist das der Fall.
Findet das System keinen Anhaltspunkt über die aktuelle Zeit, so startet es, je nach Implementierung, meist beim Unix-Timestamp 1 bzw. am 01.01.1970. Dies kann jedoch in Verbindung mit TLS eine gefährliche Wirkung entfalten, da für die Zertifikatsvalidierung auf das aktuelle Datum zurückgegriffen wird – schließlich verfügen die meisten Zertifikate über einen festen Gültigkeitszeitraum, der nur wenige Monate umfasst.
Das Ergebnis: alle mit TLS abgewickelten DNS-Anfragen über die NTP-Server schlagen fehl. Dabei ist hervorzuheben, dass NTP selber unverschlüsselt weiterhin abläuft, es können lediglich die IP-Adressen der Server nicht ermittelt werden.
Damit soetwas nicht passiert, können Administratoren auf verschiedene Art und Weise vorbeugen. Eine erste Möglichkeit wäre, wie im Artikel beschrieben, das Hinterlegen von IP-Adressen im NTP-Client. Damit umgeht man DoH/DoT und kann direkt mit der NTP-Synchronisation fortfahren. Nachteil dieser Variante ist jedoch, dass es einerseits nur wenige NTP-Server mit wirklich statischen Adressen gibt (einer der wenigen Anbieter ist z. B. die NIST) und andererseits NTP generell eher auf Hostnames arbeitet, um z. B. einen Lastausgleich sicherzustellen.
Die zweite Variante wäre der Einsatz spezieller DHCP-Optionen wie Option 42, mit der beim Bezug der Netzwerkkonfiguration auch durch den DHCP-Server bestimmte IPv4-Adressen empfohlen werden können. In der Regel handelt es sich um lokale IPv4-Adressen, wenn lokal ein eigener NTP-Server betrieben wird, der seine Zeit mit höherrangigen Servern wiederum synchronisiert. DHCPv6 verfügt mit Option 56 über ein Äquivalent. (Q, RFC 2132 sec. 8.3., RFC 5908)
Es gibt allerdings auch spannendere Methoden: so ist der Ansatz von tlsdate, die Zeit über den TLS-Handshake von Internetdiensten wie Google oder Wikipedia zu extrahieren. Darüber hinaus wird momentan bei der IETF die Entwicklung von roughtime vorangetrieben, das hierfür ein eigenes kryptographisches Protokoll einsetzt. (Q, draft-ietf-ntp-roughtime-07, Artikel von Cloudflare)
Wer ein Dateisystem wie ext4 nutzt, findet darüber hinaus im Superblock aus dem vergangenen Mount hilfreiche Zeitangaben. Diese mount time und write time werden nämlich in der Regel bei jedem Mount und Schreibvorgang gesetzt und können als Anhaltspunkt für die Systemzeit des vergangenen Starts dienen - genug, um bei regelmäßig verwendeten Systemen immerhin die DoH-Anfrage für die initiale NTP-Namensauflösung abzuwickeln. (Q)
Verschiedene komplexe Komponenten wie DoH/DoT und NTP können bei bestimmten Randbedingungen zu Situationen führen, die man bei der Erstkonfiguration vermutlich nicht vor Augen hatte. Wer jedoch mit dafür anfälligen Systemen ohne Real-Time-Clock arbeitet, kann auf verschiedene Strategien zur Abhilfe setzen: einerseits können Anhaltspunkte für die Zeit aus dem vergangenen Start gesucht werden oder zunehmend Protokolle genutzt werden, die genau dieses Problem adressieren.
