Beheerlogins beschermen tegen brute force: brute-force-bescherming voor elke login

Kort gezegd: Werkzame brute-force-bescherming voor een login bestaat uit meerdere lagen: tweefactorauthenticatie voor alle beheerders, een rem op aanmeldpogingen in de webserver, automatische blokkades op netwerkniveau en veilige wachtwoordopslag in de code. Waar mogelijk is het beheergebied bovendien alleen vanuit bekende netwerken bereikbaar.

Hoe brute-force-aanvallen op logins verlopen

Elke openbaar bereikbare aanmeldpagina wordt vroeg of laat geautomatiseerd aangevallen. Dat geldt voor CMS-logins, webshopbackends, hostingpanelen, webmail en SSH. Aanvallers hoeven daarvoor niet te weten van wie de website is; hun hulpmiddelen doorzoeken het internet naar bekende inlogadressen.

Drie varianten zijn gangbaar. Bij klassieke brute force worden veel wachtwoorden tegen één account geprobeerd. Bij password spraying wordt één veelvoorkomend wachtwoord tegen veel accounts getest om blokkades te omzeilen. Bij credential stuffing worden toegangsgegevens gebruikt die bij andere diensten zijn gestolen.

Voor directie en eigenaren is de situatie eenvoudig samen te vatten: een overgenomen beheerdersaccount is net zo gevaarlijk als een beveiligingslek in de server. Wie beheerder is, kan extensies installeren, code wijzigen en gegevens exporteren.

Zulke aanvallen zijn te herkennen aan een opeenhoping van mislukte aanmeldingen, aan POST-verzoeken op het inlogadres van veel verschillende IP-adressen en aan aanmeldpogingen met gebruikersnamen als „admin” of namen uit het colofon. Ook een merkbaar hogere serverbelasting op ongebruikelijke tijden kan erop wijzen, omdat elke aanmelding rekentijd voor de wachtwoordcontrole kost.

Brute-force-bescherming bij de login: de meest werkzame maatregelen

Niet elke maatregel past bij elk systeem. De volgende volgorde heeft zich bewezen, omdat de eerste punten het meeste effect combineren met weinig inspanning:

• Tweefactorauthenticatie voor alle accounts met beheerdersrechten. Zelfs een geraden wachtwoord volstaat dan niet. Details in de gids Tweefactorauthenticatie voor beheertoegangen.
• Unieke, lange wachtwoorden uit een wachtwoordmanager, geen gedeelde accounts.
• Rate limiting in de webserver, zodat per adres maar enkele pogingen per minuut mogelijk zijn.
• Automatische blokkades van herhaaldelijk opvallende adressen op netwerkniveau, bijvoorbeeld met Fail2ban.
• Beheergebied verkleinen: toegang alleen vanuit het bedrijfsnetwerk of via VPN, niet benodigde koppelvlakken uitschakelen.
• Uniforme foutmeldingen die niet verraden of de gebruikersnaam bestaat.
• Bewaking van mislukte aanmeldingen en melding bij opvallendheden.

Rate limiting in de webserver

Met Nginx kunt u het aantal verzoeken op een inlogadres per IP-adres beperken. Het voorbeeld toont een WordPress-aanmeldpagina; pad en PHP-overdracht past u aan uw systeem aan.

# in het http-blok
limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;

# in het server-blok
location = /wp-login.php {
    limit_req zone=login burst=3 nodelay;
    limit_req_status 429;
    # hier de gebruikelijke PHP-overdracht van uw server opnemen
    include snippets/fastcgi-php.conf;
    fastcgi_pass unix:/run/php/php-fpm.sock;
}

Onder Apache biedt de beperking van het beheergebied tot bekende adressen een eenvoudige, werkzame bescherming:

<Location "/admin">
    Require ip 192.0.2.0/24
</Location>

Het adres 192.0.2.0/24 is een plaatshouder uit het documentatiebereik; vul uw bedrijfsnetwerk of het adres van uw VPN in. Staat uw website achter een proxy of CDN, dan moet de server het echte bezoekersadres kennen, anders werkt de regel niet zoals gewenst.

Fail2ban en blokkades op netwerkniveau

Fail2ban leest logbestanden en blokkeert adressen die herhaaldelijk opvallen voor een vastgelegde tijd in de firewall. Voor de Nginx-rate-limiting levert Fail2ban al een passend filter mee:

# /etc/fail2ban/jail.local
[nginx-limit-req]
enabled  = true
port     = http,https
logpath  = /var/log/nginx/error.log
maxretry = 10
findtime = 10m
bantime  = 1h

[sshd]
enabled  = true
maxretry = 5
bantime  = 1h

Controleer na de herstart met fail2ban-client status of de jails actief zijn. Let erop uw eigen vaste adressen via ignoreip uit te zonderen, zodat u uzelf niet buitensluit. Voor aanmeldpagina's van afzonderlijke CMS'en zijn eigen filters mogelijk, maar ze moeten bij het werkelijke logformaat passen en vooraf getest worden.

Staat voor de server een CDN of proxy, dan ziet Fail2ban zonder verdere instelling alleen diens adressen. Een blokkade zou dan alle bezoekers treffen. In dat geval moet de webserver het echte bezoekersadres uit de header van de voorgeschakelde dienst overnemen, en worden blokkades beter direct bij het CDN ingesteld.

Blokkades op netwerkniveau zijn een hulpmiddel tegen massa, niet tegen gerichte aanvallen. Verspreide aanvallen vanaf zeer veel adressen met weinig pogingen per adres omzeilen elke drempel. Daarom blijft de tweede factor de belangrijkste laag, en verlaagt Fail2ban vooral belasting en logruis.

Wachtwoorden in eigen software juist opslaan

Wie eigen aanmeldingen programmeert, moet wachtwoorden nooit in leesbare tekst of met snelle hashfuncties als MD5 of SHA-1 opslaan. PHP levert met password_hash() een veilige oplossing mee die salt en methode automatisch beheert.

<?php
declare(strict_types=1);

// Bij registratie of wachtwoordwijziging
$hash = password_hash($passwort, PASSWORD_DEFAULT);

// Bij de aanmelding
if (password_verify($eingabe, $hashAusDatenbank)) {
    if (password_needs_rehash($hashAusDatenbank, PASSWORD_DEFAULT)) {
        $neu = password_hash($eingabe, PASSWORD_DEFAULT);
        // $neu in de database opslaan
    }
    // Aanmelding geslaagd, sessie-ID vernieuwen
} else {
    usleep(random_int(200000, 400000)); // gelijkmatige antwoordtijd
    // uniforme foutmelding weergeven
}

password_needs_rehash() zorgt ervoor dat oudere hashes bij de volgende login automatisch naar de actuele methode worden omgezet. Log mislukte pogingen met tijd, account en adres, zodat patronen opvallen. Aanwijzingen voor de analyse staan in de gids Webserverlogs na een aanval analyseren.

Bijzonderheden bij CMS'en, webshops en panelen

Veel systemen hebben naast de zichtbare aanmeldpagina nog andere wegen waarlangs toegangsgegevens worden gecontroleerd. Deze zij-ingangen worden bij de bescherming vaak vergeten.

• WordPress: De koppeling xmlrpc.php neemt ook aanmeldingen aan. Wordt ze niet nodig gehad, bijvoorbeeld voor oudere apps, blokkeer haar dan in de webserver. Controleer bovendien of gebruikersnamen zichtbaar zijn via auteurspagina's of de REST-koppeling, en gebruik voor beheerders namen die niet openbaar verschijnen.
• Webshops: Naast het beheergebied zijn klantaccounts een doelwit, vooral voor credential stuffing. Hier helpen rate limiting, meldingen bij nieuwe aanmeldingen en een optionele tweede factor voor klanten.
• Hostingpanelen en webmail: Deze omgevingen zijn vaak wereldwijd bereikbaar en beschermen de hele server. Ze moeten alleen vanuit bekende netwerken of via VPN bereikbaar zijn.
• SSH: Aanmelding met sleutel in plaats van wachtwoord maakt klassiek raden zinloos.

Welke beschermingsfuncties uw systeem zelf meebrengt, staat in de documentatie van de fabrikant. Extensies van derden moeten actief worden onderhouden, anders worden ze zelf een risico. Voor WordPress-beheerders vat de pagina WordPress en PHP2Shell de actuele prioriteiten samen.

Hoe helpt PHP SOS concreet?

• We inventariseren alle bereikbare aanmeldpagina's van uw servers, van CMS tot hostingpaneel, en beoordelen hun bescherming.
• We richten rate limiting, Fail2ban en toegangsbeperkingen in binnen de serververharding en testen ze.
• We begeleiden de invoering van tweefactorauthenticatie voor beheerders en documenteren noodtoegangen.
• Met de beveiligingsmonitoring houden we mislukte aanmeldingen en nieuwe beheerdersaccounts voortdurend in het oog.

Veelgestelde vragen

Bronnen

• OWASP Cheat Sheet Series (Authentication)
• BSI: aanbevelingen over veilige wachtwoorden en tweefactorauthenticatie (Duitse federale dienst voor informatiebeveiliging)
• OWASP Top 10