Kort gezegd: Wie na een beveiligingsincident van hoster wil wisselen, moet eerst bewijs veiligstellen en het incident ophelderen, daarna alleen gecontroleerde data overbrengen naar een nieuw opgezet systeem en pas dan het oude contract beëindigen. De nieuwe aanbieder kiest u op veiligheidscriteria: aantoonbare patchprocessen, scheiding van klanten, toegang tot logs, back-ups en duidelijke aanspreekpunten. Een hosterwissel is zinvol als vertrouwen of prestaties ontbreken, maar hij vervangt geen opschoning.
Als het vertrouwen weg is
Na PHP2Shell beleven veel bedrijven hun hoster voor het eerst onder druk. Sommigen kregen snel duidelijke informatie over de patchstand. Anderen wachtten dagen op een antwoord, kregen alleen algemene frasen of stelden vast dat hun website op een verouderde PHP-versie draaide. Komt er dan ook nog een incident bij, dan is de wens om te wisselen begrijpelijk.
Een hosterwissel is echter geen stap in de incidentbestrijding, maar in de herinrichting daarna. Wie hem in de verkeerde volgorde uitvoert, neemt in het slechtste geval de aanvaller mee en verliest tegelijk de sporen die tonen wat er is gebeurd.
De juiste volgorde bij de wissel
- Sporen veiligstellen zolang ze er zijn. Logs, bestanden en database van het oude systeem horen in een back-up voordat er iets wordt verwijderd of opgezegd. Vraag de oude hoster uitdrukkelijk om toegangs- en foutlogs vanaf 20 oktober 2026 en om hun bewaartermijn. Hoe u daarbij te werk gaat, beschrijft het artikel Bewijs veiligstellen voordat u opnieuw installeert.
- Het incident afbakenen. Welke systemen zijn getroffen, welke toegangen zijn gebruikt, welke data waren bereikbaar? Daarvan hangen meldplichten en de vraag af wat u mag meenemen.
- Meldplichten controleren. Kunnen persoonsgegevens getroffen zijn, dan begint de termijn voor een mogelijke AVG-melding op het moment dat u het incident kent, niet bij de verhuizing. Achtergronden staan onder AVG-meldplicht: 72 uur.
- Het nieuwe systeem schoon opbouwen. Ondersteunde PHP-versie, actuele pakketten, geharde configuratie, nog voordat het eerste bestand wordt overgedragen.
- Alleen het gecontroleerde overdragen. Code uit een schone bron, database en media na controle.
- Alle toegangsgegevens wijzigen. Database, beheerdersaccounts, SSH, FTP, API-sleutels, ook die in configuratiebestanden.
- Omschakelen en observeren. DNS-omschakeling, daarna een tijd lang scherpere monitoring.
- Het oude contract beëindigen. Pas wanneer logs en back-ups zijn veiliggesteld en de nieuwe omgeving stabiel draait.
Zeg het oude contract niet op voordat u logs en back-ups in handen hebt. Met het einde van het contract kunnen bij de aanbieder data worden gewist die u nodig hebt voor verzekeraars, autoriteiten of uw eigen onderzoek.
Wat u niet moet meenemen
Het zou gemakkelijk zijn de complete webmap of een image van de server gewoon te kopiëren. Juist dat is na een incident riskant. Webshells vermommen zich als onschuldige bestanden, achterdeuren zitten in configuratiebestanden zoals .htaccess of .user.ini, en ingeslopen code kan in database-inhoud staan.
Draag de applicatiecode daarom over uit een schone bron, bijvoorbeeld het pakket van de fabrikant in de juiste versie of uw versiebeheersysteem. Media neemt u over zonder uitvoerbare bestanden, de database na een controle op opvallende inhoud en nieuwe beheerdersaccounts. Wat op het oude systeem is gevonden, helpt bij die controle.
Denk ook aan alles wat naast de website bij de oude aanbieder staat. E-mailpostvakken, DNS-records, certificaten en doorverwijzingen worden bij een verhuizing gemakkelijk vergeten. Verlaag de geldigheidsduur van de DNS-records enkele dagen voor het omschakelen, zodat de wijziging snel bij de bezoekers aankomt. Verhuizen e-mails mee, plan de wissel van de postvakken dan apart, want ook daar kunnen na een incident toegangsgegevens getroffen zijn.
De nieuwe hoster op veiligheid kiezen
Prijs en opslagruimte staan in elk aanbod. De beslissende veiligheidsvragen moet u meestal zelf stellen. De volgende lijst helpt bij de vergelijking:
| Criterium | Vraag aan de aanbieder | Waarom het telt |
|---|---|---|
| Patchproces | Hoe en in welk kader worden PHP-beveiligingsupdates ingespeeld en herstart? | PHP2Shell heeft getoond hoe belangrijk een aantoonbaar proces is |
| Bewijs | Krijg ik op verzoek een schriftelijke bevestiging van de patchstand? | Basis voor uw eigen documentatie |
| PHP-versies | Welke takken worden aangeboden, hoe lang nog? | Oude takken zonder updates zijn een blijvend risico |
| Scheiding | Draait elke website met een eigen gebruiker en een eigen PHP-proces? | Beperkt schade als een buur wordt aangevallen |
| Logs | Heb ik toegang tot toegangs- en foutlogs, hoe lang worden ze bewaard? | Zonder logs geen opheldering |
| Back-ups | Hoe vaak, hoe lang, gescheiden van de webserver, met herstelproef? | Herstel na een incident |
| Noodcontact | Hoe bereik ik bij een incident een deskundig persoon? | Tijd is in een noodgeval de schaarsste factor |
| Verwerking | Is er een overeenkomst conform de AVG en een lijst van subverwerkers? | Verplicht bij persoonsgegevens |
Een sjabloon voor de vraag naar de patchstand biedt de gids De hoster naar de patchstatus vragen. Ze is ook geschikt om aanbieders te vergelijken vóór het sluiten van een contract.
Is een ander bedrijfsmodel het betere antwoord?
Soms ligt het probleem minder bij de hoster dan bij het bedrijfsmodel. Wie een eigen server zonder regelmatig onderhoud draait, is vaak beter af met een goed beheerd managed-aanbod. Omgekeerd kan een bedrijf met eigen IT meer controle over patchtijdstippen winnen als het zelf beheert. De afweging beschrijft het artikel Managed hosting of eigen server?.
Los van het model geldt: leg de taakverdeling schriftelijk vast. Wie speelt PHP-updates in, wie herstart, wie controleert de applicatie, wie neemt bij nood contact op met wie? Bij PHP2Shell zijn veel vertragingen precies op dit punt ontstaan, omdat elke partij dacht dat de andere het regelde.
Hoe helpt PHP SOS concreet?
- Wij stellen logs en data van het oude systeem veilig en brengen in kaart wat er bij het incident is gebeurd.
- Wij bouwen het nieuwe systeem geharded op en dragen alleen gecontroleerde inhoud uit schone bronnen over.
- Wij beoordelen aanbiedingen van nieuwe aanbieders aan de hand van de veiligheidscriteria en stellen de juiste vragen.
- Bij een lopend incident werken wij in het kader van onze incident response totdat het incident is afgerond en gedocumenteerd.
Veelgestelde vragen
Moet ik na een hack meteen van hoster wisselen?
Niet meteen. Eerst moeten sporen worden veiliggesteld, het incident worden afgebakend en de oorzaak worden opgehelderd. Een overhaaste verhuizing neemt mogelijk schadelijke code mee en kan bewijs bij de oude aanbieder vernietigen.
Was de hoster schuldig als mijn website via PHP2Shell is aangevallen?
Dat hangt af van het contract en het tijdstip. Bij shared hosting is meestal de hoster verantwoordelijk voor PHP-updates, bij eigen servers de exploitant. De patches verschenen op 21 oktober 2026; of en wanneer ze zijn ingespeeld, is alleen met bewijzen vast te stellen. Voor aansprakelijkheidskwesties raadpleegt u een advocaat.
Welke data mag ik naar de nieuwe hoster meenemen?
Alleen gecontroleerde inhoud: de database na controle op ingeslopen code, media zonder uitvoerbare bestanden en code uit een schone bron zoals het pakket van de fabrikant of uw versiebeheersysteem. Complete serverimages of webmappen van het gecompromitteerde systeem moet u niet ongecontroleerd overdragen.
Moet ik na een incident de gegevensbescherming erbij betrekken?
Als persoonsgegevens getroffen kunnen zijn, kan er een meldplicht bestaan volgens de AVG, in de regel binnen 72 uur. Bij de nieuwe hoster hebt u bovendien een verwerkersovereenkomst nodig. Stem dit af met uw functionaris voor gegevensbescherming; dit is geen juridisch advies.