De malware is weg, de site staat er weer en de schrik zakt. Precies op dat moment stopt bij veel bedrijven het traject, en precies daar gaat het mis. Website hardening na een hack is het deel dat bepaalt of u over drie maanden opnieuw aan de bak moet, want de gemiddelde besmette site die alleen wordt schoongemaakt, is binnen een halfjaar terug bij af.
Deze checklist loopt de punten langs die na een opschoning horen te gebeuren. Reken op een dagdeel werk. Dat klinkt veel, maar het is aanzienlijk minder dan het tweede herstel dat u ermee voorkomt.
Eerst: weet u hoe men binnenkwam?
Dit is de vraag die alles bepaalt. Kunt u hem niet beantwoorden, dan timmert u een muur dicht terwijl de deur openstaat.
Kijk in de serverlogboeken naar het tijdstip waarop het eerste vreemde bestand is aangemaakt en zoek de verzoeken van daarvoor. In de meeste gevallen ziet u dan een reeks pogingen op een specifieke plugin, of een geslaagde inlog vanaf een adres dat er niet hoort. Blijkt de ingang een verouderde plugin, dan hoeft die plugin niet alleen bijgewerkt maar wat ons betreft vervangen als hij al langer achterloopt.
Vindt u niets, ga dan uit van het slechtste scenario: alle wachtwoorden zijn bekend en alle bestanden waren leesbaar. Handel daar de rest van de lijst naar af.
Toegang: de belangrijkste laag
- Vervang alle wachtwoorden van beheerders, database, FTP, SSH en het hostingpaneel. Doe dat vanaf een computer waarvan u zeker weet dat hij schoon is.
- Vervang de beveiligingssleutels in het configuratiebestand. Zonder die stap blijven bestaande sessies gewoon geldig, ook die van de aanvaller.
- Loop de gebruikerslijst na op accounts die u niet kent en op accounts die stilletjes beheerdersrechten hebben gekregen.
- Verlaag rollen waar dat kan. Wie alleen teksten aanpast, hoeft geen beheerder te zijn. Welke rol wat mag, staat in het overzicht van gebruikersrollen in WordPress.
- Zet tweestapsverificatie verplicht aan voor elke beheerder. Geen uitzonderingen, ook niet voor uzelf.
- Beperk het aantal inlogpogingen per gebruikersnaam en per IP-adres.
- Trek toegang in van partijen die u niet meer gebruikt, zoals een vorig bureau of een marketeer die ooit een pixel plaatste.
Bestanden en server
- Blokkeer het uitvoeren van PHP in de uploadmap. Dit is de maatregel die de meest gebruikte achterdeur onbruikbaar maakt.
- Zet het bewerken van bestanden vanuit het beheerscherm uit. Eén regel in het configuratiebestand, en hij haalt een populaire route naar codewijzigingen weg.
- Controleer de bestandsrechten. Mappen op 755, bestanden op 644, en het configuratiebestand strenger. Staat er ergens 777, dan is dat een gat.
- Verwijder alles wat u niet gebruikt. Inactieve plugins en ongebruikte thema’s zijn nog steeds uitvoerbare code op uw server.
- Zorg dat de PHP-versie actueel is. Een verouderde versie krijgt geen beveiligingsupdates meer; wat de overstap inhoudt staat bij het bijwerken van de PHP-versie.
- Vraag uw hostingpartij om de omgeving te controleren, zeker bij gedeelde hosting waar andere sites de bron kunnen zijn.
Bewaking: zodat u het de volgende keer binnen een dag weet
Het verschil tussen een klein en een groot incident is bijna altijd de tijd tussen besmetting en ontdekking. Vier voorzieningen die dat verkorten.
- Controle op gewijzigde kernbestanden, met een melding zodra er iets verandert dat u niet zelf heeft gedaan.
- Een dagelijkse scan op bestanden en database, waarvan de uitkomst ergens terechtkomt waar iemand hem leest.
- Meldingen bij nieuwe beheerders en bij rolwijzigingen. Dit is het signaal dat het snelst iets zegt.
- Google Search Console gekoppeld, zodat u het hoort als er beveiligingsproblemen worden gevonden of als het aantal geïndexeerde pagina’s plotseling stijgt.
Zet daarnaast een externe controle op bereikbaarheid, zodat u ook hoort wanneer de site eruit ligt in plaats van dat een klant belt.
Back-ups, nu echt
Na een incident blijkt bijna altijd dat de back-upsituatie zwakker was dan gedacht. Drie punten die u nu regelt.
Bewaar back-ups buiten de webserver. Staat de kopie in een map op dezelfde server, dan is hij bij een inbraak net zo goed besmet of verwijderd. Bewaar daarnaast meer historie dan een week: bij een stille besmetting ontdekt u het pas na een maand, en dan heeft u een kopie van vóór die maand nodig.
En het punt dat het vaakst wordt overgeslagen: test één keer een terugzetting op een testomgeving. Een back-up waarvan nooit is teruggezet, is een aanname en geen voorziening.
Noteer daarbij ook hoe lang zo’n terugzetting duurt. Bij een webshop van vijf gigabyte praat u al snel over anderhalf uur, en dat getal wilt u kennen voordat u het nodig heeft in plaats van erna. Zet die uitkomst bij uw noodplan, samen met de vraag welke gegevens u kwijt bent als u naar de kopie van gisternacht teruggaat. Bij een webshop met bestellingen is dat antwoord zelden acceptabel, en dan is een frequentere kopie van alleen de database de logische aanvulling.
Wat er niet op deze lijst hoort
Nuance, want er wordt na een hack vaak overdreven ingegrepen. Het verbergen van uw inlogpagina achter een geheim adres helpt tegen geautomatiseerd geraas, maar niet tegen een gerichte aanval, en het levert bij bedrijven met meerdere gebruikers geregeld gedoe op. Het blokkeren van hele landen kan werken, maar houdt ook klanten en diensten buiten. En het stapelen van drie beveiligingsplugins maakt uw site langzamer zonder hem veiliger te maken.
De maatregelen die daadwerkelijk het verschil maken zijn saaier: actuele software, unieke wachtwoorden met tweestapsverificatie, weinig accounts met veel rechten, en snelle signalering. Al het andere is aanvulling.
Wilt u dit niet zelf bijhouden, dan hoort deze hele lijst bij een traject rond het herstellen en daarna afschermen van een gehackte site. Bij WebMaintor leveren wij zo’n traject pas op als de ingang aantoonbaar dicht is, niet als de site het weer doet.
Concrete volgende stap: controleer vandaag of het uitvoeren van PHP in uw uploadmap geblokkeerd is. Dat ene punt sluit de meest gebruikte achterdeur en kost uw beheerder vijf minuten.



