Sicurezza Linux VPS: Minacce, Livelli e Guida all'Hardening

Hai appena creato un VPS Linux. Entro 90 secondi, scanner automatizzati lo hanno già trovato. Nella prima ora, i tuoi log SSH mostreranno centinaia di tentativi di login brute-force da botnet che ciclano tra username e password comuni.

Non è uno scenario ipotetico. Succede a ogni server esposto su internet.

La maggior parte delle guide sulla sicurezza VPS ti consegna una lista numerata di 20+ consigli senza struttura né priorità. Questa guida adotta un approccio diverso. Mappa la sicurezza come livelli concentrici, ognuno dei quali riduce ulteriormente la tua attack surface. Capirai quali attacchi colpiscono davvero il tuo server e quali difese li bloccano.

Se stai configurando il tuo primo VPS, parti dai primi 5 step di sicurezza. Quella sezione da sola blocca oltre il 90% degli attacchi automatizzati.

Se sei un admin esperto, usa i link di navigazione per andare direttamente al livello che ti serve.

Questa guida copre Debian 12 e Ubuntu 24.04. Tutti i comandi sono testati su entrambi.

Quali attacchi colpiscono un VPS Linux appena creato?

Un VPS con IP pubblico subisce attacchi automatizzati entro secondi dall'andare online. Le botnet scansionano continuamente l'intero spazio IPv4. Gli attacchi più comuni sono il credential stuffing SSH, la scansione di porte per servizi esposti e lo sfruttamento di vulnerabilità note in software non aggiornato.

Capire il threat model rende ogni raccomandazione di questa guida più chiara. Ecco cosa succede davvero:

Scansione automatizzata

Le botnet scansionano l'intero range di indirizzi IPv4 in modo continuo. Progetti come Shodan e Censys indicizzano ogni porta raggiungibile. Il tuo server non viene preso di mira in modo specifico. Viene trovato perché esiste.

Nella prima ora di provisioning, aspettati:

• 200+ tentativi di login SSH da IP distribuiti
• Scansioni di porte che cercano database (3306, 5432), web server (80, 443) e pannelli di amministrazione
• Richieste a path noti come vulnerabili (/wp-admin, /phpmyadmin, /.env)

Credential stuffing e brute force

Gli attaccanti usano database di credenziali trapelate per provare combinazioni username/password contro il tuo servizio SSH. Ciclano tra root, admin, ubuntu, deploy e altri nomi comuni. Se l'autenticazione con password è abilitata con una password debole, la compromissione avviene in pochi minuti.

Supply chain e post-compromissione

Una volta dentro, gli attaccanti installano cryptominer, aggiungono backdoor SSH o usano il tuo server come relay per altri attacchi. Alcuni installano rootkit che sopravvivono ai reboot. Un VPS compromesso può essere usato per attaccare altri server, rendendoti responsabile del traffico generato.

C'è anche una tendenza crescente agli attacchi supply chain che prendono di mira repository di pacchetti e script di installazione. Il pattern curl | bash, comune in molte guide di setup, esegue codice arbitrario da internet senza verifica. Evitalo. Scarica gli script, verifica i checksum, poi eseguili.

Ricognizione tramite version disclosure

Gli attaccanti fanno fingerprinting del software del server per trovare exploit corrispondenti. Un web server che risponde con Server: nginx/1.24.0 o un banner SSH che rivela la versione esatta di OpenSSH dice a un attaccante esattamente quali CVE provare. Nascondere la versione è un piccolo passo, ma elimina il targeting a basso sforzo. In questa guida e nei tutorial collegati vedrai come disabilitare la version disclosure per ogni servizio.

Cosa significa per le tue difese

Ogni livello di questa guida affronta vettori di attacco specifici:

Vettore di Attacco	Livello di Difesa
SSH brute force	SSH key auth, Fail2Ban
Scansione porte	Firewall (UFW/nftables)
Credential stuffing	Disabilitare password auth, utente non-root
Vulnerabilità non patchate	Aggiornamenti di sicurezza automatici
Accesso non autorizzato a servizi admin	VPN (WireGuard/Tailscale)
Privilege escalation	Permessi utente, sudo

Quali sono i primi 5 step di sicurezza su un nuovo VPS?

Se non fai nient'altro, fai queste cinque cose. Richiedono meno di 15 minuti e bloccano la grande maggioranza degli attacchi automatizzati: 1) aggiorna tutti i pacchetti, 2) crea un utente non-root con sudo, 3) configura l'autenticazione SSH con chiave e disabilita le password, 4) abilita un firewall, 5) installa Fail2Ban.

Ecco la sequenza quick-start. Ogni step rimanda a un tutorial dettagliato.

1. Aggiorna tutti i pacchetti

apt update && apt upgrade -y

Questo patcha le vulnerabilità note. Su un VPS appena creato, l'immagine base potrebbe essere settimane o mesi indietro con le patch di sicurezza.

2. Crea un utente non-root

adduser deploy
usermod -aG sudo deploy

Lavorare come root significa che qualsiasi errore o exploit ha accesso completo al sistema. Un utente sudo richiede escalation esplicita dei privilegi.

3. Configura l'autenticazione SSH con chiave

Sulla tua macchina locale, genera una coppia di chiavi Ed25519 se non ne hai una:

ssh-keygen -t ed25519 -C "your-email@example.com"

Copiala sul server:

ssh-copy-id -i ~/.ssh/id_ed25519.pub deploy@your-server-ip

Poi sul server, modifica /etc/ssh/sshd_config:

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes

Riavvia SSH. Su Ubuntu 24.04, SSH usa l'attivazione socket-based:

# Ubuntu 24.04
sudo systemctl restart ssh.socket

# Debian 12
sudo systemctl restart sshd

Verifica prima di disconnetterti: apri un secondo terminale e conferma di riuscire a fare login con la tua chiave come nuovo utente. Non chiudere mai la sessione corrente finché non hai verificato l'accesso.

4. Abilita un firewall

# Installa UFW (pre-installato su Ubuntu, da installare su Debian)
sudo apt install ufw -y

# Consenti SSH prima di abilitare
sudo ufw allow ssh

# Abilita il firewall
sudo ufw enable

# Verifica
sudo ufw status

Dovresti vedere SSH (porta 22) elencato come ALLOW. Tutto il resto è negato per default.

5. Installa Fail2Ban

sudo apt install fail2ban -y

Crea una configurazione jail locale:

sudo tee /etc/fail2ban/jail.d/sshd.conf > /dev/null << 'EOF'
[sshd]
enabled = true
maxretry = 3
findtime = 600
bantime = 1800
EOF

Su Debian 12, Fail2Ban deve leggere da journald invece di auth.log:

# Solo Debian 12
echo "sshd_backend = systemd" | sudo tee -a /etc/fail2ban/paths-debian.conf

Avvia e abilita il servizio:

sudo systemctl enable --now fail2ban

Verifica che sia in esecuzione:

sudo systemctl status fail2ban
sudo fail2ban-client status sshd

Dovresti vedere la jail sshd elencata come attiva con 0 IP attualmente bannati. Nelle ore successive inizierai a vedere i ban.

Come protegge il server l'hardening SSH?

SSH è la porta d'ingresso del tuo server e il bersaglio principale degli attacchi automatizzati. L'hardening SSH significa sostituire l'autenticazione con password con chiavi crittografiche, disabilitare il login root e limitare quali utenti e algoritmi il server accetta. Queste modifiche riducono l'attack surface SSH da "prova qualsiasi password" a "presenta esattamente questa chiave privata."

Oltre alle basi coperte nei primi 5 step, una configurazione SSH hardened include:

• Solo chiavi Ed25519. Più veloci e più sicure di RSA. La chiave è 256 bit ma fornisce 128 bit di sicurezza, equivalente a RSA-3072.
• Idle timeout. Disconnette le sessioni inattive per prevenire che terminali abbandonati vengano dirottati:

ClientAliveInterval 300
ClientAliveCountMax 2

• Limita gli utenti. Restringi l'accesso SSH ad account specifici:

AllowUsers deploy

• Disabilita metodi di autenticazione non utilizzati:

KbdInteractiveAuthentication no
X11Forwarding no

• Nascondi il banner della versione SSH. Anche se OpenSSH non permette di sopprimere completamente la versione del protocollo, puoi rimuovere i banner personalizzati e limitare le informazioni trapelate:

Banner none
DebianBanner no

Dopo qualsiasi modifica a sshd_config, valida la sintassi prima di riavviare:

sudo sshd -t

Se il comando non produce output, la configurazione è valida. Poi riavvia SSH e verifica di riuscire ancora a fare login da un secondo terminale. Testa sempre da una seconda sessione. Se la configurazione è rotta, hai ancora la connessione esistente.

Per il walkthrough completo di SSH hardening con configurazioni testate per Debian 12 e Ubuntu 24.04, vedi .

Perché il tuo VPS ha bisogno di un firewall?

Un firewall controlla quale traffico di rete raggiunge il tuo server. Senza di esso, ogni servizio che esegui è esposto a internet. Un database sulla porta 5432, un dev server sulla porta 3000, un'istanza Redis sulla porta 6379: tutti raggiungibili da chiunque. Il firewall garantisce che solo le porte che apri esplicitamente siano accessibili.

Debian 12 e Ubuntu 24.04 usano entrambi nftables come framework di packet filtering a livello kernel. UFW (Uncomplicated Firewall) si posiziona sopra come interfaccia user-friendly. Per la maggior parte dei casi d'uso VPS, UFW è la scelta giusta.

UFW vs nftables: quando usare quale

	UFW	nftables
Ideale per	Setup single-server, web app	Multi-server, routing avanzato
Curva di apprendimento	Minuti	Ore o giorni
Default su	Ubuntu (pre-installato)	Debian 12 (backend)
Sintassi regole	ufw allow 443/tcp	Tabelle, chain, espressioni di regole
Quando passare	N/A	Log per-packet, regole di rate limiting, NAT complesso

Un tipico setup firewall per web server con UFW:

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow ssh
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable

Verifica le regole:

sudo ufw status numbered

Ogni porta aperta è un potenziale punto di ingresso. Apri solo ciò che la tua applicazione necessita. Se rimuovi un servizio, rimuovi anche la sua regola firewall.

Per la configurazione dettagliata del firewall incluse le regole nftables, il rate limiting e il controllo accessi per porta, vedi .

Come blocca gli attacchi brute-force Fail2Ban?

Fail2Ban monitora i file di log (o journald su Debian 12) alla ricerca di tentativi ripetuti di autenticazione fallita e banna temporaneamente gli indirizzi IP offensivi tramite regole firewall. Trasforma un attacco brute-force da "prova 10.000 password" in "prova 3 password, vieni bloccato per 30 minuti, ricomincia da un IP diverso."

Come funziona

1. Fail2Ban monitora i log di autenticazione SSH
2. Dopo maxretry fallimenti entro findtime, crea una regola firewall che blocca quell'IP
3. Dopo che bantime scade, la regola viene rimossa
4. Gli attaccanti persistenti ciclano tra IP, ma il rate limit rende il credential stuffing impraticabile

Impostazioni consigliate per un VPS

I default sono troppo permissivi per un server esposto pubblicamente. Ecco una configurazione per produzione:

sudo tee /etc/fail2ban/jail.d/sshd.conf > /dev/null << 'EOF'
[sshd]
enabled = true
maxretry = 3
findtime = 600
bantime = 3600
bantime.increment = true
bantime.factor = 2
bantime.maxtime = 86400
EOF

Questa configurazione banna un IP per 1 ora dopo 3 fallimenti. Se lo stesso IP ritorna, il ban raddoppia ogni volta, fino a 24 ore. È più efficace di un bantime fisso perché gli scanner automatizzati alla fine depriorizzeranno il tuo server.

Riavvia Fail2Ban per applicare:

sudo systemctl restart fail2ban

Controlla i ban attivi:

sudo fail2ban-client status sshd

Guarda i ban in tempo reale:

sudo tail -f /var/log/fail2ban.log

Per la guida completa all'installazione di Fail2Ban con jail personalizzate per Nginx, Postfix e altri servizi, vedi .

Come riducono la tua attack surface i permessi utente?

Eseguire servizi come root da a un attaccante accesso completo al sistema se quel servizio viene compromesso. Il principio del minimo privilegio significa che ogni processo gira con i permessi minimi di cui ha bisogno. La compromissione di un web server non dovrebbe dare accesso al database, alle chiavi SSH o alla configurazione di sistema.

Pratiche chiave

Non eseguire mai servizi applicativi come root. Web server, database e runtime applicativi devono avere ciascuno il proprio utente di sistema:

sudo useradd --system --shell /usr/sbin/nologin --home-dir /opt/myapp myapp

Il flag --system crea un utente senza login home directory. Il flag --shell /usr/sbin/nologin impedisce il login interattivo. Questo utente può eseguire la tua applicazione ma non può fare SSH o eseguire comandi arbitrari.

Limita l'accesso sudo. Solo gli utenti nel gruppo sudo dovrebbero avere privilegi elevati. Controlla chi ha sudo:

getent group sudo

Imposta correttamente i permessi sui file. I file di configurazione con password o API key non devono essere leggibili da tutti:

# Limita un file di configurazione solo al proprietario
sudo chmod 600 /etc/myapp/config.env
sudo chown myapp:myapp /etc/myapp/config.env

# Verifica
ls -la /etc/myapp/config.env

Dovresti vedere i permessi -rw-------, che indicano che solo il proprietario può leggere e scrivere.

Usa file di environment per i segreti. Invece di hardcodare le credenziali nei file di configurazione, crea un file di environment dedicato con permessi ristretti:

sudo tee /etc/myapp/env > /dev/null << 'EOF'
DB_PASSWORD=your-generated-password
API_KEY=your-api-key
EOF

sudo chmod 600 /etc/myapp/env
sudo chown myapp:myapp /etc/myapp/env

Riferiscilo nelle unit systemd con EnvironmentFile=/etc/myapp/env. Genera le password con openssl rand -base64 32 invece di sceglierle manualmente.

Per la guida completa sulla gestione utenti Linux, configurazione sudo e modelli di permessi, vedi .

Perché dovresti automatizzare gli aggiornamenti di sicurezza?

Il software non patchato è uno dei vettori di attacco più sfruttati. Quando viene divulgata una vulnerabilità, gli attaccanti iniziano a scansionare i server non patchati entro poche ore. Gli aggiornamenti manuali significa che il tuo server è vulnerabile dalla divulgazione fino alla prossima volta che ricordi di eseguire apt upgrade. Gli aggiornamenti di sicurezza automatici chiudono quella finestra.

Configurare unattended-upgrades

Ubuntu 24.04 include unattended-upgrades nella sua installazione server di default, ma alcuni provider VPS distribuiscono immagini minimali senza. Anche Debian 12 richiede l'installazione. Su entrambe le distribuzioni, installalo se non è già presente:

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

Verifica che sia attivo:

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

Dovresti vedere:

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

Il valore "1" significa giornaliero. Le liste di pacchetti vengono aggiornate ogni giorno e le patch di sicurezza vengono installate automaticamente.

Cosa viene aggiornato

Per default, vengono installati solo gli aggiornamenti di sicurezza dal repository ufficiale. È l'impostazione giusta per un server in produzione. Gli aggiornamenti di feature e i cambiamenti di versione maggiore richiedono ancora intervento manuale, il che impedisce agli aggiornamenti non supervisionati di rompere la tua applicazione.

Monitoraggio degli aggiornamenti

Controlla cosa è stato installato automaticamente:

sudo cat /var/log/unattended-upgrades/unattended-upgrades.log

Configura le notifiche email per gli aggiornamenti applicati modificando /etc/apt/apt.conf.d/50unattended-upgrades:

Unattended-Upgrade::Mail "admin@example.com";
Unattended-Upgrade::MailReport "on-change";

Per la gestione automatica dei reboot quando gli aggiornamenti del kernel lo richiedono:

Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "04:00";

Abilita i reboot automatici solo se la tua applicazione gestisce i riavvii in modo corretto. Per la maggior parte dei setup, un controllo manuale settimanale è meglio dei reboot a sorpresa.

Per la guida completa di configurazione incluso monitoraggio e troubleshooting, vedi .

Quando aggiungere l'accesso VPN al tuo VPS?

Aggiungi l'accesso VPN quando esegui servizi che non dovrebbero mai essere esposti a internet pubblico: pannelli di amministrazione, database, dashboard di monitoraggio o API interne. Una VPN crea un tunnel criptato in modo che questi servizi siano raggiungibili solo dai dispositivi sulla tua rete privata. Invece di aprire la porta 3000 al mondo sperando che la tua autenticazione regga, la chiudi completamente da internet e ci accedi tramite VPN.

WireGuard vs Tailscale

	WireGuard	Tailscale
Tempo di setup	15-30 minuti per peer	2-5 minuti totali
Configurazione	Scambio manuale di chiavi, file di config	Login SSO, automatico
NAT traversal	Port forwarding manuale	Automatico
Controllo	Completo, gestisci tutto tu	Il server di coordinamento è di terze parti
Costo	Gratuito, self-hosted	Gratuito fino a 100 dispositivi
Ideale per	Infrastruttura fissa, controllo totale	Team, dispositivi dinamici, setup rapido

Scegli WireGuard quando vuoi il controllo completo sulla tua rete, hai un'infrastruttura statica e sei a tuo agio nella gestione di coppie di chiavi e file di configurazione.

Scegli Tailscale quando hai bisogno di un setup rapido su più dispositivi, lavori in team o vuoi il NAT traversal automatico senza port forwarding.

Entrambi usano il protocollo WireGuard. Tailscale è WireGuard con orchestrazione.

Cosa mettere dietro la VPN

• Porte database (PostgreSQL 5432, MySQL 3306, Redis 6379)
• Pannelli admin (phpMyAdmin, Adminer, Grafana)
• Endpoint di monitoraggio (Prometheus, Node Exporter)
• API interne non destinate al pubblico
• Accesso SSH (cintura e bretelle: key auth + VPN)

Un pattern comune: tieni aperte le porte 80 e 443 per la tua applicazione web pubblica. Tutto il resto passa attraverso la VPN. Le tue regole firewall diventano:

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw allow 51820/udp  # WireGuard
# SSH solo dalla subnet VPN
sudo ufw allow from 10.0.0.0/24 to any port 22

Per la configurazione step-by-step sia di WireGuard che di Tailscale sul tuo VPS, vedi .

Cambiare la porta SSH serve a qualcosa?

Molte guide raccomandano di cambiare SSH dalla porta 22 a una porta con numero alto. Questa è sicurezza per oscurità. Ferma i bot più pigri che provano solo la porta 22. Non ferma nessun attaccante che esegue una scansione di porte, che richiede pochi secondi.

Il costo reale: ora devi ricordarti -p 2222 su ogni comando SSH, configurarlo in ogni script di deploy e pipeline CI, e rischi di bloccarti fuori se te ne dimentichi. L'autenticazione SSH con chiave e Fail2Ban fornisce sicurezza reale. Cambiare la porta aggiunge complessità operativa per un guadagno minimo.

La stessa logica vale per disabilitare IPv6. Se il tuo server ha un indirizzo IPv6, disabilitarlo non riduce la attack surface. Rompe la compatibilità futura. Configura il tuo firewall sia per IPv4 che per IPv6.

I livelli di sicurezza in sintesi

Ogni livello di questa guida affronta una parte specifica della tua difesa. Ecco come si combinano:

Livello	Cosa Protegge	Priorità
Aggiornamenti sistema	Patcha le vulnerabilità note	Da fare subito
Permessi utente	Limita il raggio d'azione di una compromissione	Da fare subito
SSH hardening	Blocca l'accesso remoto non autorizzato	Da fare subito
Firewall	Controlla l'esposizione di rete	Da fare subito
Fail2Ban	Rallenta gli attacchi brute-force	Da fare subito
Aggiornamenti automatici	Mantiene le patch aggiornate nel tempo	Da configurare nella prima settimana
Accesso VPN	Nasconde i servizi interni	Quando si eseguono servizi non pubblici
Kernel hardening	Limita le tecniche di exploit	Avanzato, sistemi in produzione
Audit logging	Rileva la compromissione a posteriori	Avanzato, compliance

I primi cinque livelli sono irrinunciabili per qualsiasi server connesso a internet. I livelli successivi aggiungono profondità in base a ciò che esegui e ai tuoi requisiti di compliance.

Nessun singolo livello è sufficiente da solo. L'SSH hardening senza firewall lascia ancora i servizi esposti. Un firewall senza aggiornamenti automatici lascia aperte le vulnerabilità note. I livelli lavorano insieme. Ognuno cattura ciò che gli altri mancano.

Quando usare l'hosting gestito?

Se la gestione della sicurezza sottrae tempo alla costruzione del tuo prodotto, considera l'hosting gestito. Non è un fallimento. È una decisione di allocazione delle risorse.

Segnali che dovresti considerare l'hosting gestito:

• Gestisci un servizio in produzione ma non hai tempo di monitorare gli advisory di sicurezza
• Il tuo team non ha esperienza di amministrazione Linux
• Hai bisogno di certificazioni di compliance (SOC 2, ISO 27001) e non puoi gestire il processo di audit
• Sei stato compromesso in passato e non hai le competenze per investigare

Un server gestito da un provider come Virtua Cloud gestisce il patching del sistema operativo, la gestione del firewall, il rilevamento delle intrusioni e i backup. Tu ti concentri sulla tua applicazione. Il provider gestisce il livello di sicurezza dell'infrastruttura.

Per i team che vogliono la flessibilità del VPS con una copertura di sicurezza parziale, esiste una via di mezzo: provisioning di un VPS non gestito per sviluppo e staging, e hosting gestito per la produzione.

Qualcosa è andato storto?

Controlla l'accesso SSH

Se sei bloccato fuori dopo aver cambiato la configurazione SSH:

1. Usa la console web o la console seriale del tuo provider VPS per accedere al server
2. Controlla la sintassi della configurazione SSH: sudo sshd -t
3. Verifica che la tua chiave sia in ~/.ssh/authorized_keys per l'utente corretto
4. Controlla i log SSH: journalctl -u ssh -n 50 (Ubuntu) o journalctl -u sshd -n 50 (Debian)

Controlla il firewall

Se un servizio non è raggiungibile:

sudo ufw status numbered

Assicurati che la porta sia elencata come ALLOW. Se hai appena abilitato UFW e ti sei dimenticato di consentire SSH prima, usa la console web del provider.

Controlla Fail2Ban

Se un IP legittimo è stato bannato:

# Controlla se l'IP è bannato
sudo fail2ban-client status sshd

# Rimuovi il ban per un IP specifico
sudo fail2ban-client set sshd unbanip 1.2.3.4

Leggi i log

I log ti dicono cosa è successo:

# Autenticazione SSH
journalctl -u ssh -f     # Ubuntu 24.04
journalctl -u sshd -f    # Debian 12

# Attività Fail2Ban
sudo tail -f /var/log/fail2ban.log

# Blocchi firewall (se si usa il logging nftables)
journalctl -k | grep nft

# Messaggi di sistema
journalctl -p err -b

Allenati a leggere l'output dei log. Ogni volta che qualcosa si rompe, la risposta è quasi sempre nei log.

Prossimi step

Questa guida copre i livelli di sicurezza per un VPS Linux. Ogni sezione rimanda a un tutorial dettagliato e pratico:

Parti dai primi 5 step di sicurezza se non li hai ancora fatti. Poi segui i tutorial in ordine. Ognuno si basa sul precedente.

---

Copyright 2026 Virtua.Cloud. Tutti i diritti riservati. Questo contenuto e un'opera originale del team Virtua.Cloud. La riproduzione, ripubblicazione o redistribuzione senza autorizzazione scritta e vietata.