Come configurare in sicurezza le regole del firewall di un VPS
Pubblicato il 4 settembre 2026
Un firewall dovrebbe consentire il traffico di cui il server ha bisogno e rifiutare silenziosamente il resto. Per configurare in sicurezza le regole del firewall di un VPS, inizia dai servizi che devono restare raggiungibili, soprattutto SSH, quindi aggiungi le porte web e dell'applicazione una alla volta. Non iniziare bloccando tutto dall'unica sessione terminale che hai aperta. È così che una tranquilla attività di manutenzione diventa un'attività di ripristino tramite console.
Per la maggior parte delle distribuzioni VPS Linux, l'obiettivo pratico è semplice: negare per impostazione predefinita il traffico in ingresso non richiesto, consentire il traffico in uscita necessario e creare regole in ingresso ristrette per utenti e servizi attendibili. Questo riduce la superficie di attacco senza rendere difficile l'amministrazione ordinaria.
Inizia dalla mappa del traffico
Prima di modificare qualsiasi regola, annota cosa fa realmente il VPS. Un sito WordPress pubblico, ad esempio, di solito ha bisogno di SSH per l'amministrazione e delle porte 80 e 443 per il traffico web. Un'API privata può avere bisogno solo di HTTPS, mentre un server di database dovrebbe di solito accettare connessioni solo da un server applicativo su una rete privata.
Controlla prima i servizi in ascolto. Nella maggior parte delle distribuzioni Linux, questo comando fornisce una vista utile:
```bash sudo ss -tulpn ```
Non aprire automaticamente ogni porta mostrata. Alcuni servizi ascoltano solo su localhost o su un'interfaccia privata e non necessitano di accesso pubblico tramite firewall. Altri potrebbero essere vecchi servizi di test, agenti di monitoraggio o software che non dovrebbero essere raggiungibili da Internet in alcun modo.
Per ogni porta esposta pubblicamente, rispondi a tre domande: chi ne ha bisogno, da dove e tramite quale protocollo? Una regola che consente HTTPS da ovunque è normale per un sito web pubblico. Una regola che consente una porta di database da ovunque è normalmente un problema che aspetta pazientemente nei log.
Mantieni un percorso di ripristino prima di configurare le regole del firewall del VPS
Mantieni due sessioni SSH attive mentre apporti modifiche al firewall. Usa una sessione per applicare le regole e lascia la seconda intatta. Dopo aver applicato una modifica, testa una nuova connessione da un altro terminale prima di chiudere qualsiasi cosa. Questo intercetta gli errori nel percorso di connessione reale invece di affidarsi all'ottimismo.
Conferma inoltre che la console del tuo provider VPS sia disponibile. Una console basata su browser o un ambiente di ripristino è il ripiego se SSH viene bloccato. Non sostituisce un lavoro attento, ma è una buona assicurazione operativa.
Se SSH è in esecuzione su una porta non standard, verificalo prima di creare le regole:
```bash sudo ss -tulpn | grep ssh ```
Una porta SSH non standard può ridurre il rumore di fondo delle scansioni automatizzate, ma da sola non rappresenta una sicurezza significativa. Autenticazione forte, accesso di origine limitato e applicazione tempestiva delle patch fanno il vero lavoro.
Usa un criterio predefinito di negazione del traffico in ingresso con UFW
UFW è un'interfaccia firewall pratica per i server VPS Ubuntu e basati su Debian. È facile da leggere in seguito, il che conta quando un altro amministratore deve risolvere un'interruzione alle 2 del mattino.
Per prima cosa, imposta valori predefiniti sensati:
```bash sudo ufw default deny incoming sudo ufw default allow outgoing ```
Quindi, consenti SSH prima di abilitare il firewall. Se il tuo server usa la porta SSH predefinita, usa:
```bash sudo ufw allow OpenSSH ```
Se SSH ascolta su una porta personalizzata, specificala esplicitamente. Questo esempio usa la porta 2222:
```bash sudo ufw allow 2222/tcp ```
Per un normale sito web pubblico, consenti HTTP e HTTPS:
```bash sudo ufw allow 80/tcp sudo ufw allow 443/tcp ```
Quindi abilita il firewall e controlla il criterio risultante:
```bash sudo ufw enable sudo ufw status numbered ```
Lo stato numerato è utile perché in seguito le regole possono essere rimosse con precisione. Evita di lasciare regole temporanee troppo ampie dopo la risoluzione dei problemi. Le regole temporanee hanno la curiosa abitudine di diventare arredo permanente.
Se il VPS ospita un'applicazione web dietro un proxy inverso, la porta dell'applicazione potrebbe non dover essere pubblica. Ad esempio, Nginx può accettare traffico sulle porte 80 e 443 mentre l'applicazione ascolta su `127.0.0.1:3000`. In questo schema, non è necessaria alcuna regola firewall per la porta 3000.
Limita l'accesso amministrativo in base all'IP di origine
SSH non dovrebbe essere aperto a ogni indirizzo a meno che il tuo team non abbia davvero bisogno di tale flessibilità. Se il tuo ufficio, la VPN o il jump host hanno un indirizzo IP pubblico stabile, limita SSH a quello:
```bash sudo ufw allow from 203.0.113.25 to any port 22 proto tcp ```
Per un team distribuito con IP domestici variabili, una VPN o un host bastion sono spesso una soluzione migliore rispetto all'aprire SSH globalmente. Aggiunge un po' di lavoro di configurazione, ma ti offre un unico percorso di amministrazione controllato e una traccia di audit più pulita.
La limitazione della frequenza può anche ridurre i tentativi basilari di indovinare le password SSH:
```bash sudo ufw limit 22/tcp ```
Questo non sostituisce le chiavi SSH, l'autenticazione con password disabilitata ove appropriato o l'accesso multifattore tramite il tuo percorso di gestione. Consideralo come un pannello della recinzione, non l'intera recinzione.
Tratta database, pannelli e monitoraggio separatamente
Le porte dei database come MySQL sulla 3306, PostgreSQL sulla 5432, Redis sulla 6379 e MongoDB sulla 27017 non dovrebbero quasi mai essere disponibili pubblicamente. Consentile solo dall'indirizzo IP privato o dalla subnet del server applicativo.
Ad esempio, per consentire connessioni MySQL solo da un VPS applicativo su `10.10.0.12`:
```bash sudo ufw allow from 10.10.0.12 to any port 3306 proto tcp ```
Anche il servizio di database stesso dovrebbe effettuare il bind all'interfaccia privata prevista, ove possibile. Le regole del firewall e il binding del servizio sono livelli separati. Usare entrambi significa che una modifica errata del firewall ha meno probabilità di esporre il servizio.
I pannelli di hosting, le dashboard di Grafana e gli endpoint di monitoraggio meritano la stessa attenzione. Se sono solo per il personale, limitali a una VPN, a un intervallo di IP dell'ufficio o a una rete di gestione dedicata. Le pagine di monitoraggio pubbliche possono esporre più dettagli sull'infrastruttura del previsto, anche quando non mostrano segreti.
Considera il firewall del provider e IPv6
Il tuo VPS potrebbe avere più di un livello di firewall. Un firewall cloud o a livello di provider filtra il traffico prima che raggiunga il server, mentre UFW, firewalld, nftables o iptables filtrano il traffico sul VPS stesso. Usare entrambi è sensato, ma le regole devono essere coerenti.
Se la porta 443 è aperta sul VPS ma bloccata a livello di provider, i visitatori continueranno a non riuscire a connettersi. Se il provider consente una porta ma il VPS la nega, il VPS resta protetto. Durante la risoluzione dei problemi, controlla entrambi i livelli in ordine: criterio del provider, firewall del VPS, indirizzo di ascolto del servizio e configurazione dell'applicazione. Di solito i log raccontano la stessa storia una volta controllati questi elementi.
Non dimenticare IPv6. Se il tuo VPS ha un indirizzo IPv6 pubblico, sono necessarie regole IPv6 equivalenti. UFW può gestire IPv6 quando è abilitato nella sua configurazione, ma verifica con:
```bash sudo ufw status verbose ```
Un indirizzo IPv4 correttamente protetto non aiuta se lo stesso servizio è completamente esposto tramite IPv6.
Testa dall'esterno, poi monitora il risultato
Dopo ogni modifica significativa, testa da una rete esterna al VPS. Conferma che i servizi previsti funzionino, quindi conferma che le porte destinate a restare private non siano raggiungibili. I test nel browser sono utili per i siti web, ma i test da riga di comando forniscono risposte più chiare per porte specifiche:
```bash nc -vz your-server-ip 443 ```
Per le porte bloccate, un timeout o un rifiuto possono significare cose diverse a seconda della regola e dello stato del servizio. Rivedi lo stato del firewall, lo stato del servizio e i log di sistema invece di modificare più impostazioni contemporaneamente.
Abilita il logging con attenzione quando diagnostichi un problema:
```bash sudo ufw logging low ```
Un livello di logging basso di solito è sufficiente per individuare traffico negato inatteso senza produrre attività su disco non necessaria. Sui server molto attivi, log firewall ad alto volume possono diventare a loro volta un piccolo fastidio operativo.
Rivedi le regole del firewall ogni volta che distribuisci un nuovo servizio, ritiri una vecchia applicazione, cambi gli indirizzi IP dell'ufficio o modifichi l'architettura di rete. Le regole migliori non sono l'insieme di regole più lungo. Sono l'insieme più piccolo che descrive accuratamente come il server dovrebbe comunicare.
Se preferisci non gestire questo lavoro da solo, un team VPS gestito può rivedere i requisiti di accesso, applicare le modifiche con un piano di ripristino e monitorare il server successivamente. Su kodu.cloud, questo si integra naturalmente con le operazioni gestite e il monitoraggio continuo, soprattutto per i team che devono concentrarsi sui clienti e sul prodotto invece che sul filtraggio dei pacchetti.
Un firewall sta facendo il suo lavoro quando nessuno se ne accorge. Mantieni il criterio ristretto, documenta perché esiste ogni eccezione e testa l'accesso prima di dichiarare che il servizio è di nuovo tranquillo.
Andres Saar, ingegnere Customer Care