Hosting VPS sicuro? Cosa controlli davvero

L'hosting VPS è sicuro? La risposta breve

Sì. L'hosting VPS è sicuro per la maggior parte delle attività per cui viene acquistato e rappresenta un miglioramento concreto rispetto all'hosting condiviso. Un VPS KVM (server virtuale privato) è una macchina virtuale con un kernel, memoria, disco e account utente propri. L'hypervisor che la esegue mantiene gli altri clienti separati da 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. I piani basati su container offrono un isolamento meno forte, descritto più avanti.

La risposta completa ha due aspetti. Il provider è responsabile dell'hardware e dell'hypervisor. Tu sei responsabile di tutto ciò che si trova all'interno della tua macchina virtuale, ed è lì che ha origine quasi ogni incidente reale. I server vengono compromessi a causa di una porta aperta, di una password SSH debole, di un pacchetto che nessuno ha aggiornato o di un secret contenuto in un file pubblicato. Molto raramente vengono compromessi tramite 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 compito del provider e inizia il tuo

Il provider è responsabile dell'edificio, dell'hardware host, dell'hypervisor e del kernel dell'host, della rete fisica e del pannello di controllo che può avviare, arrestare, ricostruire ed eseguire snapshot del tuo server. Se uno di questi elementi fallisce, spetta a loro risolvere il problema.

Tu sei responsabile di tutto ciò che parte dal tuo sistema operativo in su. Ciò significa i pacchetti che installi, le porte che lasci aperte, gli account e le chiavi che possono accedere, gli aggiornamenti che applichi, i tuoi backup e il codice della tua applicazione. La maggior parte dei piani VPS non è gestita, il che significa che nessuno sta applicando patch al tuo server al posto tuo e nessun ticket di supporto lo farà. La distinzione tra gestito e non gestito merita di essere letta prima dell'acquisto, poiché determina quanto di quell'elenco ricade su di te.

Una parte della tua metà è facile da dimenticare: il pannello di controllo dell'hosting stesso. Chiunque possieda quelle credenziali di accesso può ricostruire il tuo server o collegare il tuo disco a un sistema di ripristino, senza mai conoscere una password dall'interno del server. Attiva l'autenticazione a due fattori (2FA) sull'account di hosting e non riutilizzare quella password da nessun'altra parte.

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 automatizzata dell'intero spazio IPv4 da parte di Internet è continua. Un nuovo indirizzo IPv4 riceve quindi la prima sonda non richiesta entro pochi minuti dalla sua messa online. Lo spazio IPv6 è troppo grande per essere scansionato indirizzo per indirizzo, ma un indirizzo IPv6 può comunque essere individuato tramite record DNS e altre fughe di informazioni. Non considerarlo quindi nascosto. Redis senza password, un nodo Elasticsearch non autenticato, una Docker API 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 chi sei. Associa un servizio a 127.0.0.1 quando deve essere accessibile solo dalla macchina locale e blocca tutto il resto nel firewall.

Docker che aggira il firewall. La pubblicazione della porta di un container scrive regole di network address translation (NAT) valutate prima delle regole di ufw (uncomplicated firewall). Di conseguenza, un container può essere raggiungibile da Internet anche quando ufw status indica che la porta è negata. Questo problema può verificarsi anche dopo aver 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 il log di SSH su qualsiasi server con un indirizzo IPv4 pubblico (/var/log/auth.log su Ubuntu, /var/log/secure su Rocky Linux e sugli altri sistemi della famiglia RHEL, oppure journalctl -u ssh e journalctl -u sshd quando non viene mantenuto alcun file di log) e troverai righe come Failed password for root from 203.0.113.10 port 54312 ssh2, 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. Consentire soltanto l'accesso tramite chiavi e disabilitare l'accesso di root trasforma questo traffico in rumore che puoi ignorare.

Un'unica chiave privata usata ovunque. Una chiave copiata su ogni laptop e ogni server fa sì che il furto di un solo laptop consenta di sbloccare tutto. Inoltre, le chiavi SSH non scadono. Una chiave consegnata a un collaboratore due anni fa funziona ancora oggi. Una chiave per ogni persona e ogni 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 framework dell'applicazione è un insieme pubblico di istruzioni. Gli scanner iniziano a verificarlo entro pochi giorni. Gli aggiornamenti di sicurezza sono la difesa più economica disponibile e possono essere eseguiti automaticamente: consulta gli aggiornamenti automatici di sicurezza su Ubuntu.

Un secret esposto. Le password dei database e le API key si trovano nei file .env. Questi file possono essere inviati a un repository pubblico oppure serviti da un web server configurato sulla directory sbagliata. Qualsiasi contenuto incollato nel contesto di un agente di coding basato su AI può finire anche in un log. È un argomento distinto: tenere i secret fuori dalla portata di un agente.

Tutto eseguito come root. Quando l'applicazione viene eseguita come root, un suo bug può prendere il controllo dell'intera macchina. All'interno del server non resta infatti alcun confine 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 kernel e un disco virtuale propri, 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 proprio. I piani basati su container, come OpenVZ e LXC, condividono il kernel dell'host e offrono un isolamento meno forte. Verificare quindi quale tipo di virtualizzazione si sta acquistando.

Un VPS è più sicuro dell'hosting condiviso?

Per quanto riguarda l'isolamento, sì. Nell'hosting condiviso molti siti vengono eseguiti all'interno di un unico sistema operativo e l'unica barriera è costituita dai permessi dei file. Di conseguenza, un errore in un altro account può talvolta esporre i file. In un VPS la barriera è una macchina virtuale. Il compromesso è che nell'hosting condiviso gli aggiornamenti vengono applicati dal provider, mentre un VPS non gestito deve essere aggiornato dal cliente. Un VPS è più sicuro solo se si applicano effettivamente gli aggiornamenti e si chiudono le porte non necessarie.

Il provider di hosting può leggere i miei dati?

In linea di principio sì, e nessun prodotto VPS cambia questo aspetto. L'immagine del disco è archiviata 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 disco del cliente collegato. Se alcuni dati devono rimanere illeggibili per l'host, occorre cifrarli 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 attendibilità.

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 IPv4 pubblico. Per questo, un database in ascolto su 0.0.0.0 senza password, oppure un pannello di amministrazione che usa ancora le credenziali predefinite, viene individuato in pochi minuti anziché in mesi. Il log SSH di qualsiasi server con un indirizzo IPv4 pubblico (/var/log/auth.log su Ubuntu, /var/log/secure su Rocky Linux) mostra la parte relativa a SSH: righe Failed password for root ripetute provenienti da indirizzi di tutto il mondo. Gli attacchi di evasione dall'hypervisor esistono, ma sono attività di ricerca avanzata rivolte a obiettivi di alto valore, non la causa delle compromissioni comuni.