Es gibt zwei Arten, einen Server zu verlieren. Die seltene ist ein gezielter Angriff auf eine unbekannte Lücke. Die häufige ist ein automatisierter Scan, der eine Lücke findet, für die seit sechs Wochen ein Patch bereitliegt.
Zwischen der Veröffentlichung einer Lücke und dem ersten öffentlichen Exploit liegen häufig nur Tage. Wer manuell patcht, misst diesen Abstand in Wochen und zwar genau so lange, bis er einmal vergisst hinzusehen. Das ist der Normalfall, kein Versagen.
Das Fenster, das du beeinflusst#
Auf den Zeitpunkt der Veröffentlichung hast du keinen Einfluss. Auf den Zeitpunkt, an dem der Patch auf deiner Maschine landet, schon und automatische Updates verkürzen diesen Abstand von Wochen auf Stunden, ohne dass jemand wach sein muss.
Einrichten#
sudo apt install -y unattended-upgrades apt-listchanges
sudo dpkg-reconfigure -plow unattended-upgradesDer zweite Befehl legt /etc/apt/apt.conf.d/20auto-upgrades an. Prüfen, dass darin beides auf "1" steht:
cat /etc/apt/apt.conf.d/20auto-upgradesAPT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";
Die Einstellungen, die zählen#
In /etc/apt/apt.conf.d/50unattended-upgrades:
Unattended-Upgrade::Origins-Pattern {
"origin=Debian,codename=${distro_codename},label=Debian-Security";
"origin=Debian,codename=${distro_codename}-security,label=Debian-Security";
};
// Kaputte Pakete nicht liegen lassen — sonst blockiert ein halber Zustand
// alle folgenden Läufe.
Unattended-Upgrade::AutoFixInterruptedDpkg "true";
// Alte Kernel und Abhängigkeiten entfernen, sonst läuft /boot voll.
Unattended-Upgrade::Remove-Unused-Kernel-Packages "true";
Unattended-Upgrade::Remove-Unused-Dependencies "true";
// Neustart: bewusst entscheiden, siehe unten.
Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-WithUsers "false";
Unattended-Upgrade::Automatic-Reboot-Time "04:30";
// Bei Fehlern melden. Ohne Mailweg: leer lassen und stattdessen überwachen.
Unattended-Upgrade::MailReport "on-change";
Remove-Unused-Kernel-Packages ist kein Aufräumkomfort, sondern verhindert einen Ausfall: Eine volle /boot-Partition lässt Kernel-Updates fehlschlagen und zwar still. Der Server läuft weiter, bekommt aber keine Sicherheitsupdates mehr. Ein Fall, der monatelang unbemerkt bleibt.
Neustarten: ja oder nein?#
Die einzige Stelle, an der es eine echte Abwägung gibt.
| Lage | Empfehlung |
|---|---|
| Einzelner VPS, kein Ersatz | Automatic-Reboot "true" mit fester Uhrzeit |
| Zwei Maschinen hinter einem Load Balancer | manuell, versetzt |
| Datenbank ohne Replikat | manuell, mit Wartungsfenster |
| Nur Kernel-Updates stören | needrestart und kexec prüfen |
Ein Kernel-Update wirkt erst nach einem Neustart. Ein Server, der monatelang nicht neu startet, hat den Patch installiert, aber nicht in Betrieb:
# Läuft der Kernel, der installiert ist?
[ -f /var/run/reboot-required ] && cat /var/run/reboot-required.pkgsBei laufenden Diensten ohne kompletten Neustart hilft needrestart, das nur die betroffenen Dienste anfasst:
sudo apt install -y needrestart
sudo needrestart -r l # zeigt, was neu gestartet werden müsstePrüfen, ob es tatsächlich läuft#
Der wichtigste Abschnitt. Eine eingerichtete Automatik, die nie läuft, ist gefährlicher als keine, weil man sich auf sie verlässt.
# Probelauf, ohne etwas zu installieren
sudo unattended-upgrades --dry-run --debug
# Was wurde tatsächlich eingespielt?
sudo tail -40 /var/log/unattended-upgrades/unattended-upgrades.log
# Laufen die Timer überhaupt?
systemctl list-timers 'apt-daily*'Wenn die Logdatei leer ist oder der letzte Eintrag Monate alt: Die Timer sind abgeschaltet oder die Origins-Angabe passt nicht zur Distribution. Beides passiert nach einem Distributions-Upgrade regelmäßig.
In die Überwachung hängen#
Ein Wert, der zeigt, ob die Maschine hinterherhinkt:
# Wie viele Sicherheitsupdates stehen aus?
apt-get -s -o Debug::NoLocking=true upgrade \
| grep -c '^Inst.*-security'
# Wie alt ist der letzte erfolgreiche Lauf (in Tagen)?
echo $(( ( $(date +%s) - $(stat -c %Y /var/log/unattended-upgrades/unattended-upgrades.log) ) / 86400 ))Beide Zahlen gehören ins Monitoring, Details dazu in Protokolle, die den Angreifer überleben. Sinnvolle Schwellen: mehr als 0 ausstehende Sicherheitsupdates seit über 48 Stunden, oder letzter Lauf älter als 3 Tage.
Was bewusst nicht automatisch läuft#
Automatische Updates gelten hier nur für Sicherheitsquellen der Distribution. Nicht automatisch:
- Hauptversionssprünge der Distribution. Siehe Distribution aktualisieren, ohne den Dienst zu verlieren.
- Anwendungen aus Fremdquellen, Container-Images, Sprachpakete, alles was nicht aus dem Distributionsarchiv kommt. Die haben ihren eigenen Rhythmus.
- Datenbanken. Ein Schemawechsel um vier Uhr morgens ist kein Sicherheitsgewinn.
Für alles außerhalb des Distributionsarchivs braucht es einen eigenen, bewussten Ablauf mit Rückweg: Wartungsfenster und der Weg zurück.
Geschrieben aus dem laufenden Betrieb: MRMedia betreibt eigene Hosts, Kundendienste und deren Härtung in der EU. Eine veraltete Anleitung ist hier ein Sicherheitsproblem, kein Schönheitsfehler. Korrekturen bitte über Discord.
