Blindare un nuovo VPS nella prima ora

Osserva journalctl -u ssh su un server online da un'ora e la prima volta il volume sarà allarmante. Non dovrebbe esserlo. Quello che stai guardando è il rumore di fondo di internet: una manciata di operazioni di scansione, alcune accademiche, alcune commerciali, alcune criminali, che enumerano continuamente l'intero spazio IPv4 e passano i risultati a bot che indovinano credenziali. Il tuo indirizzo è stato raggiunto perché esiste, in ordine numerico, e verrà raggiunto di nuovo tra poche ore qualunque cosa tu faccia.

Questo cambia in modo utile la natura del problema. Non ti stai difendendo da un avversario che ti ha scelto e che si adatterà; ti stai difendendo da uno script con un repertorio fisso — root, admin, ubuntu, test, git, oracle, postgres, e le ventimila password comparse nei breach dump. Non ha pazienza, non ha creatività e non ha interesse per una macchina che non risponde al primo tentativo. Disattivare l'autenticazione via password non rallenta questo attaccante. Lo elimina completamente dal tavolo da gioco.

Vale la pena conoscere due dettagli. Primo, IPv6 è drammaticamente più silenzioso, perché un /64 non può essere spazzolato per intero — ma nel momento in cui il tuo record AAAA diventa pubblico, o l'indirizzo della tua macchina compare in un header di posta o in un log di certificate transparency, il silenzio finisce. Non trattare mai IPv6 come un nascondiglio; trattalo come un pagliaio più piccolo. Secondo, un indirizzo IPv4 ha un passato. Ha avuto un inquilino prima di te, e se quell'inquilino ha gestito male un server di posta o ha ospitato qualcosa che è finito in una lista nera, ne erediti la reputazione finché non si esaurisce. Se la posta ti interessa, controlla l'indirizzo sulle solite blocklist prima di costruirci sopra — è un controllo di cinque minuti che risparmia due settimane di debug sulla deliverability.

Quasi ogni compromissione reale di un piccolo server nasce in uno di due punti: una password che si poteva indovinare, o un servizio in ascolto che non avrebbe dovuto esserlo. Le correzioni corrispondenti sono PasswordAuthentication no e un firewall con policy predefinita drop. Non sono affascinanti, richiedono insieme un quarto d'ora, e valgono più di tutti gli altri controlli di questa pagina messi insieme.

Il motivo è strutturale, non statistico. Entrambe sono chiuse per default — falliscono dalla parte della sicurezza. Uno sshd solo a chiavi non può essere forzato con il brute-force per quanti tentativi arrivino, perché nel codice non esiste alcun percorso che accetti una password. Un firewall default-deny protegge servizi che non hai ancora installato, incluso il database che aggiungerai tra tre mesi e dimenticherai di vincolare a localhost. Tutto il resto in una checklist di hardening è un elenco di cose negative: una lista di elementi specifici da disattivare, completa solo quanto lo è la lista stessa.

Quindi se leggi una sola sezione e chiudi la scheda, leggi questa, esegui i passaggi da 2 a 5 qui sotto, e considera l'ora ben spesa. Il resto è genuinamente utile e genuinamente secondario.

Su Debian 13 e Ubuntu 24.04, /etc/ssh/sshd_config si apre con una riga Include /etc/ssh/sshd_config.d/*.conf, e le immagini cloud includono un file in quella directory — di solito 50-cloud-init.conf — che imposta già PasswordAuthentication. Modificare il file principale e aggiungere le proprie direttive in fondo sembra naturale e produce una configurazione che non fa quello che dichiara.

La regola è l'unica cosa di sshd che sorprende quasi tutti: per ogni parola chiave, vince il primo valore ottenuto. È l'opposto di quasi ogni altro sistema di merge delle configurazioni che hai usato. L'Include si trova vicino all'inizio del file principale, quindi un drop-in viene letto prima del corpo di sshd_config — e tra i drop-in, decide l'ordine alfabetico. Un file chiamato 10-hardening.conf batte 50-cloud-init.conf. Un file chiamato 60-hardening.conf perde contro di esso, silenziosamente, e non lo scoprirai da un riavvio che segnala successo.

Per questo non ci si deve mai fidare del file appena scritto. Chiedi al demone cosa ha effettivamente risolto:

sshd -t                 # syntax check — silence means valid
sshd -T | grep -Ei '^(permitrootlogin|passwordauthentication|pubkeyauthentication|kbdinteractive|allowusers|port) '

sshd -T stampa la configurazione effettiva dopo che ogni include, override e valore predefinito è stato risolto. Se quell'output dice passwordauthentication yes, allora l'autenticazione via password è attiva, indipendentemente da ciò che dichiara qualsiasi file su disco. Nient'altro conta come verifica.

La seconda trappola appartiene alla stessa famiglia. Ubuntu 24.04 avvia sshd tramite attivazione socket: ssh.socket possiede la porta in ascolto, e Port in sshd_config viene ignorato del tutto. Verifica con systemctl is-enabled ssh.socket; se è abilitato e vuoi una porta diversa, cambiala con systemctl edit ssh.socket e un override ListenStream= — non in sshd_config, dove l'impostazione sembrerà corretta e non farà nulla.

Siamo onesti su questo punto, perché internet non lo è. Spostare sshd sulla porta 2222 o 47000 non ferma alcun attaccante competente. Una scansione TCP completa di un host richiede secondi, il servizio si annuncia da solo nel banner, e chiunque abbia deciso di attaccare proprio te lo scoprirà prima di finire il caffè.

Quello che fa davvero è tagliare il tuo log di autenticazione di circa il novantacinque per cento, e questo ha un valore reale: è la differenza tra log che scorri velocemente e log che leggi davvero. Un segnale che riesci a vedere batte un segnale che hai sepolto. Se monitori anche solo qualcosa, un auth.log silenzioso è il modo più economico in assoluto per rendere visibile un'anomalia.

I costi sono piccoli ma reali, ed è per questo che lo definiamo facoltativo e non consigliato. Dimenticherai la porta quando tornerai tra otto mesi. Una porta non standard sopra 1024 può, in linea di principio, essere reclamata da un processo senza privilegi se sshd smette di essere in ascolto. I firewall in uscita restrittivi sulle reti dei client bloccano le porte insolite, quindi ogni tanto non riuscirai a raggiungere il tuo stesso server da un ufficio o da un hotel. E su un sistema attivato tramite socket devi cambiarla nel posto giusto, come nella sezione precedente. Fallo se i log silenziosi contano per te. Non farlo e poi sentirti sicuro, e non farlo mai al posto di solo a chiavi.

Un firewall che elenca cosa bloccare è uno schedario. Un firewall che elenca cosa permettere è un controllo di sicurezza. La distinzione è tutta la partita, perché solo il secondo copre il servizio che installerai il mese prossimo, la porta di debug che hai aperto un venerdì, e il container che ha deciso di esporsi da solo.

Sulla nostra piattaforma hai due livelli, e sono indipendenti. Il filtro edge è opzionale, configurato per singolo server nel pannello e applicato sull'hypervisor, così il traffico bloccato non raggiunge mai il tuo guest — utile per le regole di livello 4 che vuoi applicate prima che il tuo kernel gli dedichi un ciclo, e per impedire che un guest compromesso resti raggiungibile mentre ci lavori. Il firewall del guest è interamente tuo: nftables, iptables, pf, qualunque cosa includa la tua immagine. Non lo tocchiamo mai. Usali entrambi se la macchina conta davvero; usa sempre almeno il secondo.

Due cose nel ruleset del passaggio 5 meritano una spiegazione, perché la maggior parte dei ruleset copiati e incollati le sbaglia. Non droppare tutto l'ICMP. Sembra ordinato ma rompe la path-MTU discovery, il che produce la peggior classe di bug che esista: le richieste piccole funzionano, le risposte grandi restano in sospeso, e nei tuoi log non c'è alcun riferimento al firewall. Accetta almeno destination-unreachable, time-exceeded e parameter-problem. Non filtrare ICMPv6 per tipo a meno che tu non conosca l'elenco. IPv6 si basa su ICMPv6 per il neighbour discovery e i router advertisement; bloccalo in modo generico e la tua connettività IPv6 muore in un modo che sembra un problema di routing. Accettare tutto l'ICMPv6 su un singolo host è un compromesso ragionevole, ed è esattamente ciò che fa il ruleset qui sotto.

Un avvertimento prima di eseguire flush ruleset: se Docker è installato, quella riga rimuove le regole NAT e filter che Docker ha scritto, e il networking dei container si ferma finché systemctl restart docker non le rimette a posto. Carica prima il tuo ruleset, riavvia Docker subito dopo, e leggi la sezione successiva prima di pubblicare anche una sola porta di un container.

Chiedi alla macchina su cosa è in ascolto. Non cosa pensi di aver installato — cosa è effettivamente bound in questo momento:

ss -tulpn | grep -vE '127\.0\.0\.1|\[::1\]'

Tutto ciò che sopravvive a questo filtro è raggiungibile da un luogo diverso dalla macchina stessa. Su un'immagine standard le scoperte più comuni sono rpcbind sulla 111 (nulla di ciò che usi ne ha bisogno), un listener exim4 residuo dell'installazione di base, e uno stub di systemd-resolved innocuo su loopback ma un resolver aperto se non lo è. Quelli pericolosi arrivano dopo, con il software che installi di proposito: PostgreSQL su 0.0.0.0:5432 perché un tutorial diceva di modificare listen_addresses, Redis senza password perché Redis non ha avuto una password di default per gran parte della sua vita, un nodo Elasticsearch, un exporter di Prometheus, un notebook Jupyter. Ognuno di questi è stato il primo passo di una violazione reale, e non solo una volta.

Ed ecco la trappola che coglie in fallo anche le persone attente. Docker non chiede il permesso al tuo firewall. Quando scrivi -p 5432:5432, Docker inserisce regole DNAT nella chain PREROUTING della tabella nat, che il kernel valuta prima che il pacchetto arrivi mai alla tua chain input; il traffico viene poi inoltrato al container. La tua policy input default-deny non viene consultata, ufw status mostra la porta come chiusa, e il database è sulla internet pubblica. Questo è un comportamento documentato di Docker, è così da un decennio, e ha esposto un numero enorme di database.

La correzione è una singola stringa, ed è l'abitudine che vale la pena costruire:

# wrong — reachable from the entire internet, whatever your firewall says
docker run -p 5432:5432 postgres

# right — bound to loopback, reachable only through an SSH tunnel or a proxy
docker run -p 127.0.0.1:5432:5432 postgres

Infine, cerca un parere esterno. Una scansione delle porte dal server ti dice cosa pensa il kernel; una scansione da altrove ti dice cosa vede il mondo, che è l'unico numero che conta davvero. Esegui nmap -Pn -p- <your-ip> dal tuo laptop, non dalla macchina, e confronta il risultato con la lista che ti aspettavi.

La finestra che porta alla compromissione dei piccoli server non è lo zero-day. Sono le quattro settimane tra la pubblicazione di una CVE con un proof of concept funzionante e la prossima volta che ti capiterà di collegarti. Gli strumenti d'attacco assorbono un nuovo bug remoto nel giro di giorni; una macchina che aggiorni “quando ci arrivi” resta esposta per l'intero intervallo, e ogni operatore onesto sa quanto sia realmente lungo quell'intervallo.

L'obiezione agli aggiornamenti automatici è la paura di rompere qualcosa, e merita di essere presa sul serio — per poi essere circoscritta. Limita l'automazione al pacchetto di sicurezza della tua distribuzione, dove i maintainer effettuano il backport delle correzioni nella versione già pacchettizzata invece di distribuire nuove release upstream. Un aggiornamento di sicurezza Debian per openssl è una build corretta della stessa versione che già usi; il rischio che cambi il comportamento è molto minore del rischio di lasciare aperto per un mese un buco raggiungibile da remoto. Gli aggiornamenti di funzionalità restano manuali, dove è giusto che stiano.

La parte che tutti saltano è il riavvio. Una libssl corretta su disco non serve a nulla per il processo che ne aveva mappato la vecchia versione all'avvio, e un aggiornamento del kernel non serve a nulla finché non ci riavvii dentro. O accetti un riavvio non presidiato in una finestra che scegli tu, oppure installi needrestart e lo lasci dire quali servizi girano ancora contro librerie cancellate — ma fai almeno una delle due cose. “Gli aggiornamenti automatici sono attivi” mentre uptime segna 340 giorni è un'illusione rassicurante, ed è quella che vediamo più spesso.

fail2ban legge i tuoi log, nota i fallimenti ripetuti da un indirizzo e lo bandisce per un po'. CrowdSec fa lo stesso e condivide i verdetti su una rete di partecipanti, così puoi bloccare un indirizzo che si è comportato male altrove prima ancora che raggiunga te. Sono entrambi software validi. Nessuno dei due fa, su un server SSH solo a chiavi, ciò che la maggior parte delle persone crede.

Una volta che PasswordAuthentication è no, un brute-force su SSH non può avere successo. Non “è improbabile che riesca” — semplicemente non esiste un percorso di codice che lo permetta. Bandire un indirizzo dopo cinque fallimenti quindi non previene nulla; riduce il volume dei log e una quantità trascurabile di CPU. È un beneficio reale, solo che non è un beneficio di sicurezza, e il compromesso non è gratuito: una jail scritta male che osserva il log sbagliato ha chiuso fuori dai propri server più amministratori di quanti attaccanti abbia mai bloccato.

Il punto in cui questi strumenti si guadagnano davvero il loro posto è un livello più su, sui servizi che esponi realmente: un form di login, un pannello admin di WordPress, un'API con rate limit, un server di posta con SMTP AUTH. Quelli accettano davvero password, sono davvero attaccabili via brute-force, e una lista di ban è esattamente il controllo giusto. Il nostro verdetto quindi è ristretto e specifico. Salta la jail su SSH. Metti CrowdSec o fail2ban davanti a ciò che ha un campo password. E qualunque tu scelga, metti prima in whitelist il tuo indirizzo di gestione — ignoreip esiste apposta per la sera che altrimenti ricorderesti per il motivo sbagliato.

La prevenzione è ciò che puoi fare in un'ora. Il rilevamento è ciò che ti dice che quell'ora non è bastata. Non deve essere elaborato, e su un singolo server tre accorgimenti economici coprono gran parte del terreno.

Conserva i log. Su molte immagini il journal vive in /run e svanisce al riavvio, il che significa che la traccia di un incidente scompare proprio nel riavvio che lo segue. Creare /var/log/journal è una correzione di una riga ed è la cosa a maggior valore in questa sezione.

Fatti avvisare sui login. Una riga in /etc/ssh/sshrc che lancia logger a ogni inizio sessione non costa nulla e ti dà una traccia pulita e grep-abile, separata dal chiacchiericcio di sshd stesso. Un'avvertenza che coglie in fallo molti: sshd esegue ~/.ssh/rc al posto di /etc/ssh/sshrc quando l'utente ne ha uno, quindi il file di sistema viene saltato proprio per l'account che più probabilmente ha un dotfile personalizzato. Se ti serve un hook che non possa essere oscurato in questo modo, usa pam_exec invece.

Sappi com'era il filesystem il primo giorno. AIDE registra gli hash dei tuoi binari, librerie e file di unit e segnala cosa è cambiato da allora. Il problema è fondamentale e di solito viene ignorato: un database conservato sulla stessa macchina che sta sorvegliando può essere rigenerato da chiunque l'abbia compromessa, e da quel momento il controllo segnalerà per sempre “nessuna modifica”. Copia il database fuori dalla macchina, o quantomeno registrane l'hash altrove, e lo strumento vale i suoi venti minuti. Lasciato lì dov'è, è solo una coperta di Linus.

Vale la pena enunciare il principio generale a sé stante: il log di cui non puoi fidarti è quello sulla macchina compromessa. Qualunque cosa su cui intendi davvero fare affidamento — un journal, un database di integrità, un backup — dovrebbe avere una copia da qualche parte che lo stesso attaccante non controlla. Un secondo piccolo server in un'altra giurisdizione è una risposta legittima a questo, e ne basta uno da cinque dollari.

Tutto quanto sopra è lavoro perimetrale, e vale la pena essere precisi sul suo confine, così non scambierai una porta blindata per una cassaforte.

Non protegge i dati su una macchina in esecuzione. Un kernel blindato e un firewall chiuso sono irrilevanti per chiunque abbia accesso all'hypervisor, e per il contenuto della RAM mentre la macchina è accesa. Se la tua preoccupazione è il disco quando il server è spento, sequestrato o dismesso, quella è la cifratura del disco, ed è una procedura diversa con una modalità di guasto diversa — vedi cifrare un disco VPS con LUKS.

Non ti rende anonimo. Un server può essere blindato alla perfezione e comunque rivelare chi lo possiede, tramite un record WHOIS, una chiave SSH riutilizzata, un tag di analytics, un client SSH che si connette da casa senza alcun salto intermedio, o un certificato che collega due identità. Pagare in Monero e poi accedere dal proprio indirizzo personale vanifica il pagamento. Questa modalità di fallimento ha una pagina tutta sua: gli errori che ti deanonimizzano.

Non sistema la tua applicazione. Una SQL injection, un endpoint admin non autenticato o una dipendenza con una backdoor non si curano affatto delle tue impostazioni sshd. La maggior parte delle compromissioni di server ben gestiti arriva attraverso la porta che hai aperto deliberatamente, di proposito, verso un servizio che hai scritto o installato tu.

Non è un backup. Ransomware, un rm -rf con una variabile che era vuota, e un aggiornamento fallito finiscono tutti allo stesso modo. Fai una copia, mettila da un'altra parte, e ripristinala una volta prima di averne davvero bisogno — la stessa disciplina che rende sopravvivibile un trasloco verso un altro host rende sopravvivibile anche un brutto martedì.

Niente di tutto questo è un argomento contro quell'ora. È un argomento per sapere esattamente cosa quell'ora ha comprato.