Skydda admininloggningar mot brute force: brute force-skydd för varje inloggning

Kort sagt: Verksamt brute force-skydd för en inloggning består av flera lager: tvåfaktorsinloggning för alla administratörer, en broms för inloggningsförsök i webbservern, automatiska spärrar på nätverksnivå och säker lösenordslagring i koden. Där det är möjligt är adminområdet dessutom bara nåbart från kända nät.

Så går brute force-angrepp mot inloggningar till

Varje offentligt nåbar inloggningssida angrips förr eller senare automatiserat. Det gäller CMS-inloggningar, butiksbackends, hostingpaneler, webbmail och SSH. Angripare behöver inte veta vem webbplatsen tillhör; deras verktyg söker igenom internet efter kända inloggningsadresser.

Tre varianter är vanliga. Vid klassisk brute force provas många lösenord mot ett konto. Vid password spraying testas ett vanligt lösenord mot många konton för att undgå spärrar. Vid credential stuffing används inloggningsuppgifter som stulits från andra tjänster.

För ledning och ägare är läget enkelt sammanfattat: Ett övertaget adminkonto är lika farligt som en sårbarhet i servern. Den som är admin kan installera tillägg, ändra kod och exportera data.

Sådana angrepp känns igen på en ansamling misslyckade inloggningar, på POST-förfrågningar mot inloggningsadressen från många olika IP-adresser och på inloggningsförsök med användarnamn som ”admin” eller namn ur impressumet. Även märkbart högre serverbelastning vid ovanliga tider kan tyda på det, eftersom varje inloggning kostar beräkningstid för lösenordskontrollen.

Brute force-skydd vid inloggningen: de mest verksamma åtgärderna

Alla åtgärder passar inte alla system. Följande ordning har visat sig fungera, eftersom de första punkterna ger mest effekt med litet arbete:

• Tvåfaktorsinloggning för alla konton med adminrättigheter. Inte ens ett gissat lösenord räcker då. Detaljer finns i guiden Tvåfaktorsinloggning för adminåtkomst.
• Unika, långa lösenord från en lösenordshanterare, inga delade konton.
• Rate limiting i webbservern, så att bara få försök per minut är möjliga per adress.
• Automatiska spärrar av upprepat misstänkta adresser på nätverksnivå, till exempel med Fail2ban.
• Minska adminområdet: åtkomst bara från företagsnätet eller via VPN, stäng av gränssnitt som inte behövs.
• Enhetliga felmeddelanden som inte röjer om användarnamnet finns.
• Övervakning av misslyckade inloggningar och avisering vid avvikelser.

Rate limiting i webbservern

Med Nginx går det att begränsa antalet förfrågningar mot en inloggningsadress per IP-adress. Exemplet visar en WordPress-inloggningssida; sökväg och PHP-överlämning anpassar ni till ert system.

# i http-blocket
limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;

# i server-blocket
location = /wp-login.php {
    limit_req zone=login burst=3 nodelay;
    limit_req_status 429;
    # bind in serverns vanliga PHP-överlämning här
    include snippets/fastcgi-php.conf;
    fastcgi_pass unix:/run/php/php-fpm.sock;
}

Under Apache ger en begränsning av adminområdet till kända adresser ett enkelt, verksamt skydd:

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

Adressen 192.0.2.0/24 är en platshållare ur dokumentationsområdet; sätt in ert företagsnät eller adressen till ert VPN. Ligger er webbplats bakom en proxy eller ett CDN måste servern känna till besökarens verkliga adress, annars fungerar regeln inte som avsett.

Fail2ban och spärrar på nätverksnivå

Fail2ban läser loggfiler och spärrar adresser som upprepat sticker ut i brandväggen under en fastställd tid. För Nginx rate limiting har Fail2ban redan ett lämpligt filter med sig:

# /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

Kontrollera efter omstarten med fail2ban-client status att jailsen är aktiva. Se till att undanta era egna fasta adresser via ignoreip, så att ni inte låser ute er själva. För inloggningssidor i enskilda CMS går egna filter att använda, men de måste passa det faktiska loggformatet och testas i förväg.

Står ett CDN eller en proxy framför servern ser Fail2ban utan ytterligare inställning bara dess adresser. En spärr skulle då drabba alla besökare. I så fall måste webbservern ta över den verkliga besökaradressen ur headern från den förkopplade tjänsten, och spärrar sätts bättre direkt hos CDN:et.

Spärrar på nätverksnivå är ett verktyg mot massangrepp, inte mot riktade angrepp. Distribuerade angrepp från mycket många adresser med få försök per adress underskrider varje tröskel. Därför förblir den andra faktorn det viktigaste lagret, och Fail2ban sänker framför allt belastning och loggbrus.

Lagra lösenord rätt i egen programvara

Den som programmerar egna inloggningar bör aldrig lagra lösenord i klartext eller med snabba hashfunktioner som MD5 eller SHA-1. PHP har med password_hash() en säker lösning som hanterar salt och metod automatiskt.

<?php
declare(strict_types=1);

// Vid registrering eller lösenordsändring
$hash = password_hash($passwort, PASSWORD_DEFAULT);

// Vid inloggning
if (password_verify($eingabe, $hashAusDatenbank)) {
    if (password_needs_rehash($hashAusDatenbank, PASSWORD_DEFAULT)) {
        $neu = password_hash($eingabe, PASSWORD_DEFAULT);
        // spara $neu i databasen
    }
    // Inloggning lyckades, förnya sessions-ID
} else {
    usleep(random_int(200000, 400000)); // jämn svarstid
    // visa ett enhetligt felmeddelande
}

password_needs_rehash() ser till att äldre hashar vid nästa inloggning automatiskt ställs om till den aktuella metoden. Fel försök loggar ni med tid, konto och adress, så att mönster syns. Anvisningar om utvärdering står i guiden Analysera webbserverloggar efter ett angrepp.

Särdrag hos CMS, butiker och paneler

Många system har vid sidan av den synliga inloggningssidan fler vägar där inloggningsuppgifter kontrolleras. De bakdörrarna glöms ofta bort i skyddet.

• WordPress: Gränssnittet xmlrpc.php tar också emot inloggningar. Behövs det inte, till exempel för äldre appar, spärra det i webbservern. Kontrollera dessutom om användarnamn syns via författarsidor eller REST-gränssnittet, och använd för administratörer namn som inte visas offentligt.
• Butiker: Vid sidan av adminområdet är kundkonton ett mål, särskilt för credential stuffing. Här hjälper rate limiting, aviseringar vid nya inloggningar och en valfri andra faktor för kunder.
• Hostingpaneler och webbmail: Dessa gränssnitt är ofta nåbara över hela världen och skyddar hela servern. De bör bara vara nåbara från kända nät eller via VPN.
• SSH: Inloggning med nyckel i stället för lösenord gör klassisk gissning verkningslös.

Vilka skyddsfunktioner ert system har med sig står i tillverkarens dokumentation. Tillägg från tredje part bör underhållas aktivt, annars blir de själva en risk. För WordPress-ägare sammanfattar sidan WordPress och PHP2Shell de aktuella prioriteringarna.

Hur hjälper PHP SOS konkret?

• Vi kartlägger alla nåbara inloggningssidor på era servrar, från CMS till hostingpanel, och bedömer deras skydd.
• Vi sätter upp rate limiting, Fail2ban och åtkomstbegränsningar inom ramen för serverhärdningen och testar dem.
• Vi stöttar införandet av tvåfaktorsinloggning för administratörer och dokumenterar nödåtkomster.
• Med säkerhetsövervakningen har vi löpande koll på misslyckade inloggningar och nya adminkonton.

Vanliga frågor

Källor

• OWASP Cheat Sheet Series (Authentication)
• BSI: rekommendationer om säkra lösenord och tvåfaktorsinloggning
• OWASP Top 10