Kort gezegd: Met unattended-upgrades onder Debian en Ubuntu en dnf-automatic in de RHEL-familie installeren Linux-servers zelfstandig beveiligingsupdates. Om een update ook te laten werken, moeten getroffen services zoals PHP-FPM daarna herstarten; controleer dat met needrestart of de starttijden van processen. Externe bronnen zoals sury.org moeten uitdrukkelijk worden vrijgegeven, containers en hoofdversiewissels dekt de automatiek niet af.
Van patch naar server: automatiek bespaart tijd
Toen php.net op 21 oktober 2026 om 16.00 uur Duitse tijd de patches tegen PHP2Shell publiceerde, begon voor beheerders een race. Volgens berichten leverden distributies hun backports deels nog dezelfde dag uit. Servers met automatische beveiligingsupdates konden de nieuwe pakketten bij de eerstvolgende geplande run installeren zonder dat iemand hoefde in te grijpen.
Dat is het goede nieuws. Het minder goede: geïnstalleerd betekent niet werkzaam. Een PHP-FPM-service die al weken draait, blijft met de oude code in het geheugen werken tot hij wordt herstart. En pakketten uit externe bronnen, containers of hostingpanelen met eigen PHP-beheer blijven door de automatiek vaak onaangeroerd.
Dit artikel laat zien hoe u automatische beveiligingsupdates instelt en zo aanvult dat ze in een noodgeval werkelijk beschermen.
unattended-upgrades onder Debian en Ubuntu
Onder Ubuntu is het pakket unattended-upgrades standaard geïnstalleerd en installeert het beveiligingsupdates. Onder Debian installeert u het zo nodig achteraf. Het wordt aangestuurd via twee bestanden onder /etc/apt/apt.conf.d/.
sudo apt install unattended-upgrades apt-listchanges
sudo dpkg-reconfigure -plow unattended-upgrades
Het bestand 20auto-upgrades legt vast of en hoe vaak pakketlijsten worden bijgewerkt en updates worden geïnstalleerd. De waarde is het aantal dagen, "1" betekent dagelijks:
// /etc/apt/apt.conf.d/20auto-upgrades
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";
In 50unattended-upgrades staat uit welke bronnen updates mogen komen, of daarna wordt herstart en wie een bericht ontvangt. Standaard zijn alleen de officiële beveiligingsbronnen van de distributie vrijgegeven. Volgens de Ubuntu-documentatie volstaat het niet een extra repository in te voegen: ze moet bovendien in deze lijst staan, anders wordt ze door de automatiek genegeerd. Dat betreft bijvoorbeeld de repository van derden sury.org, die volgens berichten PHP-builds voor alle takken van 5.6 tot 8.5 heeft aangeboden. Achtergronden staan in het artikel De sury.org-repository.
Of alles klopt, toont een proefrun die niets wijzigt:
sudo unattended-upgrade -v --dry-run
# Logboeken van de echte runs
ls -l /var/log/unattended-upgrades/
dnf-automatic op RHEL, AlmaLinux en Rocky Linux
In de RHEL-familie neemt dnf-automatic dezelfde taak over. De configuratie staat in /etc/dnf/automatic.conf. Volgens de documentatie controleert upgrade_type = security alleen updates met een beveiligingsmelding en is apply_updates standaard uitgeschakeld.
# /etc/dnf/automatic.conf (uittreksel)
[commands]
upgrade_type = security
download_updates = yes
apply_updates = yes
reboot = never
sudo dnf install dnf-automatic
sudo systemctl enable --now dnf-automatic.timer
systemctl list-timers 'dnf-automatic*'
Naast dnf-automatic.timer, die het configuratiebestand volgt, zijn er timers die alleen melden, alleen downloaden of altijd installeren. Voor het begin is de timer met configuratiebestand het best te volgen.
Het onderschatte deel: services herstarten
Het pakketbeheer vervangt bestanden op de schijf. Draaiende processen behouden de oude code in het geheugen. Bij PHP betekent dat: zolang PHP-FPM of Apache met mod_php niet is herstart, blijft de kwetsbaarheid open.
| Hulpmiddel | Systeem | Wat het doet |
|---|---|---|
| needrestart | Debian, Ubuntu | herkent services met verouderde bestanden; herstart ze onder Ubuntu vanaf 24.04 standaard automatisch |
dnf needs-restarting -s |
RHEL-familie | somt services op die moeten worden herstart |
Automatic-Reboot |
unattended-upgrades | herstart de server als een update dat vereist; standaard uit |
reboot |
dnf-automatic | never, when-changed of when-needed |
Volgens de Ubuntu-documentatie blijven services die van needrestart zijn uitgezonderd tot de handmatige herstart met oude bestanden doorlopen. Controleer daarom na elke PHP-update de starttijd van de processen, zoals beschreven onder PHP-FPM en alle workers herstarten.
Bij backports blijft het getoonde PHP-versienummer vaak gelijk. De patch bewijst u via de pakketchangelog met de CVE-nummers, bijvoorbeeld met apt-get changelog of rpm -q --changelog. Hoe dat in detail gaat, toont Debian en Ubuntu: is mijn PHP-pakket gepatcht?.
Wat de automatiek niet dekt
Automatische updates zijn een bouwsteen, geen volledig patchbeheer. Enkele gebieden hebben eigen procedures nodig:
- Containers: PHP in Docker-images wordt door hostupdates niet bijgewerkt. Images opnieuw bouwen, containers opnieuw aanmaken.
- Hostingpanelen: Plesk, cPanel en vergelijkbare panelen beheren PHP deels via eigen pakketten en mechanismen.
- Hoofdversies: de wissel van bijvoorbeeld PHP 8.2, dat op 31-12-2026 het einde van de ondersteuning bereikt, naar een nieuwere versie gebeurt niet automatisch.
- Applicaties: CMS'en, plug-ins en Composer-afhankelijkheden hebben eigen updatewegen.
- Controle: iemand moet logboeken en foutmeldingen van de automatiek lezen. Een stil mislukkende run is erger dan geen, omdat hij veiligheid voorwendt.
Hoe deze delen tot één proces samengroeien, beschrijft Patchbeheer als proces in plaats van brandweer.
Conclusie: automatiek ja, blind vertrouwen nee
Automatische beveiligingsupdates horen op elke Linux-server die vanaf internet bereikbaar is. PHP2Shell heeft laten zien hoe krap de tijd kan worden: volgens mediaberichten werd een eerste aanvalspoging al op 17 oktober waargenomen, vier dagen vóór de patches. Wie daarna nog op een handmatig onderhoudsvenster wacht, verliest kostbare tijd.
De automatiek neemt u echter alleen het installeren uit handen. Herstart van services, bewijs van de patchstatus, containers, panelen en de tijdige overstap naar ondersteunde versies blijven taken waarvoor iemand verantwoordelijk moet zijn. Leg die verantwoordelijkheid schriftelijk vast en controleer steekproefsgewijs of de logboeken van de automatiek werkelijk worden gelezen. Pas de combinatie van automatiek en controle maakt updates betrouwbaar.
Hoe helpt PHP SOS concreet?
- Instellen: wij configureren unattended-upgrades of dnf-automatic passend bij uw servers, inclusief vrijgegeven externe bronnen.
- Herstarts waarborgen: wij richten needrestart of vergelijkbare controles in en controleren na PHP-updates de starttijden van processen.
- Hiaten dichten: containers, panelen en hoofdversiewissels nemen wij op in een vaste onderhoudsprocedure.
- Controleren: in het security-onderhoudscontract controleren wij logboeken van de automatiek en melden wij afwijkingen.
Veelgestelde vragen
Zijn automatische updates op productieservers niet te riskant?
Beperkt tot beveiligingsupdates van de distributie is het risico meestal kleiner dan dat van een openstaande kwetsbaarheid. Deze updates moeten geen nieuwe functies brengen, maar fouten verhelpen. Voor kritieke systemen horen back-ups, bewaking en een testsysteem erbij.
Herstart unattended-upgrades PHP-FPM na een update?
Niet per se zelf. Onder Ubuntu herstart vanaf versie 24.04 het hulpmiddel needrestart getroffen services standaard automatisch, maar uitgezonderde services blijven met oude bestanden doorlopen. Controleer na elke PHP-update de starttijd van alle PHP-processen.
Worden pakketten uit sury.org of andere externe bronnen automatisch bijgewerkt?
Alleen als u de bron uitdrukkelijk vrijgeeft. Volgens de Ubuntu-documentatie volstaat het niet een repository toe te voegen; ze moet bovendien in de lijst met toegestane herkomsten van unattended-upgrades staan.
Verhoogt de automatiek ook PHP 8.2 naar 8.3?
Nee. Automatische beveiligingsupdates blijven binnen de geïnstalleerde pakketversies. Een wissel van de PHP-hoofdversie, bijvoorbeeld vóór het einde van de ondersteuning voor PHP 8.2 op 31-12-2026, blijft een gepland project met tests.
Wat is er met Docker-containers?
Updates op de host werken de PHP-versie in containers niet bij. Containerimages moeten opnieuw worden gebouwd of opnieuw opgehaald en de containers opnieuw worden aangemaakt.