Zaščita skrbniških prijav pred brute force: zaščita pred brute force za vsako prijavo

Na kratko: Učinkovita zaščita pred brute force za prijavo je sestavljena iz več slojev: dvofaktorska prijava za vse skrbnike, zavora za poskuse prijave v spletnem strežniku, samodejne blokade na ravni omrežja in varno shranjevanje gesel v kodi. Kjer je mogoče, naj bo skrbniško območje dodatno dosegljivo samo iz znanih omrežij.

Kako potekajo napadi brute force na prijave

Vsaka javno dosegljiva prijavna stran je prej ali slej tarča samodejnih napadov. To velja za prijave v CMS, zaledja trgovin, upravljalne panele gostovanja, spletno pošto in SSH. Napadalcem za to ni treba vedeti, čigava je spletna stran; njihova orodja po internetu iščejo znane naslove prijav.

Razširjene so tri različice. Pri klasičnem brute force se veliko gesel preizkuša na enem računu. Pri password sprayingu se eno pogosto geslo preizkuša na številnih računih, da se zaobidejo blokade. Pri credential stuffingu se uporabljajo dostopni podatki, ukradeni pri drugih storitvah.

Za vodstvo in lastnike je stanje preprosto povzeto: prevzet skrbniški račun je tako nevaren kot varnostna ranljivost na strežniku. Kdor je skrbnik, lahko nameščanja razširitve, spreminja kodo in izvaža podatke.

Takšne napade prepoznate po kopičenju neuspelih prijav, po zahtevah POST na naslov prijave iz številnih različnih naslovov IP in po poskusih prijave z uporabniškimi imeni, kot je „admin“, ali z imeni iz kolofona. Tudi občutno višja obremenitev strežnika ob nenavadnih urah lahko kaže na to, ker vsaka prijava za preverjanje gesla zahteva računski čas.

Zaščita pred brute force pri prijavi: najučinkovitejši ukrepi

Vsak ukrep ne ustreza vsakemu sistemu. Naslednje zaporedje se je obneslo, ker prve točke z malo napora dosežejo največ:

• Dvofaktorska prijava za vse račune s skrbniškimi pravicami. Tudi ugibano geslo potem ne zadošča. Podrobnosti v vodniku Dvofaktorska prijava za skrbniške dostope.
• Edinstvena, dolga gesla iz upravljalnika gesel, brez skupnih računov.
• Rate limiting v spletnem strežniku, da je na naslov mogoče le nekaj poskusov na minuto.
• Samodejne blokade ponavljajoče sumljivih naslovov na ravni omrežja, na primer s Fail2ban.
• Zmanjšajte skrbniško območje: dostop samo iz podjetniškega omrežja ali prek VPN, nepotrebne vmesnike izklopite.
• Enotna sporočila o napakah, ki ne izdajo, ali uporabniško ime obstaja.
• Nadzor neuspelih prijav in obvestilo ob nepravilnostih.

Rate limiting v spletnem strežniku

Z Nginxom je mogoče število zahtev na naslov prijave omejiti na naslov IP. Primer prikazuje prijavno stran WordPressa; pot in predajo PHP prilagodite svojemu sistemu.

# v bloku http
limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;

# v bloku server
location = /wp-login.php {
    limit_req zone=login burst=3 nodelay;
    limit_req_status 429;
    # tu vključite običajno predajo PHP vašega strežnika
    include snippets/fastcgi-php.conf;
    fastcgi_pass unix:/run/php/php-fpm.sock;
}

Pri Apacheju omejitev skrbniškega območja na znane naslove ponuja preprosto, učinkovito zaščito:

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

Naslov 192.0.2.0/24 je nadomestni znak iz dokumentacijskega območja; vstavite svoje podjetniško omrežje ali naslov svojega VPN. Če je vaša spletna stran za proxyjem ali CDN, mora strežnik poznati pravi naslov obiskovalca, sicer pravilo ne deluje po željah.

Fail2ban in blokade na ravni omrežja

Fail2ban bere dnevniške datoteke in naslove, ki se ponavljajoče izpostavljajo, za določen čas blokira v požarnem zidu. Za rate limiting Nginx Fail2ban že prinaša ustrezen filter:

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

Po ponovnem zagonu s fail2ban-client status preverite, ali so jaili aktivni. Pazite, da z ignoreip izvzamete svoje stalne naslove, da se ne zaklenete sami. Za prijavne strani posameznih CMS-jev so mogoči lastni filtri, vendar morajo ustrezati dejanski obliki dnevnika in jih je treba prej preizkusiti.

Če je pred strežnikom CDN ali proxy, Fail2ban brez dodatnih nastavitev vidi samo njegove naslove. Blokada bi tedaj zadela vse obiskovalce. V tem primeru mora spletni strežnik pravi naslov obiskovalca prevzeti iz glave predhodne storitve, blokade pa je bolje nastaviti neposredno pri CDN.

Blokade na ravni omrežja so orodje proti množici, ne proti ciljnim napadom. Porazdeljeni napadi iz zelo veliko naslovov z malo poskusi na naslov zaobidejo vsak prag. Zato ostaja drugi faktor najpomembnejši sloj, Fail2ban pa zmanjšuje predvsem obremenitev in šum v dnevnikih.

Pravilno shranjevanje gesel v lastni programski opremi

Kdor programira lastne prijave, gesel ne sme nikoli shranjevati v čistopisu ali s hitrimi zgoščevalnimi funkcijami, kot sta MD5 ali SHA-1. PHP s password_hash() prinaša varno rešitev, ki samodejno upravlja sol in postopek.

<?php
declare(strict_types=1);

// Ob registraciji ali spremembi gesla
$hash = password_hash($passwort, PASSWORD_DEFAULT);

// Ob prijavi
if (password_verify($eingabe, $hashAusDatenbank)) {
    if (password_needs_rehash($hashAusDatenbank, PASSWORD_DEFAULT)) {
        $neu = password_hash($eingabe, PASSWORD_DEFAULT);
        // $neu shranite v podatkovno zbirko
    }
    // Prijava uspešna, obnovite ID seje
} else {
    usleep(random_int(200000, 400000)); // enakomerni odzivni čas
    // izpišite enotno sporočilo o napaki
}

password_needs_rehash() poskrbi, da se starejše zgoščene vrednosti ob naslednji prijavi samodejno preklopijo na aktualni postopek. Neuspele poskuse beležite s časom, računom in naslovom, da vzorci padejo v oči. Napotki za ovrednotenje so v vodniku Analiza dnevnikov spletnega strežnika po napadu.

Posebnosti pri CMS-jih, trgovinah in panelih

Številni sistemi imajo poleg vidne prijavne strani še druge poti, prek katerih se preverjajo dostopni podatki. Ti stranski vhodi se pri zaščiti pogosto pozabijo.

• WordPress: Vmesnik xmlrpc.php prav tako sprejema prijave. Če ga ne potrebujete, na primer za starejše aplikacije, ga blokirajte v spletnem strežniku. Preverite tudi, ali so uporabniška imena vidna prek strani avtorjev ali vmesnika REST, in za skrbnike uporabite imena, ki se javno ne pojavljajo.
• Trgovine: Poleg skrbniškega območja so tarča računi strank, še posebej za credential stuffing. Tu pomagajo rate limiting, obvestila ob novih prijavah in neobvezen drugi faktor za stranke.
• Upravljalni paneli gostovanja in spletna pošta: Ti vmesniki so pogosto dosegljivi po vsem svetu in ščitijo celoten strežnik. Dosegljivi naj bodo samo iz znanih omrežij ali prek VPN.
• SSH: Prijava s ključem namesto z geslom klasično ugibanje naredi neučinkovito.

Katere zaščitne funkcije prinaša vaš sistem sam, piše v dokumentaciji proizvajalca. Razširitve tretjih ponudnikov naj bodo aktivno vzdrževane, sicer same postanejo tveganje. Za upravljavce WordPressa stran WordPress in PHP2Shell povzema aktualne prioritete.

Kako PHP SOS pomaga konkretno?

• Zajamemo vse dosegljive prijavne strani vaših strežnikov, od CMS-ja do upravljalnega panela gostovanja, in ocenimo njihovo zaščito.
• Rate limiting, Fail2ban in omejitve dostopa vzpostavimo v okviru utrjevanja strežnika in jih preizkusimo.
• Spremljamo uvedbo dvofaktorske prijave za skrbnike in dokumentiramo zasilne dostope.
• Z varnostnim nadzorom neuspele prijave in nove skrbniške račune stalno spremljamo.

Pogosta vprašanja

Viri

• OWASP Cheat Sheet Series (Authentication)
• BSI: priporočila za varna gesla in dvofaktorsko prijavo
• OWASP Top 10