Controleer of mijn WordPress-site gehackt of kwetsbaar is: corebestanden,
PHP-bestanden in uploads, verdachte code, onbekende beheerders, verouderde
plugins met bekende lekken. Leg in gewone taal uit wat je vindt en wat je
aanraadt. Verander nog niets.
Op je hostingaccount staat een controle die in één keer de plekken nakijkt waar een WordPress-hack zich meestal verstopt. De assistent gebruikt hem als je vraagt of je site veilig is. Hij leest alleen en verandert niets, dus je kunt hem zo vaak draaien als je wilt.
Belangrijk om vooraf te weten: de uitkomst is een lijst signalen, geen bewijs. Sommige signalen hebben een onschuldige verklaring. Dit artikel loopt ze langs, zodat je weet wat je ziet.
1. Kloppen de corebestanden nog?
De bestanden van WordPress zelf worden vergeleken met de officiële versies van wordpress.org, bestand voor bestand. Een verschil betekent dat er iets in een corebestand is veranderd of dat er een bestand bij is gezet dat er niet hoort.
Dit is het sterkste signaal in de hele lijst. WordPress-bestanden horen exact te kloppen. Een hacker die een backdoor in een corebestand zet, valt hier altijd door de mand.
Onschuldige verklaring: een afgebroken update. Dan ontbreken er bestanden in plaats van dat er bestanden bij staan.
2. PHP-bestanden in je uploadmap
In wp-content/uploads horen afbeeldingen en documenten. Geen PHP. Een PHP-bestand daar is bijna nooit onschuldig, want het is de makkelijkste plek om iets te uploaden en daarna aan te roepen.
Vind je er een, dan heb je waarschijnlijk de ingang van de hack gevonden. Verwijder hem niet meteen: eerst een backup, dan pas opruimen, en kijk in je logbestanden wie hem heeft opgevraagd.
3. Wat staat er in mu-plugins?
De map wp-content/mu-plugins bevat plugins die altijd actief zijn en die je in het beheerpaneel niet kunt uitschakelen. Ideaal voor een hacker, want in je pluginlijst zie je er niets van.
De controle laat zien wat er staat. Hij zegt niet of het goed of fout is, want sommige hostingpartijen en sommige beveiligingsplugins zetten hier legitiem iets neer. De vraag is dus: ken ik deze bestanden? Zo niet, dan zoek je uit waar ze vandaan komen voordat je iets weggooit.
4. De eerste regels van index.php en wp-config.php
Deze twee bestanden worden bij elk bezoek uitgevoerd, dus ze zijn favoriet bij aanvallers. De controle kijkt naar het begin van beide bestanden en zoekt daar naar functies die code uitvoeren die ergens anders vandaan komt.
Staat daar iets, dan zie je het begin van de regel in de uitvoer. Een gewone index.php van WordPress is drie regels commentaar en één regel code. Alles wat er langer of ingewikkelder uitziet, hoort er niet.
5. Typische backdoor-patronen in al je bestanden
Daarna gaat de controle door alle PHP-bestanden van je site en zoekt de combinaties die bijna uitsluitend in kwaadaardige code voorkomen: code die versleutelde of ingepakte tekst uitvoert, code die uitvoert wat er in een webverzoek wordt meegestuurd, en varianten waarbij de functienaam zelf is verstopt achter tekencodes.
De cachemap wordt overgeslagen, want daar staat gegenereerde rommel die vals alarm geeft.
6. Welke PHP-bestanden zijn de laatste drie dagen gewijzigd?
Een hack verandert bestanden, en die wijziging heeft een datum. De controle telt hoeveel PHP-bestanden in drie dagen zijn aangepast en laat daarna specifiek de bestanden zien die buiten de normale plekken staan: niet in plugins, niet in thema's, niet in de WordPress-mappen.
Dit signaal moet je in context lezen. Heb je net updates gedraaid, dan is een hoog aantal normaal. Een gewijzigd bestand op een rare plek, terwijl je weken niets hebt gedaan, is dat niet.
7. Wie zijn je beheerders?
Alle accounts met beheerrechten komen in de lijst, met de datum waarop ze zijn aangemaakt. Daarna volgt een apart signaal voor beheerders die in de afgelopen veertien dagen zijn toegevoegd.
Dat is het signaal waar je even bij moet gaan zitten. Een onbekende beheerder is een probleem, maar een bekende naam kan ook zijn aangemaakt door iemand die legitiem meekijkt. Bel of mail degene die je site beheert voordat je accounts verwijdert.
8. Databasetriggers
Dit is de stille. Een trigger in de database is een stukje logica dat automatisch iets doet bij een wijziging in een tabel. WordPress gebruikt die niet. Sommige backdoors wel, bijvoorbeeld om bij elke nieuwe reactie opnieuw een beheerder aan te maken.
Dat is precies waarom een site soms terugkomt nadat alle bestanden zijn opgeschoond. Je hebt de bestanden gehad en de database niet. Staat er een trigger, dan zie je hem hier.
9. Staan je adressen nog goed?
Tot slot worden de twee adressen uit je instellingen getoond: het adres van de site en het adres van de voorpagina. Staat daar een domein dat jij niet kent, dan is dat de verklaring voor bezoekers die ergens anders uitkomen.
Wat de uitkomst betekent
Onderaan staat één regel. Of er zijn geen verdachte signalen gevonden, of er zijn er wel en dan is het advies om contact op te nemen met je hostingpartij voordat je gaat opruimen.
Dat advies staat er met een reden. Opruimen in de verkeerde volgorde maakt het lastiger. Wordt de ingang verwijderd voordat iemand heeft gekeken hoe hij werd gebruikt, dan weet je niet of hij ergens anders ook zit.
Wat je zelf doet
Eerst een backup, altijd. Ook van een besmette site. Dat is je bewijsmateriaal en je vangnet.
Daarna de wachtwoorden. WordPress-beheerders, je hostingaccount, de database, FTP en elk mailadres waarmee je een wachtwoord kunt herstellen. Een hack die terugkomt, komt vaak terug via een wachtwoord dat nog klopt.
Daarna de versies. Verouderde plugins zijn de meest gebruikte ingang. Werk ze bij, bij voorkeur met een momentopname vooraf, zie WordPress veilig updaten.
En zet de controle periodiek in. Je kunt de assistent vragen om hem maandelijks te draaien en je alleen te mailen als er iets uitkomt. Op de prompts-pagina staat een voorbeeld van zo'n rapport.
Veelgemaakte fouten
Signalen lezen als bewijs. Een gewijzigd corebestand na een afgebroken update is geen hack. Lees altijd de verklaring erbij.
Geen signalen lezen als "ik ben veilig". De controle kijkt naar bekende patronen in bestanden en op een paar plekken in de database. Een nette, nieuwe backdoor kan erdoorheen glippen. Combineer met updates bijhouden en met kijken naar wat je site doet.
Meteen alles weggooien. Verwijder je de ingang zonder te kijken, dan weet je niet wat er is gebeurd en kom je er over een maand opnieuw achter.
Alleen bestanden opschonen. Zie punt 8. De database hoort erbij, inclusief triggers en geplande taken.
De controle draaien op een site die al plat ligt. Dan werkt hij niet goed, want hij heeft WordPress nodig om naar je beheerders en je instellingen te kijken. Zorg eerst dat de site weer start, dan controleren.