PREVENTIEVE BEVEILIGING — HARDENING

WordPress beveiligen

De meeste gehackte WordPress-sites die bij mij binnenkomen hadden één ding gemeen: een gat dat ze hadden kunnen dichten. Een contactformulier-plugin met een bekende kwetsbaarheid die al maanden openstond. PHP in de uploads-map die nooit was afgesloten. Een admin-account met een wachtwoord van voor 2018. Ik doe de audit, voer de hardening uit die bij jouw situatie past, en zet monitoring in — zodat je bij een volgend incident een melding krijgt in plaats van een e-mail van je hoster.

  • Diagnose altijd kosteloos
  • 30 dagen garantie op hardening
  • Inclusief documentatie van alle wijzigingen

WAT IK TEGENKOM
BIJ GEHACKTE SITES

Dit zijn de zes dingen die ik bij bijna elke gehackte WordPress-site zie. Soms één, soms drie tegelijk. Ze zijn bijna altijd van tevoren te voorkomen geweest.

01

Verouderde plugins en themes

Veruit het meest gezien. Plugin-release-notes beschrijven precies welk lek is gedicht — bots lezen diezelfde notes en scannen daarna gericht op sites die nog niet hebben geüpdatet. De patch staat beschikbaar, maar je moet hem ook installeren.

02

Zwakke wachtwoorden en geen 2FA

Brute-force aanvallen op wp-login.php en xmlrpc.php draaien 24/7. Een zwak of hergebruikt wachtwoord geeft in minuten toegang. Zonder 2FA is een gestolen wachtwoord voldoende voor volledige admin-controle.

03

PHP uitvoerbaar in /uploads/

De wp-content/uploads/ map hoort alleen afbeeldingen te bevatten, maar draait standaard PHP. Aanvallers uploaden een webshell via een kwetsbaar formulier-plugin en hebben daarmee volledige server-toegang — ook nadat je alles hebt “opgeschoond”.

04

Geen file-integrity monitoring

Ik zie regelmatig sites waarbij de hack al maanden actief was voordat iemand het merkte. Intussen draait het domein als spam-relay of casino-linkfarm, en bouwt Google-vertrouwen af. File-integrity monitoring stuurt een melding zodra er iets wijzigt — niet pas als een klant er melding van maakt.

05

xmlrpc.php volledig open

xmlrpc.php staat standaard aan in WordPress en biedt aanvallers een alternatieve ingang die brute-force-bescherming op de login-pagina omzeilt. Via de system.multicall-methode kunnen duizenden wachtwoorden per request worden getest. Eén regel in .htaccess sluit dit af.

06

Te veel admin-accounts

Elk extra admin-account is een extra aanvalsdoelwit. Voormalige medewerkers, web-bureaus die ooit toegang hadden, test-accounts van installaties — ze zijn er allemaal nog. Aanvallers gaan voor de accounts met het meest voor de hand liggende wachtwoord. Minst actieve accounts, meest kwetsbaar.

12 hardening-maatregelen per site
2–4 uur van audit tot afgerond
30 dagen garantie na afloop

WAT IK DOE PER SITE

Dit is wat ik doorloop. Niet alles is voor elke site even relevant — dat bepaalt de audit. Maar het zijn maatregelen die ik op bijna elke site tegenkom die ze nog niet heeft.

  1. Plugin- en theme-audit Elke actieve plugin is een potentieel aanvalspunt. Ik check welke actief zijn, welke inactief maar nog aanwezig (ook kwetsbaar), welke verouderd zijn en welke nooit meer nodig zijn. Gedeactiveerde plugins horen volledig verwijderd te worden — de code staat er anders gewoon nog.
  2. 2FA op alle admin-accounts Twee-factor authenticatie maakt een gestolen wachtwoord nutteloos. Ik stel dit in op elke admin met WP 2FA of Wordfence Login Security, inclusief noodcode-backup voor als je je telefoon kwijt bent. Geen uitzonderingen — niet voor jou, niet voor je webbouwer.
  3. wp-config.php beveiligen DISALLOW_FILE_EDIT uit, DISALLOW_FILE_MODS overwegen, database-prefix aanpassen als dat nog wp_ is, secret keys roteren. Bestandsrechten op 640 of 600 zetten zodat de webserver het kan lezen maar niet schrijven.
  4. Uploads-map PHP-blokkade Een .htaccess in wp-content/uploads/ die .php, .phtml en .php5 bestanden weigert. Dit breekt 80% van alle geautomatiseerde webshell-aanvallen. Eén bestand, enorme impact. Standaard zit dit er niet in.
  5. xmlrpc.php blokkade of beperking Als je geen gebruik maakt van de WordPress mobiele app of externe publicatie-tools, blokkeer ik xmlrpc.php volledig via .htaccess. Gebruik je het wél, dan beperk ik het tot de specifieke IP-adressen die het nodig hebben.
  6. Gebruikersaccounts opschonen Alle admin-accounts nalopen: zijn ze nog nodig? Wie heeft er onlangs ingelogd? Accounts die al meer dan 6 maanden niet actief zijn geweest, zet ik op editor-niveau of verwijder ik na overleg. De admin-gebruikersnaam hernoemen als die nog bestaat.
  7. Database-audit en opschoning Malware zit niet alleen in bestanden — de database is een even populaire plek. Ik doorzoek wp_options op geïnjecteerde JavaScript of redirect-code (vaak in widgetinstellingen of siteurl), check wp_users op accounts die direct in de database zijn aangemaakt, en wp_posts op hidden iframes of base64-blobs. Leftover-tabellen van verwijderde plugins worden ook opgeruimd — ze zijn geen aanvalsvector op zichzelf maar reduceren de footprint.
  8. File-integrity monitoring activeren Wordfence of Sucuri als file-integrity watcher instellen, met e-mailwaarschuwingen bij gewijzigde core-bestanden. Dit is de vroeg-waarschuwing die de detectietijd van maanden naar uren terugbrengt. Ik stel de drempelwaarden zo in dat je geen valse alarmen krijgt bij reguliere updates.
  9. .htaccess hardening Toegang tot gevoelige bestanden blokkeren: wp-config.php, readme.html, license.txt, .git-mappen en de logs-map. Directorylijsting uitschakelen. HTTP-headers voor security toevoegen: X-Frame-Options, X-Content-Type-Options, Referrer-Policy.
  10. Login-bescherming Brute-force beveiliging via Wordfence of Limit Login Attempts, met slimme rate limiting. Optioneel: wp-login.php beperken tot jouw IP-adres via .htaccess — de effectiefste maatregel die er is als je altijd vanaf een vast IP werkt.
  11. Databaserechten minimaliseren De WordPress-database-gebruiker heeft standaard ALL PRIVILEGES. Dat is te veel. Ik maak een gebruiker aan met alleen de rechten die WordPress nodig heeft: SELECT, INSERT, UPDATE, DELETE, CREATE, ALTER. Zo kan een aanvaller via SQL injection minder schade aanrichten.
  12. SPF, DKIM en DMARC instellen Als je domein-reputatie niet beschermd is, kunnen aanvallers mail versturen die lijkt te komen van jouw domein — zonder ooit je site te hacken. Ik check of SPF, DKIM en DMARC correct zijn ingesteld en fix wat ontbreekt. Standaard onderdeel van mijn hardening.

ZO GAAT HET IN ZIJN WERK

Je weet na afloop wat er was, wat er is gedaan en waarom. Geen rapport van twintig pagina's — gewoon een helder overzicht zodat je het zelf kunt bijhouden.

01

Security Audit

Ik doorloop de volledige site: plugin-versies, bestandsrechten, .htaccess-configuratie, database-setup, actieve admin-accounts, log-bestanden. Ik gebruik zowel handmatige inspectie als geautomatiseerde tools om niks te missen. De audit is altijd kosteloos.

02

Rapport & Offerte

Je krijgt een concreet overzicht van wat ik heb gevonden: welke kwetsbaarheden, hoe ernstig, en in welke volgorde ze moeten worden opgelost. Inclusief een eerlijke tijdschatting. Pas als je akkoord gaat, begin ik met de hardening.

03

Hardening

Alle maatregelen doorvoeren op jouw specifieke situatie: plugins, hosting-configuratie, databaseversie, of je al een security-plugin hebt. Geen generieke template — ik pas elke maatregel aan op wat jouw site nodig heeft en wat de hoster toestaat.

04

Monitoring & Documentatie

Na de hardening stel ik monitoring in en lever ik documentatie: wat is er gedaan, wat zijn de nieuwe inloggegevens, hoe werkt 2FA, wat te doen bij een alarm. Je bent volledig op de hoogte en kunt daarna zelf bijhouden of onderhoud uitvoeren.

AL TEKENEN VAN EEN HACK?

Beveiligen en opruimen zijn niet hetzelfde. Als er al iets actief is, moet dat eerst weg — daarna pas hardening. Herken je één van deze drie?

  1. 01

    Google toont "This site may be hacked"

    Search Console heeft mogelijk al een Manual Action. Bezoekers haken massaal af bij dit label. De melding verdwijnt niet door de site te beveiligen — er is eerst een volledige cleanup en herindexering nodig. Zie mijn hack-opruim pagina voor het volledige stappenplan.

  2. 02

    Japanse, Chinese of pharma-spam in Google

    Cloaking-hacks waarbij Googlebot andere content krijgt dan jij. Je site ziet er normaal uit, maar in zoekresultaten staat spam. Volledig ander type aanpak nodig: detectie, forensische backup, cleanup, dan hardening. Casino-spam, Japanse spam, pharma-hack — elk met eigen artikel.

  3. 03

    Hosting geschorst voor spam-uitstoot

    Mail van TransIP, Hostnet of Antagonist over "verdachte uitgaande mail"? Je hebt een deadline van 24-48 uur. Beveiligen alleen helpt hier niet — de bron moet gestopt worden. Lees het stappenplan of bel direct.

Naar de hack-opruim pagina →

Een beveiligde site is goedkoper dan een gehackte site.

Een opruiming van een gehackte site kost me gemiddeld een dag. Een hardening een dagdeel. De audit om te bepalen wat jij nodig hebt is gratis — daarna beslis jij.

Gratis audit aanvragen

Wat kost WordPress beveiligen?

De audit is altijd gratis. Voor de hardening geldt: hoe groter de installatie, hoe meer werk. Standaard WordPress-site met een handvol plugins: 2-3 uur. Grotere sites met custom code of meerdere beheerders: 4-6 uur. Na de audit weet je het exact, vóór ik begin.

Wat de prijs bepaalt:

  • Aantal actieve plugins en themes (inclusief inactieve)
  • Hosting-type — shared, VPS of managed WordPress
  • Of er al een hack of infectie aanwezig is
  • Of monitoring-setup onderdeel is van de opdracht
Gratis audit aanvragen

Zonder hardening

  • Hack ontdekt als klant het meldt — of hoster schorst
  • Opruiming: gemiddeld een volledige werkdag
  • Google plaatst waarschuwing; bezoekers haken af
  • Domeinreputatie herstellen: weken tot maanden
  • Kans op herhaling via dezelfde route: hoog

Met hardening

  • Melding per mail zodra er iets aan bestanden wijzigt
  • Hardening: dagdeel, eenmalig
  • Google ziet een schone, goed-geconfigureerde site
  • Domeinreputatie intact
  • Bekende aanvalsroutes afgesloten

VEELGESTELDE VRAGEN OVER WORDPRESS BEVEILIGING

Wat er het vaakst gevraagd wordt.

Wat kost een WordPress security audit en hardening?

Hangt af van de site. Een standaard WordPress-installatie met een handvol plugins doe ik in 2-4 uur. Grotere sites of sites met veel custom code langer. De audit om dat te bepalen is altijd kosteloos — daarna weet je wat het kost voor we beginnen.

Hoe lang duurt een WordPress hardening?

Een volledige hardening-sessie duurt 2-4 uur, afhankelijk van de staat van de site. Tijdens de hardening is de site gewoon bereikbaar — ik werk in de achtergrond en geef vooraf aan welke stappen een korte downtime vereisen. Na afloop lever ik een overzicht van wat er is gedaan en waarom.

Heb ik Wordfence of Sucuri nodig als jij mijn site hardened?

Ja. Een security-plugin detecteert problemen — dat is niet hetzelfde als voorkomen dat ze kunnen binnenkomen. Wordfence of Sucuri horen gewoon in de setup, maar ze vervangen de hardening niet. De plugin is je alarm; de hardening is je slot.

Mijn site is al eerder gehackt geweest — is beveiligen dan nog zinvol?

Zeker. Een eerdere hack betekent niet dat de site structureel onveilig is — het betekent dat er op dat moment een ongedicht gat was. Na hardening sluit ik alle bekende aanvalsvectoren. Als er ook nog kans bestaat dat eerdere malware of backdoors aanwezig zijn, doe ik eerst een volledige cleanup en dan de hardening. Ik check dit tijdens de gratis audit.

Wat is het verschil tussen een security-plugin en echte hardening?

Een security-plugin detecteert en blokkeert bekende aanvallen. Hardening verandert de structuur van je site zodat aanvallen minder kans hebben om te landen. Voorbeeld: een plugin blokkeert mislukte login-pogingen; hardening verplaatst de aanvalsvector, beperkt toegang op IP-niveau, en zet 2FA aan. Een plugin zonder hardening is een alarm zonder slot.

Hoe vaak moet ik mijn WordPress site opnieuw laten beveiligen?

De hardening zelf hoef je maar één keer te doen. Wat daarna aandacht vraagt: plugins opschonen als je iets niet meer gebruikt, wachtwoorden roteren en updates bijhouden. Als je dat liever uitbesteedt kan ik jaarlijks een check doen.

Helpt WordPress beveiligen ook tegen brute-force aanvallen?

Ja. Brute-force bescherming op wp-login.php en xmlrpc.php is standaard onderdeel van de hardening — rate limiting, IP-blokkades en 2FA maken geautomatiseerde aanvallen vrijwel kansloos. Voor DDoS-mitigation (volumetrische aanvallen) heb je een cloud-WAF nodig zoals Cloudflare, die ik ook kan instellen en configureren.

Wat als ik managed WordPress hosting heb?

Managed hosting (WP Engine, Kinsta) beheert al bepaalde lagen: server-configuratie, automatic updates, basic firewalling. Maar WordPress-niveau hardening — 2FA, wp-config beveiligen, plugin-audit, uploads-map vergrendelen, file-integrity monitoring — is altijd jouw verantwoordelijkheid. Ik ken de beperkingen van de grote managed platforms en weet wat er nog handmatig gedaan moet worden.

Werkt WordPress hardening ook op TransIP, Antagonist of Hostnet?

Ja. Ik werk regelmatig op shared hosting van TransIP, Antagonist, Hostnet, Yourhosting en One.com. Elke hoster heeft zijn eigen beperkingen — op sommige kun je .htaccess-regels niet volledig controleren, andere blokkeren bepaalde PHP-functies. Ik weet wat er per hoster wel en niet kan en pas de hardening daarop aan. Niet elke maatregel is overal mogelijk, maar de meest impactvolle zijn dat altijd.

Kan ik mijn WordPress site beveiligen zonder downtime?

Bijna volledig. De meeste hardening-stappen hebben geen enkel effect op de beschikbaarheid van de site. De enige stap die kort offline kan zijn: als ik de database-gebruiker wissel of de database-prefix aanpas, is de site voor 1-2 minuten niet bereikbaar. Ik doe dat altijd buiten de drukste uren en geef vooraf aan wanneer het gepland is. Alles erna draait gewoon door.

Mijn WordPress site is al beveiligd met een certificaat (HTTPS) — is dat niet genoeg?

HTTPS versleutelt het verkeer tussen bezoeker en server — het zegt niks over de veiligheid van de WordPress-installatie zelf. De meeste hacks die ik zie lopen via plugins, wachtwoorden of serverbestanden. Een SSL-certificaat is voorwaarde voor een betrouwbare site, maar het is geen beveiliging van WordPress. Dat zijn twee verschillende lagen.

NEEM CONTACT OP

Audit is altijd kosteloos. Stuur een bericht via WhatsApp of mail — ik reageer op werkdagen binnen 4 uur en bij noodgevallen vaak binnen het uur.

Online — reactie meestal binnen 4 uur
Daniel Mulder

Daniel Mulder

Website Technical Support Specialist
WordPress · Drupal · Joomla · OpenCart · CMS Made Simple

15+JAAR
500+SITES
4uREACTIE
Diagnose altijd kosteloos 30 dagen garantie op hardening KvK 63456842 · Werkzaam in heel NL
WhatsApp Snelste manier — direct chatten, ook foto's en schermafbeeldingen delen 06 12 29 47 06 Bellen — bij urgente vragen het snelste pad info@wpts.nl E-mail — voor uitgebreidere uitleg of als je liever schrijft

Werkuren

Maandag – Vrijdag09:00 – 18:00
ZaterdagOp afspraak
ZondagGesloten

Spoed? Bel altijd — bij echte noodgevallen reageer ik vaak binnen 30 minuten.