Hardening di una VPS Linux: le verifiche che faccio dopo ogni aggiornamento 🔐🖥️

Quando arriva una notifica di aggiornamento critico, la tentazione è semplice: installare la patch, vedere che il sito risponde e considerare chiuso il problema. 🔧 In realtà, per chi ospita più applicazioni sulla stessa VPS, l’aggiornamento è solo il primo passo. La domanda successiva è: se un sito venisse compromesso, quanto lontano potrebbe arrivare l’attaccante?

È una domanda che mi pongo quando lavoro con Linux, PHP, MariaDB e WordPress. Non serve trasformare ogni server in una fortezza ingestibile: serve conoscere i punti di accesso, limitare i privilegi e sapere come ripristinare il servizio.

1. Aggiornare sì, ma sapendo cosa è cambiato 🧩

Prima verifico quali componenti sono coinvolti: sistema operativo, web server, interprete PHP, database e pannello di gestione. Un aggiornamento di PHP, per esempio, può correggere una vulnerabilità ma anche modificare il comportamento di un’estensione utilizzata da un’applicazione.

Su Ubuntu, per avere una prima fotografia dei pacchetti aggiornabili, utilizzo:

sudo apt update
apt list --upgradable

Dopo gli aggiornamenti controllo i servizi interessati, gli errori nei log e il funzionamento delle applicazioni principali. Se il kernel o alcune librerie di sistema lo richiedono, pianifico un riavvio controllato. Un sito che mostra la homepage non è necessariamente un sito che funziona: bisogna provare anche autenticazione, form, operazioni sul database e processi pianificati.

2. I permessi dei file contano più di quanto sembri 🔒

Una configurazione pericolosa è lasciare scrivibili da chiunque file e directory dell’applicazione. Non è però corretto applicare indiscriminatamente chmod 777 o, all’opposto, bloccare ogni scrittura senza capire quali processi ne abbiano bisogno.

Il controllo parte da proprietario, gruppo e permessi effettivi:

stat -c '%A %U:%G %a %n' /percorso/del/file
namei -l /percorso/del/file

Un file di configurazione contenente credenziali dovrebbe essere leggibile soltanto dai processi e dagli utenti che ne hanno realmente bisogno. Il valore numerico giusto dipende dall’utente con cui gira PHP e dal modello di isolamento dell’hosting: non esiste un permesso universale valido per tutti i server.

3. Separare le applicazioni e ridurre i privilegi

Ospitare più progetti sulla stessa VPS è comodo, ma crea un rischio: se tutte le applicazioni girano con lo stesso utente e possono leggere gli stessi file, la compromissione di una può esporre le altre. ⚠️

Per questo verifico almeno tre livelli: l’utente del processo web, i permessi sulle directory e le credenziali dei database. Ogni applicazione dovrebbe utilizzare un utente database dedicato, autorizzato solo sul proprio schema e senza privilegi amministrativi globali.

Quando l’isolamento tra siti è un requisito forte, la scelta può richiedere account di sistema separati, pool PHP distinti o ambienti containerizzati. Sono soluzioni diverse, da valutare in base al carico operativo e alla superficie d’attacco.

4. SSH, firewall e servizi esposti 🌐

Il server dovrebbe esporre soltanto le porte necessarie. Controllo i servizi in ascolto con:

sudo ss -tulpn

Poi confronto l’elenco con le regole del firewall locale e quelle del provider. Un database che deve essere utilizzato soltanto dalle applicazioni locali, per esempio, non dovrebbe ascoltare liberamente su Internet.

Per SSH preferisco autenticazione tramite chiavi, account amministrativi nominativi e accesso privilegiato tramite sudo. Prima di disabilitare l’accesso con password, però, verifico sempre da una seconda sessione che la chiave funzioni: bloccare l’unico accesso al server non è hardening, è un incidente operativo.

Su questo argomento ho già pubblicato un approfondimento: come proteggere l’accesso SSH a un server Linux.

5. Backup, log e capacità di ripristino 💾

Una patch non sostituisce un backup. Mantengo copie dei file e dei database, possibilmente fuori dalla VPS, con retention e verifiche periodiche. Un backup non testato è una promessa, non una garanzia.

Il secondo pilastro è la visibilità: errori PHP, access log, tentativi di autenticazione e stato dei servizi permettono di capire se qualcosa è cambiato dopo un intervento. È utile approfondire sia la strategia di backup 3-2-1 sia il monitoraggio di una VPS.

6. Una checklist semplice, ma ripetibile ✅

• Verificare gli aggiornamenti di sistema e applicazioni.
• Controllare servizi attivi e porte esposte.
• Esaminare permessi, proprietari e file contenenti segreti.
• Limitare gli utenti e i privilegi dei database.
• Controllare accessi SSH e regole firewall.
• Testare backup e procedure di ripristino.
• Monitorare errori e funzionalità applicative dopo ogni modifica.

La sicurezza non è il risultato di un singolo comando. È una serie di decisioni coerenti, documentate e ripetibili. E, soprattutto, è la capacità di accorgersi quando qualcosa non funziona prima che diventi un problema serio. 🙂

Per un riferimento operativo sempre utile, la documentazione ufficiale di Ubuntu Security descrive il ciclo di aggiornamento e manutenzione della piattaforma.