WordPress beveiligen: de volgorde waarin het loont

Wie zoekt op ‘WordPress beveiligen’, vindt lijsten met twintig punten. Het probleem daarvan is niet dat de punten fout zouden zijn, maar dat ze met hetzelfde gewicht naast elkaar staan. De eerste drie leveren meer op dan de overige zeventien samen.

Plaats 1: updates, en wel tijdig

De meeste overgenomen sites zijn niet het slachtoffer van een uitgekiende aanval, maar van een bekend lek in een plugin waarvoor al weken een update bestaat. Geautomatiseerde massascans zoeken precies daarnaar.

In de praktijk betekent dat: beveiligingsupdates automatisch, functie-updates handmatig na een korte controle — en vóór elke update een back-uppunt, zodat de angst voor de update geen reden wordt om die uit te stellen.

Een plugin die al twee jaar geen update heeft gekregen, is een risico, ook als hij werkt. Ruim meteen op: wat niet wordt gebruikt, hoort verwijderd te worden, niet gedeactiveerd.

Plaats 2: de login

De op één na meest voorkomende deur is een wachtwoord. Vier maatregelen, in deze volgorde:

1. Mislukte pogingen beperken — dat haalt de basis onder geautomatiseerde raadpogingen weg.
2. Wachtwoordsterkte afdwingen, in elk geval voor iedereen die mag publiceren.
3. Tweede factor inschakelen, minstens voor beheerders.
4. Geen account met de gebruikersnaam ‘admin’, en geen rol hoger dan nodig.

Het inlogadres verplaatsen is een vijfde punt, maar een zwakker: het houdt massascans weg en bespaart belasting, maar vervangt geen van de vier maatregelen hierboven. Wie het gebruikt, moet het nieuwe adres noteren voordat hij opslaat.

Plaats 3: hardening — één keer instellen, daarna vergeten

• Bestandsbewerking in de backend uitschakelen — daar wordt schadelijke code het liefst neergezet
• XML-RPC uitschakelen als niets het nodig heeft
• Directorylisting voorkomen
• PHP-uitvoering in de uploadsmap blokkeren
• Gebruikersenumeratie via de REST API beperken
• Beveiligingsheaders instellen

Deze schakelaars kosten niets tijdens gebruik en sluiten elk een bekende sluiproute af. Ze hebben de beste verhouding tussen moeite en opbrengst van de hele lijst.

Plaats 4: zien wat er verandert

Vanaf hier gaat het niet meer om voorkomen, maar om opmerken. Twee dingen lonen:

De core-vergelijking vergelijkt de WordPress-bestanden met de checksums van api.wordpress.org. Een gewijzigd corebestand is een heel duidelijk teken — daar heeft niemand een legitieme reden om iets te veranderen.

De bestandswachter legt een stand vast en meldt afwijkingen. Hij is maar zo goed als het moment waarop die stand is vastgelegd: een stand die na een infectie is vastgelegd, verklaart de schadelijke code tot normale toestand.

Leg de stand vast zolang de site aantoonbaar schoon is — het best direct na een verse installatie of na een gecontroleerd herstel.

Plaats 5: firewall en scan

Beide zijn zinvol en beide staan hier bewust onderaan. Een firewall in PHP draait pas als WordPress al opstart — hij vervangt geen firewall vóór de webserver. Een scan vindt wat op zijn patronen lijkt, niet alle schadelijke code.

Belangrijker dan het aantal regels is de omgang met vals alarm. Een tool waarvan het overzicht permanent rood is, beschermt niets meer — hij traint het wegklikken. Laat de firewall daarom eerst een week alleen melden en loop het logboek door voordat je hem laat blokkeren.

Wat vaak helemaal bovenaan staat en daar niet thuishoort

Het punt dat bijna alle lijsten vergeten

Een beveiligingsplugin voorkomt incidenten, een back-up overleeft ze. Wie tussen die twee zou moeten kiezen, moet de back-up nemen — het is de enige maatregel die ook dan nog helpt als alle andere hebben gefaald.

Veelgestelde vragen