In breve: una protezione brute force efficace per un login è fatta di più livelli: autenticazione a due fattori per tutti gli admin, un freno ai tentativi di accesso nel server web, blocchi automatici a livello di rete e un salvataggio sicuro delle password nel codice. Dove possibile, l'area admin è inoltre raggiungibile solo da reti note.
Come si svolgono gli attacchi brute force ai login
Ogni pagina di login raggiungibile pubblicamente prima o poi viene attaccata in modo automatizzato. Riguarda login di CMS, backend di shop, pannelli di hosting, webmail e SSH. Per farlo gli aggressori non devono sapere a chi appartiene il sito; i loro strumenti setacciano Internet alla ricerca di indirizzi di login noti.
Sono diffuse tre varianti. Nel brute force classico si provano molte password contro un account. Nel password spraying si testa una password comune contro molti account, per aggirare i blocchi. Nel credential stuffing si usano credenziali rubate ad altri servizi.
Per direzione e titolari il quadro si riassume facilmente: un account admin preso in carico è pericoloso quanto una vulnerabilità del server. Chi è admin può installare estensioni, modificare il codice ed esportare dati.
Tali attacchi si riconoscono da un accumulo di accessi falliti, da richieste POST all'indirizzo di login da molti indirizzi IP diversi e da tentativi di accesso con nomi utente come «admin» o nomi tratti dall'impressum. Anche un carico del server sensibilmente più alto in orari insoliti può indicarlo, perché ogni accesso costa tempo di calcolo per la verifica della password.
Protezione brute force al login: le misure più efficaci
Non ogni misura si adatta a ogni sistema. Questo ordine si è dimostrato valido, perché i primi punti uniscono il massimo effetto a poco sforzo:
- Autenticazione a due fattori per tutti gli account con diritti admin. Anche una password indovinata non basta allora. Dettagli nella guida Autenticazione a due fattori per gli accessi admin.
- Password uniche e lunghe da un gestore di password, nessun account condiviso.
- Rate limiting nel server web, in modo che per ogni indirizzo siano possibili pochi tentativi al minuto.
- Blocchi automatici degli indirizzi ripetutamente sospetti a livello di rete, ad esempio con Fail2ban.
- Ridurre l'area admin: accesso solo dalla rete aziendale o tramite VPN, disattivare le interfacce non necessarie.
- Messaggi di errore uniformi che non rivelino se il nome utente esiste.
- Monitoraggio degli accessi falliti e notifica in caso di anomalie.
Rate limiting nel server web
Con Nginx si può limitare per indirizzo IP il numero di richieste a un indirizzo di login. L'esempio mostra una pagina di login di WordPress; adatti percorso e passaggio a PHP al Suo sistema.
# nel blocco http
limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;
# nel blocco server
location = /wp-login.php {
limit_req zone=login burst=3 nodelay;
limit_req_status 429;
# qui inserire il consueto passaggio a PHP del Suo server
include snippets/fastcgi-php.conf;
fastcgi_pass unix:/run/php/php-fpm.sock;
}
Con Apache, la restrizione dell'area admin a indirizzi noti offre una protezione semplice ed efficace:
<Location "/admin">
Require ip 192.0.2.0/24
</Location>
L'indirizzo 192.0.2.0/24 è un segnaposto dell'intervallo riservato alla documentazione; inserisca la Sua rete aziendale o l'indirizzo della Sua VPN. Se il Suo sito si trova dietro un proxy o una CDN, il server deve conoscere il vero indirizzo del visitatore, altrimenti la regola non funziona come desiderato.
Fail2ban e blocchi a livello di rete
Fail2ban legge i file di log e blocca nel firewall, per un tempo stabilito, gli indirizzi che risultano ripetutamente sospetti. Per il rate limiting di Nginx, Fail2ban include già un filtro adatto:
# /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
Dopo il riavvio verifichi con fail2ban-client status che i jail siano attivi. Faccia attenzione a escludere i Suoi indirizzi fissi con ignoreip, per non bloccarsi da soli. Per le pagine di login di singoli CMS sono possibili filtri propri, ma devono essere adatti al formato di log effettivo e vanno provati prima.
Se davanti al server c'è una CDN o un proxy, Fail2ban senza ulteriori impostazioni vede solo i loro indirizzi. Un blocco colpirebbe allora tutti i visitatori. In tal caso il server web deve prendere il vero indirizzo del visitatore dall'header del servizio a monte, e i blocchi è meglio impostarli direttamente presso la CDN.
I blocchi a livello di rete sono uno strumento contro la massa, non contro gli attacchi mirati. Gli attacchi distribuiti da moltissimi indirizzi con pochi tentativi per indirizzo aggirano ogni soglia. Per questo il secondo fattore resta il livello più importante e Fail2ban riduce soprattutto carico e rumore nei log.
Salvare correttamente le password nel software proprio
Chi programma accessi propri non dovrebbe mai salvare le password in chiaro o con funzioni hash veloci come MD5 o SHA-1. PHP offre con password_hash() una soluzione sicura che gestisce automaticamente salt e algoritmo.
<?php
declare(strict_types=1);
// Alla registrazione o alla modifica della password
$hash = password_hash($passwort, PASSWORD_DEFAULT);
// Al login
if (password_verify($eingabe, $hashAusDatenbank)) {
if (password_needs_rehash($hashAusDatenbank, PASSWORD_DEFAULT)) {
$neu = password_hash($eingabe, PASSWORD_DEFAULT);
// salvare $neu nel database
}
// Accesso riuscito, rinnovare l'ID di sessione
} else {
usleep(random_int(200000, 400000)); // tempo di risposta uniforme
// restituire un messaggio di errore uniforme
}
password_needs_rehash() fa sì che gli hash più vecchi vengano convertiti automaticamente all'algoritmo attuale al login successivo. I tentativi falliti li registri con ora, account e indirizzo, in modo che gli schemi emergano. Indicazioni per l'analisi si trovano nella guida Analizzare i log del server web dopo un attacco.
Particolarità di CMS, shop e pannelli
Molti sistemi hanno, oltre alla pagina di login visibile, altre vie attraverso cui le credenziali vengono verificate. Questi ingressi secondari vengono spesso dimenticati nella protezione.
- WordPress: l'interfaccia
xmlrpc.phpaccetta anch'essa accessi. Se non serve, ad esempio per app più vecchie, la blocchi nel server web. Controlli inoltre se i nomi utente siano visibili tramite le pagine degli autori o l'interfaccia REST e usi per gli admin nomi che non compaiano pubblicamente. - Shop: oltre all'area admin sono un bersaglio gli account dei clienti, in particolare per il credential stuffing. Qui aiutano rate limiting, notifiche sui nuovi accessi e un secondo fattore facoltativo per i clienti.
- Pannelli di hosting e webmail: queste interfacce sono spesso raggiungibili in tutto il mondo e proteggono l'intero server. Dovrebbero essere raggiungibili solo da reti note o tramite VPN.
- SSH: l'accesso con chiave invece che con password rende inefficace il classico tentativo a caso.
Quali funzioni di protezione offra il Suo sistema stesso è indicato nella documentazione del produttore. Le estensioni di terze parti dovrebbero essere mantenute attivamente, altrimenti diventano esse stesse un rischio. Per i gestori WordPress la pagina WordPress e PHP2Shell riassume le priorità attuali.
Come aiuta concretamente PHP SOS?
- Rileviamo tutte le pagine di login raggiungibili dei Suoi server, dal CMS al pannello di hosting, e valutiamo la loro protezione.
- Impostiamo rate limiting, Fail2ban e restrizioni di accesso nell'ambito dell'hardening del server e li testiamo.
- Accompagniamo l'introduzione dell'autenticazione a due fattori per gli admin e documentiamo gli accessi di emergenza.
- Con il monitoraggio della sicurezza teniamo costantemente d'occhio gli accessi falliti e i nuovi account admin.
Domande frequenti
Da cosa riconosco un attacco brute force?
Sono tipici molti accessi falliti in breve tempo, spesso contro la stessa pagina di login e con nomi utente che cambiano. Nell'access log si vede come un accumulo di richieste POST all'indirizzo di login, spesso da molti indirizzi IP diversi.
Un account dovrebbe essere bloccato dopo più tentativi falliti?
Attenzione: i blocchi rigidi possono essere usati dagli aggressori per escludere gli utenti legittimi. Meglio ritardi crescenti, blocchi temporanei per indirizzo IP e una notifica al titolare dell'account.
Aiuta rinominare l'indirizzo di login?
Riduce il rumore automatizzato nei log, ma non è una vera protezione. Chi conosce o trova l'indirizzo può continuare ad attaccare. Sono efficaci l'autenticazione a due fattori, il rate limiting e una restrizione dell'area admin.
Che cos'è il credential stuffing?
Gli aggressori provano combinazioni di e-mail e password rubate ad altri servizi. Funziona se gli utenti usano la stessa password più volte. Password uniche e un secondo fattore tolgono a questo metodo la base.