Geavanceerde WordPress-hardening

Inleiding: verharden is niet toevoegen, het is weghalen

Hardening wordt bijna altijd gepresenteerd als een lijst dingen die u moet installeren. Het is precies andersom. Een systeem verharden betekent verkleinen wat het kan doen, en de meeste maatregelen op deze pagina vragen geen enkel extra programma.

Het ene principe waaruit ze allemaal volgen:

u beschermt zich niet tegen een onbekend lek, u verkleint wat dat lek kan bereiken.

Dit artikel gaat ervan uit dat de basis er staat — sterke wachtwoorden, tweefactorauthenticatie, bijgewerkte software, geteste back-ups. Is dat niet zo, begin dan met de beveiligingsaudit in 10 minuten.

1. De uitvoering — de maatregel die de grootste familie aanvallen onschadelijk maakt

Verbied PHP-uitvoering in de uploadmap. Eén enkele regel in de serverconfiguratie, en die maakt een hele klasse kwetsbaarheden onschadelijk: die waarbij een aanvaller erin slaagt een bestand neer te zetten en het vervolgens aan te roepen.

Het is de maatregel met de beste verhouding tussen inspanning en effect uit deze hele lijst, en hij ontbreekt nog steeds in de meeste installaties omdat hij vanaf het WordPress-dashboard niet zichtbaar is.

Verbied het bewerken van bestanden vanuit het beheer (DISALLOW_FILE_EDIT). Een gecompromitteerd beheerdersaccount kan dan geen code meer schrijven vanuit de browser. Dat voorkomt de inbraak niet: het voorkomt dat de inbraak volledige controle wordt.

Schakel het installeren van plugins vanuit het beheer uit op sites waar uitrol via een ander kanaal loopt (DISALLOW_FILE_MODS). Dat is strenger en past niet bij elke werkwijze — maar waar het past, sluit het de belangrijkste weg naar persistentie.

2. De rechten — precies, niet ruimhartig

De regel is niet "zo streng mogelijk", maar "schrijfrechten alleen waar ze nodig zijn".

• Configuratiebestanden hoeven bij normaal gebruik niet beschrijfbaar te zijn voor de webserver.
• De uploadmap heeft schrijfrechten nodig; de pluginmap niet, behalve tijdens een update.
• Eén te ruim recht op één enkele map doet de strengheid van alle andere teniet.

⚠ De veelgemaakte fout: zeer strenge rechten instellen, ze dan "tijdelijk" versoepelen om een update mogelijk te maken — en het vergeten. Noteer de datum wanneer u dat doet; alleen zo wordt het ooit weer aangehaald.

3. De capaciteiten — het punt waar bijna niemand naar kijkt

WordPress kent capaciteiten toe per rol, en de meeste sites gebruiken de standaardrollen zonder ze ooit na te lopen.

Drie vragen die bijna altijd iets aan het licht brengen:

1. Hoeveel beheerdersaccounts zijn er? Op de meeste sites meer dan nodig. Elk daarvan is een volledige sleutel.
2. Moet een redacteur plugins kunnen installeren? Nee. Toch worden rollen na verloop van tijd ruimer, plugin na plugin, en niemand versmalt ze weer.
3. Bestaan er nog accounts van mensen die vertrokken zijn? Een inactief account met rechten is een deur waar niemand meer naar kijkt.

De correctie is niet technisch maar organisatorisch: elk kwartaal een accountcontrole, met de datum erbij genoteerd.

4. Het beheeroppervlak

• Beperk het aantal inlogpogingen. Dat stopt geen gerichte aanval, maar het haalt de ruis weg die de logboeken overspoelt en het wezenlijke verbergt.
• Beperk de beheertoegang op IP-adres wanneer het team stabiel is. Het is de effectiefste maatregel uit deze sectie en de minst verenigbare met mobiel werken — bewust af te wegen.
• Verminder de blootgestelde informatie. Niet als bescherming, maar als hygiëne. Verwacht er geen echt effect van.
• Bewaak de integriteit van bestanden. Een onbekende aanval herkent u niet; dat een bestand is veranderd zonder dat u het weet herkent u uitstekend. Dat is het principe uit de proactieve bescherming tegen zerodaydreigingen.

5. Wat ondanks de schijn NIET beschermt

• De WordPress-versie verbergen. Een geautomatiseerde scanner probeert het lek uit, hij leest geen nummer.
• De inlogpagina verplaatsen. Nuttig tegen ruis, waardeloos tegen een lek in een plugin: het misbruik loopt niet via het formulier.
• Een beveiligingsscore in een dashboard. Een indicator die nooit daalt, meet niets.
• Beveiligingsplugins opstapelen. Twee firewalls beschermen niet dubbel; ze voegen twee oppervlakken en een waarschijnlijk conflict toe.

6. Het protocol, op één pagina

• PHP-uitvoering verboden in de uploadmap — begin hier
• DISALLOW_FILE_EDIT actief
• Rechten nagelopen: schrijfrechten alleen waar nodig, met een datum bij elke uitzondering
• Beheerdersaccounts geteld en teruggebracht tot het noodzakelijke aantal
• Inactieve accounts verwijderd, niet uitgeschakeld
• Capaciteiten per rol nagelopen: wie mag installeren, wie mag publiceren?
• Inlogpogingen beperkt
• Integriteitsbewaking actief, met een melding die dezelfde dag een mens bereikt
• Herstel echt getest, minstens één keer, in een aparte omgeving
• Aantal plugins teruggebracht — zie uw plugins in 5 stappen doorlichten

Conclusie

Geavanceerde hardening gaat niet over het stapelen van verdedigingen: het gaat over het verkleinen van wat een lek kan bereiken. De twee maatregelen met het hoogste rendement op deze pagina — PHP-uitvoering in de uploads verbieden en het aantal accounts met rechten terugbrengen — kosten geen software en verschijnen in geen enkel dashboard.

Juist daarom worden ze zelden toegepast: er valt niets te installeren, niets te laten zien, en er stijgt geen score.

De test die zegt waar u staat: als vannacht een beheerdersaccount gecompromitteerd raakte, wat zou de aanvaller dan kunnen doen dat u vandaag niet kunt tegenhouden? De lijst van die handelingen is uw werkplan.

Verder lezen: proactieve bescherming tegen zerodaydreigingen, de beveiligingsaudit in 10 minuten en uw plugins in 5 stappen doorlichten. Onze premium-extensies zijn beschikbaar met volledige terugbetaling binnen 14 dagen: bekijk de catalogus.