Kort gezegd: Na de waarschuwing voor PHP2Shell werden in Duitsland websites uitgeschakeld, volgens media onder meer het webportaal van de stad Mainz en sites van de deelstaatregering van Hessen en van het BKA (de Duitse federale recherche). Het ging om voorzorg op advies van het BSI (de Duitse federale dienst voor informatiebeveiliging), niet om bevestigde aanvallen. Bedrijven kunnen hieruit leren: uitschakelen is een legitieme optie als een patch niet direct mogelijk is, en het lukt het best als het is voorbereid.
Websites vanwege PHP uitgeschakeld: wat er op 21 oktober gebeurde
Op de dag van de PHP-beveiligingsupdates waren in Duitsland tal van openbare websites niet bereikbaar. Volgens mediaberichten heeft de stad Mainz haar centrale webportaal preventief uitgeschakeld. Gemeentelijke diensten bleven telefonisch en per e-mail bereikbaar.
In Hessen waren volgens hessenschau onder meer sites van de deelstaatregering, van het Bundeskriminalamt en van de steden Kassel en Wiesbaden tijdelijk offline. De Staatskanzlei sprak van technische aanpassingen en meldde geen aanval. De deelstaatsites waren 's avonds weer bereikbaar. Andere gemeenten, hogescholen en klinieken haalden volgens berichten eveneens aanbod preventief van het net.
Achtergrond is het advies van het BSI over PHP2Shell: direct updaten en, als dat niet meteen lukt, getroffen webservers tijdelijk van het net halen. Wat het BSI in detail adviseert, vat de pagina Wat het BSI over PHP2Shell adviseert samen.
Uitgeschakeld betekent niet gehackt
In commentaren en op sociale netwerken werd van „offline” snel „gehackt”. Dat is volgens alles wat bekend is onjuist. De uitschakelingen waren een beschermende maatregel op een moment dat veel beheerders de patchstatus van hun servers nog niet zeker kenden.
Voor bedrijven is dit onderscheid dubbel belangrijk. Ten eerste naar buiten: wie zelf preventief uitschakelt, moet dat zo benoemen en niet zwijgen. Ten tweede naar binnen: een uitschakeling beantwoordt niet de vraag of de server eerder is aangevallen. Ze stopt alleen verdere pogingen. De controle op sporen blijft nodig.
Een derde punt wordt vaak over het hoofd gezien: een uitschakeling mag geen sporen vernietigen. Wie de server om uit te schakelen gewoon opnieuw installeert of logs verwijdert om ruimte te maken, ontneemt zichzelf de mogelijkheid later na te gaan wat er vóór de uitschakeling gebeurde. Beter is het de webserver naar een noodpagina om te leiden of de toegang van buitenaf te blokkeren en de server zelf met alle logs ongewijzigd te laten.
Waarom juist openbare instanties zo reageerden
Overheden beheren vaak veel websites naast elkaar: hoofdportaal, vakportalen, formulierendiensten, sites van afzonderlijke afdelingen en instellingen. Vaak zijn daarbij meerdere dienstverleners betrokken. Op de dag van de waarschuwing was het voor veel overheden eenvoudig niet mogelijk om binnen enkele uren voor elk systeem een bewezen patchstatus te krijgen. De preventieve uitschakeling was in die situatie de snelste manier om het BSI-advies op te volgen.
Voor bedrijven met een historisch gegroeid IT-landschap is de situatie vaak vergelijkbaar. De vraag „Is alles gepatcht?” strandt niet op de techniek, maar op het ontbreken van overzicht.
Opmerkelijk is ook hoe snel de Hessische deelstaatsites volgens berichten terugkwamen: nog dezelfde avond. Dat laat zien dat een preventieve uitschakeling niet dagenlang hoeft te duren. Wie zijn systemen kent en de updateroute beheerst, kan in enkele uren patchen, controleren en weer online gaan. De uitschakeling overbrugt dan alleen de tijd tot er duidelijkheid is.
Wanneer een preventieve uitschakeling voor bedrijven zinvol is
Overheden hebben een bijzondere situatie: veel websites, vaak verspreid beheerd, en grote openbare zichtbaarheid. De afweging waarvoor ze stonden, is echter dezelfde als in elk bedrijf. Het volgende overzicht helpt bij de beslissing:
| Situatie | Eerder uitschakelen | Eerder online laten |
|---|---|---|
| Patchstatus | onduidelijk of niet bevestigd | verholpen en bewezen, processen herstart |
| PHP-versie | 8.1 of ouder zonder bevestigde backport | ondersteunde tak op actuele stand |
| Uitvoeringsmodus | Apache met mod_php | gepatcht PHP-FPM met ingestelde tussentijdse maatregelen |
| Gegevens op de server | klantgegevens, logins, betaalgegevens | uitsluitend statische inhoud |
| Bereikbaarheid van de dienstverlener | patch pas over dagen mogelijk | patch binnenkort gepland |
De afweging tussen patchen, uitschakelen en afwachten verdiept de bijdrage Patchen, uitschakelen of afwachten?. Wat technisch als overbrugging mogelijk is als de update nog ontbreekt, staat onder Directe maatregelen zonder patch.
Een webshop of klantenportaal tijdelijk uitschakelen kost omzet. Een gecompromitteerde server met klantgegevens kan aanzienlijk meer kosten, tot en met meldplichten. Neem de beslissing bewust en leg haar schriftelijk vast.
Zo bereidt u een uitschakeling voor
Mainz liet zien waar het op aankomt: de gemeente bleef via andere kanalen bereikbaar. Dat lukt alleen als het is voorbereid. Deze stappen lonen voordat de volgende noodsituatie komt:
- Noodpagina klaar hebben: een statische HTML-pagina zonder PHP, met een korte uitleg, telefoon- en e-mailcontact en, indien nodig, aanwijzingen over lopende bestellingen of afspraken.
- Omschakelroute vastleggen: Wie kan de website naar de noodpagina omleiden, via webserver, DNS of een voorgeschakelde dienst? Hoe lang duurt dat?
- Beslissingsbevoegdheid regelen: Wie mag een uitschakeling gelasten, ook buiten kantooruren?
- Afhankelijke diensten kennen: Hangen koppelingen, apps of partners aan de website? Wie moet vooraf worden geïnformeerd?
- Criteria voor de terugkeer definiëren: patch aangetoond, herstart uitgevoerd, eerste sporencontrole zonder bevinding.
- Boodschap vooraf formuleren: twee tot drie zinnen voor klanten, partners en pers.
Hoe u in zo'n situatie naar buiten communiceert, beschrijft de gids over crisiscommunicatie.
Hoe helpt PHP SOS concreet?
- Beslisgrondslag: Wij stellen patchstatus, uitvoeringsmodus en gegevenssituatie van uw servers vast en geven u een duidelijke inschatting of uitschakelen geboden is.
- Geordende uitschakeling: Wij schakelen om naar een statische noodpagina zonder logs of sporen te verliezen.
- Patch en controle: Wij werken PHP bij, herstarten alle processen en controleren op bijzonderheden.
- Gecontroleerde terugkeer: Wij brengen de website pas weer online als de afgesproken criteria zijn vervuld en gedocumenteerd.
Het verloop beschrijft de PHP2Shell-noodhulp.
Conclusie
De uitschakelingen door overheden waren geen teken van controleverlies, maar een bewuste voorzorgsmaatregel. Voor bedrijven is dat de eigenlijke les: offline gaan is een legitieme beslissing als de patchstatus onduidelijk is. Wie noodpagina, verantwoordelijkheid en terugkeercriteria heeft voorbereid, neemt haar in minuten in plaats van uren.
Veelgestelde vragen
Waarom werden overheidswebsites vanwege PHP uitgeschakeld?
Het BSI adviseert bij PHP2Shell de directe update en, als die niet meteen mogelijk is, de webservers tijdelijk van het net te halen. Meerdere overheden hebben dit advies preventief opgevolgd, tot hun systemen waren gecontroleerd en bijgewerkt.
Betekent een uitgeschakelde website dat ze is gehackt?
Nee. Een preventieve uitschakeling is een beschermende maatregel. De Hessische Staatskanzlei meldde volgens hessenschau bijvoorbeeld uitdrukkelijk geen aanval. Of een server vóór de uitschakeling getroffen was, blijkt pas uit een controle.
Hoe lang moet een website offline blijven?
Tot PHP op een verholpen stand is, alle PHP-processen zijn herstart en een eerste controle op sporen geen bijzonderheden heeft opgeleverd. Een vaste duur bestaat niet; de Hessische deelstaatsites waren volgens berichten dezelfde avond weer bereikbaar.
Wat toon ik bezoekers terwijl de website offline is?
Het best een eenvoudige, statische noodpagina zonder PHP met een korte uitleg en de contactwegen waarlangs u bereikbaar blijft. Ze moet klaarstaan voordat ze nodig is.