Regole del firewall Proxmox per una VM o un CT

La tua VM web risponde ancora, ma arrivi nel momento in cui una regola troppo ampia può aprire un servizio inutile o interrompere SSH.

Il firewall Proxmox è già attivo e la domanda diventa specifica: è necessario scrivere a livello della VM, del nodo o del sistema operativo guest?

Per una VM o un contenitore, parti dall’ospite e dai suoi flussi reali.

Leggi le opzioni di net0, costruisci le regole IN, decidi il destino di OUT, e poi raggruppa solo le regole che meritano un gruppo. I controlli Proxmox e il test applicativo rimangono separati dal firewall dell’host.

Le regole VM/CT Proxmox devono partire dai flussi reali dell’ospite, per poi essere raggruppate solo quando sono riutilizzabili.

Fissare l’obiettivo prima di scrivere la prima regola

Identifica il VMID, l’interfaccia virtuale, l’indirizzo dell’ospite e i servizi realmente esposti. Una VM Debian che serve HTTP e HTTPS non ha le stesse voci di un contenitore di amministrazione accessibile da un bastione.

anota il VMID reale e l’interfaccia net0;
elenca le porte in ingresso e le sorgenti autorizzate;
mantieni una console o un accesso amministrativo all’host;
verifica che il firewall Datacenter/Nodo sia già stato trattato.

Le zone non si sostituiscono l’una all’altra. Datacenter serve in particolare per i componenti riutilizzabili, Node riguarda l’host, e VM/CT filtra i flussi verso o da l’ospite.

Il firewall di Debian rimane uno strato separato. La documentazione ufficiale di Proxmox VE descrive questa separazione così come le direzioni IN, OUT e FORWARD.

Se il firewall del nodo non è ancora attivato o se temi di perdere l’interfaccia Web o SSH, fermati prima delle regole VM e consulta l’attivazione prudente del firewall Proxmox senza perdere l’accesso.

Il blocco dell’host rimane fuori ambito qui.

Leggi le opzioni della VM e della sua interfaccia

Prima di scrivere, rileggi la configurazione dal nodo Proxmox. Sostituisci <VMID> con l’identificativo numerico della tua VM:

qm config <VMID> --current

Controlla poi, nella configurazione della VM, enable, policy_in, policy_out, log_level_in, log_level_out e ipfilter.

Ogni interfaccia ha anche il suo indicatore firewall. L’opzione generale della VM non è sufficiente se il flag di net0 rimane disattivato.

[OPTIONS]
enable: 1
policy_in: DROP
policy_out: ACCEPT
log_level_in: nolog
log_level_out: nolog
ipfilter: 1

Questo blocco illustra un’impostazione restrittiva e un’uscita ancora permissiva. Non si tratta di un file da copiare tale e quale: adatta i valori alla tua VM, poi verifica la configurazione generata.

ipfilter serve soprattutto a limitare l’uso di indirizzi falsificati sull’interfaccia, non a creare un allowlist HTTP o SSH.

Consentire solo i flussi in ingresso realmente necessari

Inizia con gli ingressi. Per una VM web, SSH proviene generalmente da un bastione o da una rete di amministrazione.

Le porte 80 e 443 provengono dal reverse proxy o da una fonte pubblica prevista dall’architettura. Pertanto, una regola di autorizzazione deve indicare il protocollo, la porta, la sorgente e l’interfaccia quando questi elementi sono noti.

[RULES]
IN ACCEPT -p tcp -dport 22 -source +admins -i net0
IN ACCEPT -p tcp -dport 80 -source +reverse_proxy -i net0
IN ACCEPT -p tcp -dport 443 -source +reverse_proxy -i net0

In questo esempio, +admins e +reverse_proxy sono IPSet definiti separatamente.

L’indirizzo documentario 192.0.2.0/24 può illustrare una rete in un esempio o in una documentazione, ma non rappresenta la tua rete reale. Sostituiscilo con le tue sorgenti verificate, senza copiare un indirizzo trovato in un tutorial.

Posiziona le autorizzazioni specifiche prima di una politica DROP o REJECT. Un rifiuto globale aggiunto troppo presto maschera la regola utile.

Si trasforma in un semplice oblio in un’interruzione SSH. Fai una lettura della configurazione prima di indurire, poi mantieni una console host disponibile.

Decidere la politica OUT prima di renderla rigida

Un’uscita autorizzata consente il funzionamento di DNS, NTP, aggiornamenti, repository APT, supervisione o API esterne finché gli altri strati li filtrano.

Un’uscita restrittiva richiede un inventario preciso: il primo pacchetto DNS bloccato è sufficiente per far credere che la VM o il suo bridge sia fuori servizio.

Flusso della VM	Direzione	Esempio	Rischio sotto DROP
SSH di amministrazione	IN	`+admins` verso 22/tcp	Accesso rifiutato se la sorgente non è elencata.
HTTP/HTTPS	IN	`+reverse_proxy` verso 80/443	Il servizio web diventa inaccessibile.
Risoluzione DNS	OUT	UDP/TCP 53 verso il risolutore	APT e le chiamate tramite nome falliscono.
Tempo di sistema	OUT	UDP 123 verso la sorgente NTP	L’orologio deriva se nessun altro meccanismo subentra.
Repository e API	OUT	TCP 80/443 verso le destinazioni previste	Aggiornamenti e supervisione possono interrompersi.

Preferisco lasciare policy_out: ACCEPT durante l’inventario, per poi passare a DROP con le uscite documentate una per una.

Questa scelta protegge la disponibilità del servizio durante la costruzione. Non sostituisce una politica in uscita se il tuo ambiente impone realmente una lista bianca.

[OPTIONS]
policy_out: DROP

[RULES]
OUT ACCEPT -p udp -dport 53 -dest dns_interne
OUT ACCEPT -p tcp -dport 53 -dest dns_interne
OUT ACCEPT -p udp -dport 123 -dest ntp_interne
OUT ACCEPT -p tcp -dport 80 -dest repositori
OUT ACCEPT -p tcp -dport 443 -dest repositori

I nomi dns_interne, ntp_interne e repositori devono puntare verso i tuoi indirizzi o gruppi reali. La sintassi per le porte multiple e per gli alias deve essere riletta con la versione installata di Proxmox prima dell’applicazione.

Raggruppare le regole ripetibili con un Security Group

Un Security Group diventa utile quando più VM o contenitori condividono la stessa funzione.

Proxmox lo definisce a livello cluster, poi la configurazione di ogni ospite lo richiama nella sua sezione [RULES]. Il gruppo non si applica a nessuna VM finché non lo hai inserito nelle sue regole.

# /etc/pve/firewall/cluster.fw
[group webserver]
IN ACCEPT -p tcp -dport 80
IN ACCEPT -p tcp -dport 443

# /etc/pve/firewall/<VMID>.fw
[RULES]
GROUP webserver

Mantieni nel gruppo le regole realmente comuni. Un’eccezione specifica per una VM rimane in /etc/pve/firewall/<VMID>.fw. Questa separazione evita di modificare tutti gli ospiti per correggere una sola porta di amministrazione.

Nominare le sorgenti con IPSet e alias

Gli IPSet raggruppano indirizzi o reti; gli alias danno un nome leggibile a un indirizzo o a una rete.

Le regole possono usarli come sorgenti o come destinazioni. Riscrivi così +admins o dns_interne senza dover interpretare una serie di IP ad ogni passaggio.

# /etc/pve/firewall/cluster.fw
[ALIASES]
dns_interne 192.0.2.53

[IPSET admins]
192.0.2.10

[IPSET reverse_proxy]
192.0.2.20
192.0.2.21

Gli indirizzi 192.0.2.10, 192.0.2.20 e 192.0.2.21 sono dei segnaposto di documentazione. Un IPSet si fa riferimento con il prefisso +, ad esempio -source +admins.

Senzo questo prefisso, Proxmox legge il nome come un indirizzo o un alias e la regola non corrisponde all’intenzione.

Non confondere ipfilter-net0 con una allowlist applicativa.

Questo IPSet collegato all’interfaccia aiuta a prevenire la falsificazione dell’indirizzo sorgente. Non decide chi può aprire la porta 443 della tua applicazione.

Leggere l’ordine delle regole prima di indurire la policy

Una regola di gruppo o una regola locale ha effetto solo se letta nel posto giusto. Posiziona le corrispondenze precise prima del rifiuto generale e rileggi la configurazione dopo ogni modifica.

Ordine di lettura	Esempio	Rischio se posizionato troppo in basso
1. Sorgente e porta precise	SSH da `+admins` verso 22/tcp	Il bastione è bloccato dalla policy.
2. Gruppo riutilizzabile	`GROUP webserver`	Le porte web rimangono chiuse su questa VM.
3. Uscite documentate	DNS, NTP, repository	Il servizio parte e poi perde le sue dipendenze.
4. Policy predefinita	`DROP` o `REJECT`	Tutto il flusso dimenticato va qui.

La documentazione ufficiale descrive la sintassi IN/OUT, le opzioni --source, --dest, --dport e --iface, oltre all’inserimento di un Security Group.

Utilizza la forma corrispondente alla tua versione, poi controlla la configurazione compilata invece di assumere che il gruppo sia attivo.

Attivare un log mirato durante il test

La registrazione di Proxmox è disattivata per impostazione predefinita per il traffico filtrato. Le opzioni log_level_in e log_level_out attivano i log standard della VM/CT, visibili in Firewall → Log.

Il livello aggiunto al log serve a identificare il pacchetto: non aumenta automaticamente il numero di pacchetti registrati.

[OPTIONS]
log_level_in: info
log_level_out: nolog

[RULES]
IN ACCEPT -p tcp -dport 22 -source +admins -i net0 -log info

Attiva il livello solo durante il test del flusso che ti interessa, poi ripristina nolog se il volume diventa rumoroso.

Una registrazione globale permanente complica la lettura dei veri rifiuti e aumenta il rumore operativo.

Attenzione: un log vuoto non prova che un servizio funzioni. È ancora necessario verificare la regola, la risposta dell’applicazione e il percorso di rete dalla sorgente reale.

Compilare, testare e prevedere il ritorno indietro

Inizia leggendo lo stato del firewall sul nodo:

pve-firewall status
pve-firewall compile

pve-firewall status rilegge e compila le regole: un avviso di sintassi è un problema da correggere prima del test di rete.

pve-firewall compile permette di visualizzare la configurazione generata.

La documentazione ufficiale di pve-firewall descrive anche pve-firewall simulate, che può aiutare a simulare una sorgente, una destinazione, una porta e un protocollo, ma non prova né il routing del kernel né il funzionamento dell’applicazione.

Il controllo finale deve partire dalla sorgente autorizzata, poi da una sorgente che deve essere rifiutata se puoi utilizzarla senza rischi:

SSH dall’IP di amministrazione atteso con ssh -v;
HTTP o HTTPS dal reverse proxy con curl -I https://<IP_VM>;
DNS, NTP e APT dalla VM se policy_out è restrittiva;
lettura del registro Proxmox durante la finestra di test, poi ritorno a nolog.

Non presentare questi comandi come un test già eseguito: formano il tuo protocollo di convalida.

Un risultato atteso è una connessione autorizzata che risponde, un flusso vietato che fallisce e una traccia coerente con la regola esaminata.

Se una regola blocca la VM, ritira quella regola o disabilita temporaneamente il firewall di quella VM/CT.

Ripristina policy_out: ACCEPT se DNS, NTP o gli aggiornamenti si interrompono.

Non utilizzare pve-firewall stop come ritorno indietro normale: questo comando rimuove le regole Proxmox dall’host e può lasciare il server senza protezione.

Mantenere i limiti visibili

Una VM senza indirizzo IP, un bridge assente o un VLAN mal trasportato non si riparano con una regola firewall.

Se la regola sembra corretta ma l’ospite non ha IP, passa alla diagnostica di rete di una VM Proxmox, dal bridge all’ospite: ripristinare la rete della VM.

Per un problema lato host, la guida creare un bridge Proxmox senza perdere l’accesso al server tratta lo strato appropriato.

Il backend nftables proxmox-firewall rimane contrassegnato come tech preview nella documentazione PVE 9.2.11.

Gli esempi sopra rimangono focalizzati sul backend di default pve-firewall. Se il tuo ambiente utilizza IPv6, controlla anche NDP e gli indirizzi IPv6 invece di concludere solo da un test IPv4.