Een veelgehoorde vraag is, hoe veilig is zo’n open source cms nou eigenlijk?
WordPress is van zichzelf al behoorlijk goed qua beveiliging. Zowel de developers als de community van gebruikers signaleren hacks of lekken razendsnel. Vaak worden er dan bijzonder snel updates uitgegeven om de gevonden problemen op te lossen. Die snelheid van handelen is het voordeel van zo’n grote community achter open source software.

Maar dat neemt niet weg dat er nog veel gedaan kan worden aan de beveiliging na installatie op een server. Naast erg voor de hand liggende zaken die je zelf eenvoudig kunt regelen (zie: beveiligingstips voor wordpress deel 1 ) zijn er nog wat zaken die een stuk dieper gaan.

Zo kun je ervoor zorgen dat bepaalde bestanden ontoegankelijk worden gemaakt voor iedereen behalve het admin account en de webserver.

Om bij het begin te beginnen, om de volgende beveiligingen te kunnen realiseren heb je toegang nodig tot het .htacces bestand op je server.

Belangrijk: Voordat je aan de gang gaat, controleer eerst de WordPress Codex of de codes hieronder nog wel actueel zijn.

Bestandsbeveiliging

Voor sommige functies van WordPress is het nodig dat de webserver naar bestanden kan schrijven. Helaas is dat kunnen schrijven naar bestanden ook een potentieel beveiligingsrisico. Helemaal als je site op een server draait waarop ook andere sites worden gehost. Dat risico kan worden ingeperkt door te zorgen dat het schrijven naar die bestanden wordt geweigerd voor alles en iedereen behalve de webserver.

Via ftp kun je de rechten van bestanden aanpassen:

/
De root van de WordPress installatie. Alle bestanden moeten alleen beschrijfbaar zijn door de gebruiker, behalve .htaccess als je wilt dat WordPress automatisch rewrite regels aanmaakt.

/wp-admin/
De WordPress admin: alle bestanden moeten alleen beschrijfbaar zijn door de gebruiker.

/wp-includes/
WordPress (systeem) bestanden: moeten alleen bewerkt kunnen worden door de gebruiker.

/wp-content/
Bedoeld voor de gebruiker: moet beschrijfbaar zijn door de gebruiker en door de webserver.

Binnen /wp-content/ vind je:

/wp-content/themes/
De thema bestanden. Als je vanuit de editor dingen wilt aanpassen moet deze voor de gebruiker en de webserver bewerkbaar zijn.

/wp-content/plugins/
Moet alleen voor de gebruiker bewerkbaar zijn.

Via ftp kun je de rechten van al deze bestanden aanpassen.

De waarde voor directories moet 755 zijn.

De waarde voor bestanden moet 644 zijn.

Beveilig wp-admin

Het toevoegen van server-side wachtwoordbeveiliging vormt een tweede laag van beveiliging voor het admingedeelte (het loginscherm en je bestanden). Wanneer actief moet eerst deze laag worden gekraakt voordat kan worden begonnen aan het kraken van het inlogwachtwoord.

Dit is een instelling die via het controlepaneel van je webhost kan worden ingesteld. Als je hoster cpanel of Plesk gebruikt, dan is dat redelijk simpel.

Plesk:

Login op je controlepaneel, ga naar ‘met wachtwoord afgeschermde mappen’.

Beveilig wp-admin in Plesk

 

 

Klik op ‘afgeschermde map toevoegen’.

Beveiligde map toevoegen Plesk

 

 

 

 

Vul /wp-admin/ als map in. De maplocatie is afhankelijk van je hoster. Bij ‘titel van de afgeschermde omgeving’ kun je een tekst invullen die wordt getoond als iemand de wp-admin wil benaderen.
Vervolgens moet je nog een gebruiker aanmaken die toegang heeft tot die map. Klik daartoe op de map die je net hebt aangemaakt, en voeg een gebruiker toe. Met bij voorkeur een sterk wachtwoord.

Beveilig wp-includes

Er kan een tweede laag van beveiliging worden toegevoegd daar waar scripts staan die niet bedoeld zijn om toegankelijk te zijn voor gebruikers. Een manier om dit te doen is om die scripts te blokkeren met mod_rewrite in het .htaccess bestand.
Belangrijk: Om er voor te zorgen dat WordPress de beveiligingscodes niet overschrijft moeten deze buiten de # BEGIN en # END tags van het .htaccess bestand worden geplaatst. Alles binnen die tags kan door WordPress worden overschreven.

# Block the include-only files.
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^wp-admin/includes/ - [F,L]
RewriteRule !^wp-includes/ - [S=3]
RewriteRule ^wp-includes/[^/]+\.php$ - [F,L]
RewriteRule ^wp-includes/js/tinymce/langs/.+\.php - [F,L]
RewriteRule ^wp-includes/theme-compat/ - [F,L]
&lt;/IfModule&gt;

# BEGIN WordPress

Beveilig wp-config.php

Wp-config bevat de inloggegevens voor de database, die kun je ook blokkeren voor iedereen behalve het gebruikersaccount. Deze code voeg je ook weer toe buiten de # BEGIN en # END tags van het .htaccess bestand.

&lt;Files wp-config.php&gt;
order allow,deny
deny from all
&lt;/Files&gt;
# BEGIN WordPress

Voorkom bladeren via een browser door je bestanden

Een groot beveiligingsrisico is het openbaar hebben staan van alle bestanden van je WordPress installatie.
Er is een eenvoudige test om te kijken of de bestanden op jouw site beschermd zijn of niet:Voer dit in je browser in: ” http://www.domein.nl/wp-includes/ ” (zonder de aanhalingstekens).
Als je een witte pagina ziet, of een “Forbidden” melding, of wordt geredirect naar je home pagina, dan zijn je bestanden beschermd.

Zie je iets wat lijkt op dit:

Voorkom WordPress directory bladeren in browser

 

 

 

 

 

Dan zijn je bestanden niet veilig en via een browser te bekijken.

Om alle bestanden hiertegen te beveiligen plaats je deze code in je .htaccess  bestand:

# Prevent folder browsing
Options All -Indexes

Verberg errorberichten die een volledig pad laten zien

Een mogelijk risico is de functie van WordPress die in geval van fouten in plugins of wat dan ook het gehele pad naar de foutmelding laat zien. Je ziet dan iets als:
Warning: require(ABSPATHwp-includes/load.php) [function.require]: failed to open stream: No such file or directory in /home/inlognaamhier/public_html/wp-settings.php on line 21

Dit zou kunnen betekenen dat een mogelijke aanvaller aan dat pad kan zien dat de inlognaam ‘inlognaamhier’ is, en die hoeft dan alleen nog maar op zoek naar het wachtwoord.

Dit is te voorkomen door in het .htacces bestand (ook weer buiten het gedeelte dat WordPress kan bewerken) de volgende code op te nemen:

php_flag display_errors off

Die foutmeldingen worden dan niet meer getoond.

Verberg inlog foutberichten

Foutberichten bij het inloggen kunnen mogelijk hackers een idee geven of ze de gebruikersnaam goed hebben of niet, het is verstandig om, wanneer die berichten getoond worden, ze te verbergen.
Plaats hiertoe de volgende code in het functions.php bestand

add_filter('login_errors',create_function('$a', "return null;"));

Als er al geen fouten worden getoond dan hoef je dit niet te doen natuurlijk.

Lees ook de  andere berichten in deze serie:
Deel 1
Deel 3
Deel 4