Another one bites the dust

De laatste dagen wordt OBA erg geplaagd door bots die proberen in te loggen als admin.
Het is geen gerichte aanval.
Afgezien van het feit dat het script het password probeert te raden aan de hand van een woordenlijst waar het password niet uit afkomstig is, bestaat ook de gebruiker “admin” niet.
We zijn dus redelijk safe, maar de beheerder krijgt wel bij elke mislukte poging een waarschuwing.
Ik zag in de log meerdere pogingen binnen 1 minuut, niet gek dus dat de beheerder me vroeg om hier iets aan te doen.
Dat was nog niet eens zo simpel.
Een vorig script was nog erg makkelijk af te slaan, doordat het een zeer oude browser nabootste, maar dit script presenteert zichzelf als een recente versie van Firefox, en vult zelfs het referer-veld in met de naam van de website die hij aanvalt.

De bot gaat zonder omwegen naar wp-login.php
Er is een plugin die daar een stokje voor steekt, en die heb ik eerst maar eens geïnstalleerd.
HC Custom WP-Admin URL zorgt er voor dat de url die je nodig hebt om in te loggen verandert in een waarde die je zelf kan instellen.
Hij verandert niets aan wp-login.php, maar hij voegt een redirect toe aan de .htaccess file.
Je kan nog steeds via de oude url wp-login.php bereiken, maar doordat de plugin zichzelf tussen wp-login.php en wordpress nestelt, kom je daarlangs niet meer binnen.
Dat loste het probleem al voor 99% op.
Nog op te lossen was :

• Inloggen gebeurt op de back-end en ik houd bots bij voorkeur al op de proxy-server tegen.
• De links die wordpress genereert werken niet meer.

Hoewel een deel van de beveiliging weer ongedaan gemaakt wordt, als je je login links openbaar maakt, kun je daar met een groot ledenbestand niet omheen.
Ik heb dus wat code toegevoegd aan de plugin, zodat hij zelf geldige links produceert als wordpress de login link op de voorpagina probeert te schrijven. Dat was iets lastiger dan het leek; in de testomgeving werkte het goed, maar in productie ontstond er een redirect-loop, waardoor ik niet kon inloggen. De truuk was, om ?reauth=1 achter de login link te plakken. Het is een parameter die wordpress vertelt dat je wil inloggen, zelfs als je al een loggedin cookie hebt. Kennelijk voorkomt het tevens dat wordpress een redirect terugstuurt.

De bot gebruikt een fake referer als hij wp-login.php opvraagt. Het is de hostnaam zelf, gevolgd door /wp-login.php
In werkelijkheid heeft hij de site niet eerder bezocht. Echte logins zullen de nieuwe url als referer hebben, dus ik heb speciaal voor dit geval een rule in de proxyserver opgenomen : bij proberen om in te loggen met deze referer krijg je een error 404.
Dat gebeurt met opzet, omdat error 404 de fail2ban server waarschuwt. Probeer je het nog een keer, dan krijg je een 24 uur ip-ban.
Die rule bestond al, want daarmee worden alle bots die desperately op zoek zijn naar een beveiligingslek geweerd.
Fail2ban kost 1% cpu-tijd, maar het is wel de makkelijkste manier om dit soort bots buiten de deur te houden. Het zou PHP veel meer kosten om hetzelfde te doen.