Il VPS hosting è sicuro? Rischi e responsabilità

Il VPS hosting è sicuro? La risposta breve

Sì. Il VPS hosting è sicuro per le attività per cui la maggior parte delle persone lo acquista e rappresenta un miglioramento concreto rispetto all’hosting condiviso. Un VPS (virtual private server) è una macchina virtuale con un kernel, memoria, disco e account utente propri; l’hypervisor che la esegue impedisce agli altri clienti di accedere a tutte queste risorse. La persona che noleggia il server accanto al tuo sulla stessa macchina fisica non può leggere i tuoi file, elencare i tuoi processi, accedere al tuo server o vedere il tuo traffico di rete.

La risposta completa ha due aspetti. Il provider possiede l’hardware e l’hypervisor. Tu sei responsabile di tutto ciò che si trova all’interno della tua macchina virtuale, ed è qui che iniziano quasi tutti gli incidenti reali. I server vengono violati a causa di una porta aperta, di una password SSH debole, di un pacchetto che nessuno ha aggiornato oppure di un secret presente in un file che è stato pubblicato. Solo in casi molto rari vengono violati attraverso l’hypervisor.

Che cosa separa realmente l'hypervisor

Un hypervisor è il software che esegue le macchine virtuali su un singolo host fisico. Su un VPS KVM (KVM significa kernel based virtual machine ed è lo standard sugli host Linux), il tuo server è una macchina virtuale completa. Avvia il proprio kernel. L'host gli assegna una regione fissa della memoria fisica e l'unità di gestione della memoria del processore rifiuta qualsiasi accesso al di fuori di quella regione. Di conseguenza, il codice in esecuzione in un altro guest non può indirizzare in alcun modo la tua RAM. Non esistono un filesystem condiviso né una tabella degli utenti condivisa, quindi i permessi sui file del server di un vicino non hanno alcun effetto sul tuo.

L'hosting condiviso funziona in modo diverso. Molti siti risiedono nello stesso sistema operativo, sotto lo stesso web server e la stessa installazione di PHP, come normali account utente. L'unico confine è costituito dai permessi sui file. Un errore nei permessi o un plugin vulnerabile eseguito da un utente che può leggere troppi dati può quindi raggiungere i file di un altro account. È questo il limite che il passaggio dall'hosting condiviso a un VPS elimina.

Verifica che cosa stai acquistando, perché non tutti i piani venduti come VPS sono macchine virtuali. I piani basati su container (OpenVZ, LXC, Virtuozzo) condividono il kernel dell'host e separano i clienti tramite namespace e cgroup invece di usare la virtualizzazione hardware. È un confine più debole, perché un bug nel kernel dell'host è anche un bug nel kernel del tuo server. Inoltre, su questi piani non puoi caricare moduli del kernel, escludendo così alcuni software. KVM è l'opzione predefinita più sicura. Chiedi quale tecnologia stai acquistando prima di pagare.

Cosa può causare un vicino rumoroso

Condividere un host fisico riduce le prestazioni, e questo è l'unico costo. Le macchine guest dello stesso sistema condividono la CPU fisica e i dischi. Quando la CPU è occupata da un altro cliente, la CPU virtuale attende e Linux registra questa attesa come steal time: il campo %st in top e vmstat. Uno steal time superiore a qualche punto percentuale per diverse ore indica che l'host è sovrallocato. Non significa che qualcuno stia leggendo i tuoi dati. La soluzione è scegliere un piano diverso o un altro provider. Prima di decidere, puoi misurare la CPU e il disco che hai effettivamente ottenuto.

Esiste un effetto tra clienti che è utile conoscere, ma non è una vulnerabilità di sicurezza. Se invii email dal tuo VPS, il tuo indirizzo IP appartiene a un intervallo utilizzato anche da altri clienti. Un vicino che invia spam può far inserire parte di quell'intervallo in una blocklist, quindi i tuoi messaggi finiscono nelle cartelle spam per un motivo che non hai causato tu. I provider che contrastano gli abusi mantengono intervalli con una reputazione migliore. Chiedi informazioni in merito se l'email è importante per te.

Cosa non può fare un vicino ostile e il raro caso in cui può farlo

Un cliente sullo stesso host non ha accesso ai tuoi file. Non può vedere i tuoi processi, montare il tuo disco o aprire una shell sul tuo server, perché nessuno di questi elementi esiste all'interno della sua macchina virtuale. È opportuno indicare un'eccezione: considera ogni rete privata del provider come una rete condivisa con persone che non conosci e cifra i dati che la attraversano, invece di presumere che siano invisibili.

Gli attacchi di tipo hypervisor escape sono reali. Un bug nel livello di virtualizzazione può consentire al codice in esecuzione in un guest di raggiungere l'host e, dall'host, tutti i guest che ospita. Questi bug vengono individuati, pubblicati con un identificativo CVE (common vulnerabilities and exposures) e corretti. I provider di hosting li correggono rapidamente, perché l'intera attività dipende da quel livello. Sfruttarne uno richiede un exploit funzionante per una versione specifica dell'hypervisor. È una risorsa costosa da impiegare contro un piccolo account di hosting.

Anche i side channel tra guest sono reali. Appartengono alla famiglia Spectre e Meltdown e sfruttano le cache condivise del processore per dedurre piccole quantità di dati oltre il confine di isolamento. Gli aggiornamenti del microcode e del kernel ne riducono l'impatto, mentre i tassi di fuga indicati negli studi pubblicati sono molto bassi. I casi pubblicati sono dimostrazioni di ricerca, non attacchi su larga scala. Il rischio non è nullo. Semplicemente, è molto meno prioritario rispetto agli altri problemi che possono causarti danni.

Dove finisce il lavoro del provider e dove inizia il tuo

Il provider è responsabile dell'infrastruttura, dell'hardware del server host, dell'hypervisor e del kernel dell'host, della rete fisica e del pannello di controllo che consente di avviare, arrestare, ricreare e creare snapshot del server. Se uno di questi componenti non funziona, spetta al provider risolvere il problema.

Tu sei responsabile di tutto ciò che parte dal sistema operativo e si trova ai livelli superiori. Questo include i pacchetti che installi, le porte che lasci aperte, gli account e le chiavi che possono autenticarsi, gli aggiornamenti che applichi, i tuoi backup e il codice delle tue applicazioni. La maggior parte dei piani VPS non è gestita, quindi nessuno applica le patch al server al posto tuo e nessun ticket di supporto lo farà automaticamente. La distinzione tra servizi gestiti e non gestiti merita una lettura prima dell'acquisto, perché determina quanta parte di queste attività ricade su di te.

C'è un elemento della tua parte che è facile dimenticare: il pannello di controllo dell'hosting. Chiunque disponga delle credenziali di accesso può ricreare il server o collegare il disco a un sistema di ripristino, senza conoscere alcuna password presente nel server. Attiva l'autenticazione a due fattori (2FA) sull'account di hosting e non riutilizzare quella password in altri servizi.

Il provider di hosting può vedere i tuoi dati?

Sì, in linea di principio. Questo è il limite effettivo e trasparente di un VPS. L'immagine del disco si trova nello storage del provider. La console del provider consente l'accesso a livello di schermo alla macchina virtuale. La modalità di ripristino può avviare un sistema diverso con il disco collegato. Un VPS protegge dagli altri clienti, ma il provider non rientra in questa garanzia.

Se gestisci dati che devono restare illeggibili per l'host, cifrali nell'applicazione prima di scriverli. La cifratura completa del disco all'interno del guest protegge da un'immagine copiata quando il sistema non è in esecuzione, ma la chiave deve essere presente in memoria mentre il server è attivo. Pertanto non esclude il provider dal modello di fiducia. Lo stesso livello di fiducia vale per un server dedicato che noleggi esclusivamente per te, con un livello condiviso in meno.

Cosa compromette realmente un VPS

Un servizio in ascolto su tutte le interfacce. Database, cache, code di messaggi e pannelli di amministrazione spesso si associano per impostazione predefinita a 0.0.0.0, cioè a tutte le interfacce di rete, inclusa quella pubblica. La scansione di Internet è continua e automatizzata, quindi un nuovo indirizzo IP riceve la prima richiesta non sollecitata entro pochi minuti dalla connessione. Redis senza password, un nodo Elasticsearch senza autenticazione, un'API Docker esposta sulla porta 2375 e un pannello di amministrazione che usa ancora le credenziali predefinite vengono individuati in questo modo, da scanner che non sanno nulla dell'identità del proprietario. Associa un servizio a 127.0.0.1 quando deve essere accessibile solo dalla macchina locale e blocca tutto il resto con il firewall.

Docker che aggira il firewall. La pubblicazione della porta di un container crea regole di network address translation (NAT) valutate prima delle regole di ufw (uncomplicated firewall), quindi un container può essere raggiungibile da Internet anche se ufw status indica che la porta è negata. Questo problema colpisce anche chi ha configurato correttamente tutto il resto. Il motivo per cui una porta Docker ignora ufw merita una lettura prima di pubblicare una porta del container.

SSH con le password abilitate. Leggi /var/log/auth.log su qualsiasi server pubblico e troverai righe come Failed password for root from 203.0.113.10 port 54312 ssh2, a migliaia, giorno e notte. I bot provano nomi utente e password comuni. L'accesso con password, insieme a un account root che accetta connessioni, è tutto ciò che serve a un attaccante. Usare solo chiavi e disabilitare l'accesso di root trasforma quel traffico in rumore che puoi ignorare.

Un'unica chiave privata usata ovunque. Copiare una singola chiave su ogni laptop e ogni server significa che il furto di un laptop consente di sbloccare tutto. Inoltre, le chiavi SSH non scadono, quindi una chiave consegnata a un collaboratore due anni fa funziona ancora oggi. Una chiave per persona e per macchina non costa nulla e limita ciò che una singola chiave rubata può raggiungere.

Pacchetti mai aggiornati. Un CVE pubblicato per il tuo web server o per il tuo framework applicativo è un insieme pubblico di istruzioni, e gli scanner iniziano a verificare la presenza della vulnerabilità entro pochi giorni. Gli aggiornamenti di sicurezza sono la difesa meno costosa disponibile e possono essere eseguiti automaticamente: consulta gli aggiornamenti automatici di sicurezza su Ubuntu.

Un secret esposto. Le password dei database e le chiavi API si trovano nei file .env, che possono essere inviati a un repository pubblico oppure pubblicati da un web server configurato sulla directory sbagliata. Anche qualsiasi contenuto incollato nel contesto di un agente di coding basato sull'AI può finire in un log. È un argomento separato: tenere i secret fuori dalla portata di un agente.

Tutto eseguito come root. Quando l'applicazione viene eseguita come root, un suo bug prende il controllo dell'intera macchina, perché nel server non rimane alcun confine interno che ne impedisca la propagazione.

La tua parte del lavoro

Nessuna delle attività seguenti riguarda il lavoro dell’hypervisor. Sono tutte di tua competenza e determinano la sicurezza del tuo VPS.

• Configura correttamente la prima ora: i primi dieci minuti su un nuovo VPS descrivono la creazione di un utente non root e la configurazione di un firewall.
• Proteggi l’accesso remoto: hardening di SSH su un VPS.
• Chiudi le porte che non utilizzi: nozioni di base sul firewall ufw.
• Concedi a ogni servizio soltanto gli accessi necessari: utenti con privilegi minimi su un VPS.
• Rallenta i tentativi di accesso tramite brute force: fail2ban su Ubuntu 24.04.
• Mantieni un backup che hai ripristinato almeno una volta: backup restic per un VPS.

La parte del provider è già completata quando il server viene avviato. La tua parte richiede circa un’ora il primo giorno e pochi minuti al mese in seguito. Se stai ancora confrontando le opzioni, che cos’è realmente un VPS descrive le basi su cui si fonda tutto questo.

FAQ

Un altro cliente sullo stesso server fisico può leggere i miei file?

No, non su un VPS KVM. Il server è una macchina virtuale con un proprio kernel e un proprio disco virtuale, oltre a una regione di memoria fisica assegnata dall'host; il processore blocca qualsiasi accesso al di fuori di quella regione. Non esiste un filesystem condiviso tra i guest, quindi i permessi dei file sul server di un altro cliente non hanno alcun effetto sul tuo. I piani basati su container, come OpenVZ e LXC, condividono il kernel dell'host e offrono un isolamento meno forte. Verifica quindi quale tipo di virtualizzazione stai acquistando.

Un VPS è più sicuro dell'hosting condiviso?

Per quanto riguarda l'isolamento, sì. Nell'hosting condiviso molti siti vengono eseguiti all'interno dello stesso sistema operativo e l'unico confine è costituito dai permessi dei file. Un errore in un altro account può quindi esporre alcuni file. Su un VPS il confine è una macchina virtuale. Il compromesso è che nell'hosting condiviso gli aggiornamenti vengono applicati dal provider, mentre su un VPS non gestito devi applicarli tu. Un VPS è più sicuro solo se installi effettivamente gli aggiornamenti e chiudi le porte non necessarie.

Il provider di hosting può leggere i miei dati?

In linea di principio sì, e nessun prodotto VPS modifica questo aspetto. L'immagine del disco è memorizzata sull'hardware del provider, la console consente di accedere a livello di schermo alla macchina in esecuzione e la modalità di ripristino può avviare un sistema diverso con il tuo disco collegato. Se alcuni dati devono restare illeggibili al provider, cifrali nell'applicazione prima di scriverli. La cifratura del disco all'interno del guest mantiene comunque la chiave in memoria mentre il server è in esecuzione, quindi non esclude il provider dal modello di fiducia.

Qual è il modo più comune con cui un VPS viene compromesso?

Un servizio esposto o un accesso SSH debole, con grande distacco rispetto alle altre cause. Gli scanner automatizzati analizzano continuamente ogni indirizzo IP pubblico. Di conseguenza, un database in ascolto su 0.0.0.0 senza password o un pannello di amministrazione lasciato con le credenziali predefinite viene individuato in pochi minuti, non in pochi mesi. /var/log/auth.log su qualsiasi server pubblico mostra la componente SSH del problema: righe Failed password for root ripetute provenienti da indirizzi di tutto il mondo. Le evasioni dell'hypervisor esistono, ma richiedono attività di ricerca avanzata e prendono di mira obiettivi di alto valore. Non sono la causa delle violazioni ordinarie.