Die meisten erfolgreichen Servereinbrüche geschehen nicht über raffinierte Exploits, sondern über eine Schwachstelle, für die der Patch vor Monaten erschienen ist. Der Grund ist meist keine Faulheit: Von Hand zu aktualisieren ist auf einem laufenden Server unheimlich, weil apt upgrade mitunter Dinge neu startet, um die niemand gebeten hat. Automatische Updates lösen die Frage, haben aber einen schlechten Ruf — verdient genau in dem Maß, in dem sie hastig eingerichtet werden.

Sehen wir uns eine Einrichtung an, bei der Sicherheitspatches von selbst eintreffen und die PHP-Version nachts nicht wechselt.

Installation

sudo apt install unattended-upgrades apt-listchanges
sudo dpkg-reconfigure -plow unattended-upgrades

Der Dialog erzeugt /etc/apt/apt.conf.d/20auto-upgrades. Prüfen Sie, was dabei herausgekommen ist:

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

Die Einsen bedeuten „täglich“. Angestoßen wird das Ganze von einem systemd-Timer, nicht vom klassischen Cron:

systemctl list-timers | grep apt

Das Wichtigste: nur Sicherheit

Die Hauptdatei ist /etc/apt/apt.conf.d/50unattended-upgrades. Sie enthält eine Liste Allowed-Origins (unter Debian Origins-Pattern), und standardmäßig ist dort nur das Sicherheits-Repository aktiviert. Lassen Sie es dabei.

Die Versuchung, die Zeile mit -updates auszukommentieren — „soll doch alles aktualisiert werden“ —, ist groß. Tun Sie es nicht: Das Update-Repository bringt neue Versionen, nicht nur Korrekturen, und genau daher kommen die nächtlichen Überraschungen. Sicherheit und Aktualität sind verschiedene Aufgaben, und die zweite erledigt man besser von Hand, während man an der Tastatur sitzt.

Darf ein Paket nicht automatisch aktualisiert werden, gibt es dafür eine Sperrliste:

Unattended-Upgrade::Package-Blacklist {
    "mariadb-server";
    "php8.3-fpm";
};

Nutzen Sie sie bewusst: Jede Zeile darin bedeutet „dieses Paket aktualisiere ich selbst“ — und dieses Versprechen müssen Sie einlösen.

Neustarts

Die entscheidende Zeile:

Unattended-Upgrade::Automatic-Reboot "false";

false stehen zu lassen ist für einen Server mit Website richtig: Ein unangekündigter Neustart um drei Uhr nachts ist schlimmer als ein um einen Tag verschobener Patch. Diese Entscheidung hat aber eine zwingende zweite Hälfte, und die wird vergessen.

Wird der Kernel, libc oder openssl aktualisiert, legt das System die Datei /var/run/reboot-required an. Bis zum Neustart liegt die korrigierte Fassung auf der Festplatte, während im Arbeitsspeicher die alte läuft — die Schwachstelle ist also keineswegs verschwunden, obwohl das Paket als aktualisiert gilt. Prüfen Sie das ausdrücklich:

ls -l /var/run/reboot-required
cat /var/run/reboot-required.pkgs

Die zweite Datei nennt genau, wodurch der Neustart nötig wurde. Die Regel ist einfach: Sehen Sie das Kennzeichen, planen Sie ein Zeitfenster innerhalb der nächsten ein bis zwei Tage, nicht „irgendwann“.

Ein eigener Fall sind Bibliotheken. openssl wird aktualisiert, während nginx und PHP-FPM mit der alten Fassung im Speicher weiterlaufen — und ein Neustart-Kennzeichen erscheint dabei überhaupt nicht. Wer einen Neustart braucht, zeigt needrestart:

sudo apt install needrestart
sudo needrestart -b

Versetzen Sie es nur in den Modus „anzeigen, nicht fragen“ — sonst beginnt es mitten in einer nicht interaktiven Installation Fragen zu stellen und blockiert sie. Legen Sie dafür in /etc/needrestart/conf.d/ eine Datei mit der Zeile $nrconf{restart} = 'l'; ab.

Prüfen, ob es überhaupt läuft

Ein Probelauf ohne Installation:

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

Die Ausgabe zeigt, welche Pakete den Regeln entsprechen und welche verworfen wurden und warum. Was tatsächlich geschah, steht in den Protokollen:

sudo tail -50 /var/log/unattended-upgrades/unattended-upgrades.log

Wie viele Updates gerade warten:

apt list --upgradable 2>/dev/null | grep -i security

Der letzte Befehl ist der nützlichste von allen. Eingerichtete automatische Updates haben die Angewohnheit, still kaputtzugehen: Auf /boot ist kein Platz mehr, ein Repository hat den Schlüssel gewechselt, der Timer wurde nach irgendeiner Handänderung abgeschaltet. Nach außen ist alles in Ordnung, und seit Monaten wird nichts mehr gepatcht.

Platz auf /boot

Ein Klassiker: Alte Kernel werden nicht entfernt, die Partition /boot läuft voll, die Installation eines neuen Kernels scheitert, und die Updates bleiben insgesamt stehen. Alle paar Monate lohnt ein Blick:

df -h /boot
sudo apt autoremove --purge

Oder aktivieren Sie die automatische Bereinigung in derselben 50unattended-upgrades: Remove-Unused-Kernel-Packages "true" und Remove-Unused-Dependencies "true".

Was dem Menschen bleibt

Automatische Updates nehmen die Routine ab, nicht das Hinsehen. Zwei Fragen sollten Sie jederzeit beantworten können: wie viele Sicherheitsupdates warten und ob das Neustart-Kennzeichen gesetzt ist. Beide Antworten sind je eine Zeile auf einer Seite, und der ganze Sinn besteht darin, dass diese Zeile von selbst ins Auge fällt und nicht erst auf Ihre Initiative hin einmal im Quartal.