Mettere in sicurezza un server Ubuntu 24.04 appena creato: le prime 10 cose da fare

Un VPS Ubuntu 24.04 appena creato arriva con una configurazione pensata per essere comoda, non per essere sicura. Root abilitato, nessun firewall attivo, nessuna chiave SSH imposta. Prima di metterci sopra qualsiasi servizio, conviene passare da questa checklist. Comandi testati su Ubuntu 24.04 LTS (noble), da eseguire in ordine perché alcuni passaggi, se invertiti, ti tagliano fuori dal server.

1. Connettiti e crea subito un utente non privilegiato

adduser deploy
usermod -aG sudo deploy

Da questo momento in poi lavori con deploy, non con root. Prova subito sudo whoami da quell'utente prima di chiudere la sessione root: deve rispondere root.

2. Copia la tua chiave pubblica sul nuovo utente

rsync --archive --chown=deploy:deploy ~/.ssh /home/deploy

Oppure, da locale: ssh-copy-id deploy@IP_SERVER. Verifica che il login con chiave funzioni prima di toccare la password authentication.

3. Disabilita il login root via SSH

Su Ubuntu 24.04 il valore di default di PermitRootLogin nel file /etc/ssh/sshd_config è già prohibit-password, quindi il login root con password è bloccato fin dall'installazione. Per chiuderlo del tutto, anche via chiave:

sudo nano /etc/ssh/sshd_config

Imposta:

PermitRootLogin no
PasswordAuthentication no

Attenzione a un dettaglio che manda in confusione molti: se nella cartella /etc/ssh/sshd_config.d/ esiste un file che imposta di nuovo PermitRootLogin, quel valore vince sul file principale, perché viene incluso dopo. Controlla con:

grep -rn "PermitRootLogin" /etc/ssh/sshd_config /etc/ssh/sshd_config.d/*.conf 2>/dev/null

Prima di riavviare, verifica la sintassi e poi applica:

sudo sshd -t
sudo systemctl restart ssh

Tieni aperta la sessione attuale e aprine una seconda per testare il login: se qualcosa non va, la prima sessione ti permette ancora di correggere.

4. Cambia la porta SSH (facoltativo, riduce il rumore nei log)

Nello stesso file:

Port 2222

Non è una misura di sicurezza vera, ma abbassa il numero di tentativi di bruteforce automatico sulla 22. Se la cambi, ricordati di aprirla su ufw al passo successivo, altrimenti resti fuori.

5. Attiva ufw con solo le porte indispensabili

Prima regola fissa: apri la porta SSH prima di attivare il firewall, altrimenti ti blocchi fuori.

sudo ufw allow 2222/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose

Se non hai cambiato la porta SSH, usa sudo ufw allow 22/tcp o, più leggibile, sudo ufw allow OpenSSH. Ogni porta aperta in più è una porta da giustificare: se il server fa solo da backend dietro un reverse proxy, 80 e 443 magari non ti servono nemmeno.

6. Verifica che unattended-upgrades sia davvero attivo

Su Ubuntu Server 24.04 il pacchetto unattended-upgrades è preinstallato e l'installazione automatica degli aggiornamenti di sicurezza è già abilitata subito dopo l'installazione del sistema. Non è un'impostazione da attivare da zero: è da verificare.

cat /etc/apt/apt.conf.d/20auto-upgrades

Il contenuto atteso è:

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";

Se il file manca o è vuoto, installa il pacchetto e riconfigura:

sudo apt update
sudo apt install -y unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades

Per impostazione predefinita il meccanismo applica solo gli aggiornamenti dell'origine -security, lasciando fuori gli aggiornamenti ordinari (-updates): la politica è definita in /etc/apt/apt.conf.d/50unattended-upgrades, nel blocco Unattended-Upgrade::Allowed-Origins. Se vuoi includere anche gli aggiornamenti non di sicurezza, decommenta la riga "${distro_id}:${distro_codename}-updates"; in quel file: è una scelta che espone a più cambi non controllati, quindi su un server di produzione la maggior parte dei sistemisti la lascia disattivata.

I log di ogni esecuzione finiscono in /var/log/unattended-upgrades/, utile da controllare se un riavvio notturno ti sorprende senza preavviso.

7. Blocca anche il login diretto come root sul sistema

Oltre a SSH, vale la pena bloccare root pure in locale/console se non ti serve:

sudo passwd -l root

Il comando blocca la password, non elimina l'account: resta disponibile sudo -i dall'utente con privilegi.

8. Imposta un timezone e un hostname sensati

Non è sicurezza in senso stretto, ma i log con timestamp coerenti ti servono il giorno che devi correlare un evento:

sudo timedatectl set-timezone Europe/Rome
sudo hostnamectl set-hostname nome-del-server

9. Separa l'utente di deploy da quello dei servizi applicativi

L'utente deploy creato al punto 1 serve per entrare, fare sudo, gestire il sistema. Non deve essere lo stesso account sotto cui gira l'applicazione web o il database. Per ogni servizio, crea un utente di sistema dedicato senza shell:

sudo adduser --system --no-create-home --group nomeapp

Così, se un'applicazione viene compromessa, l'attaccante eredita i permessi di nomeapp, non quelli di un utente con sudo.

10. Verifica finale prima di andare avanti

Prima di installare qualunque altro software, un controllo in sequenza:

sudo sshd -T | grep -i permitrootlogin
sudo ufw status verbose
systemctl status unattended-upgrades
sudo passwd -S root
awk -F: '($3 == "0") {print}' /etc/passwd

L'ultimo comando deve restituire solo la riga di root: se compare un secondo utente con UID 0, c'è un problema serio da risolvere prima di qualsiasi altra cosa.

Da qui in poi il server è pronto per i passaggi successivi: fail2ban o crowdsec per il brute-force, backup automatici, monitoraggio. Ma quello è un altro pezzo.