Rootserver en vServer zelf beveiligen

Kort gezegd: Wie een rootserver of vServer zelf beheert, moet die na PHP2Shell ook zelf beveiligen: PHP-pakketten naar een gecorrigeerde status brengen, alle PHP-processen herstarten en het resultaat controleren. De datacenterexploitant zorgt in de regel alleen voor hardware, virtualisatie en netwerk. Daarna loont het de server duurzaam te harden.

Uw verantwoordelijkheid bij een eigen server

Bij een onbeheerde rootserver of vServer huurt u rekenkracht, geen begeleiding. Besturingssysteem, webserver, PHP, database, firewall, back-ups en bewaking liggen in uw handen. Voor directie en eigenaren betekent dat: als niemand in huis of bij een dienstverlener deze taken uitdrukkelijk heeft overgenomen, doet niemand ze.

PHP2Shell maakt dat zichtbaar. De twee kwetsbaarheden CVE-2026-109618 en CVE-2026-109619 zitten in PHP zelf en maken het uitvoeren van code zonder inloggen mogelijk. Het PHP-project heeft op 21-10-2026 de versies 8.5.12, 8.4.27, 8.3.36 en 8.2.35 uitgebracht. Het BSI adviseert een onmiddellijke update en, als dat niet kan, de webserver tijdelijk van het net te halen.

vServer beveiligen: inventaris en pakketstatus controleren

Verschaf u eerst een overzicht van welke PHP-versies zijn geïnstalleerd en uit welke bron ze komen. Veel servers gebruiken naast de pakketten van de distributie extra pakketbronnen. De volgende opdrachten lezen alleen. Pakketnamen zijn voorbeelden.

# Debian/Ubuntu: geïnstalleerde PHP-pakketten en hun herkomst
apt list --installed 'php*' 2>/dev/null
apt-cache policy php8.3-fpm

# AlmaLinux/Rocky/RHEL
dnf list installed 'php*'

# Welke PHP-binaries zijn er eigenlijk?
ls /usr/bin/php* /usr/sbin/php-fpm* 2>/dev/null

Het versienummer alleen volstaat niet. Distributies leveren beveiligingscorrecties vaak als backport, het getoonde nummer blijft dan ouder. Doorslaggevend is het wijzigingslogboek van het pakket.

# Debian/Ubuntu (pakketnaam als voorbeeld)
apt changelog php8.3-fpm 2>/dev/null | grep -iE 'CVE-2026-1096(18|19)'

# RHEL-familie (pakketnaam als voorbeeld)
rpm -q --changelog php-fpm | grep -iE 'CVE-2026-1096(18|19)'

Een uitgebreide handleiding vindt u onder PHP-versie en patchstatus controleren.

Update doorvoeren en alle processen vernieuwen

Voer de updates door via de pakketbeheerder en herstart daarna elke dienst die PHP laadt. Dat zijn, afhankelijk van de opzet, PHP-FPM, Apache met mod_php, LiteSpeed of een applicatieserver. Nieuwe bestanden op de schijf volstaan niet zolang oude processen in het geheugen draaien.

# Diensten met PHP vinden
systemctl list-units --type=service | grep -iE 'php|apache2|httpd|lsws'

# Processen met starttijd weergeven
ps -eo pid,lstart,cmd | grep -E 'php|apache2|httpd' | grep -v grep

# Debian/Ubuntu: programma's met verouderde bibliotheken herkennen (indien geïnstalleerd)
needrestart -r l

Elk relevant proces hoort na de update te zijn gestart. Handig is het hulpmiddel needrestart op Debian-systemen, dat diensten met verouderde bibliotheken toont. Details over de herstart beschrijft PHP-FPM en alle workers herstarten.

Voor een eerste speurtocht naar sporen bieden zich enkele controles aan die niets wijzigen. Zoek naar PHP-bestanden die sinds 17-10-2026 in webmappen nieuw zijn aangemaakt of gewijzigd, naar onbekende vermeldingen in de crontabs van alle gebruikers, naar nieuwe systeemgebruikers en SSH-sleutels en naar processen van de gebruiker van de webserver die uitgaande verbindingen openhouden.

# Sinds 17-10-2026 gewijzigde PHP-bestanden (pad als voorbeeld)
find /var/www -type f -name '*.php' -newermt '2026-10-17' -ls

# Netwerkverbindingen met bijbehorend proces
ss -tupn

Geen van deze controles bewijst op zichzelf een inbraak, en een leeg resultaat bewijst niet het tegendeel. Ze laten wel zien of een diepgaander onderzoek nodig is. Werk op kopieën van de logs en wijzig verdachte bestanden niet totdat de toestand is veiliggesteld. Bij vondsten is een geordend onderzoek de veilige weg. Schakel de server in dat geval niet zomaar uit en zet hem niet meteen opnieuw op, want daarmee gaan sporen verloren die belangrijk zijn voor de beoordeling van meldplichten en voor een mogelijke aangifte.

De server duurzaam harden

Na de acute patch volgt de basisbeveiliging. Ze voorkomt niet elke kwetsbaarheid, maar beperkt de schade en verkort de reactietijd de volgende keer. Deze punten hebben zich bewezen:

• Toegangen: SSH alleen met sleutel, geen directe root-aanmelding, beheerinterfaces alleen bereikbaar vanuit bekende netwerken.
• Firewall: alleen de poorten openen die echt nodig zijn, uitgaande verbindingen van de webserver beperken.
• PHP-configuratie: gevaarlijke functies uitschakelen, open_basedir per website, eigen pools en gebruikers per toepassing.
• Bestandsrechten: de webserver mag programmacode niet beschrijven, uploadmappen voeren geen PHP uit.
• Updates: beveiligingsupdates automatisch doorvoeren, herstart en controle vast inplannen.
• Back-ups: back-ups volgens de 3-2-1-regel, minstens één kopie buiten de server en beschermd tegen wijziging.
• Logboeken: logs centraal verzamelen en lang genoeg bewaren.

Hoe een betrouwbare back-up eruitziet, beschrijft Back-ups volgens de 3-2-1-regel. Als kader voor bedrijven is de IT-Grundschutz van het BSI geschikt.

Wanneer een managed server de betere keuze is

Een eigen server loont als iemand het onderhoud betrouwbaar overneemt: updates volgen, situaties zoals PHP2Shell beoordelen, 's nachts kunnen reageren. Ontbreekt die capaciteit, dan is een managed server of een vast onderhoudscontract zinvol. Belangrijk is in beide gevallen de verantwoordelijkheden schriftelijk vast te leggen. Meer daarover onder Managed server: verantwoordelijkheid duidelijk maken.

Hoe helpt PHP SOS concreet?

• Wij inventariseren alle PHP-installaties, pakketbronnen en diensten van uw server en beoordelen de werkelijke patchstatus.
• Wij voeren updates door, herstarten alle processen en documenteren het resultaat.
• Wij controleren de server op sporen van een compromittering en leggen logs vast voor latere analyse.
• In het kader van onze serverhardening richten we toegangen, firewall, PHP-pools en rechten netjes in.
• Op verzoek nemen we het lopende onderhoud over via een beveiligingsonderhoudscontract.

Veelgestelde vragen

Bronnen

• php.net: beveiligingsmeldingen
• PHP 8 ChangeLog
• php.net: ondersteunde versies
• BSI IT-Grundschutz