Sicurezza del VPS da zero: chiavi SSH, firewall e Fail2ban

Un nuovo VPS non è protetto automaticamente dopo l’installazione di Ubuntu. Prima ancora di configurare l’accesso, il server è già visibile agli scanner: provano password SSH, cercano pannelli esposti e verificano le vulnerabilità più comuni. In questa guida vedremo come mettere in sicurezza un VPS da zero: creeremo un utente separato, configureremo l’accesso tramite chiave SSH, limiteremo le porte di rete con UFW e aggiungeremo Fail2ban. Tutti i passaggi sono adatti a Ubuntu 22.04 e 24.04, se i comandi vengono eseguiti da un utente con privilegi sudo.

Prima della configurazione: crea un elenco delle porte

Non aprire le porte «per sicurezza». Per un normale server web servono:

• 22/tcp — SSH, preferibilmente limitato per IP oppure spostato su un’altra porta solo come misura aggiuntiva;
• 80/tcp — HTTP, normalmente necessario per il reindirizzamento a HTTPS e per la verifica del certificato;
• 443/tcp — HTTPS.

Una porta applicativa come 3000, 8080 o 9000 non dovrebbe essere accessibile da internet se davanti all’applicazione funziona Nginx o Caddy. Collega l’applicazione a 127.0.0.1 oppure consenti la sua porta solo alla rete interna. Per prima cosa verifica cosa è in ascolto sul server:

sudo ss -tulpn

Dopo aver installato Docker, controlla separatamente le sue regole iptables: la pubblicazione -p 3000:3000 può aprire una porta aggirando lo schema previsto. Per un servizio pubblico è più sicuro usare un proxy HTTPS e nascondere la porta interna.

Passaggio 1. Aggiorna il sistema e crea un amministratore

Connettiti al VPS con l’account fornito e installa gli aggiornamenti:

sudo apt update
sudo apt full-upgrade -y
sudo apt install -y ufw fail2ban unattended-upgrades

Crea il tuo utente personale. Al posto di alex usa il tuo nome:

sudo adduser alex
sudo usermod -aG sudo alex

Non rimuovere l’accesso iniziale finché non hai verificato il nuovo account in una finestra separata del terminale. È una regola importante: correggere un errore SSH è più semplice quando la sessione attuale è ancora aperta.

Passaggio 2. Crea una chiave SSH e installala sul server

Sul tuo computer Linux, macOS o Windows PowerShell esegui:

ssh-keygen -t ed25519 -C "alex@my-computer"

Premi Enter per salvare la chiave nel file predefinito e imposta una passphrase. La chiave privata non deve essere inviata in chat, inserita in un repository o copiata sul VPS. Sul server devi trasferire solo il file con estensione .pub:

ssh-copy-id alex@SERVER_IP

Se ssh-copy-id non è disponibile, apri la chiave pubblica con il comando Get-Content $env:USERPROFILE\.ssh\id_ed25519.pub in PowerShell, quindi aggiungila al server:

sudo install -d -m 700 -o alex -g alex /home/alex/.ssh
sudo nano /home/alex/.ssh/authorized_keys
sudo chown alex:alex /home/alex/.ssh/authorized_keys
sudo chmod 600 /home/alex/.ssh/authorized_keys

Incolla la chiave su una sola riga e verifica l’accesso prima di disabilitare le password:

ssh alex@SERVER_IP
sudo whoami

L’output atteso dell’ultimo comando è root. Se il client SSH non trova la chiave, indicagliela esplicitamente: ssh -i ~/.ssh/id_ed25519 alex@SERVER_IP.

Passaggio 3. Disabilita root e l’accesso tramite password

Crea una copia di backup della configurazione SSH:

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak
sudo nano /etc/ssh/sshd_config

Assicurati che nel file siano presenti questi parametri:

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
KbdInteractiveAuthentication no
MaxAuthTries 3

In Ubuntu le impostazioni possono trovarsi in /etc/ssh/sshd_config.d/*.conf, quindi controlla la configurazione risultante:

sudo sshd -t
sudo sshd -T | grep -E 'permitrootlogin|passwordauthentication|pubkeyauthentication|maxauthtries'

Se sshd -t mostra un errore, non riavviare il servizio finché non hai corretto la sintassi. Dopo una verifica riuscita applica le impostazioni:

sudo systemctl reload ssh

Lascia aperta la vecchia connessione SSH e, in una nuova finestra, verifica l’accesso con la chiave. Disabilitare le password senza aver verificato una chiave funzionante è il modo più comune per perdere l’accesso al server.

Passaggio 4. Configura UFW senza bloccare SSH

UFW è un’interfaccia comoda per le regole di rete di Linux. Imposta prima i valori predefiniti sicuri, poi consenti SSH e le porte web:

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp comment 'SSH'
sudo ufw allow 80/tcp comment 'HTTP'
sudo ufw allow 443/tcp comment 'HTTPS'
sudo ufw enable

Conferma l’attivazione solo dopo aver aggiunto la regola SSH. Controlla il risultato:

sudo ufw status verbose
sudo ufw status numbered

Per un IP aziendale permanente puoi limitare SSH a quell’indirizzo:

sudo ufw delete allow 22/tcp
sudo ufw allow from YOUR.PUBLIC.IP to any port 22 proto tcp comment 'SSH office'

Usa questa variante solo se hai un IP fisso e accesso alla console del provider: se l’indirizzo cambia, potresti bloccarti fuori dal server.

Come aprire temporaneamente una porta applicativa

Se devi verificare direttamente un servizio, crea una regola con la sorgente limitata:

sudo ufw allow from YOUR.PUBLIC.IP to any port 8080 proto tcp

Dopo il test rimuovila usando il numero mostrato da ufw status numbered:

sudo ufw delete RULE_NUMBER

Non usare sudo ufw allow 1:65535/tcp: una regola di questo tipo trasforma il firewall in una formalità.

Passaggio 5. Attiva Fail2ban per SSH

Fail2ban analizza i log e aggiunge una regola di blocco temporanea dopo diversi accessi falliti. Non sostituisce le chiavi SSH né il firewall, ma riduce il rumore dei tentativi automatici.

Crea una configurazione locale, così gli aggiornamenti del pacchetto non sovrascriveranno le tue impostazioni:

sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
sudo nano /etc/fail2ban/jail.local

Nella sezione [DEFAULT] imposta valori ragionevoli:

[DEFAULT]
bantime = 1h
findtime = 10m
maxretry = 5
backend = systemd
banaction = ufw

[sshd]
enabled = true
port = 22

Avvia il servizio e controlla il jail:

sudo systemctl enable --now fail2ban
sudo fail2ban-client status
sudo fail2ban-client status sshd

Nell’output di sshd controlla il numero di tentativi falliti e gli indirizzi bloccati. Non aggiungere il tuo IP all’elenco dei ban. Per un’esclusione permanente usa il parametro ignoreip = 127.0.0.1/8 YOUR.PUBLIC.IP in [DEFAULT].

Passaggio 6. Attiva gli aggiornamenti automatici

Gli aggiornamenti automatici sono utili per i pacchetti di sicurezza, ma il riavvio del kernel deve comunque essere controllato:

sudo dpkg-reconfigure -plow unattended-upgrades
sudo systemctl status unattended-upgrades

Una volta alla settimana verifica se è necessario riavviare il server:

test -f /var/run/reboot-required && echo 'Требуется перезапуск'

Prima di un riavvio manuale assicurati di avere una chiave funzionante e accesso alla console del VPS. Dopo il riavvio controlla i servizi dell’applicazione, Nginx, UFW e Fail2ban.

Passaggio 7. Verifica il risultato dall’esterno

Controlla la protezione da un altro computer, non solo leggendo il contenuto della configurazione:

ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no alex@SERVER_IP

Il comando dovrebbe terminare con un rifiuto. Verifica separatamente l’accesso funzionante tramite chiave:

ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519 alex@SERVER_IP

Sul VPS controlla gli indirizzi in ascolto e le regole:

sudo ss -lntup
sudo ufw status numbered
sudo fail2ban-client status sshd

La porta dell’applicazione dovrebbe essere in ascolto su 127.0.0.1 se non è destinata all’accesso diretto. Da un nodo esterno puoi usare nmap SERVER_IP, ma esegui la scansione solo sul tuo server: controllare infrastrutture altrui senza autorizzazione può violare la legge e le regole del provider.

Backup e ripristino

La protezione SSH non ti salva dalla cancellazione dei dati, da un errore dell’amministratore o dalla compromissione dell’applicazione. Conserva separatamente dal VPS le copie del database, delle configurazioni e dei file degli utenti. Uno schema minimo prevede una copia giornaliera, diverse versioni dei giorni precedenti e una verifica periodica del ripristino.

Non salvare password e token in script non protetti. In caso di fuga di dati revoca immediatamente il segreto e creane uno nuovo.

Come scegliere un VPS per un progetto sicuro

La sicurezza inizia dal controllo dell’infrastruttura. Su un VPS puoi scegliere autonomamente il sistema operativo, le regole del firewall, il metodo di accesso, il backup e la posizione dei servizi. Per un piccolo sito o una API sono più importanti una rete stabile, un disco SSD e una console di ripristino che un numero eccessivo di core virtuali.

Quando avvii un progetto su un VPS di tropic.host, definisci in anticipo i suoi punti di ingresso pubblici: nella maggior parte dei casi sono sufficienti SSH, HTTP e HTTPS. Lascia il database e i pannelli di amministrazione nel perimetro interno. Per un progetto in crescita, VPS separati per applicazione, database e monitoraggio aiutano a suddividere le zone di guasto.

Errori frequenti

• Disabilitare la password prima di aver verificato l’accesso tramite chiave. Mantieni la sessione attuale e testa separatamente il nuovo accesso.
• Lasciare 22/tcp aperta a tutto il mondo quando sarebbe possibile consentirla solo da indirizzi affidabili.
• Pubblicare direttamente le porte Docker. Controlla prima le regole di Docker e UFW.
• Installare Fail2ban e non controllare più i log. Dopo ogni modifica verifica journalctl -u ssh e lo stato del jail.

Conclusione

La protezione di base di un VPS richiede poco tempo se eseguita nell’ordine corretto: crea un utente separato, installa una chiave SSH, verifica l’accesso, vieta root e le password, attiva UFW, configura Fail2ban e gli aggiornamenti automatici. Poi aggiungi backup, logging e monitoraggio esterno.

Questi passaggi non rendono il server invulnerabile, ma eliminano gli errori più comuni della configurazione iniziale. In seguito dovrai adattare il profilo all’applicazione specifica: aggiorna le dipendenze, limita i privilegi dei servizi, proteggi i pannelli di amministrazione e controlla regolarmente le porte aperte.

FAQ

È necessario cambiare la porta SSH predefinita?

Non necessariamente. Spostare la porta riduce il rumore automatico, ma non sostituisce le chiavi, il divieto delle password, UFW e Fail2ban. Se cambi porta, aggiorna la regola del firewall e il parametro port nel jail di Fail2ban.

Cosa devo fare se perdo l’accesso dopo aver configurato UFW?

Usa la console web o la rescue console del provider e controlla la regola SSH e la configurazione di sshd. Non chiudere la vecchia sessione funzionante finché non hai confermato il nuovo accesso.

Fail2ban è sufficiente per proteggere SSH?

No. Fail2ban reagisce agli errori di accesso già avvenuti. La base deve essere costituita da chiavi SSH, autenticazione tramite password disabilitata, privilegi minimi per l’utente e un firewall limitato.

Posso consentire SSH solo da un IP?

Sì, se l’indirizzo è permanente: aggiungi a UFW una regola allow from per quell’IP. Predisponi prima la console del provider o un accesso di riserva, perché dopo un cambio di IP la connessione verrà bloccata.

Con quale frequenza devo controllare la sicurezza del VPS?

Dopo ogni modifica a SSH, al firewall o alla pubblicazione di porte Docker, controlla le porte e testa l’accesso. Come attività programmata, esamina aggiornamenti e log almeno una volta alla settimana e verifica regolarmente il ripristino dei backup.