Ungepatchte Sicherheitslücken sind einer der häufigsten Angriffsvektoren auf Linux-Server, besonders in KMU ohne eigenes Patching-Team. unattended-upgrades ist das Standardwerkzeug unter Debian und Ubuntu, um Sicherheitsaktualisierungen automatisch einzuspielen. Richtig konfiguriert ist es das Linux-Äquivalent zu WSUS: nur geprüfte Security-Origins, heikle Dienste per Blacklist ausgenommen, Reboots nur im Wartungsfenster, E-Mail bei Fehlern. Die Anleitung reicht von der Installation bis zur Logauswertung.

Voraussetzungen

Debian 13 (Trixie) oder 12 (Bookworm) bzw. Ubuntu 22.04 LTS oder 24.04 LTS, x86_64 oder ARM64
Ressourcen: unattended-upgrades braucht kaum eigene Leistung; jeder Server ab 1 CPU-Kern, 512 MB RAM und etwa 2 GB freiem Platz unter /var für heruntergeladene Pakete genügt
Root- oder sudo-Zugriff auf den Server
Paket unattended-upgrades installiert (auf Ubuntu oft vorinstalliert)
Konfigurierter MTA (postfix als Relay oder msmtp) für E-Mail-Benachrichtigungen
Gültige E-Mail-Adresse für Fehlerbenachrichtigungen
Bekanntes Wartungsfenster (Uhrzeit) für Updates und Reboots
Liste der Dienste/Pakete, die von automatischen Updates ausgenommen werden sollen

Schritt 1: Paket installieren und Grundkonfiguration aktivieren

Auf Debian ist unattended-upgrades nicht immer vorinstalliert. Installieren Sie es zusammen mit apt-listchanges, das Changelog-Einträge vor dem Update anzeigen kann:

sudo apt update && sudo apt install unattended-upgrades apt-listchanges

Den interaktiven Einrichtungsassistenten rufen Sie so auf:

sudo dpkg-reconfigure -plow unattended-upgrades

Der Assistent erzeugt oder überschreibt /etc/apt/apt.conf.d/20auto-upgrades mit den Grundeinstellungen. Passen Sie diese Datei anschließend manuell an:

# /etc/apt/apt.conf.d/20auto-upgrades
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";
APT::Periodic::Download-Upgradeable-Packages "1";
APT::Periodic::AutocleanInterval "7";

"1" bedeutet täglich, "0" deaktiviert eine Funktion. AutocleanInterval "7" bereinigt den APT-Cache wöchentlich, damit heruntergeladene Pakete die Festplatte nicht füllen.

Verifizieren: apt-config dump APT::Periodic zeigt Update-Package-Lists "1" und Unattended-Upgrade "1", systemctl is-enabled apt-daily-upgrade.timer meldet enabled.

Schritt 2: Die eigene Konfigurationsdatei anlegen (52unattended-upgrades-local)

Bearbeiten Sie /etc/apt/apt.conf.d/50unattended-upgrades nicht direkt. Die Datei gehört dem Paket; eigene Änderungen kollidieren bei Paketupdates mit der neuen Fassung und gehen leicht verloren. APT liest Konfigurationsdateien in lexikalischer Reihenfolge, Dateien mit höherem Präfix überschreiben frühere Einstellungen. Legen Sie eine eigene Datei an:

sudo nano /etc/apt/apt.conf.d/52unattended-upgrades-local

Wichtig bei Listen wie Package-Blacklist oder Origins-Pattern: APT kumuliert Listen statt sie zu ersetzen. Wollen Sie die Original-Liste komplett neu definieren, stellen Sie ein #clear voran:

#clear Unattended-Upgrade::Origins-Pattern;

Die vollständige Konfiguration für Debian-Server:

# /etc/apt/apt.conf.d/52unattended-upgrades-local

// --- Nur Security-Origins (Debian) ---
// #clear leert die aus 50unattended-upgrades geerbte Liste
#clear Unattended-Upgrade::Origins-Pattern;
Unattended-Upgrade::Origins-Pattern {
    "origin=Debian,codename=${distro_codename},label=Debian-Security";
    "origin=Debian,codename=${distro_codename}-security,label=Debian-Security";
};

// --- Blacklist fuer heikle Dienste ---
Unattended-Upgrade::Package-Blacklist {
    "nginx$";
    "nginx-";
    "mysql-server";
    "mysql-client";
    "mariadb-server";
    "mariadb-client";
    "postgresql";
    "postgresql-";
    "redis-server";
    "haproxy";
};

// --- E-Mail bei Fehlern ---
Unattended-Upgrade::Mail "admin@example.com";
Unattended-Upgrade::MailReport "only-on-error";
// Optional: Unattended-Upgrade::Sender "server@example.com";

// --- Automatischer Neustart im Wartungsfenster ---
Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-WithUsers "false";
Unattended-Upgrade::Automatic-Reboot-Time "03:00";

// --- Aufraeumen nach Updates ---
Unattended-Upgrade::Remove-Unused-Dependencies "true";
Unattended-Upgrade::Remove-New-Unused-Dependencies "true";

Auf Ubuntu-Servern verwenden Sie statt Origins-Pattern den historischen Schlüssel Allowed-Origins der Ubuntu-Standarddatei (beide funktionieren auf beiden Systemen):

// --- Nur Security-Origins (Ubuntu) ---
#clear Unattended-Upgrade::Allowed-Origins;
Unattended-Upgrade::Allowed-Origins {
    "${distro_id}:${distro_codename}-security";
    "${distro_id}ESMApps:${distro_codename}-apps-security";
    "${distro_id}ESM:${distro_codename}-infra-security";
};

Die ESM-Zeilen sind nur relevant bei Ubuntu Pro / Ubuntu Advantage. Auf Standard-Ubuntu ohne Pro-Abonnement können Sie sie weglassen.

Verifizieren: apt-config dump Unattended-Upgrade::Origins-Pattern (Ubuntu: Unattended-Upgrade::Allowed-Origins) listet nur die Security-Einträge, apt-config dump Unattended-Upgrade::Mail zeigt Ihre Adresse.

Schritt 3: Debian vs. Ubuntu – Unterschiede auf einen Blick

Eigenschaft	Debian (Trixie/Bookworm)	Ubuntu (22.04/24.04 LTS)
Origins-Schlüssel	`Origins-Pattern`	`Allowed-Origins` (historisch)
Security-Origin-Format	`origin=Debian,codename=...,label=Debian-Security`	`${distro_id}:${distro_codename}-security`
Security-Quellen	Zwei Einträge nötig (codename + codename-security)	Ein Eintrag + optional ESM für Ubuntu Pro
Vorinstalliert	Nein, manuell installieren	Ja, seit Ubuntu 16.04
needrestart auf 24.04	Normales Verhalten	Ubuntu-Mode ignorierte die Einstellung anfangs (Bug #2068543, behoben)

Verifizieren: grep -E '^(ID|VERSION_CODENAME)=' /etc/os-release zeigt, welche Spalte für Ihren Server gilt; apt-cache policy listet bei Debian eine Quelle mit l=Debian-Security, bei Ubuntu eine mit a=noble-security bzw. a=jammy-security.

Schritt 4: Package-Blacklist korrekt mit Regex-Ankern definieren

Die Package-Blacklist verwendet reguläre Ausdrücke (Python, re.match): Ein Muster greift ab dem Anfang des Paketnamens, das Ende ist offen. mysql trifft mysql-server und mysql-common, aber nicht php8.2-mysql. Häufiger Fehler ist das fehlende $, wenn genau ein Paket gemeint ist:

mysql-server$ – trifft genau das Paket mysql-server, nicht mysql-server-core-8.0
mysql- – trifft alle Pakete, die mit mysql- beginnen
postgresql$ – trifft genau postgresql
postgresql- – trifft alle versionierten Pakete wie postgresql-16

Den Origin-Wert einer eigenen Paketquelle (PPA, Drittanbieter) ermitteln Sie so:

# Beispiel fuer nginx aus dem offiziellen nginx.org-Repo
apt-cache policy nginx
# Ausgabe auswerten: o=Origin l=Label
# 500 http://nginx.org/packages/debian bookworm/nginx amd64 Packages
#     release o=nginx, l=nginx, a=stable, n=bookworm, ...
# -> Pattern: "origin=nginx,label=nginx";

Verifizieren: sudo unattended-upgrade --dry-run --debug 2>&1 | grep -i blacklist nennt die gesperrten Pakete, die gerade ein Update hätten; Pakete, die nicht gesperrt sein sollen, tauchen dort nicht auf.

Schritt 5: Wartungsfenster per systemd-Timer-Override setzen

Zwei systemd-Timer steuern den Ablauf: apt-daily.timer lädt die Paketlisten, apt-daily-upgrade.timer spielt die Updates ein. Ihr Standardwert RandomizedDelaySec verschiebt die Ausführung, bei apt-daily bis zu 12 Stunden, bei apt-daily-upgrade bis zu 60 Minuten. Ohne Override auf 0 greift kein Wartungsfenster zuverlässig.

Legen Sie zuerst den Override für den Paketlisten-Download an (5 Minuten vor der Installation):

sudo systemctl edit apt-daily.timer

Fügen Sie folgenden Inhalt ein und speichern Sie:

[Timer]
OnCalendar=
OnCalendar=02:55
RandomizedDelaySec=0

Dann den Override für die eigentliche Installation:

sudo systemctl edit apt-daily-upgrade.timer

[Timer]
OnCalendar=
OnCalendar=03:00
RandomizedDelaySec=0

Die leere OnCalendar=-Zeile setzt den bestehenden Wert zurück. Danach Timer neu laden und prüfen:

sudo systemctl daemon-reload && sudo systemctl restart apt-daily.timer apt-daily-upgrade.timer
sudo systemctl status apt-daily-upgrade.timer

Verifizieren: systemctl list-timers 'apt-daily*' zeigt in der Spalte NEXT die nächste Ausführung um 02:55 bzw. 03:00 Uhr ohne zufälligen Versatz.

Schritt 6: needrestart für automatischen Dienstneustart konfigurieren

Dienste, die aktualisierte Bibliotheken laden, laufen ohne Neustart mit der alten, verwundbaren Version im Arbeitsspeicher weiter. needrestart erkennt das und startet betroffene Dienste neu, ohne vollständigen Reboot.

sudo apt install needrestart

Setzen Sie den Restart-Modus in /etc/needrestart/needrestart.conf auf automatisch:

sudo nano /etc/needrestart/needrestart.conf

# a = automatisch, i = interaktiv (blockiert unattended-upgrades!), l = nur auflisten
$nrconf{restart} = 'a';

Achtung bei Ubuntu 24.04: Der dort eingeführte Ubuntu-Modus hat $nrconf{restart} anfangs ignoriert und Dienste immer neu gestartet, auch bei 'l' (Launchpad Bug #2068543, inzwischen per Update behoben). Prüfen Sie das Verhalten nach jedem Ubuntu-LTS-Upgrade.

Wer systemd-Services kennt, sieht den Vorteil gegenüber einem Reboot: Nur die betroffenen Units starten neu, der Rest läuft ungestört weiter.

Verifizieren: sudo needrestart -b läuft ohne Rückfrage durch und gibt maschinenlesbar aus, ob Kernel oder Dienste einen Neustart brauchen (NEEDRESTART-SVC:-Zeilen).

Schritt 7: E-Mail-Benachrichtigungen einrichten

Für Fehler-E-Mails braucht der Server einen konfigurierten MTA. Für den Versand über einen Relay-Host ist postfix die klassische Wahl:

sudo apt install postfix mailutils
# Typ bei Installation: "Satellite system" oder "Internet with smarthost"

Alternativ ist msmtp als leichtgewichtiger SMTP-Client geeignet:

sudo apt install msmtp msmtp-mta
# Symlink fuer sendmail-Kompatibilitaet
sudo ln -fs /usr/bin/msmtp /usr/sbin/sendmail

Nach der MTA-Konfiguration senden Sie eine Testmail:

echo 'Test unattended-upgrades Mail' | mail -s 'Test' admin@example.com

Kommt die Testmail nicht an, schlagen auch alle späteren Fehlerbenachrichtigungen lautlos fehl – dieser Test ist Pflicht.

Verifizieren: Die Testmail liegt im Postfach von admin@example.com; im Log des MTA (journalctl -u postfix bzw. ~/.msmtp.log, falls aktiviert) steht ein erfolgreicher Versand.

Schritt 8: Konfiguration testen und Logs auswerten

Bevor das System das erste Mal automatisch läuft, machen Sie einen Trockentest:

# Trockentest: zeigt was getan wuerde, ohne Pakete zu veraendern
sudo unattended-upgrade --dry-run --debug

# Sofortiger Testlauf mit Verbose-Ausgabe (spielt Updates wirklich ein)
sudo unattended-upgrade -v

Die wichtigsten Logdateien für die laufende Überwachung:

# Hauptlog: Uebersicht aller Laeufe und installierten Pakete
tail -f /var/log/unattended-upgrades/unattended-upgrades.log

# Fehler und Warnungen filtern
grep -i 'error\|warn\|upgrade' /var/log/unattended-upgrades/unattended-upgrades.log

# dpkg-Aktionen des letzten Update-Laufs
tail -100 /var/log/unattended-upgrades/unattended-upgrades-dpkg.log

# Pruefen ob ein Reboot faellig ist
cat /var/run/reboot-required
cat /var/run/reboot-required.pkgs

/var/run/reboot-required existiert, wenn ein Paket einen Neustart erfordert; reboot-required.pkgs listet die Pakete. Mehr zur Loganalyse: Logs lesen und auswerten mit journalctl und /var/log.

Verifizieren: Der Trockentest endet ohne Zeilen mit ERROR, nennt unter „Allowed origins are:“ nur Ihre Security-Quellen, und am Morgen nach dem ersten Wartungsfenster enthält unattended-upgrades.log einen Lauf mit Zeitstempel kurz nach 03:00 Uhr.

Troubleshooting / Typische Fehler

Updates laufen nicht zur konfigurierten Zeit: RandomizedDelaySec war nicht auf 0 gesetzt. Prüfen Sie den Override mit sudo systemctl cat apt-daily-upgrade.timer. Der [Timer]-Abschnitt im Override muss die leere OnCalendar=-Zeile, den neuen Wert und RandomizedDelaySec=0 enthalten.
Eigene Einstellungen verschwinden nach apt upgrade: /etc/apt/apt.conf.d/50unattended-upgrades wurde direkt bearbeitet. Diese Datei gehört dem Paket und kann ersetzt werden. Legen Sie alle Anpassungen in 52unattended-upgrades-local ab.
Package-Blacklist greift nicht oder zu weit: nginx ohne $ trifft auch nginx-common oder nginx-full, aber nie libnginx-mod-http-geoip, weil der Vergleich am Namensanfang beginnt. Nutzen Sie nginx$ für exaktes Matching und testen Sie mit --dry-run --debug.
Keine E-Mail bei Fehlern: Kein MTA installiert oder falsch konfiguriert. Testen Sie mit echo 'Test' | mail -s 'Test' admin@example.com. Ohne funktionierenden MTA schlägt der Versand lautlos fehl.
unattended-upgrades hängt und läuft nicht durch: needrestart ist im interaktiven Modus ('i') konfiguriert und wartet auf Benutzereingabe. Setzen Sie $nrconf{restart} = 'a'; in /etc/needrestart/needrestart.conf.
Listeneinträge werden doppelt ausgewertet: Beide Dateien definieren Package-Blacklist oder Origins-Pattern – APT kumuliert Listen. Stellen Sie ein #clear Unattended-Upgrade::Package-Blacklist; vor dem Block in der lokalen Datei.
Reboot startet trotz angemeldeter SSH-Session: Automatic-Reboot-WithUsers "true" ist gesetzt oder die Zeile fehlt (Standard ist true). Setzen Sie Automatic-Reboot-WithUsers "false" ausdrücklich.

Häufige Fragen

Wie unterscheiden sich Debian und Ubuntu bei den Origins-Pattern?

Debian nutzt origin=Debian,codename=${distro_codename},label=Debian-Security mit zwei Einträgen, da Debian-Security-Updates aus zwei Quellen kommen. Ubuntu verwendet historisch Allowed-Origins mit ${distro_id}:${distro_codename}-security. Beide Schlüssel funktionieren überall; prüfen Sie beim Kopieren zwischen Systemen, ob die Origins auf vorhandene Quellen zeigen.

Was ist der Unterschied zwischen 20auto-upgrades und 50unattended-upgrades?

20auto-upgrades schaltet die Funktion ein (1) oder aus (0) und legt die Frequenz fest. 50unattended-upgrades bzw. Ihre 52unattended-upgrades-local definiert Paketquellen, Ausnahmen, Reboot und E-Mail.

Kann ich unattended-upgrades auf einem Produktivserver mit Datenbank betreiben?

Ja, aber Datenbankpakete (mysql-server, postgresql, mariadb-server) und Reverse-Proxy-Pakete (nginx$, haproxy) gehören in die Package-Blacklist. Ihre Updates erfordern oft Konfigurationsänderungen, Schemamigration oder geplante Downtime; spielen Sie sie manuell im Wartungsfenster ein.

Wie stelle ich sicher, dass Reboots nur im Wartungsfenster stattfinden?

Setzen Sie Automatic-Reboot-Time (z. B. "03:00") und legen Sie apt-daily-upgrade.timer per Override auf denselben Zeitraum (OnCalendar=03:00, RandomizedDelaySec=0). Entscheidend ist RandomizedDelaySec=0.

Was passiert, wenn ein Update fehlschlägt?

Das System bleibt konsistent, da unattended-upgrades auf APT basiert und kein Update halb eingespielt wird. Alle Aktionen stehen in /var/log/unattended-upgrades/unattended-upgrades.log; mit MailReport "only-on-error" erhalten Sie eine E-Mail. --dry-run simuliert jederzeit, was installiert würde.

Wie teste ich die Konfiguration ohne echte Updates einzuspielen?

sudo unattended-upgrade --dry-run --debug zeigt erkannte Updates, angewandte Origins-Pattern und Blacklist-Treffer, ohne Pakete zu verändern, im Terminal und im Logfile. Das ist die wichtigste Debugging-Methode nach jeder Konfigurationsänderung.

Fazit

Richtig konfiguriert liefert unattended-upgrades eine automatische Patch-Strategie für Linux-Server, vergleichbar mit WSUS: Security-Only-Origins verhindern ungewollte Funktionsupdates, die Package-Blacklist schützt heikle Dienste, das Wartungsfenster sorgt für Vorhersagbarkeit, E-Mails melden Fehler. Regelmäßige Log-Kontrolle mit grep -i error /var/log/unattended-upgrades/unattended-upgrades.log schließt die Kontrollschleife.

Firewall und Intrusion Prevention ergänzt Linux-Server absichern mit UFW und Fail2ban; den APT-Unterbau erklärt Paketverwaltung mit apt und dpkg.

Weiterführende Anleitungen und Quellen

Offizielle Quellen: Ubuntu Server Dokumentation: Automatic Updates | Debian Wiki: PeriodicUpdates | Debian Manpage: unattended-upgrades(8)