WordPress beveiligen bij Vevida

Als je een WordPress website hebt wil je deze goed beschermen. In dit artikel vertellen we meer over de beveiliging van WordPress sites en de belangrijke dingen waar je rekening mee moet houden.

Inhoudsopgave

Inleiding

WordPress beveiligen tegen hacks is een steeds terugkerend onderwerp onder gebruikers en ontwikkelaars van dit CMS. Wij geven jou graag tekst en uitleg over de mogelijkheden rond WordPress beveiliging op Windows Server hosting. 

Het is vooral belangrijk om te beseffen op welke wijze hackers een site kunnen binnendringen. Wij zien voornamelijk vier methodes voorbij komen:

  1. De populairste werkwijze verloopt via lekken in thema's en plugins die worden gebruikt.
  2. Hackers maken dankbaar gebruik van websites die draaien op verouderde versies van WordPress.
  3. Hackers houden van zwakke wachtwoorden, zoals ‘geheim’, ‘password’ of ‘12345’.
  4. Tot de overige oorzaken behoort onder andere de configuratie van de server zelf.

Zelf WordPress beveiligen

De eerste stappen om jouw WordPress website te beveiligen neem je in WordPress zelf. Je kunt namelijk beginnen met het installeren en activeren van een beveiligingsplugin. Enkele voorbeelden van beveiligingsplugins zijn:

  • iThemes
  • WordFence
  • Sucuri 

Het is wel belangrijk dat deze plugin op de juiste manier wordt ingesteld. De beste configuratie is sterk afhankelijk van de gebruikte plugin, de opbouw van je site, de instellingen van je plugin en andere factoren. Zoek dus altijd goed uit wat in jouw specifieke situatie de beste resultaten geeft. Ook raden wij het af om twee plugins met (bijna) dezelfde functionaliteit te gebruiken. Dat bijt elkaar en komt zelden de performance ten goede.

Inlogmethode beveiligen

Naast het gebruik van een beveiligingsplugin moet je ook zorgen voor veilige en dus sterke wachtwoorden. Ten tweede is het van belang om voor de hoofdgebruiker in elk geval geen voor de hand liggende gebruikersnaam te kiezen. Zo is ‘admin’ of ‘administrator’ af te raden. Deze gebruikersnamen zijn dusdanig ingeburgerd op het internet dat ze als eerste worden geprobeerd.

  • Het is verstandig om ervoor te kiezen om het hoofdaccount binnen WordPress niet te gebruiken voor het aanmaken van posts. De gebruikersnaam van de hoofdgebruiker is hierdoor altijd te herleiden. Maak hiervoor in de plaats een gebruikersaccount aan dat alleen posts mag aanmaken en bewerken.
  • Gebruik two factor authentication (2FA) voor het inloggen. Dit zorgt ervoor dat er naast je gebruikersnaam en wachtwoord nog een tweede stap nodig is om in te loggen, zoals een code dat via je telefoon wordt gegenereerd. 
  •  Wist je dat WordPress login hints gebruikt om jouw te vertellen of de gebruikersnaam of het wachtwoord foutief ingevuld was? Voor een aanvaller is dit heel waardevolle informatie om te bepalen welk gegeven fout is tijdens een bruteforce-aanval. Je kunt dit eenvoudig uitschakelen met de PD Login Security plugin.
  • In het artikel WordPress wp-login.php toegang beveiligen vind je meer manieren om jouw wp-login.php te beveiligen tegen kwaadwillenden.

Inactieve plugins en thema's

Inactieve plugins en thema’s zijn voor hackers eveneens potentiële achterdeurtjes. Veel gebruikers laten deze staan. De plugins en thema’s uitschakelen is niet voldoende. Zolang de bestanden nog op je site aanwezig zijn, kunnen zwakheden hierin worden misbruikt.

 Houd je installatie dus altijd zo schoon mogelijk. Zodra een plugin of thema niet meer wordt gebruikt, kun je deze het beste direct uitschakelen en verwijderen. Dit maakt jouw website tevens sneller.

Wijzigingen in de WordPress core

Het kan zijn dat je bepaalde wijzigingen wilt doorvoeren aan de werking van de WordPress Core zelf. Het is verleidelijk om dit rechtstreeks in de core zelf te doen. Doe dit niet! Het is uit den boze om WordPress Core bestanden aan te passen. Niet alleen moet je de wijzigingen na elke update opnieuw doorvoeren. Ook bestaat de kans dat je door de wijzigingen onbedoeld zwakheden in je site introduceert. Als je functionaliteit wilt aanpassen doe dit dan door middel van plugins.

Updates

Het laatste punt is meteen ook de belangrijkste: installeer altijd de laatste updates die voorhanden zijn. Updates bevatten vrijwel altijd belangrijke beveiligingsoplossingen waarmee lekken worden gedicht. Daarnaast wordt ook nieuwe functionaliteit door middel van updates verspreid. Ook dit is dus een belangrijke stap waarmee je WordPress beveiligt.

Wist je ook dat een nieuwe WordPress Core-, Plugin-, of Thema-versie ook vaak beter geoptimaliseerde code bevat en daardoor net iets sneller is? Heel handig, door te updaten wordt jouw website veiliger én sneller.

Serverniveau

Niet alleen binnen WordPress kun je de beveiliging aanscherpen. WordPress beveiligen is ook op serverniveau mogelijk. Denk aan de verschillende aanpassingen van je wp-config.php-bestand, het correct instellen van de lees- en schrijfrechten op je site, het gebruik van robots.txt en het aanpassen van je web.config– of .htaccess-bestand.

Een van de eerste wijzigingen die je kunt doorvoeren is het toevoegen van de volgende regel in je wp-config.php-bestand:

define( 'DISALLOW_FILE_EDIT', true );

Dit zorgt ervoor dat vanuit het WordPress Dashboard (de admin-omgeving) geen wijzigingen kunnen worden doorgevoerd aan bestanden op de site. Zowel in het thema als de plugins heb je hierdoor geen mogelijkheid meer om bestanden te wijzigen.

Mocht iemand toegang tot het dashboard verkrijgen, dan zorgt dit er in elk geval voor dat diegene geen schadelijke code meer aan de bestaande bestanden kan toevoegen. Je kunt ook de volgende regels nog toevoegen:

define( 'WP_AUTO_UPDATE_CORE', true ); add_filter( 'auto_update_plugin', '__return_true' ); add_filter( 'auto_update_theme', '__return_true' );

Deze toevoeging forceert de automatische updates van zowel WordPress als de aanwezige plugins en thema’s.

Toegang blokkeren

Je kunt rechtstreeks het aanroepen van de include-mappen blokkeren. Reguliere gebruikers moeten hiervan geen hinder ondervinden. Tegelijkertijd maken we het kwaadwillenden weer een stuk lastiger. Neem hiervoor de volgende regels op in je web.config-bestand:

<rewrite> <rules> <rule name="Blokkeer includes" stopProcessing="true"> <match url="^wp-admin/includes" ignoreCase="false" /> <action type="CustomResponse" statusCode="403" statusReason="Forbidden" statusDescription="Forbidden" /> <conditions> <add input="{REQUEST_URI}" pattern="^wp-includes" /> </conditions> </rule> <rule name="Blokkeer includes 2" stopProcessing="true"> <match url="^wp-includes/[^/]+\.php$" ignoreCase="false" negate="true" /> <action type="CustomResponse" statusCode="403" statusReason="Forbidden" statusDescription="Forbidden" /> <conditions> <add input="{REQUEST_URI}" pattern="^wp-includes" /> </conditions> </rule> <rule name="Blokkeer includes 3" stopProcessing="true"> <match url="^wp-includes/js/tinymce/langs/.+\.php" ignoreCase="false" negate="true" /> <action type="CustomResponse" statusCode="403" statusReason="Forbidden" statusDescription="Forbidden" /> <conditions> <add input="{REQUEST_URI}" pattern="^wp-includes" /> </conditions> </rule> <rule name="Blokkeer includes 4" stopProcessing="true"> <match url="^wp-includes/theme-compat/" ignoreCase="false" negate="true" /> <action type="CustomResponse" statusCode="403" statusReason="Forbidden" statusDescription="Forbidden" /> </rule> </rules> </rewrite> 

Brutefoce aanvallen tegen gaan

De volgende stap is het beschermen van WordPress tegen bruteforce-aanvallen. We doen dit door in het web.config bestand het volgende op te nemen, onderaan net boven </configuration>

<location path="wp-login.php"> <system.webServer> <security> <ipSecurity allowUnlisted="false"> <add ipAddress="123.45.67.89" allowed="true" /> </ipSecurity> </security> </system.webServer> </location>:

Vervang hierbij het genoemde ipAddress door jouw eigen IP-adres, zodat je zelf wel gewoon toegang blijft houden tot deze map. Wat jouw IP-adres is vind je eenvoudig via mijnip6.nl. Hiermee maak je dus eenvoudig een wp-login.php IP whitelist voor jouw website. 

Vindbaarheid

Een andere aanvalsmethode die op de site kan worden uitgevoerd, verloopt via de HTTP TRACE methode. Om te voorkomen dat je site hiervoor wordt gebruikt, blokkeer je deze specifieke http-methode met de volgende URL Rewrite-regel: 

<rule name="Trace rule"> <match url=".*" ignoreCase="false" /> <conditions logicalGrouping="MatchAll"> <add input="{REQUEST_METHOD}" pattern="^TRACE" ignoreCase="false" /> </conditions> <action type="CustomResponse" statusCode="403" statusReason="Forbidden" statusDescription="Forbidden" /> </rule>

Alle verzoeken die via deze methode naar je site worden gestuurd, worden nu geweigerd door middel van een HTTP 403 status code.

 Er zijn nog meer verzoeken die we preventief kunnen blokkeren. Zo wordt standaard de gehele site door diverse robots geïndexeerd. Op die manier is de site ook terug te vinden in de diverse zoekmachines.

Met de volgende regels in het robots.txt-bestand kunnen we bepaalde gevoelige mappen afschermen van dit gedrag. Hierdoor is het wat lastiger om zomaar gegevens van je site te achterhalen:

User-agent: * Disallow: /feed/ Disallow: /trackback/ Disallow: /wp-admin/ Disallow: /wp-content/ Disallow: /wp-includes/ Disallow: xmlrpc.php Disallow: /wp-

Een robot als BaiduSpider blokkeer je hiermee helaas niet. Je vindt meer informatie in de blogpost Block BaiduSpider bot User-Agent mocht je de Baidu robot graag willen blokkeren op jouw site.

Let op: Deze methode heeft invloed op de wijze waarop je site wordt geïndexeerd. Dit kan dus negatieve gevolgen hebben voor de ranking in de zoekresultaten. Ook kan het zijn dat bepaalde SEO-plugins hierdoor hun werk niet goed kunnen uitvoeren. Denk dus eerst goed na over hetgeen je wilt blokkeren en probeer zelf een balans te vinden tussen vindbaarheid en veiligheid.

PHP code

In sommige mappen verwachten we geen PHP-code. Een voorbeeld hiervan is de folder wp-content/uploads/. Uit veiligheidsoogpunt kunnen we daarom het beste het uitvoeren van PHP-scripts in deze map geheel uitschakelen. Je schakelt de PHP-uitvoer eenvoudig uit door de volgende code te plaatsen in een web.config-bestand in de map wp-content/uploads/:

<?xml version="1.0" encoding="UTF-8"?> <configuration> <system.webServer> <handlers accessPolicy="Read" /> </system.webServer> </configuration>

Hiermee zorg je ervoor dat alle scripthandlers (waaronder PHP) in deze én onderliggende mappen alleen leesrechten hebben. Ook dit is in het WordPress Hosting pakket al voor jou ingesteld.

M
Marjolein is the author of this solution article.

Was dit antwoord nuttig? Ja Nee

Feedback versturen
Het spijt ons dat we u niet hebben kunnen helpen. Als u feedback geeft, kunnen we het artikel verbeteren.