Laatste update: 6 juni 2013 – filter toegevoegd om de URLs van de site_url() en get_site_url() functies ook te filteren (voor o.a. de URL van het inlogformulier). Daarnaast de verschillende variabelen (voor de opbouw van de inlog & uitlog URLs) global gemaakt om er zeker van te zijn dat de URLs juist opgebouwd worden (dit zorgde voor problemen in de (get_)site_url filter).

Zoals je in mijn vorige artikel hebt kunnen lezen zijn WordPress websites behoorlijk het doelwit geweest. Helaas is er in de berichten daarover (ja, zelfs die van mij) twee verschillende termen door elkaar gebruikt.

DDoS en Brute Force Attacks

DDoS staat voor Dedicated Denial of Service en betekent het platgooien van een service (app, website etc.) door ongelooflijk veel aanvragen tegelijkertijd te versturen. Doordat de service zoveel aanvragen tegelijkertijd ontvangt raakt het hele systeem in de war.
Zie het als een computer waarop je alle programma’s tegelijkertijd opent terwijl je ook nog daadwerkelijk in programma’s probeert te werken. Resultaat: een computer die compleet crasht omdat ‘ie de aanvragen niet kan verwerken.

Brute Force Attacks zijn aanvallen met “brute kracht”. Net als met DDoS Attacks wordt er niet gauw opgegeven. Een groot verschil tussen de twee echter, is dat het met Brute Force Attacks niet de bedoeling is een Denial of Service (platgooien) te veroorzaken. Voor het inloggen in administratie-gedeeltes van websites / FTP accounts daarentegen wordt het wel veel gebruikt.

Dat laatste is dus waar veel WordPress websites vorige maand (en een deel ook nu nog) last van hadden.

Plugins als Limit Login Attempts en Login Security Solution hebben de mogelijkheid om de admins een e-mail te sturen op het moment dat er inlogpogingen worden/zijn gedaan. De laatste had ik geïnstalleerd op de site van een van mijn opdrachtgevers. Met de basis instellingen (bij 50 inlogpogingen gemaild worden) kreeg ik overdag zeer regelmatig een mailtje. ‘s Nachts kreeg ik ze zelfs elke paar minuten! Tijd om daar een oplossing voor te vinden dus.

Brute Force Attacks verhinderen – .htaccess en PHP

Om het proberen in te loggen via wp-login.php te verhinderen zijn er verschillende manieren. Een daarvan is met behulp van een .htaccess bestand de toegang ontzeggen voor iedereen, behalve mensen met een verbinding vanaf specifieke IP-adressen.
Als je de enige bent die jouw website onderhoudt dan kan dit handig zijn, maar zodra je ook extern met je website bezig wel zijn gaat dit erg lastig worden. Je IP-adres is namelijk afhankelijk van de locatie waar je probeert in te loggen (thuis heb je een ander IP-adres dan wanneer je bijvoorbeeld in de trein zit). En steeds je huidige IP-adres nakijken via bijvoorbeeld watismijnip.nl en dan je .htaccess aanpassen is vreselijk irritant en absoluut niet gebruiksvriendelijk.

Maar zo’n zelfde werking wilde ik wel graag implementeren: alleen mensen die wel in mogen loggen toelaten op wp-login.php en de rest terug naar de website.

.htaccess en PHP to the rescue

Ik bedacht een manier om met een specifieke variabele in de URL (die een specifieke waarde moet hebben) te gaan werken. Als dan die specifieke key en/of waarde niet aanwezig is dan de bezoeker doorsturen naar de homepagina.

Omdat de key geheim moet blijven en het onthouden nog weleens lastig zou kunnen worden bedacht ik om via .htaccess een nieuwe URL op te geven voor wp-login.php (in de voorbeeldbestanden gebruikte ik /more-secure-login/ als voorbeeld). Dus in plaats van mijndomeinnaam.nl/wp-login.php?secure=GeheimeKey ga je naar mijndomeinnaam.nl/more-secure-login/ -> véél makkelijker te onthouden (en ook daar wordt de geheime key niet weergegeven).

Daarnaast kwam ik een .htaccess stuk tegen om inlogpogingen zonder referer te weren (bots die met “grof geweld” proberen in te loggen hebben vaak geen referer, en als ze die wel hebben: meestal een die niet overeenkomt met jouw URL). Fijne toevoeging van de .htaccess code (die overigens ook is overgenomen in de .htaccess hieronder) is dat veel spam reacties ook worden tegengehouden (bots die reacties proberen te posten zonder referer worden ook geweerd).

Een combinatie van de twee dus, voor wat extra zekerheid.

Wijzigingen voor .htaccess

  1. Als eerste moet je een 401.html bestand aanmaken, een voorbeeldbestand vind je hier.
  2. Daarna is het belangrijk dat je de URL(s) aanpast:
    RewriteCond %{HTTP_REFERER} !.*(domain1.com|domain2.nl).* [OR]Een enkele domeinnaam wordt bijvoorbeeld (mijndomeinnaam.nl), meerdere domeinnamen (bijvoorbeeld met een WordPress Multisite omgeving) kun je zoals in de voorbeeldregel aanpassen (meerdere domeinnamen scheiden met een |).
  3. Nu gaan we een secret key toevoegen aan de URLs:
    RewriteRule ^more-secure-login/lostpassword/?$ /wp-login.php?secure=XXXXXXXXX&action=lostpassword [NC,L] # $secret_login + $secret_lostpw
    RewriteRule ^more-secure-login/?$ /wp-login.php?secure=XXXXXXXXX [NC,L] # $secret_login
    RewriteRule ^custom-logout/?(.*?)/?$ /wp-login.php?secure=XXXXXXXXX&%{QUERY_STRING} [NC,L] # $secret_logout
    Het XXXXXXXXX moet op alle drie de regels aangepast naar dezelfde geheime code. Die kun je gewoon zelf bedenken, door wat op je toetsen te drukken. Bijvoorbeeld: awetSDRG346DGrthkjr78y235DRGdagoij.
    Door deze voorbeeldcode te kopiëren naar de .htaccess komt het er zo uit te zien:
    RewriteRule ^more-secure-login/lostpassword/?$ /wp-login.php?secure=awetSDRG346DGrthkjr78y235DRGdagoij&action=lostpassword [NC,L] # $secret_login + $secret_lostpw
    RewriteRule ^more-secure-login/?$ /wp-login.php?secure=awetSDRG346DGrthkjr78y235DRGdagoij [NC,L] # $secret_login
    RewriteRule ^custom-logout/?(.*?)/?$ /wp-login.php?secure=awetSDRG346DGrthkjr78y235DRGdagoij&%{QUERY_STRING} [NC,L] # $secret_logout
  4. Als laatste kun je de URLs eventueel aanpassen. In de huidige .htaccess gaat het om:
    • Inlogpagina: mijndomeinnaam.nl/more-secure-login/
    • Wachtwoord vergeten: mijndomeinnaam.nl/more-secure-login/lostpassword/
    • Uitloggen: mijndomeinnaam.nl/custom-logout/

    Deze kun je dus ook aanpassen, bijvoorbeeld naar de volgende URLs:

    • Inlogpagina: mijndomeinnaam.nl/admin-inloggen/
    • Wachtwoord vergeten: mijndomeinnaam.nl/admin-inloggen/wachtwoord-vergeten/
    • Uitloggen: mijndomeinnaam.nl/admin-uitloggen/

    Dat moet dan op deze manier worden aangepast in de .htaccess:
    RewriteRule ^admin-inloggen/wachtwoord-vergeten/?$ /wp-login.php?secure=awetSDRG346DGrthkjr78y235DRGdagoij&action=lostpassword [NC,L] # $secret_login + $secret_lostpw
    RewriteRule ^admin-inloggen/?$ /wp-login.php?secure=awetSDRG346DGrthkjr78y235DRGdagoij [NC,L] # $secret_login
    RewriteRule ^admin-uitloggen/?(.*?)/?$ /wp-login.php?secure=awetSDRG346DGrthkjr78y235DRGdagoij&%{QUERY_STRING} [NC,L] # $secret_logout

De redirect-wp-login.php komt in de mu-plugins map te staan. Deze map maak je – als ‘ie nog niet bestaat – in je wp-content map. Plugins die daarin worden gezet zijn altijd geactiveerd (hoef je dus via de Plugins pagina niet te activeren).

Wijzigingen voor redirect-wp-login.php

De punten die aangepast kunnen worden heb ik – voor het gemak – in aparte variabelen bovenaan het bestand gezet. Het gaat om deze variabelen:

$secret_login = 'more-secure-login';
$secret_lostpw = 'lostpassword'; # for the lost password page, combines $secret_login with $secret_lostpw
$secret_logout = 'custom-logout'; # same, but for the logout URL

$secret_key = 'XXXXXXXXX'; # the secret key-value that's given in the URL, must be the same as in the .htaccess

Met de voorbeeldgegevens bij het .htaccess onderdeel wordt dat dit:

$secret_login = 'admin-inloggen';
$secret_lostpw = 'wachtwoord-vergeten'; # for the lost password page, combines $secret_login with $secret_lostpw
$secret_logout = 'admin-uitloggen'; # same, but for the logout URL

$secret_key = 'awetSDRG346DGrthkjr78y235DRGdagoij'; # the secret key-value that's given in the URL, must be the same as in the .htaccess

LET OP: probeer niet al te algemene URLs te gebruiken voor, met name, het inloggen. Een URL als mijndomeinnaam.nl/login/ wordt namelijk ook vaak standaard geprobeerd door brute force attacks bots en zal dus alsnog een beste load op je hosting account kunnen veroorzaken (met een offline website als gevolg).

Deel Tweet Deel Deel

WooCommerce

Leave a Reply

Your email address will not be published. Required fields are marked *

Skip to content