WordPress Brute Force Attack!

OK, dat was even een einde aan mijn zondagochtend die net wat anders liep dan verwacht. Eigenlijk wilde ik gewoon even een bericht plaatsen op het Activegeek weblog (komt zo meteen alsnog). Maar ik merkte dat de site heel erg traag was.

Toen ik ging kijken binnen Virtualmin (de beheeromgeving van de server) hoe dat zou kunnen, zag ik daar dat de server inderdaad stond te blazen. De CPU load averages kwamen ver boven de 40 uit, terwijl die idealiter bij deze server onder de 2.0 zou moeten blijven. De server bereiken via het admin-scherm ging gelukkig nog, maar WordPress trok het niet meer.

Toen ik in de Apache Access log keek om te zien wat of wie er dan zoveel beslag legde op de server, werd al snel duidelijk wat er aan de hand was: mijn server had te maken met een “WordPress Brute Force Attack“.


Het logbestand liep namelijk vol met verzoeken voor het bestand wp-login.php vanuit een groot aantal verschillende IP-adressen.
Ik heb, nu de aanval voorbij is, het logbestand even gedownload en geanalyseerd. In totaal duurde de aanval 2 uur (totdat ik hem kon stoppen) en in die tijd werd er 21.715 keer geprobeerd in te loggen vanuit 1.957 verschillende IP-adressen.

Hoe stop je zo’n aanval?
Mocht je hier komen via Google en jouw server staat ook te stomen, eerst maar even de oplossing die mijn server weer adem gaf: Dat was het (tijdelijk) aanpassen van het .htaccess bestand op je server. Ik heb daarin de volgende regel (bovenaan) toegevoegd: RewriteRule ^wp-login http://google.nl/ [L]
Hierdoor wordt elk verzoek voor de login-pagina doorgestuurd naar Google. Eigenlijk niet netjes omdat ik nu de aanval doorstuur naar Google, het zou ook hiermee moeten werken: RewriteRule ^wp-login http://%{REMOTE_ADDR}/$ [L] (je stuurt hem nu door naar zichzelf) maar ik kon op dat moment even niets beters verzinnen.

Zoals je in de grafiek boven bij het bericht kunt zien, zakte de aanval (ik voerde de aanpassing om 12:30 uur in) daarna snel in en de CPU load zakte ook weer naar zijn normale niveau terug.

Wat is een Brute Force Attack?
Bij een Brute Force Attack probeert een hacker heel lomp (met brute kracht) toegang te krijgen tot je WordPress installatie door simpelweg een groot aantal combinaties van wachtwoorden uit te proberen. Dat doet zo’n hacker niet vanaf één computer, maar vanaf een groot aantal computers die hij/zij in een eerder stadium al eens gehackt heeft. Als ik pech gehad had, dan was de aanval gelukt voordat ik het opgemerkt had en dan had de hacker admin toegang gehad tot mijn WordPress weblog..

Hoe voorkom je zo’n aanval?
Er is een pagina op de WordPress website waarin een aantal verschillende opties wordt besproken om zo’n aanval af te slaan. Een aantal van de eenvoudige opties had ik gelukkig al uitgevoerd: mijn weblogs hebben niet langer een administrator-account dat als usernaam “admin” of “administrator” heeft.  Ook de naam van je weblog zelf (“activegeek” in mijn geval) is niet verstandig, ik zag namelijk dat ook die als username geprobeerd werd. Het idee achter het aanpassen van die account-naam is je anders een hacker al 50% van het totale geheim (account-naam + wachtwoord) cadeau geeft. Zolang een Brute Force Attack op mijn weblog een account-naam gebruikt die niet bestaat, komt zo’n hacker op die manier in ieder geval nooit binnen. En zorg voor een sterk wachtwoord!
Daarnaast heeft mijn weblog geen gebruiker meer met user-id = 1. Dat is standaard wel zo, dat is namelijk normaal gesproken het admin-account dat bij installatie wordt aangemaakt. Bij een Brute Force Attack heeft een hacker er niets aan, maar bij een fout in een plugin waarbij hij op afstand SQL-code op mijn database los kan laten kan dat zo’n hacker wel helpen (en nu dus niet).
Ook is de prefix van de tabellen in mijn database niet langer “wp_”, ook dat maakt het moeilijker om via SQL-code iets te veranderen in de database.

Je hoeft die aanpassingen gelukkig niet allemaal zelf door te voeren. Er zijn een aantal WordPress plugins die hiermee kunnen helpen. Eentje die ik zelf gebruik is “Better WP Security“. Daarmee kun je de admin naam en ID aanpassen, een backup voor je database plannen (ook belangrijk!), het aantal keren dat iemand tevergeefs probeert in te loggen instellen en nog veel meer. In dat laatste geval is het al handig dat je een mail krijgt als zo’n aanval plaats vindt. Dan kun je er op dat moment alsnog voor kiezen om tijdelijk de .htaccess hack toe te passen en het inloggen helemaal uit te zetten. Alleen is dat natuurlijk niet zo handig als je met meerdere personen ook daadwerkelijk gebruik wilt kunnen maken van de site.

Een andere optie die ook genoemd wordt is het gebruik van CloudFlare. Daar heb ik nog geen ervaring mee, het aanpassen van mijn nameservers voor de .nl domeinen die ik heb moet via de helpdesk van Bhosted (waar ze geregistreerd zijn) gebeuren.
Wel heb ik dit codeblok aan mijn .htaccess toegevoegd:

<lIfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{REQUEST_METHOD} POST
RewriteCond %{REQUEST_URI} .(wp-comments-post|wp-login)\.php*
RewriteCond %{HTTP_REFERER} !.*activegeek.nl.* [OR]
RewriteCond %{HTTP_USER_AGENT} ^$
RewriteRule (.*) http://%{REMOTE_ADDR}/$ [R=301,L]
</ifModule>

Het zou moeten voorkomen dat een hacker de login-pagina aanroept zonder dat het formulier vanaf de site opgestuurd wordt, maar het lijkt er op het moment op dat dat zeker niet 100% van de pogingen tegen houdt, want de afgelopen uren werden toch nog 13 IP-adressen automatisch geblokkeerd omdat ze te vaak hadden geprobeerd in te loggen. Gelukkig geen nieuwe aanval, maar wel iets om in de gaten te houden.

p.s. de grafiek boven bij het bericht laat het aantal login-pogingen per minuut zien. Zelfs bij zo’n 250 login pogingen per minuut kwam mijn server, die normaal dus niet veel te doen heeft al tot stilstand. Dat vind ik zelf redelijk snel, dus als iemand daar nog tips voor heeft, dan hou ik me aanbevolen.