Kort gezegd: Een IT-inventaris voor webservers is een lijst van alle websites, portalen, shops en servers met de gegevens die u bij een beveiligingsmelding direct nodig hebt: waar het draait, met welke PHP-versie en werkingsmodus, welke toepassing, wie verantwoordelijk is en welke gegevens getroffen zouden zijn. Zonder deze lijst begint elke reactie met zoeken. Met de lijst duurt de vergelijking bij een melding als PHP2Shell minuten in plaats van dagen.
De eerste vraag was: waar draait bij ons eigenlijk PHP?
Toen het PHP-project op 21-10-2026 de patches publiceerde en het BSI (Duitse federale dienst voor informatiebeveiliging) direct handelen adviseerde, was de opdracht duidelijk: PHP bijwerken, alle processen herstarten. Toch was voor veel bedrijven de eerste stap niet de update, maar een inventarisatie. De hoofdwebsite was bekend. Maar het dealerportaal? De carrièrepagina bij een andere aanbieder? De landingspagina uit een campagne van drie jaar geleden? De interne wiki?
De vakpers en meetdiensten hebben de omvang van het probleem zichtbaar gemaakt. Palo Alto Networks (Unit 42) telde meer dan 22,6 miljoen blootgestelde, potentieel kwetsbare instanties. Daaronder zullen veel systemen zijn waaraan hun beheerders eenvoudigweg niet meer denken.
Wat in een IT-inventaris voor webservers hoort
Een bruikbare inventaris is een tabel met één regel per website of toepassing. Deze kolommen hebben zich bewezen:
| Kolom | Voorbeeld | Waarvoor |
|---|---|---|
| Adres | shop.voorbeeld.nl | eenduidige toewijzing |
| Doel en belang | webshop, cruciaal voor de omzet | prioritering |
| Hoster of locatie | managed server bij aanbieder X | wie u belt |
| Server en besturingssysteem | vServer, Debian | updateroute, beveiligingsbronnen |
| Webserver en PHP-werkingsmodus | Nginx met PHP-FPM | risico, bijv. mod_php |
| PHP-versie en pakketstatus | 8.3, pakket met datum | vergelijking met meldingen |
| Toepassing en versie | Shopware, plug-ins | meldingen van de fabrikant |
| Verantwoordelijke intern / extern | IT-leiding / bureau Y | wie handelt |
| Verwerkte gegevens | klantaccounts, bestellingen | meldplichten, urgentie |
| Back-ups | dagelijks, extern, laatst getest op … | herstel |
| Laatste patchbewijs | datum en bewijsstuk | bewijs tegenover derden |
De werkingsmodus verdient bijzondere aandacht. Bij PHP2Shell schatte het PHP-team het risico bij Apache met mod_php het hoogst in. Wie weet welke systemen zo draaien, kan ze als eerste aanpakken. De kolom over de pakketstatus is belangrijk, omdat het getoonde versienummer na backports vaak gelijk blijft; aanwijzingen daarover staan onder PHP-versie en patchstatus juist controleren.
Vergeten systemen vinden: zo gaat u te werk
De bekende systemen zijn snel ingevoerd. Het eigenlijke werk zijn de onbekende. Deze bronnen helpen ze op te sporen:
- Domeinen en DNS: Loop alle domeinen van het bedrijf en hun subdomeinen na. Elke vermelding die naar een webserver wijst, is een kandidaat.
- Facturen: De boekhouding kent elke hoster, registrar en cloudaanbieder die geld ontvangt. Dat is vaak de meest complete lijst.
- Bureaus en vakafdelingen: Marketing, verkoop en personeelszaken laten graag rechtstreeks websites bouwen. Vraag het na.
- Bekende servers: Op elke server laat de configuratie zien welke websites hij werkelijk uitlevert.
- Apparaten met webinterface: NAS, routers en appliances brengen soms eigen PHP mee, zie PHP op NAS, routers en appliances.
Voor stap 4 helpen op Linux-servers enkele alleen-lezen opdrachten. Ze tonen geconfigureerde websites, PHP-diensten en FPM-pools:
# Geconfigureerde websites (Apache resp. Nginx)
apachectl -S 2>/dev/null
nginx -T 2>/dev/null | grep -E "^\s*server_name" | sort -u
# Draaiende PHP-diensten en processen
systemctl list-units --type=service | grep -iE "php|fpm|lsws|litespeed"
ps -eo user,cmd | grep -E "php-fpm|php-cgi|lsphp" | grep -v grep | sort | uniq -c
# FPM-pools onder Debian en Ubuntu
ls /etc/php/*/fpm/pool.d/ 2>/dev/null
Draaien op een server meerdere PHP-versies naast elkaar, dan hoort elke versie op de lijst. Elke versie moet afzonderlijk worden bijgewerkt en herstart.
Voer ook systemen in die eigenlijk uitgeschakeld hadden moeten worden. Juist die draaien vaak nog, zijn al jaren niet bijgewerkt en worden vergeten. Met een vermelding „uitschakelen vóór …“ blijft de taak zichtbaar.
De inventaris actueel houden
Een inventaris is maar zo goed als haar laatste update. Drie regels houden haar levend. Ten eerste: één persoon is verantwoordelijk en wordt bij elke nieuwe website, elke verhuizing en elke uitschakeling geïnformeerd, ook als een bureau het werk uitvoert. Ten tweede: eens per kwartaal wordt de lijst vergeleken met DNS, facturen en serverconfiguratie. Ten derde: de inventaris maakt deel uit van het noodplan en is ook buiten de eigen IT beschikbaar, bijvoorbeeld uitgeprint.
Voor bedrijven met veel verspreide systemen, zoals dealerportalen, configurators en leverancierstoegangen, beschrijft IT-beveiliging voor mkb en industrie typische vindplaatsen. Hoe de inventaris in het noodplan wordt opgenomen, leest u onder IT-noodplan voor webservers opstellen.
Veelgemaakte fouten bij de inventaris van webservers
Veel inventarissen bestaan, maar helpen in een noodgeval niet. De oorzaken lijken op elkaar:
- Alleen servers, geen websites: De lijst noemt machines, maar niet welke websites erop draaien en wie ze inhoudelijk verantwoordt. Bij een lek weet dan niemand welke afdeling getroffen is.
- Versie in plaats van pakketstatus: „PHP 8.3“ zegt na PHP2Shell weinig. Pas pakketstatus en datum tonen of de correctie erin zit.
- Externe systemen ontbreken: Wat bij een bureau of platformdienst draait, wordt weggelaten omdat men daar „niet verantwoordelijk“ voor zou zijn. De verantwoordelijkheid voor de gegevens blijft toch in huis.
- Geen contactpersonen: Een vermelding zonder naam en telefoonnummer van de verantwoordelijke kost in een noodgeval tijd.
- Eenmalige actie: De inventaris wordt in een crisisweek gemaakt en daarna nooit meer geopend. Na een jaar klopt een flink deel niet meer.
Wie deze vijf punten vermijdt, heeft bij de volgende melding een lijst waarmee echt te werken valt.
Hoe helpt PHP SOS concreet?
- Wij leggen samen met u alle websites en servers vast, ook de vergeten, via DNS, facturen, dienstverleners en serverconfiguratie.
- Wij stellen voor elk systeem de werkingsmodus, de PHP-versie en de werkelijke pakketstatus vast.
- Wij prioriteren de systemen naar bereikbaarheid, gegevens en werkingsmodus en zeggen waar het eerst moet worden gehandeld.
- Waar PHP2Shell nog openstaat, dichten wij het lek via de PHP2Shell-noodhulp en voeren wij het bewijs in de inventaris in.
Conclusie: Een inventaris is de onopvallendste en tegelijk meest doeltreffende beveiligingsmaatregel. Wie weet wat er draait, kan bij de volgende melding direct handelen in plaats van eerst te zoeken.
Veelgestelde vragen
Welke gegevens heeft een inventaris voor webservers minimaal nodig?
Adres van de website, server of hoster, werkingsmodus van PHP, PHP-versie met pakketstatus, toepassing met versie, interne en externe verantwoordelijke, soort verwerkte gegevens en locatie van de back-ups. Met deze gegevens is elke nieuwe beveiligingsmelding snel af te stemmen.
Hoe vind ik websites waarvan niemand meer weet dat ze bestaan?
Via meerdere wegen tegelijk: domeinbeheer en DNS-zones, facturen van hosters en registrars, vragen aan bureaus en vakafdelingen en de configuratie van de bekende servers. Oude campagnepagina's, testsystemen en subdomeinen komen zo meestal boven water.
Wie moet de inventaris bijhouden?
Een aangewezen persoon, meestal bij IT of de IT-leiding. Belangrijk is dat elke wijziging aan websites en servers daar wordt gemeld, ook als een vakafdeling of bureau haar heeft aangevraagd.
Volstaat een tabel of is software nodig?
Voor de meeste mkb-bedrijven volstaat een goed bijgehouden tabel. Software loont zodra veel systemen automatisch moeten worden vastgelegd. Beslissend is de actualiteit, niet het gereedschap.