Automatische Sicherheits-Updates einrichten

Warum automatische Updates — und welche?

Sicherheitslücken in Linux-Distributionen werden ständig gefunden und gepatcht. Zwischen Veröffentlichung eines Patches und einem Server, der ihn einspielt, sollte möglichst wenig Zeit liegen — denn ab dem Moment, in dem ein CVE öffentlich ist, gibt es zwei parallele Rennen: Defender installieren den Patch, Angreifer scannen das Internet nach noch ungepatchten Systemen. Wer einmal pro Monat manuell upgradet, ist im Schnitt zwei Wochen verwundbar; wer jede Stunde auf neue Security-Pakete prüft, ist es im Schnitt 30 Minuten.

Das automatische Einspielen birgt allerdings ein Gegenrisiko: Updates können Funktionalität brechen. Eine geänderte Default-Konfiguration in nginx, ein Library-Update mit subtiler API-Änderung, ein Kernel-Patch, der den Treiber für die Netzwerkkarte beeinträchtigt — alles ist passiert, alles wird wieder passieren. Daher ist die wichtigste Frage nicht „automatisch oder nicht?”, sondern „welche Updates automatisch?”.

Eine pragmatische Standard-Antwort:

• Security-Repositories: ja, automatisch — diese enthalten gezielt Patches für bekannte Sicherheitslücken, ohne neue Funktionalität. Das Risiko, etwas zu brechen, ist vergleichsweise gering.
• Allgemeine Updates: nein, manuell — neue Versionen von Anwendungen, optionale Bugfixes, geänderte Defaults. Lieber bewusst entscheiden, wann das eingespielt wird.
• Major-Versionen (PHP 8.3 → 8.4, PostgreSQL 16 → 17, Distro-Upgrade): niemals automatisch — das sind Migrations-Themen, die Vorbereitung und Tests brauchen.

Der Rest dieses Artikels setzt diese Default-Strategie um: Security-Updates automatisch, alles andere kontrolliert.

unattended-upgrades — Installation auf Debian/Ubuntu

Auf Ubuntu ist unattended-upgrades standardmäßig installiert und meist auch aktiviert (dpkg-reconfigure -plow unattended-upgrades zeigt den Status). Auf Debian fehlt es per Default:

sudo apt install unattended-upgrades apt-listchanges -y

apt-listchanges ist ein nützliches Begleitpaket: es listet vor jedem Update die offiziellen Changelog-Einträge der betroffenen Pakete und kann sie per Mail verschicken. So erfährt man nicht nur, dass Updates eingespielt wurden, sondern auch, was sich geändert hat.

Das Aktivieren erledigt ein interaktives Tool:

sudo dpkg-reconfigure -plow unattended-upgrades

Die Auswahl Yes legt eine Datei /etc/apt/apt.conf.d/20auto-upgrades an, die das tägliche Auto-Update aktiviert. Inhalt sieht so aus:

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";

Die 1 bedeutet „täglich” — APT führt einmal pro Tag ein update und ein unattended-upgrade aus. Den Zeitpunkt steuert ein systemd-Timer (apt-daily.timer und apt-daily-upgrade.timer), per Default randomisiert zwischen 06:00 und 07:00 Uhr morgens — das verteilt die Last und vermeidet, dass alle Server gleichzeitig upgrade-Pakete ziehen.

Welche Repositories werden automatisch gezogen?

Die zentrale Steuerdatei ist /etc/apt/apt.conf.d/50unattended-upgrades. Hier wird festgelegt, aus welchen Quellen automatisch Updates eingespielt werden — der entscheidende Schalter zwischen „nur Security” und „alles”.

sudo nano /etc/apt/apt.conf.d/50unattended-upgrades

Im oberen Teil der Datei findet sich der Allowed-Origins-Block. Standard-Konfiguration auf Debian:

Unattended-Upgrade::Origins-Pattern {
    "origin=Debian,codename=${distro_codename}-security,label=Debian-Security";
    // "origin=Debian,codename=${distro_codename}-updates";
    // "origin=Debian,codename=${distro_codename}-proposed";
    // "origin=Debian,codename=${distro_codename}-backports";
};

Auf Ubuntu sieht es ähnlich aus, mit Ubuntu-spezifischen Origins:

Unattended-Upgrade::Allowed-Origins {
    "${distro_id}:${distro_codename}-security";
    "${distro_id}ESMApps:${distro_codename}-apps-security";
    "${distro_id}ESM:${distro_codename}-infra-security";
    // "${distro_id}:${distro_codename}-updates";
};

Die mit // auskommentierten Zeilen sind abgeschaltet. Die einzige aktive Zeile ist die jeweilige -security-Quelle — das ist die empfohlene Default-Konfiguration: ausschließlich Security-Patches.

Wer den Komfort möchte, dass auch normale Bugfix-Updates automatisch eingespielt werden, kann die -updates-Zeile aktivieren (Kommentar entfernen). Das spart manuelle Pflege, erhöht aber das Risiko, dass eine geänderte Default-Konfiguration ein laufendes Setup beeinflusst. Persönliche Entscheidung — auf produktiven Servern bleibt die konservative Variante mit nur Security empfehlenswert.

Wichtig: Pakete, die du nicht automatisch aktualisiert haben willst, lassen sich über Unattended-Upgrade::Package-Blacklist ausnehmen. Beispiel: "postgresql-16"; oder "linux-image-*"; falls Kernel-Updates manuell laufen sollen. Sinnvoll für Pakete mit potenziell brechendem Verhalten.

Auto-Reboot und Service-Restart

Manche Updates wirken erst nach einem Neustart. Klassischer Fall: Kernel-Updates. Solange der alte Kernel noch im RAM läuft, bringt der gepatchte Kernel auf der Disk wenig — der Server ist erst dann wirklich gepatcht, wenn er neu gestartet ist. unattended-upgrades kann diesen Reboot automatisch ausführen:

Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-WithUsers "false";
Unattended-Upgrade::Automatic-Reboot-Time "03:00";

Erläuterungen:

• Automatic-Reboot “true” — wenn ein Reboot nötig ist (signalisiert über die Datei /var/run/reboot-required), startet der Server automatisch neu.
• Automatic-Reboot-WithUsers “false” — wenn aktive Login-Sessions existieren, wird der Reboot nicht ausgeführt. Auf einem Single-Use-Server eher nicht relevant; auf einem Server mit dauerhaft eingeloggten Benutzern (z. B. Screen/tmux-Sessions) sicherheitshalber so lassen, sonst werden Sessions abgeschossen.
• Automatic-Reboot-Time “03:00” — Uhrzeit für den Reboot. Nachts/außerhalb der Geschäftszeiten ist der natürliche Ort.

Wichtig zu verstehen: Auch ohne Kernel-Update können Updates Service-Restarts verlangen. Wenn z. B. eine Library aktualisiert wird, von der nginx abhängt, dann läuft der nginx-Prozess weiter mit der alten Library aus dem Speicher — die neue Library greift erst nach systemctl restart nginx. Solche Restarts erkennt das Tool needrestart:

sudo apt install needrestart -y

needrestart hängt sich nach jedem apt-Lauf ein und prüft, welche laufenden Prozesse veraltete Bibliotheken nutzen. In der Default-Konfiguration fragt es interaktiv nach. Für unbeaufsichtigten Betrieb auf automatischen Modus stellen:

# Automatisch alle Services neustarten, die veraltete Libs nutzen
$nrconf{restart} = 'a';

Damit werden Services wie nginx, php-fpm, postgresql automatisch neu gestartet, wenn ihre Libraries aktualisiert wurden — ohne expliziten Reboot.

Trockenlauf, Mail-Benachrichtigung, Logs

Trockenlauf vor der ersten Aktivierung ist eine gute Vorsichtsmaßnahme:

sudo unattended-upgrade --dry-run --debug

Das simuliert einen Lauf, ohne tatsächlich etwas zu installieren. Du siehst, welche Pakete für ein Update infrage kämen, welche durch Origins erlaubt sind, welche durch die Blacklist ausgenommen werden, und welche Services neu gestartet würden.

Mail-Benachrichtigung bei Updates oder Fehlern ist sinnvoll, sonst läuft das Auto-Update unsichtbar im Hintergrund:

Unattended-Upgrade::Mail "admin@mydomain.com";
Unattended-Upgrade::MailReport "on-change";

MailReport "on-change" schickt nur eine Mail, wenn tatsächlich Pakete aktualisiert wurden. Die Alternative "only-on-error" schickt nur bei Fehlern, "always" täglich (zu viel Rauschen). Für die Mail braucht der Server einen funktionierenden lokalen MTA — z. B. msmtp mit SMTP-Relay-Konfiguration.

Logs finden sich an zwei Stellen:

# Was hat unattended-upgrade gemacht?
sudo less /var/log/unattended-upgrades/unattended-upgrades.log

# Systemd-Timer-Lauf
journalctl -u apt-daily-upgrade.service

Ein Blick alle paar Wochen in diese Logs reicht, um zu sehen, ob alles glatt läuft. Bei Fehlern (Festplatte voll, kaputte Paketquelle, Konflikte) bricht der Lauf ab, die Logs sind dann der einzige Anhaltspunkt.

RHEL-Familie: dnf-automatic

Auf AlmaLinux/Rocky/RHEL übernimmt dnf-automatic die gleiche Aufgabe — das Paket bringt einen systemd-Timer und eine Konfigurationsdatei mit:

sudo dnf install dnf-automatic -y

Konfiguration in /etc/dnf/automatic.conf:

[commands]
# security: nur Security-Updates
# default: alles
upgrade_type = security

# Updates herunterladen?
download_updates = yes

# Updates installieren?
apply_updates = yes

# Reboot wenn nötig?
reboot = when-needed
reboot_command = "shutdown -r +5 'Reboot fuer Sicherheits-Updates'"

[emitters]
# Wie wird benachrichtigt? motd|email|stdio|command_email
emit_via = email

[email]
email_from = admin@mydomain.com
email_to = admin@mydomain.com
email_host = localhost

Die wichtigsten Optionen:

• upgrade_type = security — nur Security-Updates, analog zur Origins-Filterung bei unattended-upgrades. Alternative default zieht alles.
• download_updates = yes, apply_updates = yes — beide auf yes heißt: tatsächlich installieren. Wer nur runterladen, aber manuell installieren möchte, setzt apply_updates = no.
• reboot = when-needed — Reboot nur, wenn das Paket-Set einen erfordert. Alternative never.
• reboot_command — Reboot mit 5 Minuten Vorlauf und Broadcast-Nachricht an alle eingeloggten User.

Service aktivieren:

sudo systemctl enable --now dnf-automatic.timer
systemctl list-timers | grep dnf-automatic

Der Timer läuft per Default einmal täglich. Logs: journalctl -u dnf-automatic.service.

Pakete bewusst ausnehmen

Manche Pakete sollten nicht automatisch aktualisiert werden, weil sie Migrationen nötig machen oder ihren Service in einer Weise restartet, die produktiven Traffic verlieren würde.

Typische Kandidaten zum Ausnehmen:

• Datenbanken — PostgreSQL, MariaDB. Eine Major-Version-Migration ist immer manuell. Auch Minor-Updates restartet die DB, was bei langlaufenden Verbindungen unschön ist — bei kontrolliertem Wartungsfenster besser aufgehoben.
• Kernel — wenn der Server kein automatisches Reboot machen soll und du die Kernel-Auswahl kontrollieren möchtest (LTS-Stränge etc.).
• Distro-Upgrade-Trigger — update-manager oder ähnliche Tools, die ungewollt eine Distro-Version anheben könnten.

Auf Debian/Ubuntu in 50unattended-upgrades:

Unattended-Upgrade::Package-Blacklist {
    "postgresql-.*";
    "mariadb-server-.*";
    "linux-image-.*";
    "linux-headers-.*";
};

Auf RHEL-Familie über die dnf-Konfiguration:

[main]
# ... bestehende Einträge ...
exclude = postgresql* mariadb* kernel*

Diese Pakete werden dann von dnf upgrade (und damit auch von dnf-automatic) ignoriert. Manuelles Upgrade bleibt jederzeit möglich mit dnf upgrade postgresql --disableexcludes=main.

Sicherheits-Checkliste

• Auto-Updates aktiviert, beim ersten Mal mit --dry-run getestet
• Quellen auf Security-Repositories beschränkt — keine generellen Updates ohne bewusste Entscheidung
• Mail-Benachrichtigung an eine real abgerufene Adresse, mit funktionierendem MTA (z. B. msmtp-Setup)
• Datenbanken, Kernel und andere kritische Pakete in der Blacklist (Package-Blacklist bzw. exclude)
• Auto-Reboot konfiguriert oder bewusst deaktiviert — wenn deaktiviert, regelmäßig prüfen, ob /var/run/reboot-required existiert
• needrestart installiert und auf automatischen Modus gestellt, sonst laufen veraltete Library-Versionen weiter im Speicher
• Logs alle 1–2 Wochen geprüft (Stichprobe), bei Fehlern eingreifen
• Backup-Strategie unabhängig von Auto-Update vorhanden — falls ein Update doch etwas bricht, ist Restore die Rückfall-Option

Verwandte Artikel

• Linux für den eigenen Server wählen — Distro entscheidet das Tool (unattended-upgrades vs. dnf-automatic)
• SSH-Hardening — sshd ist eines der Pakete, die Auto-Updates regelmäßig anfasst
• Firewall-Grundausstattung mit ufw — die zweite Standard-Härtungs-Schicht neben Auto-Updates
• Linux-Doku: apt richtig nutzen — Tiefen-Doku zur Paketverwaltung darunter

Externe Quellen

• Debian Wiki: UnattendedUpgrades — offizielle Doku samt Konfigurationsoptionen
• Ubuntu Server Guide: Automatic Updates — Ubuntu-spezifische Hinweise
• dnf-automatic Manpage — vollständige Konfigurations-Referenz
• needrestart auf GitHub — Quellcode und Dokumentation
• Debian Security Tracker — welche CVEs sind in welchem Paket-Stand gepatcht