Proteggere un VPS Linux: la checklist completa (2026)

Checklist di sicurezza: panoramica

Applicare questi passaggi nell'ordine, ognuno rafforza il successivo.

Azione	Priorità	Tempo stimato	Guida dettagliata
Aggiornamenti di sistema	Critica	5 min	Sezione qui sotto
Creare un utente non root	Critica	5 min	Sezione qui sotto
Rafforzare SSH (chiave + disattivare root/password)	Critica	10 min	Guida chiave SSH
Configurare UFW (firewall)	Critica	5 min	Guida UFW
Installare Fail2ban	Alta	10 min	Guida Fail2ban
Attivare HTTPS (Certbot)	Alta	5 min	Guida Certbot
Mettere in atto i backup	Alta	15 min	Sezione qui sotto
Monitoraggio di base	Media	5 min	Sezione qui sotto

1. Aggiornamenti di sistema

I pacchetti non aggiornati sono la prima fonte di compromissione. Applicare gli aggiornamenti fin dalla prima connessione, poi automatizzare.

Aggiornamento iniziale

sudo apt update && sudo apt upgrade -y
sudo apt autoremove -y

Automatizzare gli aggiornamenti di sicurezza

Il pacchetto unattended-upgrades applica automaticamente gli aggiornamenti di sicurezza senza intervento manuale. Fonte: wiki.debian.org/UnattendedUpgrades

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

Rispondere "Sì" alla domanda posta dal configuratore. Gli aggiornamenti di sicurezza si applicano quindi automaticamente ogni notte.

2. Creare un utente non root con sudo

Connettersi e operare permanentemente come root è una cattiva pratica: un errore di comando o una compromissione ha un impatto immediato su tutto il sistema. Creare un utente dedicato con privilegi sudo.

adduser nomeutente
usermod -aG sudo nomeutente

Verificare che sudo funzioni prima di chiudere la sessione root:

su - nomeutente
sudo whoami

Il comando deve restituire root. Una volta confermato, utilizzare questo utente per tutte le operazioni successive.

Fonte: wiki.debian.org/sudo

3. Rafforzare SSH

SSH è il vettore di attacco più comune su un VPS esposto. Tre misure fondamentali: autenticazione con chiave, disattivazione del login root, disattivazione dell'autenticazione con password.

Autenticazione con chiave SSH

Generare e distribuire una chiave SSH dalla vostra macchina locale, poi verificare la connessione prima di disattivare le password. La procedura completa è nella guida dedicata: guida chiave SSH OuiHeberg.

Disattivare il login root e l'autenticazione con password

Una volta confermata la connessione con chiave, modificare /etc/ssh/sshd_config:

sudo nano /etc/ssh/sshd_config

Modificare o aggiungere queste direttive:

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes

Ricaricare SSH:

sudo systemctl reload ssh

Fonte: man.openbsd.org/sshd_config

Cambiare la porta SSH (opzionale)

Cambiare la porta SSH (per esempio da 22 a 2222) non costituisce una misura di sicurezza in sé: una scansione delle porte la rileva in pochi secondi. In compenso, riduce significativamente il volume di tentativi automatizzati nei log, il che facilita il monitoraggio. Se cambiate la porta, aprire questa porta in UFW prima di ricaricare SSH, e non chiudere la porta 22 prima di aver verificato la connessione sulla nuova porta.

# In /etc/ssh/sshd_config
Port 2222

4. Configurare il firewall UFW

UFW (Uncomplicated Firewall) è l'interfaccia raccomandata per gestire le regole iptables su Debian e Ubuntu. Regola di base: bloccare tutto il traffico in entrata per impostazione predefinita, aprire solo le porte necessarie.

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow ssh
sudo ufw enable

Guida completa (regole per servizio, limitazione delle connessioni, verifica): guida UFW OuiHeberg.

5. Installare Fail2ban

Fail2ban monitora i log di sistema e bandisce automaticamente gli indirizzi IP che moltiplicano i tentativi di connessione falliti. Complementare a UFW: UFW filtra le porte, Fail2ban filtra i comportamenti.

sudo apt install -y fail2ban

Configurazione raccomandata, monitoraggio e sblocco nella guida dedicata: guida Fail2ban OuiHeberg.

6. Attivare HTTPS con Certbot

Un certificato TLS è indispensabile per qualsiasi servizio web esposto. Certbot automatizza l'ottenimento e il rinnovo dei certificati Let's Encrypt per Nginx e Apache.

sudo apt install -y snapd
sudo snap install certbot --classic
sudo certbot --nginx -d miosito.it -d www.miosito.it

Il rinnovo automatico, i certificati wildcard e la risoluzione degli errori comuni sono trattati nella guida dedicata: guida Certbot OuiHeberg.

7. Backup

Un backup non verificato non è un backup. La regola 3-2-1 è lo standard minimo: 3 copie dei dati, su 2 supporti diversi, di cui 1 fuori sede.

Backup di base con tar

# Backup di una directory applicativa
tar -czf /root/backup-$(date +%F).tar.gz /var/www/miosito

# Backup di un database MariaDB/MySQL
mysqldump -u root nome_db > /root/backup-db-$(date +%F).sql

Automatizzare con cron

sudo crontab -e

Aggiungere una riga per un backup quotidiano alle 3 del mattino:

0 3 * * * tar -czf /root/backup-$(date +\%F).tar.gz /var/www/miosito

Snapshot VPS

Le offerte VPS OuiHeberg includono spazi di backup e snapshot configurabili dal pannello di gestione. Uno snapshot cattura lo stato completo del VPS (sistema + dati) e permette un ripristino rapido in caso di incidente grave.

Verificare il ripristino

Pianificare una prova di ripristino almeno una volta a trimestre. Un backup il cui ripristino non è mai stato verificato non può essere considerato affidabile.

8. Monitoraggio di base

Il monitoraggio non richiede strumenti complessi per iniziare. I log di sistema contengono l'essenziale dei segnali di allarme.

Monitorare i tentativi di connessione SSH

# Ultime connessioni riuscite e fallite
sudo journalctl -u ssh --since "24 hours ago" | grep -E "Accepted|Failed"

# Equivalente tramite auth.log (Debian/Ubuntu)
sudo grep -E "Accepted|Failed" /var/log/auth.log | tail -50

Connessioni di rete attive

# Porte in ascolto e connessioni stabilite
sudo ss -tlnp

Verificare che solo le porte previste siano aperte. Qualsiasi porta sconosciuta merita un'indagine.

Carico di sistema

# Carico CPU, memoria, processi
top
# oppure, se installato:
htop

Segnali di allarme da monitorare

Picco di CPU o di memoria inspiegato
Processo sconosciuto che consuma risorse
Connessioni in uscita verso IP sconosciuti
File modificati di recente in /etc o /usr/bin

# File modificati nelle ultime 24 ore in /etc
sudo find /etc -mtime -1 -type f

Domande frequenti

In quale ordine applicare queste misure?

Seguire l'ordine della checklist all'inizio di questa guida. Prima gli aggiornamenti di sistema e la creazione di un utente non root, poi SSH rafforzato, quindi UFW. Non attivare UFW prima di aver aperto la porta SSH: è l'errore più comune che blocca l'accesso al VPS.

Serve un antivirus su un VPS Linux?

Gli antivirus tradizionali sono poco adatti ai server Linux. La superficie di attacco si riduce meglio con le misure di questa guida (aggiornamenti, SSH rafforzato, firewall, Fail2ban) che con un antivirus. ClamAV può essere utile se il VPS ospita file caricati dagli utenti (moduli, condivisione di file), ma resta opzionale per la maggior parte dei casi.

Come capire se il mio VPS è stato compromesso?

I segnali più comuni: picco di CPU inspiegato, processo sconosciuto in top, connessioni in uscita anomale in ss -tlnp, voci sospette in /var/log/auth.log, file di sistema modificati di recente. In caso di dubbio serio, ripristinare da uno snapshot pulito è più sicuro di un'indagine incompleta.

Queste misure bastano per un VPS in produzione?

Coprono i vettori di attacco più comuni e costituiscono una base solida. Per ambienti con esigenze elevate (dati sensibili, conformità normativa), si aggiungono misure complementari: audit di sicurezza regolari, rilevamento delle intrusioni (AIDE, auditd), segmentazione di rete, cifratura dei volumi. Questa guida copre il livello fondamentale applicabile a qualsiasi VPS esposto a Internet.

Questo VPS ospiterà un sito attualmente altrove? Mettetelo in sicurezza prima, poi seguite la guida alla migrazione da un hosting condiviso.