Meldingen instellen voor openstaande server-reboots en beveiligingsupdates

Een server kan wekenlang beveiligingsupdates hebben die wel geïnstalleerd maar nog niet actief zijn, in afwachting van een herstart die niemand heeft ingepland. De oplossing is om te alarmeren op de status 'reboot vereist' en 'updates openstaand' zelf, niet op de storing die daar uiteindelijk uit voortkomt. Op Debian en Ubuntu wordt die status al naar schijf geschreven; er moet alleen iets zijn dat ernaar kijkt.

Dit is een stillere manier van falen dan een service die crasht. Automatische beveiligingsupdates downloaden en installeren de pakketten, maar de kernel, libc of een langlopende daemon blijft de oude code in het geheugen gebruiken totdat iets ze herstart. De fix staat ongebruikt op de schijf, en niets aan de server ziet er verkeerd uit totdat de gepatchte kwetsbaarheid wordt misbruikt, of totdat er op het slechtst denkbare moment toch een reboot plaatsvindt, omdat niemand heeft bepaald wanneer.

Hoe Linux weet dat een reboot nodig is

Er bestaat geen POSIX-standaard voor "deze machine moet herstart worden"; het is volledig distributie-afhankelijk. Op Debian en Ubuntu haakt het pakket update-notifier-common in op APT en schrijft het een vlagbestand zodra een pakket dat een herstart vereist (de kernel, een kernbibliotheek, systemd zelf) klaar is met installeren:

$ cat /var/run/reboot-required
*** System restart required ***
$ cat /var/run/reboot-required.pkgs
linux-image-6.8.0-45-generic
libssl3

Het tweede bestand somt precies op welke pakketten de vlag hebben veroorzaakt. Dat is handig als je moet beslissen of een reboot tot het weekend kan wachten of nu moet gebeuren. Systemen uit de RHEL-familie gebruiken een ander mechanisme (dnf needs-restarting -r), en needrestart gaat op beide families een stap verder door te controleren welke draaiende processen nog naar verwijderde bestanden verwijzen. Het vlagbestand van Debian/Ubuntu is echter het eenvoudigste en meest gebruikte signaal, en daarom controleren de meeste monitoringopstellingen dat als eerste.

Hoe beveiligingsupdates blijven liggen

De meeste Debian- en Ubuntu-servers draaien unattended-upgrades, dat beveiligingspatches automatisch volgens een timer installeert, geconfigureerd in /etc/apt/apt.conf.d/50unattended-upgrades en /etc/apt/apt.conf.d/20auto-upgrades. Als het werkt, denk je er nooit aan. Als het stopt (een kapotte dependency, een vastgezet pakket, een cronjob die stilletjes is mislukt), stapelen de updates zich gewoon op:

$ apt list --upgradable 2>/dev/null | grep -i security
openssl/jammy-security 3.0.2-0ubuntu1.15 amd64 [upgradable from: 3.0.2-0ubuntu1.14]

Een handvol upgradebare pakketten gedurende een dag of twee is normaal: mirrors synchroniseren, timers lopen gespreid. Beveiligingsupdates die langer dan ongeveer een dag niet geïnstalleerd zijn, betekenen bijna altijd dat de automatisering die ze zou moeten installeren stilletjes is gestopt, niet dat er niets belangrijks is uitgebracht. Dat is een ander probleem dan een openstaande reboot, en het verdient een aparte melding: een server kan helemaal geen reboot nodig hebben en toch op ongepatchte kwetsbaarheden zitten.

Deze meldingen instellen zonder een script te schrijven

Je kunt dit zelf in elkaar zetten met een cronjob, een Prometheus textfile collector of een Nagios-plugin die op /var/run/reboot-required test en het resultaat omzet naar een check-status. Dat werkt, maar het is weer een extra script om per server te onderhouden, en je hebt nog steeds een plek nodig om de melding naartoe te sturen en een manier om te voorkomen dat je elke vijf minuten wordt opgepiept.

InfraNest levert beide checks als ingebouwde meldingen onder Monitoring → Alert defaults, voor elke server waarop de agent is geïnstalleerd:

Beide lezen dezelfde signalen op distributieniveau die hierboven zijn beschreven (de reboot-required-vlag en de lijst met upgradebare beveiligingspakketten), dus op de server zelf hoef je niets extra te configureren. Zet een van beide schakelaars één keer aan en hij geldt voor elke gemonitorde server in de organisatie; elke afzonderlijke server kan later via het tabblad Alerts & rules zijn eigen waarden krijgen zonder dat de rest verandert.

NoteBeide meldingen worden specifiek door Debian- en Ubuntu-servers gerapporteerd, omdat daar de onderliggende vlagbestanden staan. Op andere distributies blijven de meldingen uitgeschakeld in plaats van zonder reden af te gaan.

Waarom de reboot-melding je niet blijft lastigvallen

Een server die op een herstart wacht, doet dat vaak met opzet: niemand wil dat een productieserver midden in een deploy herstart alleen omdat er een uur geleden een kernelupdate binnenkwam. Daarom meldt de reboot-melding het je één keer wanneer de vlag voor het eerst verschijnt, en nog één keer als de server na het door jou gekozen aantal dagen nog steeds wacht, en blijft ze daartussen stil. Een server die bewust is geparkeerd voor een rustig onderhoudsvenster, blijft je daar niet over storen; een server die een week vergeten is, krijgt een tweede seintje.

De melding voor beveiligingsupdates gedraagt zich anders, omdat er geen goede reden is om te wachten. Ze gaat af zodra updates 24 uur niet geïnstalleerd zijn en verdwijnt vanzelf op het moment dat de server bij is. Aan het toepassen van een patch valt niets te "plannen", dus er is geen tweede uitstelperiode ingebouwd.

TipHoud het venster in minuten of uren realistisch in plaats van agressief. Een drempel die afgaat zodra er ook maar één update verschijnt, leert je alleen het kanaal te negeren waarin hij terechtkomt. Zie onze notities over monitoring en alerting voor het voorkomen van alertmoeheid in het algemeen, niet alleen voor deze check.

De cirkel rond maken met automatisering

Een melding die om 2 uur 's nachts in Slack belandt en op een mens wacht, is maar het halve werk. Omdat dit gewone InfraNest-meldingen zijn, kun je ze doorgeven aan een automatisering in plaats van, of naast, een notificatie: open een ticket als een server al meer dan twee weken op een reboot wacht, plaats elke maandag een overzicht in een kanaal met de servers die wachten, of vereis goedkeuring en herstart de server automatisch zodra iemand akkoord geeft. De melding vertelt je iets; de automatisering is wat het daadwerkelijk afhandelt zonder dat je de herstart met de hand uitvoert.

Twijfel je nog wat je verder op een server in de gaten wilt houden voordat het een storing wordt? Servermetrics en meldingen behandelt CPU, geheugen, schijf en load op dezelfde manier, en is het lezen waard naast onze bredere checklist voor het beveiligen van infrastructuur als je patchritme deel uitmaakt van een grotere audit.

Zet beide meldingen aan onder Monitoring → Alert defaults, dan laten de servers die een herstart of een duwtje nodig hebben om het patchen af te ronden het je zelf weten, in plaats van te wachten tot er eerst iets kapotgaat.