Kort gezegd: White-label IT-beveiliging betekent voor uw bureau: u behoudt de klantrelatie, wij doen op de achtergrond het beveiligingswerk. Bij PHP2Shell betekent dat een inventaris van alle klantsites, prioritering naar risico, patch en herstart per server en een bewijsstuk per klant dat u kunt doorgeven.
Waarom bureaus bij PHP2Shell extra onder druk staan
Een bureau met veel klanten beheert zelden een uniform landschap. Een deel van de sites staat op eigen servers met Plesk, een deel bij de hostingproviders van de klanten, enkele oude projecten draaien op PHP-versies die allang geen officiële updates meer krijgen. Daarbij komen verschillende systemen: WordPress, TYPO3, Shopware, Craft CMS, eigen Laravel-ontwikkelingen.
Bij een kwetsbaarheid in PHP zelf worden alle projecten tegelijk getroffen. Klanten verwachten een antwoord op de vraag of hun site veilig is, en het projectteam zit vol met lopende opdrachten. Veel onderhoudscontracten regelen het CMS, maar niet de server eronder.
Daar komen systemen bij die op geen enkele projectlijst meer voorkomen: stagingomgevingen op subdomeinen, campagnesites van afgesloten projecten, testinstallaties van ontwikkelaars op eigen vServers. Ze draaien vaak op oudere PHP-versies, worden niet bewaakt en dragen toch de naam van uw bureau of uw klant. Voor geautomatiseerde scans zijn ze even zichtbaar als de hoofdsite.
Welke vragen uw klanten nu stellen
- Is mijn website getroffen, en is hij inmiddels gepatcht?
- Is er vóór de patch al iets ingebracht?
- Geldt de update van het CMS als bescherming? Nee, een CMS-update sluit het PHP-lek niet.
- Moet ik mijn website offline halen? Het BSI (de Duitse federale dienst voor informatiebeveiliging) adviseert dat voor servers die niet direct kunnen worden bijgewerkt.
Op elk van deze vragen heeft uw bureau per klant een aantoonbaar antwoord nodig, geen rondmail met algemene uitspraken.
Hoe white-label IT-beveiliging voor bureaus verloopt
Wij werken als onderdeel van uw team, maar zonder eigen klantcontact. De taakverdeling is duidelijk:
| Taak | Uw bureau | PHP SOS |
|---|---|---|
| Klantcommunicatie en facturering | ja | nee |
| Inventaris van alle klantsites met PHP-status | levert toegangen | stelt op en onderhoudt |
| Patch, herstart, controle per server | geeft onderhoudsvenster vrij | voert uit of coördineert met hostingproviders |
| Controle op compromittering | ontvangt bevinding | zoekt naar webshells en bijzonderheden |
| Bewijsstuk per klant | geeft door | stelt op, neutraal of in uw opmaak |
Bij sites op andere hostingproviders vragen wij de bevestiging van de pakketstatus op. Het getoonde versienummer alleen volstaat niet, omdat backports het ongewijzigd kunnen laten.
Geef eerst prioriteit aan servers met Apache en mod_php, waar het PHP-team het risico het hoogst inschat, daarna aan webshops en sites met logins, dan aan projecten op PHP 8.1 en ouder. Statische oude projecten die niemand meer nodig heeft, schakelt u beter uit dan dat u ze patcht.
Meerdere klantsites op één server: isolatie controleren
Op bureauservers delen vaak veel klantsites één machine. Wordt er één gecompromitteerd, dan bepaalt de scheiding of de aanvaller ook bij de andere komt. Belangrijk zijn eigen systeemgebruikers en PHP-FPM-pools per website, nette bestandsrechten en grenzen zoals open_basedir. Op Plesk-servers zijn deze instellingen per abonnement te controleren.
Na de patch geldt: alle pools en workers herstarten. Pas dan draaien er geen oude PHP-processen meer in het geheugen. Logs vanaf 20 oktober 2026 moeten voor elke klantsite worden bewaard.
Klantinformatie: wat vaststaat en wat niet
De grootste verleiding in deze situatie is een geruststellende verzamelmail. Veiliger is een uitspraak per klant die alleen bevat wat vaststaat: welke server, welke PHP-pakketstatus, wanneer herstart, of er een controle op compromittering heeft plaatsgevonden en met welk resultaat. Wat nog openstaat, staat er eveneens in.
Formuleringen als “Uw site is veilig” kunt u beter vermijden. Een patch sluit het lek, maar bewijst niet dat er daarvoor niets is gebeurd. Wie dat eerlijk scheidt, hoeft later geen uitleg te geven als er toch een bevinding opduikt.
Onderhoudscontracten na PHP2Shell herzien
Veel bureaucontracten regelen updates van CMS en extensies, maar zwijgen over de server. Gebruik de situatie om per klant vast te leggen wie PHP bijwerkt, wie verantwoordelijk is voor herstarts, wie bij een incident beslist en welke diensten apart worden opgedragen. Ook een verwerkersovereenkomst met alle betrokken dienstverleners hoort daarbij. De contractuele invulling bespreekt u met uw juridisch adviseur.
Hoe helpt PHP SOS concreet?
- Wij nemen de inventarisatie van alle klantsites over, met PHP-versie, uitvoeringsmodus, hostingprovider en verantwoordelijkheid.
- Via onze PHP-patchservice patchen wij uw eigen servers, herstarten alle workers en tonen dat per klant aan.
- Wij controleren geprioriteerde sites op compromittering en saneren bij een bevinding, tot het incident is afgerond en gedocumenteerd.
- Wij leveren tekstblokken voor uw klantinformatie, die u aanpast en zelf verstuurt.
- Daarna nemen wij op verzoek met een beveiligingsonderhoudscontract de doorlopende beveiligingszorg op de achtergrond over.
Veelgestelde vragen
Treden jullie naar onze klanten toe op?
Alleen als u dat wilt. In het white-labelmodel werken wij uitsluitend op de achtergrond en loopt alle communicatie via uw bureau. Onze documentatie leveren wij neutraal of in uw eigen opmaak.
Hebben wij daarvoor een verwerkersovereenkomst nodig?
Als wij toegang krijgen tot systemen met persoonsgegevens van uw klanten, is in de regel een verwerkersovereenkomst nodig, vaak als subverwerkersovereenkomst. Hoe dat in uw bestaande contracten past, bespreekt u met uw juridisch adviseur. Wij stellen de benodigde gegevens over onze werkzaamheden beschikbaar.
Wat doen we met klantsites waarvan wij de server helemaal niet beheren?
Staan klantsites bij andere hostingproviders, dan vragen wij namens u of met uw sjablonen bevestigingen op over patchstatus en herstart. Waar alleen FTP- of CMS-toegang bestaat, onderzoeken wij wat vanaf daar mogelijk is en geven wij open aan wat alleen de hostingprovider kan aantonen.
Kunnen we dit ook na PHP2Shell blijvend uitbesteden?
Ja. Veel taken keren bij elke kwetsbaarheid terug: inventaris bijhouden, patches doorvoeren, herstarts aantonen, bijzonderheden melden. Dit werk is als doorlopend beheer op de achtergrond te organiseren.