Een gehackte website voelt als een noodgeval, en dat is het ook. Toch maak je in de eerste uren vaak de meeste fouten: je wist sporen, je zet een besmette back-up terug of je vergeet een wachtwoord dat de aanvaller nog kent. Dit stappenplan helpt je rustig en in de goede volgorde te werken. Het is geschreven voor developers en webbureaus, met extra tips voor Laravel-sites.
Stap 1: stel vast wat er aan de hand is
Niet elke vreemde melding is een hack. Kijk eerst wat je ziet:
- De site toont andere inhoud, reclame of een melding van de aanvaller.
- Bezoekers worden doorgestuurd naar een andere site, soms alleen vanaf Google of alleen op mobiel.
- Google of de browser waarschuwt dat de site misleidend of schadelijk is.
- Er staan onbekende gebruikers, bestanden of geplande taken op de server.
- Je hostingpartij heeft de site of het account geblokkeerd.
Leg vast wat je ziet, met screenshots en tijdstippen. Die heb je later nodig voor je analyse, voor de klant en eventueel voor een melding.
Stap 2: beperk de schade
Zorg dat de aanvaller niet verder kan en dat bezoekers geen schade oplopen:
- Zet de site offline of in onderhoudsmodus. In Laravel kan dat met
php artisan down. Werkt de applicatie zelf niet meer betrouwbaar, laat de webserver dan een statische pagina tonen. - Blokkeer toegang die je niet vertrouwt. Schakel onbekende gebruikersaccounts uit en beperk SSH- en beheertoegang tot bekende IP-adressen.
- Verwijder nog niets. Bestanden en logs die de aanvaller achterliet zijn je belangrijkste bron om de oorzaak te vinden.
Stap 3: stel bewijs veilig
Maak een kopie van de huidige situatie voordat je iets herstelt:
- De bestanden op de server, inclusief verborgen bestanden.
- Een dump van de database.
- Webserverlogs, applicatielogs en de logs van je hostingpartij.
Bewaar deze kopie apart en zet hem nooit terug. Hij is bedoeld om te onderzoeken, niet om te herstellen.
Stap 4: wijzig alle wachtwoorden en sleutels
Ga ervan uit dat alles wat op de server stond bekend is bij de aanvaller. Vervang daarom:
- Wachtwoorden van de database, SSH, FTP, het hostingpaneel en beheerdersaccounts.
- API-sleutels van externe diensten, zoals betaalproviders, mailproviders en opslag.
- In Laravel de
APP_KEY. Zet de oude sleutel inAPP_PREVIOUS_KEYS, zodat versleutelde data nog te lezen is terwijl je die opnieuw versleutelt. - Sessies en tokens van gebruikers, zodat niemand ingelogd blijft met een gestolen sessie.
Doe dit vanaf een apparaat waarvan je zeker weet dat het schoon is.
Stap 5: vind de oorzaak
Herstellen zonder de oorzaak te kennen betekent dat de aanvaller morgen terug is. Veelvoorkomende oorzaken:
- Verouderde software, zoals een oude Laravel- of PHP-versie of een package met een bekende kwetsbaarheid. Draai
composer auditom dat snel te zien. - Gelekte inloggegevens, bijvoorbeeld een wachtwoord dat ook op een andere site gebruikt werd.
- Fouten in eigen code, zoals SQL-injectie, onveilige file uploads of ontbrekende autorisatie.
- Een openbaar
.env-bestand of debugmodus in productie.
Zoek in je logs naar ongebruikelijke requests rond het moment van de hack. Vergelijk de bestanden op de server met je Git-repository: git status en git diff laten direct zien wat er gewijzigd of toegevoegd is. Controleer ook de crontab en geplande taken, want daar verstoppen aanvallers graag een manier om terug te komen.
Stap 6: herstel naar een schone situatie
Herstel niet door losse bestanden op te schonen. Zet de site opnieuw neer:
- Deploy de code opnieuw vanuit je repository, op een schone server of in een schone map.
- Installeer dependencies opnieuw met
composer installen werk ze bij waar nodig. - Zet een database-back-up terug van voor het moment van de hack, of schoon de huidige database handmatig op.
- Dicht het lek dat je in stap 5 vond.
- Zet de nieuwe wachtwoorden en sleutels in de configuratie.
Weet je niet zeker wanneer de aanvaller binnenkwam, ga dan verder terug in je back-ups. Een back-up van gisteren kan al besmet zijn.
Stap 7: bepaal of je een datalek moet melden
Kan de aanvaller persoonsgegevens hebben ingezien of gekopieerd, zoals klantgegevens, e-mailadressen of bestellingen? Dan is er mogelijk sprake van een datalek volgens de AVG.
- De verwerkingsverantwoordelijke, meestal je klant, moet een datalek binnen 72 uur na ontdekking melden bij de Autoriteit Persoonsgegevens, tenzij het lek waarschijnlijk geen risico oplevert voor de betrokkenen.
- Is het risico hoog, dan moeten ook de betrokkenen zelf geïnformeerd worden.
- Ben jij als bureau de verwerker, dan moet je je klant zonder onnodige vertraging informeren. Kijk in je verwerkersovereenkomst welke termijn jullie hebben afgesproken.
Valt de organisatie onder de Cyberbeveiligingswet, dan gelden voor significante incidenten aparte meldplichten bij het NCSC, met een eerste waarschuwing binnen 24 uur. Lees daarover meer in ons artikel over NIS2 en de Cyberbeveiligingswet voor webbureaus.
Stap 8: zet de site weer online en communiceer
- Controleer de site grondig voordat je hem online zet.
- Staat de site bij Google gemarkeerd als onveilig, vraag dan via Google Search Console een nieuwe beoordeling aan nadat je alles hebt opgeschoond.
- Informeer je klant met een kort, eerlijk incidentrapport: wat er gebeurde, wat de impact was, wat je hebt gedaan en wat je doet om herhaling te voorkomen. Gebruik ons gratis incidentrapport-template als basis.
Stap 9: voorkom de volgende keer
De meeste hacks zijn te voorkomen met een paar vaste gewoontes:
- Houd Laravel, PHP en packages up-to-date, en draai
composer auditin je CI. - Gebruik tweestapsverificatie voor alle beheertoegang.
- Maak dagelijks back-ups, bewaar ze buiten de server en test of je ze kunt terugzetten.
- Monitor je sites. Een site die onverwacht andere statuscodes geeft, een piek in fouten of een verlopen certificaat zijn vaak de eerste signalen dat er iets mis is.
nopanic helpt webbureaus daarbij: uptime, errors, certificaten en kwetsbare code van al je Laravel-sites in één overzicht, gehost in de EU. Zo zie je het als er iets misgaat, voordat je klant belt.