Automatische beveiligingsupdates inrichten met unattended-upgrades

Tussen het verschijnen van een beveiligingsupdate en de installatie ervan zit op de meeste servers een gat. Dat gat ontstaat zelden uit nalatigheid, maar doordat iemand zich voorneemt de update "volgende week" te installeren. Scanners proberen een pas bekend geworden kwetsbaarheid binnen enkele uren op grote schaal uit. Het pakket unattended-upgrades dicht dat gat.

De korte versie staat als stap 7 in de checklist voor een nieuwe rootserver. Hier gaat het om alles daarna: alleen beveiligingsupdates of alle updates, het herstartgedrag op een gameserver, melding per e-mail, uitgezonderde pakketten, de testrun en het bewijs in het logbestand.

Getest op Debian 13 (trixie), Debian 12 (bookworm), Ubuntu 24.04 LTS en Ubuntu 22.04 LTS. Waar die vier van elkaar verschillen, staat dat erbij. De commando's gelden voor root; werkt u als gewone gebruiker, zet er dan telkens sudo voor.

Wat hier eigenlijk draait

Foutzoeken duurt hier lang, omdat onduidelijk is welk van de drie betrokken onderdelen niet doet wat het moet doen:

1. Twee systemd-timers: apt-daily.timer voor de pakketlijsten en het downloaden, apt-daily-upgrade.timer voor de installatie.
2. Het script /usr/lib/apt/apt.systemd.daily, dat de opties onder APT::Periodic:: uitleest.
3. Het programma unattended-upgrade, dat de opties onder Unattended-Upgrade:: uitleest en het werk doet.

Let op het enkelvoud: het pakket heet unattended-upgrades, het programma unattended-upgrade.

systemctl list-timers 'apt-daily*' --all
systemctl cat apt-daily-upgrade.timer

De kolommen LAST en PASSED laten zien of er ooit een run heeft plaatsgevonden. In de unit staat OnCalendar=*-*-* 6:00 samen met RandomizedDelaySec=60m: de run vindt tussen zes en zeven uur plaats, bij apt-daily.timer met een spreiding van twaalf uur. Wie om 06:05 gaat kijken, houdt het mechanisme ten onrechte voor kapot.

Vóór de eerste wijziging: de weg terug

Automatische updates grijpen in op momenten dat u er niet bij zit. Er kunnen drie dingen misgaan: een herstart haalt de server uit bedrijf, een pakketbewerking breekt af en laat dpkg in een onvolledige toestand achter, of een dienst start daarna niet meer.

De toegang die in alle drie de gevallen nog werkt, is niet SSH. KVM-rootservers en dedicated servers van KernelHost hebben geen IPMI en geen iDRAC: de noodtoegang loopt via de VNC-console in het klantenpaneel. Die console hangt aan de virtualisatielaag of aan de aansluiting zelf, en een storing in het gastsysteem raakt haar dus niet. Log er van tevoren één keer op in en controleer het root-wachtwoord. Een noodtoegang die u pas in een echte noodsituatie voor het eerst uitprobeert, is er geen.

Leg daarna de uitgangssituatie vast:

mkdir -p /root/voor-unattended
cp -a /etc/apt/apt.conf.d/50unattended-upgrades /root/voor-unattended/
dpkg --get-selections > /root/voor-unattended/pakketten.txt
apt-mark showhold > /root/voor-unattended/holds.txt

De noodstop bestaat in twee varianten. Hard, via de timers:

systemctl disable --now apt-daily-upgrade.timer apt-daily.timer

De zachte variant zet in /etc/apt/apt.conf.d/20auto-upgrades de waarde APT::Periodic::Unattended-Upgrade "0";. De pakketlijsten blijven dan actueel, maar er wordt niets geïnstalleerd.

Controle:

systemctl is-enabled apt-daily-upgrade.timer
apt-config dump APT::Periodic

Om terug te rollen: /var/log/apt/history.log noemt het oude en het nieuwe versienummer. Een apt install paket=version lukt echter alleen zolang de oude versie nog op een mirror staat, en de archieven bewaren meestal alleen de actuele stand. Reken er dus op dat u vooruit moet repareren, en zorg voor een back-up.

Installatie en activeren

apt update
apt install -y unattended-upgrades

Verschil tussen de distributies: op Ubuntu 22.04 en 24.04 staat het pakket op de server-images al geïnstalleerd en actief, controleer dat daar dus eerst. Op Debian ontbreekt het in de minimale images, en tijdens de installatie wordt gevraagd of stabiele updates automatisch moeten worden geïnstalleerd. Verloopt die installatie niet-interactief, bijvoorbeeld tijdens het bouwen van een image, dan geldt de standaardwaarde en wordt het beslissende bestand niet aangemaakt.

Want het pakket alleen activeert nog niets. Dat doet pas dit bestand:

cat /etc/apt/apt.conf.d/20auto-upgrades

Ontbreekt het, dan meldt het commando cat: /etc/apt/apt.conf.d/20auto-upgrades: No such file or directory. Haal de vraag dan alsnog op met dpkg-reconfigure -plow unattended-upgrades, of schrijf het bestand zelf:

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

De waarden zijn geen simpele aan-of-uitschakelaars, maar intervallen in dagen: "1" dagelijks, "7" hoogstens wekelijks, "0" uit. AutocleanInterval ruimt pakketbestanden op die op de mirror niet meer bestaan, op kleine systeemschijven merkbaar (schijf vol onder Linux).

Controle: apt-config dump APT::Periodic geeft de ingestelde regels weer. Komt er helemaal niets, dan is er geen bestand gelezen en doet de nachtelijke run niets.

Eigen instellingen op de juiste plek

De meegeleverde /etc/apt/apt.conf.d/50unattended-upgrades is eigendom van het pakket. Wijzigt u dat bestand, dan ontstaat bij de volgende pakketupdate een conflict over het configuratiebestand en slaat unattended-upgrades het pakket over. Uitgerekend de tool voor automatische updates zou daarmee zelf zijn uitgezonderd.

Eigen waarden horen in een eigen bestand met een hoger nummer. APT leest de map alfabetisch en bij enkelvoudige waarden wint de laatst gelezen waarde:

cat > /etc/apt/apt.conf.d/52unattended-upgrades-local <<'EOF'
Unattended-Upgrade::Automatic-Reboot "false";
Unattended-Upgrade::Remove-Unused-Kernel-Packages "true";
Unattended-Upgrade::Remove-New-Unused-Dependencies "true";
Unattended-Upgrade::MinimalSteps "true";
EOF

MinimalSteps staat standaard aan en knipt de run op in kleine stappen die bij het afsluiten netjes kunnen worden afgebroken. Remove-Unused-Kernel-Packages ruimt oude kernels op die anders de /boot-partitie vol laten lopen. Beide opruimopties staan op Ubuntu standaard aan, op Debian niet.

De bestandsnaam is geen detail. APT leest hier alleen bestanden zonder extensie of met .conf, en alleen namen die bestaan uit letters, cijfers, koppelteken, onderstrepingsteken en punt. Een back-upbestand 52unattended-upgrades-local.bak wordt stilzwijgend genegeerd, wat handig is; een bestand 52-meine-einstellungen.txt net zo goed, wat vervelend is.

Controle, meteen na elke wijziging:

apt-config dump > /dev/null && echo "Syntax in orde"
apt-config dump | grep "^Unattended-Upgrade::"

Eén ontbrekende puntkomma legt elke apt-aanroep lam, ook de nachtelijke.

Alleen beveiligingsupdates of alle updates

Welke pakketten in aanmerking komen, bepaalt een lijst met toegestane bronnen. De distributies verschillen al in de naam van de sleutel: Debian gebruikt Unattended-Upgrade::Origins-Pattern, Ubuntu Unattended-Upgrade::Allowed-Origins.

sed -n '/Allowed-Origins\|Origins-Pattern/,/};/p' /etc/apt/apt.conf.d/50unattended-upgrades

Standaard actief zijn de patronen voor de beveiligingsbron en voor het hoofdarchief van de eigen release. Uitgecommentarieerd staan de pockets -updates, -proposed en -backports. Op Ubuntu staan er daarnaast twee regels voor de uitgebreide onderhoudsdienst in; zonder abonnement leveren die niets op. De variabelen ${distro_id} en ${distro_codename} vult het programma tijdens de uitvoering in, bijvoorbeeld met Debian en trixie.

Waar de onderdelen van zo'n patroon vandaan komen, laat apt-cache policy zien. Bij elke bron staat daar een regel die met release begint, met de velden o= (herkomst), a= (archief), n= (codenaam), l= (label) en c= (component). De beveiligingsbron van Debian draagt het label Debian-Security, en precies daarop mikt het meegeleverde patroon.

Wilt u ook de lopende correcties van de distributie automatisch binnenhalen, vul dan het patroon aan in uw eigen bestand. Lijsten worden in de apt-configuratie aangevuld en niet vervangen:

Unattended-Upgrade::Origins-Pattern {
        "origin=Debian,codename=${distro_codename}-updates";
};

Op Ubuntu luidt het equivalent "${distro_id}:${distro_codename}-updates"; in een Allowed-Origins-blok. Een lijst volledig vervangen kunt u alleen door die eerst met #clear Unattended-Upgrade::Origins-Pattern; leeg te maken.

Voor externe bronnen geldt dezelfde werkwijze. Die leveren echter vaak nieuwe functieversies in plaats van pure beveiligingscorrecties, en dat 's nachts onbeheerd laten installeren is een heel andere risicoklasse. Voor productiesystemen geldt daarom: blijf bij de beveiligingsbronnen.

De testrun

apt update
unattended-upgrade --dry-run --debug

De apt update ervoor is geen bijzaak: de testrun werkt de pakketlijsten niet zelf bij, en zonder die aanroep beoordeelt u de situatie van gisteren. Er wordt niets geïnstalleerd. Vier plekken in de uitvoer tellen:

• Allowed origins are: met de lijst die werkelijk geldt. Dat is het bewijs dat uw wijziging is aangekomen, niet de blik in het bestand.
• Initial blacklist: met uw uitzonderingen. Staat daar niets terwijl u er wel hebt ingevoerd, dan wordt uw bestand niet gelezen.
• De regels die met Checking: beginnen, per pakket met bron en toelating.
• Aan het eind ofwel Packages that will be upgraded: met een lijst, ofwel No packages found that can be upgraded unattended and no pending auto-removals.

Die laatste melding verschijnt ook wanneer apt list --upgradable wel degelijk pakketten opsomt. Dat is geen fout, maar het filter dat zijn werk doet: elk pakket dat daar staat en in de testrun ontbreekt, komt uit een niet toegestane bron, staat op uw uitzonderingslijst, is met apt-mark hold vastgezet of veroorzaakt een vraag over een configuratiebestand.

Pakketten uitsluiten van de automatische updates

Sommige dingen moeten 's nachts niet worden bijgewerkt: een database waarvan de herstart een applicatie loskoppelt, of de kernel van een systeem dat niet onaangekondigd opnieuw mag opstarten. De eerste van twee manieren werkt alleen op de automatische updates:

Unattended-Upgrade::Package-Blacklist {
        "mariadb-server$";
        "nginx$";
        "linux-image-";
};

De regels zijn reguliere expressies, verankerd aan het begin van de pakketnaam. "nginx" zonder dollarteken raakt daarom ook nginx-common en nginx-full; de $ beperkt de regel tot precies die ene naam. Omgekeerd is "linux-image-" zonder $ juist correct als u alle kernelpakketten bedoelt.

De tweede manier werkt op elke apt-aanroep, dus ook op uw handmatige apt upgrade:

apt-mark hold mariadb-server
apt-mark showhold

Ongedaan maakt u dat met apt-mark unhold. Moet een pakket alleen niet onbeheerd worden bijgewerkt, gebruik dan de uitzonderingslijst; moet het helemaal niet worden bijgewerkt, dan hold.

Controle: apt-config dump | grep -i "Package-Blacklist" en apt-mark showhold. De ongemakkelijke keerzijde: een uitgezonderd pakket moet u zelf bijwerken. Zet daar een datum voor in de agenda, anders is die uitzondering over een half jaar een vergeten kwetsbaarheid.

Automatische herstart

Een nieuwe kernel staat na de update wel op de schijf, maar draait pas na een herstart; vervangen bibliotheken werken pas als de dienst opnieuw start. Drie opties sturen dat aan:

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

Automatic-Reboot staat standaard uit. Automatic-Reboot-WithUsers staat standaard aan, en dat verrast veel beheerders: een open SSH-sessie voorkomt de herstart niet. Wie dat wel wil, zet de waarde op "false". Automatic-Reboot-Time hoort er dwingend bij zodra de herstart aanstaat. Zonder die vermelding geldt now, en dan start de server meteen na de run opnieuw op, dus tussen zes en zeven uur 's ochtends.

Hij wordt niet door het kernelpakket in gang gezet, maar door een markeringsbestand:

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

Het verschil met de grootste gevolgen in dit artikel: Ubuntu maakt dit bestand aan (uit het pakket update-notifier-common), en het tweede bestand noemt de verantwoordelijke pakketten. Debian maakt het standaard niet aan. Daar kan Automatic-Reboot "true" permanent zonder effect blijven, zonder dat iets een fout meldt. Wie daarop vertrouwt, draait maandenlang met een oude kernel en een goed gevoel. Op Debian helpt in plaats daarvan:

apt install -y needrestart
needrestart -b

De uitvoer noemt onder NEEDRESTART-KCUR de draaiende kernel en onder NEEDRESTART-KEXP de verwachte kernel; verschillen die twee, dan staat er een herstart op de planning. De regels NEEDRESTART-SVC sommen de diensten op die nog met vervangen bibliotheken draaien.

Waarom de instelling op een gameserver anders uitvalt

Op een webserver is een herstart om 02:00 uur een kwestie van seconden die niemand opmerkt. Op een gameserver zijn er spelers verbonden, de wereld staat in het werkgeheugen en de spelstand wordt pas bij een geordend afsluiten volledig weggeschreven. Wordt het proces hard afgebroken, dan verliest u de voortgang sinds de laatste tussentijdse opslag, en in het slechtere geval blijft het wereldbestand beschadigd achter.

Daar komt een detail van systemd bij: bij het afsluiten krijgt elke dienst zijn stopsignaal en daarna een beperkte termijn, waarna het proces hard wordt beëindigd. Een spelserver die bij het afsluiten eerst nog opslaat, heeft vaak meer tijd nodig dan de standaardwaarde toestaat, plus een stopcommando dat een stop naar de serverconsole stuurt in plaats van alleen een signaal naar een startprogramma. Voor gameservers is daarom deze combinatie de verstandige:

• Automatic-Reboot "false". De beveiligingsupdates lopen gewoon door, de herstart blijft uw beslissing.
• Een onderhoudsvenster op een moment met weinig spelers, aangekondigd in plaats van verrassend.
• Een systemd-unit met een stopcommando dat opslaat en een ruim genomen TimeoutStopSec, zie een systemd-service aanmaken.
• Wilt u het toch automatisch, zet Automatic-Reboot-Time dan op een tijdstip met weinig spelers.

Testen kunt u dat zonder herstart: stop de dienst met systemctl stop, bekijk de spelstand en start hem weer. Verloopt dat netjes, dan overleeft hij ook een herstart om 02:00 uur.

Het tijdstip van de run verschuiven

systemctl edit apt-daily-upgrade.timer

[Timer]
OnCalendar=
OnCalendar=*-*-* 03:30
RandomizedDelaySec=30m

De lege regel OnCalendar= is verplicht, want die wist de meegeleverde waarde. Zonder die regel komt uw tijdstip er gewoon bij en draait de taak twee keer per dag.

systemctl daemon-reload
systemctl restart apt-daily-upgrade.timer
systemctl list-timers 'apt-daily*' --all

Controle: in de kolom NEXT staat het nieuwe tijdstip.

Melding per e-mail

Een mechanisme waar niemand iets van hoort, wordt niet bewaakt maar vergeten. Twee regels veranderen dat:

Unattended-Upgrade::Mail "admin@uw-domein.nl";
Unattended-Upgrade::MailReport "on-change";

MailReport kent drie waarden: always na elke run, on-change alleen als er iets is geïnstalleerd of misging, en only-on-error alleen bij een fout. De oudere optie MailOnlyOnError vervangt u zodra u die tegenkomt.

Voorwaarde is dat er een verzendweg bestaat. unattended-upgrades verstuurt via /usr/bin/mail of via /usr/sbin/sendmail. Ontbreken beide, dan blijft het versturen uit en merkt u daar niets van. Op een verse server is dat de normale situatie:

apt install -y bsd-mailx
echo "Testbericht" | mail -s "Test van de server" admin@uw-domein.nl

Daarbij wordt meteen een mailtransportdienst geïnstalleerd. Controleer daarna met ss -lntp | grep ':25' dat die alleen op 127.0.0.1 luistert. Berichten die rechtstreeks vanaf een server-IP vertrekken, belanden bovendien vaak in de spammap. Moet het rapport echt aankomen, laat het versturen dan lopen via een relayserver met een correct ingericht afzenderdomein.

Praktisch advies: zet het de eerste twee weken op always. Een dagelijks bericht dat meldt dat er niets te doen was, is het eenvoudigste bewijs dat het mechanisme draait. Zet het daarna terug op on-change, anders verwijdert u die berichten binnenkort ongelezen.

Nalezen of er werkelijk iets is gebeurd

ls -l /var/log/unattended-upgrades/
tail -n 40 /var/log/unattended-upgrades/unattended-upgrades.log

Daar liggen maximaal drie bestanden. unattended-upgrades.log legt vast wat het programma heeft besloten. unattended-upgrades-dpkg.log bevat de ruwe uitvoer van de installatie; daar kijkt u als een pakket bij het instellen is mislukt. unattended-upgrades-shutdown.log ontstaat bij een run die tijdens het afsluiten is geëindigd.

Een run zonder gebeurtenissen eindigt met No packages found that can be upgraded unattended and no pending auto-removals. Een run die wel iets heeft gedaan, bevat Packages that will be upgraded: en verderop All upgrades installed. Is het bestand leeg of ontbreekt de map, dan heeft er nooit een run plaatsgevonden.

Los daarvan legt het pakketbeheer elke actie vast met het oude en het nieuwe versienummer:

grep -E "^(Start-Date|Commandline|Upgrade|End-Date):" /var/log/apt/history.log | tail -n 20
zgrep -h "^Upgrade:" /var/log/apt/history.log*.gz | tail -n 10

De tweede aanroep gaat de geroteerde bestanden langs; wie alleen naar het actuele bestand kijkt, vindt niets en trekt daaruit de verkeerde conclusie. De derde bron is systemd:

journalctl -u apt-daily-upgrade.service --since "-7 days" --no-pager

De valkuil waar bijna iedereen een keer intrapt: systemctl status unattended-upgrades.service toont permanent active (running). Dat is geen lopende update. Deze unit rondt een begonnen run af tijdens het afsluiten en wacht de rest van de tijd. Geïnstalleerd wordt er in apt-daily-upgrade.service.

Veelvoorkomende fouten en oplossingen

cat: /etc/apt/apt.conf.d/20auto-upgrades: No such file or directory
Het pakket is geïnstalleerd, maar er staat niets aan; op Debian is dat de normale toestand na een niet-interactieve installatie. Oplossing: dpkg-reconfigure -plow unattended-upgrades.

No packages found that can be upgraded unattended and no pending auto-removals, terwijl apt list --upgradable wel pakketten toont
Geen fout, maar het filter. Controleer op volgorde: de toegestane bronnen in de testrun, de uitzonderingslijst, apt-mark showhold en openstaande vragen over configuratiebestanden.

E: Syntax error /etc/apt/apt.conf.d/52unattended-upgrades-local:2: Extra junk at end of file
Een ontbrekende puntkomma aan het einde van een regel of een accolade die niet is gesloten. Zolang de fout erin staat, mislukt elke apt-aanroep, niet alleen de automatische.

E: Could not get lock /var/lib/dpkg/lock-frontend. It is held by process 1234 (unattended-upgr) samen met E: Unable to acquire the dpkg frontend lock (/var/lib/dpkg/lock-frontend), is another process using it?
De automatische run is bezig; de tot vijftien tekens afgekapte procesnaam verraadt het. Wacht een paar minuten. Het proces afschieten levert de volgende fout uit deze lijst op. Uitgebreid: apt-fout "Could not get lock" oplossen.

E: dpkg was interrupted, you must manually run 'dpkg --configure -a' to correct the problem.
Voer precies dat commando uit. De standaard ingeschakelde Unattended-Upgrade::AutoFixInterruptedDpkg laat de volgende run dat zelf herstellen, maar alleen als die zover komt.

Package nginx-common has conffile prompt and needs to be upgraded manually in het logbestand
U hebt een configuratiebestand gewijzigd dat eigendom is van het pakket, en de nieuwe pakketversie brengt een aangepaste versie van dat bestand mee. Het programma slaat het pakket dan permanent over. Voer die update handmatig uit. Openstaande gevallen laat dit zien:

find /etc -type f \( -name "*.dpkg-dist" -o -name "*.dpkg-new" -o -name "*.ucf-dist" \)

Cache has broken packages, exiting in het logbestand
Uit een eerdere actie is een onvolledige toestand blijven staan. Voer apt --fix-broken install uit en daarna dpkg --configure -a. Tot dat moment doen de automatische updates elke nacht niets.

Uw instellingen hebben geen effect en er verschijnt geen foutmelding.
Dat is het kenmerk van een genegeerde bestandsnaam. Controleer met apt-config dump | grep -i unattended of de waarden zijn gelezen.

Automatic-Reboot "true" doet op Debian niets.
Daar ontbreekt het markeringsbestand /var/run/reboot-required.

De vier systemen vergeleken

Wat de automatische updates niet doen

• Geen overstap naar een nieuwe hoofdversie en geen externe bronnen, zolang daar geen patroon voor is ingevoerd.
• Niets buiten het pakketbeheer. Handmatig uitgepakte programma's, uitbreidingen van een contentmanagementsysteem, plug-ins van een spelserver en containers draaien gewoon door op hun eigen versie.
• Geen vervanging voor back-up en monitoring. Een update kan een dienst stilleggen, en als niemand kijkt, staat hij stil tot de ochtend.
• Geen bescherming tegen netwerkaanvallen. Actuele pakketten dichten bekende kwetsbaarheden; tegen volumeaanvallen helpt alleen filtering in het netwerk ervoor, bij KernelHost in het maincubes-datacenter in Frankfurt am Main.

De eindcontrole

1. apt-config dump APT::Periodic geeft Update-Package-Lists "1" en Unattended-Upgrade "1" weer.
2. apt-config dump | grep "^Unattended-Upgrade::" toont uw eigen waarden.
3. systemctl list-timers 'apt-daily*' --all toont beide timers met een plausibele kolom NEXT.
4. unattended-upgrade --dry-run --debug loopt foutloos door en noemt de verwachte bronnen.
5. tail -n 40 /var/log/unattended-upgrades/unattended-upgrades.log bevat na de eerste run een regel met datum.
6. ls -l /var/run/reboot-required op Ubuntu, needrestart -b op Debian.

Punt vijf is degene die echt telt, en die vraagt een dag geduld: alles daarvoor is voorbereiding, pas de regel van vannacht is het bewijs.