Cosa fare nei primi 10 minuti su un nuovo VPS

I primi 10 minuti determinano il livello di sicurezza del server

Un VPS appena creato non è sicuro. Dal momento in cui dispone di un IP pubblico, gli scanner tentano di accedervi e l'immagine predefinita offre loro un'ampia superficie d'attacco: spesso root è raggiungibile, le password sono spesso consentite, il firewall non è configurato e non sono stati applicati aggiornamenti con una pianificazione regolare. La buona notizia è che bastano circa dieci minuti e pochi comandi per correggere tutte queste condizioni. Questa è la procedura operativa che seguo su ogni nuovo server prima di installarvi qualsiasi servizio.

Esegui i passaggi nell'ordine indicato, perché ciascuno si basa sui precedenti. Ogni passaggio dispone di una guida dedicata, collegata nel punto appropriato; questa pagina è il percorso rapido che le riunisce.

Minuto 1: aggiornare tutto

Accedi come root usando le credenziali fornite dal provider e aggiorna completamente il sistema prima di eseguire qualsiasi altra operazione:

apt update && apt upgrade -y

Un sistema privo delle patch più recenti è il bersaglio più facile. Per questo, questo passaggio viene prima di tutto. Al termine, configura gli aggiornamenti automatici di sicurezza, così il sistema resterà aggiornato senza doverlo ricordare manualmente.

Minuto 2: creare un utente normale con sudo

Non continuare a lavorare come root. Crea un utente personale e assegnagli sudo:

adduser matt
usermod -aG sudo matt

Da questo momento accedi con questo utente e usa sudo per le attività amministrative. Lavorare sempre come root fa sì che ogni errore e ogni compromissione avvengano con privilegi illimitati. È esattamente ciò che l'esecuzione con un utente senza privilegi serve a impedire.

Minuto 4: configurare le chiavi SSH

Le password possono essere indovinate; le chiavi no. Sul tuo laptop, se non hai già una chiave, creane una:

ssh-keygen -t ed25519

Poi copia la parte pubblica sul server:

ssh-copy-id matt@YOUR_SERVER

ssh-copy-id richiede che l'accesso tramite password sia abilitato per il nuovo utente; se è già disabilitato, copia ~/.ssh/authorized_keys di root in /home/matt/.ssh/authorized_keys, assegnandolo a matt, oppure incolla manualmente la tua chiave pubblica in quel file.

Il modello alla base di questo passaggio, una chiave per dispositivo, i permessi che impediscono l'accesso tramite chiave e la revoca di una chiave smarrita sono descritti in Nozioni di base sulla gestione delle chiavi SSH.

Disconnettiti e accedi nuovamente come matt usando la chiave. Verifica che funzioni prima di procedere. Limitare l'accesso SSH prima di riuscire ad accedere con una chiave è il modo più comune per rimanere chiusi fuori dal server. Se l'accesso restituisce Permission denied (publickey), risolvi subito il problema invece di tornare alla password, perché quel messaggio può indicare cinque problemi diversi e l'output di ssh -v mostra quale si è verificato.

Minuto 6: Disabilitare l'accesso root e le password

Ora che la chiave funziona, chiudi i due punti di accesso utilizzati dagli scanner. Usa un file drop-in, in modo che gli aggiornamenti dei pacchetti non lo sovrascrivano. Chiamalo 00-, così viene ordinato prima di 50-cloud-init.conf, incluso nelle immagini cloud di Ubuntu con PasswordAuthentication yes; sshd mantiene il primo valore letto, quindi un file ordinato successivamente verrebbe ignorato senza alcun avviso:

sudo nano /etc/ssh/sshd_config.d/00-hardening.conf

PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no

Quindi ricarica SSH:

sudo systemctl restart ssh

Controlla poi le impostazioni effettivamente utilizzate da sshd, così un drop-in ignorato non può trarre in inganno:

sudo sshd -T | grep -Ei 'passwordauthentication|permitrootlogin'

Con le password disabilitate e l'accesso root rimosso, il traffico costante di tentativi brute-force diretto contro il server non può avere successo. La procedura completa, incluso il cambio facoltativo della porta, è descritta in Mettere in sicurezza SSH su un VPS.

Minuto 8: Attivare il firewall

Imposta il criterio predefinito di negazione per tutto il traffico in ingresso, quindi consenti soltanto ciò che serve. Consenti SSH prima di attivare il firewall, altrimenti interromperai la connessione attiva:

sudo ufw default deny incoming
sudo ufw allow 22/tcp
sudo ufw enable

Aggiungi le regole allow per ogni servizio effettivamente in esecuzione, ad esempio 80/tcp e 443/tcp per un sito web. Se dopo questa modifica una nuova sessione SSH non riesce più a connettersi, leggi l'errore prima di intervenire, perché un rifiuto indica che sshd ha risposto, mentre un timeout di solito indica che il firewall ha scartato il pacchetto. Verifica che siano coperti sia IPv4 sia IPv6, perché un firewall che filtra soltanto IPv4 lascia il lato IPv6 completamente esposto. La procedura completa è disponibile in Introduzione ai firewall su un VPS. Questi comandi ufw presuppongono Ubuntu o Debian; su un sistema Rocky o AlmaLinux l'obiettivo di negare tutto per impostazione predefinita è lo stesso, ma lo strumento è firewalld. Segui quindi la versione di questo passaggio per firewalld.

Minuto 10: rallenta gli scanner con Fail2ban

Infine, aggiungi Fail2ban per escludere gli indirizzi che inviano continuamente richieste alle tue porte:

sudo apt install -y fail2ban

Su Ubuntu 24.04, l'installazione predefinita protegge SSH già dal primo avvio. Poiché le chiavi sono già obbligatorie, questa misura serve come protezione aggiuntiva: riduce il rumore nei log e blocca i responsabili delle violazioni ripetute, ma non sostituisce la difesa principale.

La checklist

Questa è la procedura operativa. Usa il generatore qui sotto per selezionare ogni controllo e creare una checklist personalizzata da conservare insieme al server, includendo il comando esatto per ogni passaggio:

Eseguila una volta per ogni nuovo server: in questo modo l’intera procedura diventa automatica. Dieci minuti investiti ora evitano il pomeriggio molto difficile che segue la compromissione di un server.

Dopo aver configurato gli elementi essenziali, gli aggiornamenti automatici di sicurezza su Ubuntu mantengono il server aggiornato senza dover accedere di nuovo. Ogni servizio aggiunto richiede poi una verifica specifica e i punti deboli cambiano: con un vault di password self-hosted il server non conserva le password in chiaro, quindi i rischi reali di Vaultwarden riguardano il token amministrativo e il file di backup.

FAQ

Cosa devo fare per prima cosa su un nuovo VPS?

Aggiorna il sistema con apt update && apt upgrade -y, quindi crea un utente normale con sudo e smetti di lavorare come root. Configura quindi le chiavi SSH, disabilita l'accesso root e l'autenticazione tramite password, abilita un firewall con criterio predefinito di negazione e installa Fail2ban. Eseguire queste operazioni in quest'ordine consente di procedere in sicurezza senza rischiare di perdere l'accesso al server.

Come posso evitare di perdere l'accesso mentre metto in sicurezza SSH?

Configura e verifica l'accesso SSH tramite chiave prima di disabilitare le password o root. Esci dalla sessione e accedi nuovamente con la chiave per confermare che funzioni, quindi disabilita PasswordAuthentication e PermitRootLogin. Quando abiliti il firewall, consenti la porta 22 prima di eseguire ufw enable. Se perdi comunque l'accesso, la console web del provider ti consente di rientrare senza SSH.

Servono davvero tutte queste misure su un server di piccole dimensioni?

Sì, perché gli scanner non considerano le dimensioni del server. Provano allo stesso modo ogni indirizzo IP pubblico. L'intera procedura richiede circa dieci minuti ed elimina i vettori più semplici: niente accesso root, nessun tentativo di indovinare la password, nessun servizio esposto che tu non abbia scelto di pubblicare e vulnerabilità note corrette automaticamente.

Qual è l'unica misura più importante?

Usare SSH solo con chiavi e disabilitare l'accesso root. La maggior parte degli attacchi contro un VPS appena creato consiste in tentativi automatizzati di indovinare la password dell'account root. Disabilitare entrambe le modalità rende impossibile questa intera categoria di attacchi. Il firewall e Fail2ban limitano quindi ciò che è esposto e rallentano gli attacchi rimanenti.

Come posso verificare che il server sia effettivamente protetto?

Prima di considerarlo affidabile, controlla manualmente tre aspetti. Esegui sudo ss -tlnp e verifica che siano in ascolto su un indirizzo pubblico soltanto le porte che intendevi aprire, senza servizi 0.0.0.0 o [::] di cui ti eri dimenticato. Esegui sudo ufw status verbose e verifica che il criterio predefinito per il traffico in ingresso sia deny e che siano presenti sia le regole normali sia quelle (v6). Apri sempre una seconda sessione SSH prima di chiudere la prima, così un errore nella configurazione SSH non può farti perdere l'accesso al server. Se tutti e tre i controlli hanno esito corretto, le misure di base sono attive.