# Time Security Mastery: Warum die Uhrzeit über Sicherheit entscheidet

TL;DR / Management Summary Ohne präzise Uhrzeit bricht die moderne Kryptografie zusammen. Zertifikate werden ungültig (Artikel 319), OTP-Tokens schlagen fehl (Artikel 318) und Logs lassen sich nicht mehr korrelieren. Aber das klassische NTP (Port 123 UDP) ist unsicher und kann für DDoS-Attacken missbraucht werden. Ein Senior Admin nutzt heute chrony statt dem alten ntpd und setzt auf Network Time Security (NTS), um Zeitdaten verschlüsselt und fälschungssicher zu beziehen.

# 1. Einführung & Architektur

Zeit als kritische Infrastruktur.

In Linux-Systemen haben wir zwei Uhren:

1. Hardware-Uhr (RTC): Die Batterie-gepufferte Uhr auf dem Mainboard.
2. System-Uhr: Die vom Kernel verwaltete Zeit (wird beim Boot von der RTC geladen).

# Die Bedrohungs-Matrix (Mermaid)

graph TD
    A[Public NTP Server] -->|UDP 123: Unencrypted| B[SLES / Arch Host]
    C[Attacker] -->|MITM / Spoof| B
    C -->|Drift Injection| B
    B --> D{Impact}
    D --> E[Broken TLS Handshakes]
    D --> F[Log Manipulation]
    D --> G[MFA Token Rejection]
    subgraph "Solution: NTS"
        H[NTS Provider: Cloudflare / PTB] -->|TLS Handshake| B
        B -->|Encrypted NTP| B
    end

# 2. Der moderne Standard: Chrony

Schneller und sicherer als ntpd.

Chrony ist für virtuelle Maschinen und instabile Verbindungen optimiert.

# Installation & Aktivierung

sudo apt install chrony # Debian/Ubuntu
sudo dnf install chrony # RHEL
sudo systemctl enable --now chronyd

# Konfiguration für NTS (Verschlüsselte Zeit)

Datei: /etc/chrony.conf

# Nutze Cloudflare mit NTS
server time.cloudflare.com iburst nts
# Nutze PTB (Physikalisch-Technische Bundesanstalt)
server ptbtime1.ptb.de iburst nts

# Verhindere, dass der Server selbst als NTP-Relay missbraucht wird
allow 127.0.0.1
# (Keine weiteren 'allow' Zeilen ohne Firewall-Schutz!)

# 3. systemd-timesyncd

Die minimalistische Alternative.

Für einfache Clients oder Container reicht oft der integrierte systemd-Dienst. Datei: /etc/systemd/timesyncd.conf

[Time]
NTP=0.arch.pool.ntp.org 1.arch.pool.ntp.org

# 4. Day-2 Operations: Status & Drift

Läuft die Uhr synchron?

# Chrony Status prüfen

# Zeige Quellen und deren Genauigkeit
chronyc sources -v

# Zeige Drift-Statistiken
chronyc tracking

Achten Sie auf “Last offset”. Ein Wert im Mikrosekunden-Bereich ist ideal.

# 5. Troubleshooting & “War Stories”

Wenn die Zeit springt.

# Story 1: “Der hängende Kerberos-Login”

Symptom: In einer AD-Domain können sich User nicht mehr einloggen. Fehlermeldung: Clock skew too great. Ursache: Die Zeit des SLES-Servers weicht um mehr als 5 Minuten von der Zeit des Domain Controllers ab. Lösung: Synchronisieren Sie den Server direkt mit dem DC: chronyc manual on && chronyc add server dc01.company.local iburst.

# Story 2: “NTP-Amplification-Angriff”

Symptom: Ein Server im RZ hat massive Outbound-Bandbreite auf Port 123 UDP und steht auf einer Blacklist. Ursache: Der Admin hat den alten ntpd installiert und die Standard-Config gelassen. Angreifer nutzen den Server als Reflektor für DDoS-Attacken. Lösung: Wechseln Sie zu Chrony (das standardmäßig keine Anfragen von außen beantwortet) oder konfigurieren Sie restrict Regeln in der ntp.conf.

# 6. Fazit & Empfehlung

• Wahl: Nutzen Sie Chrony für alle Server.
• Security: Aktivieren Sie NTS, um sich gegen “Man-in-the-Middle” Angriffe auf die Systemzeit zu schützen.
• Best Practice: Nutzen Sie mindestens 4 verschiedene Zeitquellen, um Fehlmessungen einzelner Server zu erkennen.

# Anhang: Cheatsheet