Hardening SSH e buone pratiche di audit

La misura di hardening SSH più efficace consiste nell'impostare PasswordAuthentication no in /etc/ssh/sshd_config. In questo modo tutti gli utenti devono autenticarsi con chiavi pubbliche, eliminando i rischi legati a password deboli o riutilizzate e agli attacchi di forza bruta. Prima di disabilitare l'autenticazione tramite password, verifichi che sia installata almeno una chiave autorizzata, per evitare di bloccare il proprio accesso.

Le direttive AllowUsers e AllowGroups limitano l'accesso SSH agli utenti indicati o ai membri dei gruppi specificati. Ad esempio, AllowGroups sshusers consente l'accesso solo ai membri del gruppo sshusers. Questo offre una difesa in profondità: anche se un aggressore conosce un nome utente e ottiene le credenziali, l'accesso SSH viene negato se l'account non è esplicitamente autorizzato.

Spostare SSH dalla porta 22 a una porta con numero elevato è una forma di security through obscurity, non una misura di sicurezza. Tuttavia, riduce significativamente il rumore nei log generato dagli scanner automatizzati che prendono di mira la porta 22. In questo modo è più facile analizzare i log alla ricerca di minacce reali. Mantenga sempre le regole del firewall come principale controllo degli accessi; l'offuscamento della porta deve essere solo una misura supplementare.

Impostare PermitRootLogin no impedisce l'autenticazione diretta dell'utente root tramite SSH. Gli aggressori che prendono di mira root hanno un nome utente sicuramente valido e privilegi illimitati in caso di successo. L'impostazione consigliata è PermitRootLogin prohibit-password, che consente l'accesso root solo tramite autenticazione con chiave pubblica, bloccando gli attacchi di forza bruta basati sulle password e mantenendo al contempo l'accesso di emergenza.

MaxAuthTries 3 limita a tre il numero di tentativi di autenticazione per connessione. Dopo tre tentativi falliti, il server termina la connessione. Questo rallenta i tentativi di forza bruta. In combinazione con il backoff esponenziale di fail2ban o SSHGuard, che bloccano temporaneamente gli indirizzi IP dopo ripetuti fallimenti, gli attacchi di forza bruta diventano computazionalmente irrealizzabili.

LoginGraceTime specifica per quanto tempo il server attende un'autenticazione riuscita prima di disconnettere il client. Il valore predefinito è 120 secondi; ridurlo a 20 secondi impedisce i tentativi di forza bruta lenti e riduce il consumo di risorse dovuto alle connessioni non autenticate. ClientAliveInterval e ClientAliveCountMax controllano i test dello stato della connessione per disconnettere le sessioni inattive o non più attive.

Le configurazioni SSH moderne dovrebbero limitare gli algoritmi alle opzioni forti e attuali. In sshd_config, imposti Ciphers su chacha20-poly1305@openssh.com,aes256-gcm@openssh.com, imposti MACs su hmac-sha2-256-etm@openssh.com e imposti KexAlgorithms su curve25519-sha256. In questo modo elimina gli algoritmi legacy come arcfour, DES e i MAC basati su MD5, che potrebbero essere disponibili per garantire la compatibilità con le versioni precedenti.

fail2ban monitora i log di autenticazione e blocca gli indirizzi IP che superano una soglia di tentativi di accesso falliti. Dopo un numero configurabile di errori entro un determinato intervallo di tempo, fail2ban aggiunge una regola iptables per scartare gli ulteriori pacchetti provenienti da quell'indirizzo IP. Questa risposta automatizzata rende impraticabili gli attacchi di forza bruta senza richiedere interventi manuali.

Lo strumento ssh-audit si connette a un server SSH e ne valuta la configurazione: gli algoritmi di scambio delle chiavi, i tipi di chiavi host, i cifrari e i MAC offerti, segnalando le opzioni obsolete o deboli. Eseguire ssh-audit sui propri server prima e dopo l'hardening fornisce una valutazione oggettiva della situazione precedente e successiva e identifica eventuali lacune nella configurazione.

Gli eventi di autenticazione SSH vengono registrati tramite syslog. Su Linux, /var/log/auth.log (Debian) o /var/log/secure (RHEL) registra ogni accesso riuscito e fallito con indicazione di data e ora, nome utente, IP di origine e fingerprint della chiave utilizzata. L'invio di questi log a un SIEM centralizzato consente di rilevare schemi di accesso insoliti, come accessi da Paesi imprevisti o in orari inconsueti.

Un file sshd_config sottoposto a hardening combina: PasswordAuthentication no, PermitRootLogin prohibit-password, MaxAuthTries 3, LoginGraceTime 20, AllowGroups sshusers, Ciphers e MAC limitati, X11Forwarding no e AllowTcpForwarding no (a meno che il tunneling non sia necessario). Ogni direttiva rimuove uno specifico vettore di attacco e, insieme alle altre, contribuisce a una postura SSH basata sulla difesa in profondità.

Quale impostazione di sshd_config è più efficace per eliminare gli attacchi di forza bruta basati sulle password contro SSH?

Checklist per l'hardening SSH: disabilitare l'autenticazione tramite password, limitare l'accesso con AllowGroups/AllowUsers, disabilitare l'accesso root o limitarlo alle sole chiavi, impostare MaxAuthTries 3, ridurre LoginGraceTime, limitare gli algoritmi ai soli cifrari moderni, implementare fail2ban o SSHGuard, eseguire ssh-audit per una valutazione oggettiva e centralizzare i log per rilevare le anomalie.