De meeste geslaagde inbraken op servers verlopen niet via vernuftige exploits maar via een kwetsbaarheid waarvan de patch maanden geleden verscheen. De reden is doorgaans geen luiheid: met de hand bijwerken op een productieserver is eng, omdat apt upgrade soms herstart wat niemand heeft gevraagd. Automatische updates lossen de kwestie op, maar hebben een slechte naam — verdiend precies in de mate waarin ze haastig worden ingericht.

Laten we een inrichting bekijken waarbij beveiligingspatches vanzelf binnenkomen en de PHP-versie ’s nachts niet verandert.

Installatie

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

De dialoog maakt /etc/apt/apt.conf.d/20auto-upgrades aan. Controleer wat daaruit is gekomen:

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

De enen betekenen «dagelijks». Dit alles wordt gestart door een systemd-timer, niet door de klassieke cron:

systemctl list-timers | grep apt

Het belangrijkste: alleen beveiliging

Het hoofdbestand is /etc/apt/apt.conf.d/50unattended-upgrades. Daarin staat een lijst Allowed-Origins (op Debian Origins-Pattern), en standaard is daar alleen de beveiligingsrepository ingeschakeld. Laat dat zo.

De verleiding om de regel met -updates uit commentaar te halen — «laat alles maar bijwerken» — is groot. Doe het niet: de updaterepository brengt nieuwe versies en niet alleen correcties, en juist daaruit komen de nachtelijke verrassingen. Veiligheid en actualiteit zijn verschillende taken, en de tweede doet u beter met de hand, terwijl u achter het toetsenbord zit.

Mag een pakket niet automatisch worden bijgewerkt, dan is daar een zwarte lijst voor:

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

Gebruik die bewust: elke regel daarin betekent «dit pakket werk ik zelf bij» — en die belofte moet worden nagekomen.

De herstarts

De sleutelregel:

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

false laten staan is juist voor een server met een site: een onaangekondigde herstart om drie uur ’s nachts is erger dan een patch die een dag wordt uitgesteld. Maar die beslissing heeft een verplichte tweede helft, en die wordt vergeten.

Wanneer de kernel, libc of openssl wordt bijgewerkt, maakt het systeem het bestand /var/run/reboot-required aan. Zolang er geen herstart is geweest, ligt de gecorrigeerde versie op de schijf terwijl de oude in het geheugen draait — de kwetsbaarheid is dus geenszins verdwenen, ook al geldt het pakket als bijgewerkt. Controleer dat uitdrukkelijk:

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

Het tweede bestand somt op waardoor de herstart nodig werd. De regel is eenvoudig: ziet u de vlag, plan dan een venster binnen de komende één of twee dagen, en niet «ooit».

Bibliotheken zijn een geval apart. openssl wordt bijgewerkt terwijl nginx en PHP-FPM met de oude versie in het geheugen doordraaien, en er verschijnt helemaal geen herstartvlag. Wie een herstart nodig heeft, toont needrestart:

sudo apt install needrestart
sudo needrestart -b

Zet hem alleen in de stand «tonen, niet vragen» — anders begint hij midden in een niet-interactieve installatie vragen te stellen en laat die hangen. Leg daarvoor in /etc/needrestart/conf.d/ een bestand neer met de regel $nrconf{restart} = 'l';.

Controleren of het werkt

Een proefdraaiing zonder te installeren:

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

De uitvoer toont welke pakketten binnen de regels vallen en welke zijn afgewezen en waarom. Wat er werkelijk gebeurde staat in de logboeken:

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

Hoeveel updates er op dit moment wachten:

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

Dat laatste commando is het nuttigste van allemaal. Ingerichte automatische updates hebben de gewoonte stilzwijgend stuk te gaan: de ruimte op /boot is op, een repository wisselde van sleutel, de timer bleef uitgeschakeld na een handmatige aanpassing. Van buiten is alles in orde, en er worden al maanden geen patches geïnstalleerd.

De ruimte op /boot

Een klassieker: oude kernels worden niet verwijderd, de partitie /boot loopt vol, de installatie van een nieuwe kernel mislukt, en de updates staan als geheel stil. Eens in de paar maanden loont een blik:

df -h /boot
sudo apt autoremove --purge

Of schakel het automatisch opruimen in in datzelfde 50unattended-upgrades: Remove-Unused-Kernel-Packages "true" en Remove-Unused-Dependencies "true".

Wat er voor de mens overblijft

Automatische updates nemen de routine weg, niet het toezicht. Twee vragen die u op elk moment zou moeten kunnen beantwoorden: hoeveel beveiligingsupdates er wachten en of de herstartvlag staat. Beide antwoorden zijn één regel op een pagina, en de hele zin is dat die regel u vanzelf opvalt, en niet op uw initiatief eens per kwartaal.