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: Configurazione delle chiavi SSH

Le password possono essere indovinate; le chiavi no. Sul proprio portatile, se non si possiede già una chiave, crearne una:

ssh-keygen -t ed25519

Quindi copiare la metà pubblica sul server:

ssh-copy-id matt@YOUR_SERVER

ssh-copy-id richiede che l'accesso tramite password sia attivo per il nuovo utente; se è già disattivato, copiare il file ~/.ssh/authorized_keys di root in /home/matt/.ssh/authorized_keys (di proprietà di matt), oppure incollare manualmente la propria 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, è trattato in fondamenti della gestione delle chiavi SSH.

Disconnettersi e rientrare come matt utilizzando la chiave e confermare che funzioni prima di passare al passaggio successivo. Limitare l'accesso SSH prima di riuscire ad accedere con una chiave è il modo in cui le persone rimangono chiuse fuori dal server. Se l'accesso restituisce Permission denied (publickey), risolvere il problema ora invece di ripiegare sulla password, poiché quel singolo messaggio copre cinque diversi errori e l'output di ssh -v indica quale di essi si è effettivamente verificato.

Minuto 6: disabilitare l'accesso root e le password

Ora che la chiave funziona, chiudi i due punti di accesso sfruttati dagli scanner. Usa un file drop-in, così gli aggiornamenti dei pacchetti non lo sovrascrivono. Chiamalo 00-, in modo che venga ordinato prima di qualsiasi altro file in quella directory. Le immagini cloud di Ubuntu includono 60-cloudimg-settings.conf con PasswordAuthentication no, ma se il provider imposta ssh_pwauth in cloud-init, cloud-init scrive 50-cloud-init.conf. Questo file viene ordinato intenzionalmente prima di quello dell'immagine e può riattivare le password. sshd mantiene il primo valore che legge, quindi un file ordinato successivamente verrebbe ignorato senza messaggi:

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

PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no

Quindi ricarica SSH:

sudo systemctl restart ssh

Controlla quindi 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 brute force diretto contro il server non può riuscire. La procedura completa, incluso il cambio facoltativo della porta, è descritta in Messa in sicurezza di 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.