Beskyt admin-logins mod brute force: brute force-beskyttelse til ethvert login

Kort sagt: Virksom brute force-beskyttelse af et login består af flere lag: tofaktor-login for alle admins, en bremse for loginforsøg i webserveren, automatiske spærringer på netværksniveau og sikker adgangskodelagring i koden. Hvor det er muligt, kan admin-området desuden kun nås fra kendte netværk.

Sådan forløber brute force-angreb på logins

Enhver offentligt tilgængelig loginside bliver før eller siden angrebet automatiseret. Det gælder CMS-logins, shop-backends, hostingpaneler, webmail og SSH. Angribere behøver ikke vide, hvem websitet tilhører; deres værktøjer gennemsøger internettet efter kendte login-adresser.

Tre varianter er udbredte. Ved klassisk brute force prøves mange adgangskoder mod én konto. Ved password spraying testes en hyppig adgangskode mod mange konti for at omgå spærringer. Ved credential stuffing bruges adgangsdata, der er stjålet hos andre tjenester.

For ledelse og ejere kan situationen sammenfattes enkelt: En overtaget admin-konto er lige så farlig som en sårbarhed i serveren. Den, der er admin, kan installere udvidelser, ændre kode og eksportere data.

Sådanne angreb kan genkendes på en ophobning af mislykkede logins, på POST-forespørgsler til login-adressen fra mange forskellige IP-adresser og på loginforsøg med brugernavne som „admin“ eller navne fra kolofonen. Også en mærkbart højere serverbelastning på usædvanlige tidspunkter kan pege på det, fordi hvert login koster regnetid til adgangskodekontrollen.

Brute force-beskyttelse ved login: de mest virksomme foranstaltninger

Ikke enhver foranstaltning passer til ethvert system. Følgende rækkefølge har vist sit værd, fordi de første punkter forener mest virkning med lidt arbejde:

• Tofaktor-login for alle konti med admin-rettigheder. Selv en gættet adgangskode er så ikke nok. Enkeltheder i vejledningen Tofaktor-login til admin-adgange.
• Unikke, lange adgangskoder fra en adgangskodemanager, ingen delte konti.
• Rate limiting i webserveren, så der kun er få forsøg pr. minut pr. adresse.
• Automatiske spærringer af gentagne påfaldende adresser på netværksniveau, f.eks. med Fail2ban.
• Gør admin-området mindre: adgang kun fra firmanetværket eller via VPN, slå ikke-nødvendige grænseflader fra.
• Ensartede fejlmeddelelser, som ikke afslører, om brugernavnet findes.
• Overvågning af mislykkede logins og underretning ved påfaldende forhold.

Rate limiting i webserveren

Med Nginx kan antallet af forespørgsler til en login-adresse begrænses pr. IP-adresse. Eksemplet viser en WordPress-loginside; sti og PHP-videregivelse tilpasser I til jeres system.

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

# i server-blokken
location = /wp-login.php {
    limit_req zone=login burst=3 nodelay;
    limit_req_status 429;
    # indbind her jeres servers sædvanlige PHP-videregivelse
    include snippets/fastcgi-php.conf;
    fastcgi_pass unix:/run/php/php-fpm.sock;
}

Under Apache giver begrænsningen af admin-området til kendte adresser en enkel, virksom beskyttelse:

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

Adressen 192.0.2.0/24 er en pladsholder fra dokumentationsområdet; sæt jeres firmanetværk eller adressen på jeres VPN ind. Ligger jeres website bag en proxy eller CDN, skal serveren kende den rigtige besøgsadresse, ellers virker reglen ikke som ønsket.

Fail2ban og spærringer på netværksniveau

Fail2ban læser logfiler og spærrer adresser, der gentagne gange falder i øjnene, i en fastlagt tid i firewallen. Til Nginx-rate limiting har Fail2ban allerede et passende filter med:

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

Kontrollér efter genstarten med fail2ban-client status, om jails er aktive. Sørg for at undtage jeres egne faste adresser via ignoreip, så I ikke låser jer selv ude. Til loginsider i enkelte CMS er egne filtre mulige, men de skal passe til det faktiske logformat og testes først.

Står der en CDN eller proxy foran serveren, ser Fail2ban uden yderligere indstilling kun dennes adresser. En spærring ville så ramme alle besøgende. I så fald skal webserveren overtage den rigtige besøgsadresse fra headeren fra den foranliggende tjeneste, og spærringer sættes bedre direkte hos CDN'et.

Spærringer på netværksniveau er et værktøj mod masse, ikke mod målrettede angreb. Distribuerede angreb fra meget mange adresser med få forsøg pr. adresse underløber enhver tærskel. Derfor forbliver den anden faktor det vigtigste lag, og Fail2ban sænker først og fremmest belastning og logstøj.

Gem adgangskoder rigtigt i egen software

Den, der programmerer egne logins, bør aldrig gemme adgangskoder i klartekst eller med hurtige hash-funktioner som MD5 eller SHA-1. PHP har med password_hash() en sikker løsning med, som selv håndterer salt og metode.

<?php
declare(strict_types=1);

// Ved registrering eller ændring af adgangskode
$hash = password_hash($passwort, PASSWORD_DEFAULT);

// Ved login
if (password_verify($eingabe, $hashAusDatenbank)) {
    if (password_needs_rehash($hashAusDatenbank, PASSWORD_DEFAULT)) {
        $neu = password_hash($eingabe, PASSWORD_DEFAULT);
        // gem $neu i databasen
    }
    // login lykkedes, forny session-ID
} else {
    usleep(random_int(200000, 400000)); // ensartet svartid
    // udskriv ensartet fejlmeddelelse
}

password_needs_rehash() sørger for, at ældre hashes ved næste login automatisk omstilles til den aktuelle metode. Fejlforsøg logger I med tid, konto og adresse, så mønstre falder i øjnene. Henvisninger til analysen står i vejledningen Analysér weblogs efter et angreb.

Særligheder ved CMS, shops og paneler

Mange systemer har ud over den synlige loginside andre veje, hvorigennem adgangsdata kontrolleres. Disse sideindgange glemmes ofte ved beskyttelsen.

• WordPress: Grænsefladen xmlrpc.php modtager også logins. Bruges den ikke, f.eks. til ældre apps, så spær den i webserveren. Kontrollér desuden, om brugernavne er synlige via forfattersider eller REST-grænsefladen, og brug til admins navne, som ikke fremgår offentligt.
• Shops: Ved siden af admin-området er kundekonti et mål, især for credential stuffing. Her hjælper rate limiting, underretninger ved nye logins og en valgfri anden faktor for kunder.
• Hostingpaneler og webmail: Disse flader kan ofte nås fra hele verden og beskytter hele serveren. De bør kun kunne nås fra kendte netværk eller via VPN.
• SSH: Login med nøgle i stedet for adgangskode gør klassisk gætteri virkningsløst.

Hvilke beskyttelsesfunktioner jeres system selv har med, står i producentens dokumentation. Udvidelser fra tredjepart bør være aktivt vedligeholdt, ellers bliver de selv en risiko. For WordPress-driftsansvarlige sammenfatter siden WordPress og PHP2Shell de aktuelle prioriteter.

Hvordan hjælper PHP SOS konkret?

• Vi kortlægger alle tilgængelige loginsider på jeres servere, fra CMS til hostingpanel, og vurderer deres beskyttelse.
• Vi opsætter rate limiting, Fail2ban og adgangsbegrænsninger inden for rammerne af serverhærdningen og tester dem.
• Vi følger indførelsen af tofaktor-login for admins og dokumenterer nødadgange.
• Med sikkerhedsovervågningen holder vi løbende øje med fejllogins og nye admin-konti.

Ofte stillede spørgsmål

Kilder

• OWASP Cheat Sheet Series (Authentication)
• BSI (det tyske forbundskontor for informationssikkerhed): anbefalinger om sikre adgangskoder og tofaktor-login
• OWASP Top 10