2026-07-08 · Team Fenrir

Hardening SSH su Linux: cosa conta davvero

Se il tuo server Linux è esposto su internet, il suo SSH viene già martellato: il brute force sulle credenziali è una tecnica d’attacco così diffusa che MITRE la cataloga in quattro varianti distinte (T1110), e SSH è uno dei suoi bersagli preferiti. La buona notizia: quattro interventi — chiavi al posto delle password, sshd_config sistemato, accessi limitati, fail2ban — chiudono la porta alla quasi totalità di questi attacchi. Ecco la checklist, comando per comando.

Perché proprio SSH?

Perché è la porta di amministrazione: chi entra da lì ha (o può ottenere) il controllo completo della macchina. MITRE ATT&CK cataloga l’indovinare credenziali come T1110 (Brute Force) — password guessing, password spraying, credential stuffing — e l’uso di SSH per muoversi tra macchine compromesse come T1021.004 (Remote Services: SSH). Tradotto: SSH serve agli attaccanti sia per entrare, sia per allargarsi una volta dentro.

Il punto debole non è il protocollo — è solido — ma la configurazione: password deboli, root esposto, chiavi dimenticate. Tutte cose che si sistemano in un pomeriggio.

Come passo dalle password alle chiavi?

È il singolo intervento più efficace. Una password si indovina per tentativi; una chiave ed25519 no. Tre comandi:

# 1. Genera la coppia di chiavi (sul TUO computer, non sul server)
ssh-keygen -t ed25519 -a 64

# 2. Installa la chiave pubblica sul server
ssh-copy-id utente@server

# 3. Verifica di entrare SENZA password prima di proseguire
ssh utente@server

Solo quando il punto 3 funziona, disattiva le password. Attenzione al default: nel manuale ufficiale di OpenSSH, PasswordAuthentication è yes di default — se non lo spegni tu, il brute force resta possibile. In /etc/ssh/sshd_config:

PasswordAuthentication no
KbdInteractiveAuthentication no

Poi systemctl reload sshd — tenendo aperta la sessione corrente: se hai sbagliato qualcosa, hai ancora una shell per rimediare.

Cosa sistemo in sshd_config?

Le direttive che contano, coi default reali del manuale (molte guide online li sbagliano):

• PermitRootLogin no — il default OpenSSH è prohibit-password: root può già entrare solo con chiave, non con password. Metterlo a no è comunque meglio: si entra con un utente nominale e si eleva con sudo, così ogni azione nei log ha un nome e un cognome.
• MaxAuthTries 3 — il default è 6 tentativi per connessione. Tre bastano a chiunque abbia la chiave giusta.
• LoginGraceTime 30 — il default è 120 secondi per completare il login. Trenta bastano, e riducono le connessioni parcheggiate da scanner.
• AllowUsers mario deploy (o AllowGroups ssh-users) — di default qualunque utente di sistema può fare login. Elencare esplicitamente chi può entrare taglia fuori account di servizio e utenti dimenticati.
• ClientAliveInterval 300 + ClientAliveCountMax 2 — chiude le sessioni morte invece di lasciarle appese.

E la porta? Spostarla da 22 riduce il rumore, non il rischio: gli scanner di massa si fermano, un attaccante mirato la trova con una scansione delle porte. Va bene farlo per pulizia dei log, mai come misura di sicurezza.

Come limito chi può connettersi?

Due livelli, complementari:

1. A livello di rete — se l’amministrazione avviene da IP noti (ufficio, VPN), il firewall è la prima linea: ufw allow from 203.0.113.10 to any port 22 e nient’altro. Un SSH non raggiungibile è un SSH non attaccabile.
2. A livello di sshd — AllowUsers/AllowGroups come sopra, e Match per regole mirate (per esempio: l’utente deploy può entrare solo dall’IP del CI, solo con chiave, senza shell interattiva).

fail2ban serve ancora?

Sì, come livello aggiuntivo. fail2ban fa una cosa sola e la fa bene: banna gli IP che accumulano errori di autenticazione leggendo i log in tempo reale. Con le password disattivate il brute force classico è già sterile, ma fail2ban tiene puliti i log, rallenta la ricognizione e protegge anche gli altri servizi esposti.

apt install fail2ban        # Debian/Ubuntu
systemctl enable --now fail2ban
fail2ban-client status sshd # jail attiva, IP bannati

Il suo limite strutturale: è reattivo e per-IP. Un attacco distribuito su migliaia di IP — pochi tentativi ciascuno — passa sotto la soglia di ban. Per questo è il livello in più, non il fondamento.

E le chiavi, chi le gestisce?

Il rovescio della medaglia delle chiavi: si accumulano. Il NIST ha dedicato al problema un rapporto intero (IR 7966): nelle infrastrutture reali le chiavi SSH proliferano senza inventario né scadenza — dipendenti usciti anni fa che risultano ancora in qualche authorized_keys, chiavi di automazione con più privilegi del necessario. L’hardening non finisce con la configurazione: serve igiene continua.

In pratica, ogni trimestre:

# Chi può entrare su questa macchina?
for u in $(cut -d: -f1 /etc/passwd); do
  f="/home/$u/.ssh/authorized_keys"
  [ -s "$f" ] && echo "== $u" && wc -l < "$f"
done

Ogni chiave che non sai a chi appartiene va rimossa. Ogni chiave di automazione va vincolata (command=, from= in authorized_keys) al minimo che deve fare.

Come verifico che la configurazione regga?

Non fidarti del file: chiedi a sshd cosa sta effettivamente applicando (include, override e Match compresi):

sshd -T | grep -Ei 'passwordauth|permitroot|maxauthtries|allowusers|kbdinteractive'

Se l’output dice passwordauthentication no e permitrootlogin no, la porta è chiusa davvero. Poi guarda i log — è lì che vedi l’assedio:

journalctl -u ssh --since today | grep -c 'Failed\|Invalid'

Su un server esposto, quel numero non sarà zero. Va bene così: l’obiettivo dell’hardening non è fermare i tentativi, è renderli tutti inutili.

Perché il monitoraggio conta quanto l’hardening?

Perché l’hardening è una fotografia, e il server è un film. La configurazione perfetta di oggi si eroderà: un collega riattiva le password “per cinque minuti”, un tool di provisioning riscrive sshd_config, una chiave di troppo finisce in authorized_keys. E il brute force delle 2 di notte non ti manda un’email da solo.

Serve qualcosa che osservi in continuo: i log di autenticazione, le modifiche a sshd_config e alle chiavi autorizzate, i pattern di accesso anomali — e che agisca quando serve, non lunedì mattina. È esattamente il lavoro di Fenrir SOC: correla i log SSH coi suoi altri monitor, classifica l’attacco e sopra la soglia di confidenza blocca da solo, in meno di un secondo. Tu firmi la checklist di questa pagina una volta; lui la difende ogni notte.