Come proteggere un nuovo VPS: i primi dieci minuti

Un nuovo server è più esposto proprio nel momento in cui riceve un indirizzo IP. Scanner automatizzati perlustrano continuamente l'intero spazio IPv4, quindi i primi tentativi di accesso contro una macchina distribuita un minuto fa arrivano di solito prima che tu abbia finito di leggere il suo messaggio di benvenuto. Niente di tutto ciò è mirato a te — è rumore di fondo, ed è per questo che un server non protetto con una password su root viene compromesso nel giro di ore, non di mesi. La buona notizia è che chiuderlo è un lavoro breve: dieci minuti di passaggi ordinati eliminano sostanzialmente tutto il rischio opportunistico. Questa guida copre quella checklist, l'ordine che ti impedisce di restare tagliato fuori, e una cosa che la maggior parte dei tutorial di hardening non menziona mai — i dettagli personali che una configurazione predefinita scrive silenziosamente su una macchina che hai noleggiato apposta perché non fosse collegata a te.

Da cosa ti protegge davvero l'hardening

L'hardening vale la pena farlo proprio perché i suoi benefici sono circoscritti e reali. Essere chiari sul confine ti evita un falso senso di sicurezza nelle aree che non tocca.

• Elimina del tutto l'attaccante opportunista. Bot di credential stuffing, tentativi di forza bruta su SSH e scansioni alla ricerca di pannelli di amministrazione esposti falliscono tutti contro un'autenticazione solo a chiavi e un firewall a blocco predefinito.
• Limita i danni quando qualcosa che esegui presenta una falla. Un servizio legato a localhost dietro una porta chiusa non può essere raggiunto da uno sconosciuto nemmeno il giorno in cui viene pubblicata la sua CVE.
• Riduce quanto costa un errore. Utenti non privilegiati, chiavi separate e patch automatiche fanno sì che una singola decisione sbagliata non consegni l'intera macchina.
• Non nasconde il server al tuo host. Chiunque abbia accesso all'hypervisor può in linea di principio leggere la memoria di una macchina in funzione — una questione su chi sia il tuo fornitore, non sulle regole del tuo firewall.
• Non ti rende anonimo. L'hardening protegge la macchina; se la macchina è collegata al tuo nome si decide in fase di registrazione e di pagamento, molto prima del tuo primo accesso.

Quest'ultima distinzione è quella che la gente capisce al contrario. Un server perfettamente sottoposto a hardening ma acquistato con una carta di credito intestata al tuo nome legale resta comunque un server intestato al tuo nome legale. I due livelli sono complementari: l'hosting no-KYC e un saldo finanziato in crypto decidono a chi appartiene la macchina sulla carta, e i dieci minuti qui sotto decidono chi può entrarci.

L'ordine che ti impedisce di restare tagliato fuori

Quasi ogni storia dell'orrore sull'hardening è la stessa storia: qualcuno ha disabilitato l'autenticazione via password prima di confermare che la propria chiave funzionasse, oppure ha abilitato un firewall le cui regole non includevano SSH, restando tagliato fuori da una macchina che non può più raggiungere. La sequenza esiste per rendere questo impossibile. Installa prima la chiave e verifica che funzioni in una seconda finestra. Solo allora disattiva le password. Aggiungi la regola del firewall per SSH prima di abilitare il firewall, mai dopo.

Vale anche la pena sapere qual è il tuo percorso di recupero prima di averne bisogno. Un VPS raggiungibile solo via SSH ha esattamente una porta d'accesso, quindi la console nella dashboard del tuo provider è il fallback che trasforma un blocco d'accesso in un semplice inconveniente invece che in una ricostruzione da zero. Controlla di riuscire ad aprirla mentre tutto funziona ancora.

Passo dopo passo: i primi dieci minuti su una macchina nuova

1. 01Aggiorna l'indice dei pacchetti e i pacchetti installatiUn'immagine appena creata è un'istantanea del momento in cui è stata generata. Portarla aggiornata è l'azione a maggior valore dell'intera lista, e richiede meno di un minuto.
2. 02Crea un utente non privilegiato con sudoLavorare sempre come root significa che ogni errore di battitura e ogni processo gira con piena autorità. Crea un utente normale, aggiungilo al gruppo sudo o wheel, e usa quello.
3. 03Copia la tua chiave pubblica su quell'utenteGenera una chiave ed25519 sulla tua macchina se non ne hai già una, poi invia la metà pubblica con ssh-copy-id. La chiave privata non lascia mai il tuo laptop.
4. 04Apri un secondo terminale e conferma che il login con chiave funzioniNon saltare questo passaggio. Accedi come nuovo utente con la chiave, in una nuova finestra, prima di modificare qualsiasi cosa relativa all'autenticazione.
5. 05Disabilita l'autenticazione via password e il login di rootImposta PasswordAuthentication no e PermitRootLogin prohibit-password, poi ricarica sshd. Ora un attacco a forza bruta contro la macchina non ha più nulla da indovinare.
6. 06Abilita un firewall a blocco predefinito con SSH consentitoNega tutto il traffico in entrata, consenti la tua porta SSH, poi abilitalo. Aggiungi in seguito le porte di cui i tuoi servizi hanno bisogno, una alla volta.
7. 07Attiva gli aggiornamenti di sicurezza automaticiunattended-upgrades su Debian e Ubuntu, dnf-automatic sulla famiglia RHEL. È questo che mantiene la macchina sicura al sesto mese, quando avrai smesso di prestarci attenzione.
8. 08Elenca cosa è in ascolto e chiudi ciò che non dovrebbe esserloUn singolo ss -tulpn ti mostra ogni socket aperto. Tutto ciò che non hai messo lì deliberatamente va rimosso o legato a localhost.

SSH: solo chiavi, e le impostazioni che contano

L'autenticazione a chiave pubblica è tutto l'hardening SSH che serve. Una volta disattivate le password, un attaccante ha bisogno di una chiave privata che non possiede, e nessuna quantità di tentativi ne produce una. Genera chiavi ed25519 — sono corte, veloci e lo standard moderno — e proteggi la chiave con una passphrase, così un laptop rubato non diventa un server rubato. Tutto il resto in sshd_config è un affinamento sopra quest'unica decisione.

• PasswordAuthentication no — l'impostazione che pone fine alla forza bruta. Verifica prima che la tua chiave funzioni, in una seconda sessione.
• PermitRootLogin prohibit-password — root resta raggiungibile con chiave per il recupero, ma mai con password. Impostalo su no una volta verificato il tuo utente sudo.
• AllowUsers o AllowGroups — una allowlist esplicita di chi può accedere, così un account di servizio creato da qualche pacchetto non potrà mai diventare un punto d'ingresso SSH.
• KbdInteractiveAuthentication no — chiude l'altro percorso interattivo che su alcune distribuzioni può riattivare silenziosamente i prompt della password.
• Una seconda chiave per un secondo dispositivo, invece di copiare in giro un'unica chiave privata. Perdere un telefono dovrebbe significare rimuovere una riga da authorized_keys, non ruotare tutto.
• Spostare SSH fuori dalla porta 22 riduce drasticamente il volume dei tuoi log, ma trattalo come una riduzione del rumore, non come sicurezza — non cambia nulla per chi sta davvero guardando il tuo IP.

Se vuoi andare oltre le chiavi, la soluzione più solida è non esporre affatto SSH pubblicamente: metti la macchina dietro un tunnel WireGuard e blocca con il firewall la porta 22, così accetta connessioni solo dall'indirizzo del tunnel. Questo trasforma il tuo demone SSH in qualcosa che internet non può vedere, un risultato migliore di qualsiasi quantità di hardening della configurazione su un demone esposto.

Il firewall: blocca tutto di default, poi apri esattamente ciò che usi

Un firewall ha senso solo se il suo comportamento predefinito è rifiutare. Consentire tutto e poi bloccare le porte note per essere pericolose è al contrario: finisci per proteggerti dai servizi che ti sei ricordato ed esporre quelli che hai dimenticato. Nega tutto il traffico in entrata, consenti quello in uscita, poi apri le singole porte man mano che distribuisci ciò che ne ha bisogno. Le distribuzioni Linux moderne usano nftables sotto il cofano, e ufw o firewalld sono interfacce perfettamente valide per gestirlo — lo strumento conta molto meno del comportamento predefinito.

• Consenti SSH prima di abilitare il firewall, non dopo. È il secondo modo più comune per restare tagliati fuori.
• Apri solo le porte di cui un servizio ha davvero bisogno dall'esterno. Un web server vuole la 80 e la 443; un database quasi mai vuole qualcosa.
• Lega i servizi solo-locali a 127.0.0.1 invece che a 0.0.0.0. Una porta chiusa e un servizio che non è mai in ascolto pubblicamente sono due protezioni indipendenti, e le vuoi entrambe.
• Scrivi regole IPv6 oltre a quelle IPv4. Un set di regole che copre solo v4 su una macchina dual-stack lascia lo stesso servizio spalancato sul suo indirizzo v6.
• Limita le porte di gestione per indirizzo di origine quando puoi. Se l'amministrazione arriva sempre da un unico endpoint VPN, specificalo nella regola.
• Rileggi le regole dopo aver aggiunto un servizio. Le porte aperte per qualcosa che nel frattempo hai rimosso sono l'accumulo silenzioso che vanifica un inizio pulito.

Alcuni carichi di lavoro ribaltano la logica e hanno bisogno di una porta spalancata di proposito — un relay Tor deve accettare connessioni da qualsiasi luogo, e un nodo Bitcoin completo serve i peer solo se la 8333 è raggiungibile. Va benissimo così. La regola non è "non aprire nulla", è "aprire deliberatamente", e un servizio pensato per essere pubblico è una scelta deliberata.

fail2ban, e perché conta meno di quanto pensi

fail2ban osserva i tuoi log e banna gli indirizzi che falliscono ripetutamente l'autenticazione. È genuinamente utile, ma vale la pena essere onesti su cosa fa una volta che hai già disabilitato l'autenticazione via password: a quel punto nessuno può riuscire tentando a caso, quindi fail2ban non sta più prevenendo un'intrusione. Ciò che previene sono migliaia di righe di log inutili al giorno, la CPU che quei tentativi di connessione consumano, e il rischio che un evento reale resti sepolto in un rumore che hai smesso di leggere mesi fa.

Vale comunque dieci secondi di configurazione, e diventa genuinamente protettivo nel momento in cui esegui qualcosa che accetta davvero una password — il login di un'applicazione web, un server di posta, un pannello di controllo. Puntalo su quei log invece che solo su sshd. Imposta la finestra di ban in ore anziché in minuti, e aggiungi il tuo stesso indirizzo alla ignore list, così una password digitata male non ti chiude fuori dalla tua stessa macchina.

Aggiornamenti che non devi ricordarti di fare

La minaccia realistica per un server ben configurato non è qualcuno che sconfigge le tue chiavi SSH. È una vulnerabilità pubblicata per qualcosa che hai installato e dimenticato, sfruttata da uno scanner tre giorni dopo mentre stavi facendo altro. Gli aggiornamenti di sicurezza automatici sono la risposta: su Debian o Ubuntu è unattended-upgrades configurato per installarli, su Fedora, Rocky o Alma è dnf-automatic. Attivalo durante i primi dieci minuti e la macchina continuerà ad applicare da sola le patch molto dopo che la tua attenzione si sarà spostata altrove.

Gli aggiornamenti del kernel e della libc sono l'eccezione che ha ancora bisogno di te: hanno effetto solo dopo un riavvio, quindi un server attivo da quattrocento giorni sta quasi certamente eseguendo codice che sul disco era stato corretto un anno prima. needrestart di Debian ti dirà quali servizi stanno girando contro librerie ormai cancellate, e una finestra di reboot programmata — anche solo mensile — è la differenza tra patch installate e patch applicate. Qualsiasi cosa tu esegua dovrebbe comunque sopravvivere a un reboot inatteso; se non lo fa, è un problema separato che vale la pena risolvere.

Le fughe di identità che una checklist di hardening non nota

Questa è la sezione che conta se hai scelto di proposito un host offshore e no-KYC. Una guida di hardening standard è scritta per un server aziendale il cui proprietario è di dominio pubblico, quindi non si chiede mai cosa la configurazione predefinita scriva su di te. Su una macchina noleggiata in modo anonimo, diverse di quelle impostazioni predefinite ricollegano silenziosamente il tuo nome ad essa.

• La tua chiave pubblica SSH porta con sé un commento — per default il tuo username locale e l'hostname del tuo laptop, qualcosa come alex@alex-macbook — e quel commento viene salvato testualmente in authorized_keys sul server. Impostalo con il flag -C quando generi la chiave, oppure modifica la riga dopo averla copiata.
• L'hostname del server che scegli finisce nei log, negli header delle email, nell'output del monitoraggio e a volte nei banner dei servizi. Un hostname generico non rivela nulla; il tuo nome o quello della tua azienda sì.
• Il fuso orario di sistema. Le immagini cloud per default sono in UTC, che non dice niente a nessuno. Impostarlo sul tuo fuso locale restringe l'area di dove ti trovi, e i timestamp in ogni log confermano poi il tuo orario di lavoro.
• La configurazione Git copiata sulla macchina, che porta con sé il nome e l'indirizzo email con cui fai commit. Lo stesso vale per i file di cronologia della shell, i dotfile sincronizzati dalla tua workstation, e qualsiasi credenziale rimasta in cache durante un test frettoloso.
• L'indirizzo email che consegni a Let's Encrypt durante l'emissione del certificato, che diventa parte di un registro pubblico per quel certificato. Usa un indirizzo non collegato alla tua identità.
• I banner di versione del web server e gli header X-Powered-By, più qualsiasi analytics, crash reporter o agente di monitoraggio del fornitore che invia dati dalla macchina portando con sé un identificatore di account.

Vale la pena tenere distinti i livelli. L'hardening tiene gli estranei fuori dalla macchina. Questi dettagli impediscono alla macchina di descriverti a chi la sta già osservando. E il livello del pagamento decide se ci fosse mai stato un nome da trovare — un tema trattato onestamente in se comprare un VPS con Bitcoin sia davvero anonimo, e approfondito da ricaricare in Monero. Ogni livello, da solo, può fallire; insieme reggono.

Backup: la parte che l'hardening non può fare al posto tuo

Nessuna regola del firewall protegge da un database cancellato, un disco guasto o una modifica di configurazione che al momento sembrava ragionevole. I backup sono l'unico controllo che ti fa riprendere dagli errori che commetti tu stesso, che è statisticamente il modo più probabile in cui perderai dati su una macchina ben protetta. Cifrali prima che lascino il server, tienine almeno una copia da qualche parte che il server stesso non può raggiungere, e impostali per girare secondo una pianificazione invece che quando te ne ricordi.

Quest'ultimo punto conta più di quanto sembri: un processo di backup che il server può sovrascrivere è un backup che chiunque abbia root sul server può distruggere. Inviare archivi cifrati a un server di storage separato — oppure prelevarli da lì, così le credenziali vivono fuori dalla macchina di cui fai il backup — ti dà una copia che sopravvive alla macchina. E fai il restore una volta, di proposito, mentre non c'è nulla che non va. Un backup non testato è un'ipotesi, non una rete di sicurezza.

Errori che silenziosamente vanificano il lavoro

• Disabilitare l'autenticazione via password prima di testare la chiave, per poi scoprire l'errore da un laptop che non riesce più ad accedere.
• Abilitare il firewall prima di consentire SSH — lo stesso blocco d'accesso, raggiunto dalla direzione opposta.
• Scrivere solo regole IPv4, lasciando ogni servizio raggiungibile sull'indirizzo IPv6 della macchina.
• Fare un hardening accurato il primo giorno, per poi installare un pannello di controllo, un database e uno stack di monitoraggio che aprono ciascuno la propria porta senza che gli venga chiesto.
• Eseguire tutto come root perché è un sudo in meno da digitare, così la prima falla in una qualsiasi di quelle cose diventa una compromissione totale.
• Trattare fail2ban come un sostituto delle chiavi, il che lascia comunque attivo un gioco di indovinare la password, solo più lento.
• Presumere che un server noleggiato possa essere reso privato rispetto al proprio host cifrando il disco — la crittografia completa del disco protegge un disco rubato, non una macchina in funzione.
• Non riavviare mai, così mesi di patch del kernel installate restano sul disco mentre il vecchio kernel continua a girare.

Niente di tutto questo è difficile, e niente richiede molto tempo. Fallo in ordine, verifica ogni passaggio da un secondo terminale prima di proseguire, e la macchina che hai distribuito pochi minuti fa smette di essere un'opportunità per chiunque stia setacciando lo spazio degli indirizzi. Poi distribuisci qualunque cosa tu sia realmente venuto a eseguire qui — un sito web, un nodo, un tunnel, un endpoint privato per un modello — su una base che conosci a fondo.