Cum protejați autentificările de admin împotriva brute force: protecție brute force pentru orice autentificare

Pe scurt: O protecție brute force eficientă pentru o autentificare constă din mai multe straturi: autentificare cu doi factori pentru toți adminii, o frână pentru încercările de autentificare în serverul web, blocări automate la nivel de rețea și o stocare sigură a parolelor în cod. Acolo unde este posibil, zona de admin este în plus accesibilă doar din rețele cunoscute.

Cum decurg atacurile brute force asupra autentificărilor

Orice pagină de autentificare accesibilă public este atacată mai devreme sau mai târziu în mod automatizat. Aceasta privește autentificările CMS, backend-urile magazinelor, panourile de hosting, webmail și SSH. Atacatorii nu trebuie să știe cui aparține site-ul; instrumentele lor scotocesc internetul după adrese de autentificare cunoscute.

Sunt răspândite trei variante. La brute force clasic sunt încercate multe parole împotriva unui cont. La password spraying este testată o parolă frecventă împotriva multor conturi, pentru a ocoli blocările. La credential stuffing sunt folosite date de acces furate de la alte servicii.

Pentru conducere și proprietari, situația se rezumă simplu: un cont de admin preluat este la fel de periculos ca o vulnerabilitate a serverului. Cine este admin poate instala extensii, modifica cod și exporta date.

Asemenea atacuri se recunosc după o acumulare de autentificări eșuate, după cereri POST către adresa de autentificare de la multe adrese IP diferite și după încercări de autentificare cu nume de utilizator precum „admin” sau nume din impresum. Și o sarcină sensibil mai mare a serverului la ore neobișnuite poate indica acest lucru, deoarece fiecare autentificare costă timp de calcul pentru verificarea parolei.

Protecție brute force la autentificare: cele mai eficiente măsuri

Nu orice măsură se potrivește fiecărui sistem. Ordinea următoare s-a dovedit utilă, deoarece primele puncte combină cel mai mult efect cu puțin efort:

• Autentificare cu doi factori pentru toate conturile cu drepturi de admin. Chiar și o parolă ghicită nu mai este atunci suficientă. Detalii în ghidul Autentificare cu doi factori pentru accesurile de admin.
• Parole unice și lungi dintr-un manager de parole, fără conturi partajate.
• Rate limiting în serverul web, pentru ca pentru fiecare adresă să fie posibile doar câteva încercări pe minut.
• Blocări automate ale adreselor suspecte în mod repetat, la nivel de rețea, de exemplu cu Fail2ban.
• Micșorați zona de admin: acces doar din rețeaua firmei sau prin VPN, dezactivați interfețele care nu sunt necesare.
• Mesaje de eroare uniforme, care nu dezvăluie dacă numele de utilizator există.
• Monitorizarea autentificărilor eșuate și notificare la anomalii.

Rate limiting în serverul web

Cu Nginx se poate limita numărul de cereri către o adresă de autentificare pentru fiecare adresă IP. Exemplul arată o pagină de autentificare WordPress; adaptați calea și transmiterea către PHP la sistemul dumneavoastră.

# în blocul http
limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;

# în blocul server
location = /wp-login.php {
    limit_req zone=login burst=3 nodelay;
    limit_req_status 429;
    # includeți aici transmiterea obișnuită către PHP a serverului dumneavoastră
    include snippets/fastcgi-php.conf;
    fastcgi_pass unix:/run/php/php-fpm.sock;
}

Pe Apache, restrângerea zonei de admin la adrese cunoscute oferă o protecție simplă și eficientă:

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

Adresa 192.0.2.0/24 este un substituent din domeniul documentației; introduceți rețeaua firmei dumneavoastră sau adresa VPN-ului. Dacă site-ul dumneavoastră se află în spatele unui proxy sau CDN, serverul trebuie să cunoască adresa reală a vizitatorului, altfel regula nu acționează așa cum doriți.

Fail2ban și blocări la nivel de rețea

Fail2ban citește fișiere de log și blochează în firewall, pentru un timp stabilit, adresele care atrag repetat atenția. Pentru rate limiting-ul Nginx, Fail2ban vine deja cu un filtru potrivit:

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

După repornire, verificați cu fail2ban-client status dacă jail-urile sunt active. Aveți grijă să excludeți propriile adrese fixe prin ignoreip, pentru a nu vă bloca singur. Pentru paginile de autentificare ale unor CMS-uri individuale sunt posibile filtre proprii, dar ele trebuie să se potrivească formatului real al logului și trebuie testate în prealabil.

Dacă în fața serverului se află un CDN sau un proxy, Fail2ban vede fără alte setări doar adresele acestuia. O blocare ar lovi atunci toți vizitatorii. În acest caz, serverul web trebuie să preia adresa reală a vizitatorului din antetul serviciului din față, iar blocările se setează mai bine direct la CDN.

Blocările la nivel de rețea sunt un instrument împotriva maselor, nu împotriva atacurilor țintite. Atacurile distribuite din foarte multe adrese, cu puține încercări pe adresă, ocolesc orice prag. De aceea, al doilea factor rămâne cel mai important strat, iar Fail2ban reduce mai ales sarcina și zgomotul din loguri.

Cum stocați corect parolele în software propriu

Cine programează autentificări proprii nu ar trebui să stocheze niciodată parolele în text clar sau cu funcții hash rapide precum MD5 sau SHA-1. PHP vine cu password_hash() o soluție sigură, care gestionează automat salt-ul și metoda.

<?php
declare(strict_types=1);

// La înregistrare sau la schimbarea parolei
$hash = password_hash($passwort, PASSWORD_DEFAULT);

// La autentificare
if (password_verify($eingabe, $hashAusDatenbank)) {
    if (password_needs_rehash($hashAusDatenbank, PASSWORD_DEFAULT)) {
        $neu = password_hash($eingabe, PASSWORD_DEFAULT);
        // salvați $neu în baza de date
    }
    // Autentificare reușită, reînnoiți ID-ul de sesiune
} else {
    usleep(random_int(200000, 400000)); // timp de răspuns uniform
    // afișați un mesaj de eroare uniform
}

password_needs_rehash() face ca hashurile mai vechi să fie trecute automat la metoda actuală la următoarea autentificare. Înregistrați încercările eșuate cu ora, contul și adresa, pentru ca tiparele să iasă în evidență. Indicații despre evaluare găsiți în ghidul Cum analizați logurile serverului web după un atac.

Particularități la CMS-uri, magazine și panouri

Multe sisteme au, pe lângă pagina de autentificare vizibilă, alte căi prin care sunt verificate datele de acces. Aceste intrări laterale sunt adesea uitate la protecție.

• WordPress: Interfața xmlrpc.php primește și ea autentificări. Dacă nu este necesară, de exemplu pentru aplicații mai vechi, blocați-o în serverul web. Verificați, de asemenea, dacă numele de utilizator sunt vizibile prin paginile de autori sau prin interfața REST și folosiți pentru admini nume care nu apar public.
• Magazine: Pe lângă zona de admin, conturile clienților sunt o țintă, mai ales pentru credential stuffing. Aici ajută rate limiting, notificările la autentificări noi și un al doilea factor opțional pentru clienți.
• Panouri de hosting și webmail: Aceste interfețe sunt adesea accesibile din toată lumea și protejează întregul server. Ele ar trebui să fie accesibile doar din rețele cunoscute sau prin VPN.
• SSH: Autentificarea cu cheie în loc de parolă face inutilă ghicirea clasică.

Ce funcții de protecție aduce sistemul dumneavoastră însuși se află în documentația producătorului. Extensiile terților ar trebui să fie întreținute activ, altfel devin ele însele un risc. Pentru operatorii WordPress, pagina WordPress și PHP2Shell rezumă prioritățile actuale.

Cum ajută PHP SOS concret?

• Inventariem toate paginile de autentificare accesibile ale serverelor dumneavoastră, de la CMS până la panoul de hosting, și evaluăm protecția lor.
• Configurăm rate limiting, Fail2ban și restricții de acces în cadrul securizării serverului și le testăm.
• Însoțim introducerea autentificării cu doi factori pentru admini și documentăm accesurile de urgență.
• Cu monitorizarea de securitate urmărim continuu autentificările eșuate și conturile noi de admin.

Întrebări frecvente

Surse

• OWASP Cheat Sheet Series (Authentication)
• BSI: recomandări privind parolele sigure și autentificarea cu doi factori
• OWASP Top 10