Come riconoscere e bloccare i tentativi di brute force su SSH

Perché questo controllo va fatto subito

Un server esposto su SSH riceve tentativi automatici in modo continuo. Nella maggior parte dei casi non si tratta di un attacco mirato, ma di scansioni massive che provano combinazioni di password, utenti comuni e chiavi deboli. Il punto non è chiedersi se accadrà, ma riconoscere in tempo i segnali e ridurre la superficie d’attacco prima che un errore di configurazione apra la porta sbagliata.

La parte utile non è il panico, ma il metodo: prima si verifica se ci sono davvero tentativi anomali, poi si controlla come è esposto il servizio, infine si applicano contromisure reversibili. Se l’accesso remoto è già stato compromesso o sospetti attività non autorizzata, trattalo come incidente: raccogli evidenze, limita l’esposizione e solo dopo intervieni in modo più profondo.

Segnali tipici di brute force su SSH

Il brute force lascia tracce riconoscibili. Non serve aspettare un login riuscito per accorgersene.

• Tanti tentativi falliti nello stesso intervallo di tempo.
• Connessioni ripetute da pochi IP o da una rete distribuita di IP diversi.
• Richieste verso utenti prevedibili come root, admin, ubuntu, debian, ec2-user.
• Messaggi di log come Failed password, Invalid user, authentication failure, PAM error.
• Picchi di accesso notturni o a intervalli regolari, spesso automatizzati.

Il dettaglio importante è distinguere il rumore da un rischio reale. Se vedi solo tentativi falliti, sei davanti a scansioni comuni. Se noti un login riuscito da un IP insolito, chiavi autorizzate che non riconosci o modifiche a utenti e servizi, la situazione cambia e va trattata con priorità alta.

Dove guardare prima: log e contesto

La fonte primaria è sempre il log di autenticazione del sistema. Su distribuzioni Debian e Ubuntu il riferimento è spesso /var/log/auth.log; su RHEL, AlmaLinux e Rocky puoi trovare i dati in /var/log/secure. In entrambi i casi, la lettura va fatta cercando eventi concentrati nel tempo, non righe isolate.

Se hai accesso alla shell, questi controlli sono i più rapidi e utili:

sudo grep -Ei 'Failed password|Invalid user|authentication failure|Accepted password|Accepted publickey' /var/log/auth.log | tail -n 50

Su sistemi RHEL-based:

sudo grep -Ei 'Failed password|Invalid user|authentication failure|Accepted password|Accepted publickey' /var/log/secure | tail -n 50

L’esito atteso è capire se ci sono solo fallimenti oppure anche accessi riusciti. Se compaiono Accepted password da IP non noti o in orari insoliti, non limitarti a bloccare gli IP: verifica subito utenti, chiavi SSH e sessioni attive.

Un secondo controllo utile è contare i tentativi per IP. Questo aiuta a distinguere un attacco distribuito da una singola macchina ostinata:

sudo grep -Ei 'Failed password|Invalid user' /var/log/auth.log | awk '{print $11}' | sort | uniq -c | sort -nr | head

Il risultato atteso è una classifica degli IP più rumorosi. Se un IP domina la lista, è un buon candidato per il blocco. Se invece i tentativi arrivano da molti indirizzi diversi, conviene puntare di più su hardening e limitazioni di accesso.

Diagnosi pratica: cosa significa quello che vedi

Non tutti i tentativi sono uguali. Un pattern con pochi IP e molte richieste indica spesso un bot o un host compromesso. Un pattern con molte origini diverse suggerisce una campagna automatizzata più ampia, contro cui il blocco manuale ha effetto limitato e temporaneo.

Se il server usa ancora autenticazione con password, il rischio è maggiore. Se invece usi solo chiavi, disabilitando la password, il brute force perde quasi tutta la sua efficacia. Restano comunque utili le difese su rate limit, allowlist e fail2ban, perché riducono rumore, carico e superficie d’attacco.

Va anche verificato se SSH è esposto sulla porta standard. Cambiare porta non è una difesa forte da sola, ma riduce il rumore dei bot più banali. Non deve essere la prima misura, ma può essere un complemento dopo aver chiuso le falle più importanti.

Soluzione consigliata: riduzione del rischio in ordine di sicurezza

La sequenza migliore è: prima rendere inefficaci i tentativi, poi limitare l’esposizione, infine automatizzare il blocco dei comportamenti ripetuti.

1. Disabilita l’accesso con password se usi chiavi SSH

È la misura più efficace e reversibile, purché tu abbia già verificato l’accesso con chiave da un secondo terminale. Prima di toccare la configurazione, conserva una sessione SSH già aperta o un accesso console dal pannello del provider.

File tipico: /etc/ssh/sshd_config. Fai sempre un backup prima di modificare:

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak.$(date +%F-%H%M)

Poi imposta almeno questi parametri:

PasswordAuthentication no
PubkeyAuthentication yes
PermitRootLogin no

Dopo la modifica, verifica la sintassi e ricarica il servizio:

sudo sshd -t && sudo systemctl reload sshd

Esito atteso: nessun errore di sintassi e servizio ricaricato senza interruzioni. Se il comando di test fallisce, ripristina il backup prima di procedere.

2. Limita gli IP autorizzati, se l’accesso è da reti note

Se amministri il server da una VPN, da uffici fissi o da un IP statico, la misura più pulita è consentire SSH solo da quelle origini. Puoi farlo con firewall o con le regole del pannello cloud. È più sicuro di “nascondere” SSH su una porta diversa.

Su sistemi con firewall semplice, l’approccio migliore è consentire SSH solo dalle reti fidate e bloccare il resto. Se usi un pannello hosting, verifica se esiste una sezione dedicata a firewall o security policy, perché lì la gestione è più comoda e meno soggetta a errori.

Se non puoi usare una allowlist, limita almeno il traffico con rate limiting e blocco automatico dei fallimenti ripetuti.

3. Attiva fail2ban per bloccare i tentativi ripetuti

Fail2ban è una difesa pratica contro brute force e password spraying. Legge i log e applica un ban temporaneo agli IP che superano una soglia di errori.

Su Debian, Ubuntu, AlmaLinux e Rocky è spesso disponibile nei repository standard. L’idea di base è semplice: installazione, abilitazione della jail SSH, controllo dei log e verifica del ban.

Per verificare se è attivo:

sudo systemctl status fail2ban

Esito atteso: servizio in stato active (running). Poi controlla le jail disponibili:

sudo fail2ban-client status

Per SSH, il controllo specifico dovrebbe mostrare il numero di ban e i tentativi intercettati:

sudo fail2ban-client status sshd

Se non hai una jail configurata, crea o modifica il file dedicato, ad esempio /etc/fail2ban/jail.d/sshd.local, partendo da un backup della configurazione esistente. Una configurazione prudente prevede un numero limitato di tentativi, un tempo di ban graduale e una durata abbastanza lunga da scoraggiare il bot, ma non così aggressiva da bloccare operatori legittimi per errore.

4. Disabilita l’accesso root diretto

Consentire l’accesso diretto a root aumenta molto il rischio operativo. È meglio usare un utente normale con sudo. In questo modo, anche se un account viene toccato, l’impatto è più controllabile e i log sono più leggibili.

La chiave è questa: il brute force non deve trovare una strada semplice verso l’utente più potente del sistema. Se hai bisogno di root per manutenzione, entra con un account nominativo e alza i privilegi solo quando serve.

5. Controlla le chiavi autorizzate e i file di avvio

Se sospetti che un accesso sia riuscito, non fermarti alla porta SSH. Controlla gli utenti con shell valida, i file authorized_keys, la presenza di chiavi sconosciute e le directory di avvio automatico. Un login riuscito può lasciare persistenze anche se la password cambia subito dopo.

Controlli minimi:

• /home/*/.ssh/authorized_keys per chiavi inattese.
• /root/.ssh/authorized_keys se l’accesso root è stato consentito in passato.
• /etc/ssh/sshd_config per parametri troppo permissivi.
• Utenti recenti in /etc/passwd e gruppi amministrativi in /etc/group.

Se usi cPanel, Plesk o un pannello hosting

Quando il server è gestito da un pannello, conviene usare prima la GUI se disponibile. In molti casi puoi intervenire senza aprire la shell completa.

In cPanel/WHM cerca le sezioni relative a sicurezza, SSH e accesso root. In Plesk verifica le opzioni del server per il servizio SSH e le policy di firewall. In FastPanel controlla l’area dedicata alla protezione del server e ai blocchi IP. L’obiettivo resta lo stesso: ridurre accessi con password, limitare gli IP e monitorare i ban.

Se il pannello offre un firewall integrato, usa quello per la allowlist o per bloccare gli IP sospetti. Se offre solo la gestione del servizio, usa il pannello per abilitare SSH in modo sicuro e poi delega al sistema operativo o a fail2ban il blocco dei tentativi ripetuti.

Come distinguere un falso allarme da un problema serio

Non tutti i picchi di login sono malevoli. Un cambio di password, una sincronizzazione di client o un team che prova credenziali vecchie può generare molti fallimenti. Per questo è utile confrontare ora, origine e utente coinvolto.

È più probabile un brute force se:

• i tentativi arrivano da IP esterni non riconosciuti;
• gli utenti provati sono generici o casuali;
• gli errori sono continui e regolari;
• non c’è un motivo operativo che giustifichi quei login falliti.

È più probabile un problema interno se:

• i tentativi provengono da una tua VPN o da un ufficio noto;
• gli utenti sono quelli del team amministrativo;
• coincidono con un cambio di chiavi, password o automazioni.

In entrambi i casi, il log è il punto di partenza. La differenza è la risposta: nel primo caso blocchi e restringi, nel secondo correggi la procedura o l’automazione che sta generando errore.

Hardening minimo che vale sempre

Ci sono misure che hanno buon rapporto tra rischio e beneficio e che conviene applicare quasi sempre su un SSH esposto su Internet.

1. Aggiorna il sistema e il pacchetto OpenSSH con regolarità, così riduci il rischio di vulnerabilità note.
2. Usa chiavi SSH forti e proteggile con passphrase.
3. Disabilita il login root diretto e preferisci utenti nominativi con privilegi limitati.
4. Attiva fail2ban o una soluzione equivalente per bloccare i pattern ripetuti.
5. Monitora i log di autenticazione e conserva una finestra di controllo sugli accessi riusciti.

Se vuoi una protezione più robusta, aggiungi una VPN per l’amministrazione e consenti SSH solo da lì. È una scelta spesso più pulita di qualsiasi porta “strana” o tentativo di nascondere il servizio.

Verifiche finali dopo il fix

Dopo ogni intervento, verifica sempre che l’accesso legittimo funzioni ancora. Il controllo più importante non è che il bot sia bloccato, ma che tu riesca ancora a entrare quando serve.

ssh -v utente@server

Esito atteso: autenticazione riuscita con chiave o con il metodo previsto dalla tua policy. Se il login fallisce, non insistere con prove a caso: ripristina il backup della configurazione SSH o accedi dalla console del provider per correggere l’errore.

Controlla anche il comportamento dei ban:

sudo fail2ban-client status sshd

Esito atteso: presenza di IP bannati se ci sono stati tentativi ripetuti, senza colpire il tuo indirizzo amministrativo. Se noti un falso positivo, riduci aggressività della jail o aggiungi l’IP fidato in whitelist.

Rollback sicuro se qualcosa va storto

Il rollback deve essere semplice e già previsto. Se hai modificato sshd_config e perdi l’accesso, usa la console del provider o la sessione già aperta per ripristinare il backup:

sudo cp /etc/ssh/sshd_config.bak.YYYY-MM-DD-HHMM /etc/ssh/sshd_config
sudo sshd -t && sudo systemctl reload sshd

Se hai attivato regole firewall troppo restrittive, rimuovi prima il blocco sull’IP amministrativo, poi verifica il servizio. Se fail2ban ha bannato un IP legittimo, sbloccalo con il client dedicato e correggi la configurazione della jail prima di riattivarla.

La regola pratica è questa: mai fare più di una modifica critica alla volta senza un controllo immediato. Così, se qualcosa si rompe, sai esattamente dove intervenire e riporti il server in uno stato noto senza inseguire il problema a tentoni.

Checklist operativa rapida

• Controlla i log SSH e verifica se ci sono solo fallimenti o anche accessi riusciti.
• Disabilita le password se usi solo chiavi e conferma il login da una seconda sessione.
• Attiva fail2ban o una protezione equivalente con una jail dedicata a SSH.
• Blocca root diretto e limita l’accesso agli IP fidati quando possibile.
• Conserva un backup della configurazione SSH per un rollback immediato.

Assunzione: il server è amministrato in modo legittimo e hai accesso console o una seconda sessione prima di cambiare la policy SSH.