Il Proxmox Hardening inizia con un quadro operativo preciso: quali accessi di management esistono, quali reti sono critiche, quali dipendenze dei percorsi di storage sono presenti? Questo capitolo fornisce una guida ampliata e pratica per amministratori, ingegneri di sistema, operatori e fornitori di servizi IT con controlli concreti, passaggi di implementazione, insidie tipiche e strategie di rollback testate.
Proxmox Hardening: precisare il modello di minaccia: chi, come e cosa proteggere
Un modello di minaccia realistico è la base di ogni hardening. Ponetevi almeno le seguenti domande: chi necessita accesso GUI/API? Quali account di automazione usano API‑Token? I host di management sono raggiungibili tramite VPN o direttamente? Documentate anche vettori d’attacco come token API rubati, jump‑host compromessi o lateral movement da una rete VM.
Termini brevemente spiegati: API (Application Programming Interface) è l’interfaccia programmabile; Corosync è il protocollo di comunicazione del cluster di Proxmox; Ceph è un backend di storage distribuito. Se conoscete questi concetti, capirete perché una GUI chiusa serve a poco se le porte del cluster rimangono aperte.
Segmentazione, Break‑Glass e gestione delle modifiche
Separare chiaramente le reti di management, storage e VM
Separate Management (GUI/API/SSH), Storage (NFS/iSCSI/Ceph) e traffico VM in VLAN/subnet dedicate. Questo evita che VM compromesse raggiungano direttamente il cluster o lo storage. Errori ricorrenti sono bridge condivisi o tag VLAN mancanti sulle bridge degli hypervisor, che rendono visibili le IP di management.
Break‑Glass e percorsi di rollback testati
Definite almeno due percorsi di rollback: console locale/IPMI e un jump‑host testato con Always‑Allow‑IP nella firewall. Prima di attivare Default‑DROP, documentate i passaggi per l’apertura temporanea: disabilitare pve‑firewall, adattare la regola firewall, reindirizzare la porta SSH. Eseguite una prova live di questi passaggi.
pve‑firewall: Architettura, regole e attivazione sicura
La pve‑firewall è un componente centrale per il Proxmox Hardening. Opera su più livelli – Datacenter, Node e VM/CT – e genera infine regole nftables/iptables sugli host. Pianificate le regole in blocchi funzionali: Cluster/Corosync, Storage, Management, Monitoring.
Corosync & comunicazione di cluster
Corosync utilizza in installazioni standard porte UDP per il traffico di quorum e heartbeat (es. 5404/5405). Se queste connessioni vengono bloccate dalla firewall, i nodi escono dal quorum e i servizi diventano instabili. Create regole che consentano Corosync tra i subnet del cluster e testate latenza/perdita pacchetti con ping/iperf.
# Prüfen, ob Corosync läuft und UDP-Ports offen sind
systemctl status corosync
ss -uanp | grep -E '5404|5405'
# Testweise UDP-Pakete senden (nur in Lab/mit Absprache)
echo test | nc -u -w1 node2.example.org 5405Consentire in modo preciso gli accessi allo storage
I protocolli di storage usano porte tipiche: NFS (2049), iSCSI (3260) e Ceph (Mon 6789, OSD 6800–7300). Aprite solo le porte effettivamente necessarie per il vostro design di storage. I cluster Ceph richiedono spesso raggiungibilità bidirezionale tra OSD e monitor; una configurazione firewall incompleta causa errori di re‑balance e latenza elevata.
Sequenza pratica per l’attivazione
- Rilevare: porte, interfacce, nomi DNS.
- Aggiungere regole: consentire Cluster & Storage.
- Limitare gradualmente il management: GUI/API/SSH solo per le sorgenti amministrative.
- Attivare logging e rate‑limiting.
- Impostare la policy predefinita su DROP; osservare il monitoring.
Diagnosi del firewall e quadri di errore tipici
Sintomi frequenti a seguito di una configurazione errata del firewall: split del cluster, messaggi di quorum poco chiari, migrazioni interrotte o timeout dello storage. La risoluzione dei problemi inizia con controlli dei servizi e della rete.
# Service- und Netzwerkstatus prüfen
systemctl is-active pveproxy pvedaemon pvestatd corosync
journalctl -u pve-firewall -n 200 --no-pager
ss -tulpen | sed -n '1,200p'
# Temporäre Deaktivierung für Test (Node-lokal)
systemctl stop pve-firewall || trueModificate le regole sempre in modo controllato: utilizzate i log di audit, annotate timestamp e autore. Così è possibile risalire più rapidamente alla causa.
Protezione di API e Web‑GUI: TLS, token, MFA
L’API di Proxmox (pveproxy) consente l’automazione ed è funzionalmente equivalente alla GUI — pertanto richiede le stesse misure di protezione: trasmissione cifrata, autenticazione forte e RESTrizione di rete.
Controlli TLS e monitoraggio
Verificate i certificati regolarmente: scadenza, SAN/nome DNS, CA‑Trust sui client amministrativi. Evitate workaround come „insecure_skip_verify“ nelle verifiche di monitoring; se il monitoring non può validare, la soluzione è una gestione migliore dei certificati.
# Zertifikat schnell prüfen
openssl s_client -connect pve.example.org:8006 -servername pve.example.org </dev/null | openssl x509 -noout -subject -issuer -dates -fingerprint -sha256API‑Token e principio del privilegio minimo
Per l’automazione usate API‑Token con diritti limitati invece delle password personali. Separate gli account amministrativi interattivi dagli account di servizio. I token dovrebbero avere una rotazione e una documentazione nel change management.
# Beispiel: pvesh nutzt die API ohne separate Tokens zur schnellen Abfrage
echo 'Nodes:'
pvesh get /nodesMFA e WebAuthn
Abilitate l’autenticazione a due fattori (ad es. TOTP o WebAuthn/U2F) dove possibile. La MFA protegge le sessioni interattive dalle password rubate; tuttavia non sostituisce le RESTrizioni di rete o la gestione dei token.
Indurimento di SSH e rollout sicuri
SSH è il punto di accesso chiave. L’indurimento riduce gli attacchi di brute‑force, migliora l’auditabilità e minimizza il rischio di un account root compromesso.
Esecuzione graduale
- Inventario: quali account usano SSH? Dove si trovano authorized_keys?
- Obbligo: almeno un account con chiave funzionante per nodo e una console aperta durante i test.
- Modificare la configurazione: PasswortAuthentication no, PermitRootLogin no, LogLevel VERBOSE.
- Rollout a fasi: nodo per nodo, monitoraggio dopo ogni modifica.
# /etc/ssh/sshd_config (empfohlen, Auszug)
PubkeyAuthentication yes
PasswordAuthentication no
PermitRootLogin no
LogLevel VERBOSE
AllowGroups proxmox-adminsPrevedete sempre un piano di fallback: la console locale/IPMI può annullare le modifiche, altrimenti si rischia un lockout amministrativo.
Fail2ban, RESTrizioni IP e scenari NAT
Fail2ban aiuta contro tentativi di login ripetuti, ma va usato con cautela in ambienti con NAT o proxy dove più amministratori provengono dalla stessa IP. Definite set di IP in whitelist per jump host e endpoint di monitoraggio automatizzati.
# Fail2ban-Status prüfen
systemctl status fail2ban
fail2ban-client status sshd
# Beispiel: Whitelist in /etc/fail2ban/jail.d/proxmox.conf
# ignoreip = 10.0.0.5 192.168.100.0/24Controlli di audit, rilevamento delle derive e controllo automatizzato
L’hardening non è un’azione una tantum. Audit automatizzati individuano precocemente la deriva di configurazione e sgravano l’operatività.
Verifiche essenziali (mensile)
- Stato patch: pveversion -v e revisione del kernel.
- Porte aperte e listener: ss -tulpen.
- Stato firewall e policy di default: pve-firewall status e nft list ruleset.
- Policy SSH: sshd -T.
- Coerenza temporale: timedatectl e log NTP/SNTP.
- Test di backup/RESTore: ripristino completo in ambiente isolato.
# Basis-Checks als Skript (Auszug)
pveversion -v; uname -a
ss -tulpen
pve-firewall status
sshd -T | egrep 'passwordauthentication|permitrootlogin' || true
timedatectl statusRilevamento della deriva e registro delle modifiche
Utilizzate la replica di /etc/pve (filesystem pmxcfs) e registrate le modifiche. Un semplice diff prima/dopo la manutenzione evita sorprese. Inoltrate i log di journald a un SIEM/central syslog, in modo che gli eventi di audit non vadano persi.
Note specifiche VMware (migrazione e esercizio)
Molte infrastrutture Proxmox si trovano nel contesto di migrazioni da VMware. Nel hardening emergono questioni specifiche: conversione dei dischi, mapping di rete e timeout dello storage. Tenete conto di questi aspetti quando chiudete le reti di management.
Problemi tipici in ambienti VMware
- Formato disco: dopo qm importdisk o conversione con qemu‑img verificare che le UUID dei dischi VM e gli adattatori SCSI siano mappati correttamente.
- Rete: tradurre i concetti di vSwitch/DVSwitch in bridge/VLAN — un’errata assegnazione del bridge può esporre rotte di management.
- Storage: timeout iSCSI/NFS sono frequenti durante le migrazioni; aprite le porte necessarie dello storage e, se necessario, aumentate temporaneamente i timeout durante la migrazione.
Suggestione per il troubleshooting: se dopo la migrazione mancano reti, controllate ‚qm config‘ e confrontate le voci bridge con l’inventario dei bridge host (ip -br a).
Runbook: hardening passo-passo con piano di test
Un rollout sicuro prevede test, punti di osservazione e chiare procedure di rollback:
- Documentare lo stato corrente (porte, servizi, topologia dello storage).
- Test in laboratorio: simulare le regole in un cluster di test.
- Stage: applicare le regole nodo per nodo, attivare il monitoring.
- Produzione: attivare Default‑DROP dopo 48–72 h di funzionamento senza anomalie.
- Review: rapporto di audit e lezioni apprese.
Monitoraggio, logging e allertistica
Centralizzate i log di sistema, impostate allarmi per perdite di Corosync, timeout dello storage, stop di pve‑firewall e tentativi SSH ripetuti. Gli alert devono essere chiari: p.es. Corosync Quorum Lost — avviare il runbook.
Conclusione
Il hardening di Proxmox è un processo continuo con priorità chiare: segmentazione, protezione della comunicazione cluster e storage, RESTrizione graduale di API/GUI/SSH e controlli di audit consolidati. Pianificate ogni passo con test, monitoraggio e piano di rollback documentato. Soprattutto nelle migrazioni VMware e nello storage distribuito si osserva che regole firewall incomplete e modifiche SSH non verificate causano interruzioni più rapidamente del previsto. Con l’ordine e le verifiche descritte qui ridurrete il rischio senza compromettere l’operatività.
FAQ
La GUI di Proxmox (porta 8006) dovrebbe essere accessibile da Internet?
No. La Web‑GUI/API offrono ampie possibilità di gestione. Meglio che la raggiungibilità sia esclusivamente da una rete di management isolata, tramite VPN o un Jump‑Host. Se l’accesso esterno è inevitabile, deve avvenire attraverso strati di protezione a monte (VPN, autenticazione forte, reti sorgente RESTrittive, monitoraggio).
Cosa succede se si attiva la pve‑firewall senza preparazione?
Spesso il traffico di cluster o di storage fallisce perché mancano regole necessarie. Di conseguenza si verificano avvisi di Quorum, migrazioni in sospeso o timeout dello storage. Perciò: prima consentire esplicitamente cluster e storage, poi RESTringere il management e solo alla fine impostare il Default‑DROP.
Fail2ban è sufficiente come protezione per gli accessi a Proxmox?
Fail2ban è uno strato aggiuntivo utile contro tentativi falliti ripetuti, ma non sostituisce la segmentazione di rete, le regole firewall o l’autenticazione forte. In ambienti NAT/Proxy Fail2ban può addirittura risultare problematico se molti utenti si trovano dietro lo stesso IP.
Come indurire SSH senza RESTare esclusi?
Prima di disabilitare i login con password assicuratevi che almeno un account amministratore abbia l’autenticazione tramite chiave. Usate sshd -t per la verifica prima del riavvio e mantenete aperta una seconda sessione. Testate le modifiche prima su un Node e distribuitele in modo graduale.
Quali controlli di audit sono i più importanti nella pratica quotidiana?
Controlli regolari sul livello delle patch, sulle porte aperte, sullo stato del firewall e sulla policy SSH (nessun login con password, nessun login root) sono fondamentali. In aggiunta: consistenza NTP, test di backup e RESTore e changelog verificabili (Diffs in /etc/pve).
Operazioni, integrazioni e rischi: prospettive estese
Oltre al rafforzamento di firewall, API e SSH conviene esaminare i processi operativi e le integrazioni, poiché qui spesso si nascondono rischi non considerati. Tre ambiti sono particolarmente critici: gestione dei segreti, ciclo di vita dei certificati/firmware e modifiche automatizzate provenienti dalle pipeline CI/CD.
Gestione di Secrets e Token
I token API e le chiavi di servizio sono strumenti potenti — ma anche obiettivi attraenti per un attacco. Evitate Long‑Lived‑Tokens nelle configurazioni in chiaro. Integrate la vostra automazione Proxmox in una vault centrale per i secrets (z. B. HashiCorp Vault o una PKI interna all’azienda) e applicate la rotazione dei token e la separazione dei ruoli.
# Beispiel: Liste der API-Tokens (nur als Admin lokal ausführen)
pvesh get /access/tokens
# Nutzen Sie das Ergebnis zur Abgleichsliste gegen Ihre Vault-EinträgeWarum: Tokens können über Backups, CI‑Logs oder falsch konfigurierte Playbooks exponiert werden. Gefahr: ein kompromittiertes Token erlaubt automatisierte VM‑Aktionen ohne interaktiven Login.
PKI, certificati e rinnovo progressivo
Una gestione centralizzata dei certificati riduce il rischio di interruzioni dovute alla scadenza dei certificati TLS. Pianificate i rinnovi progressivi in modo che non tutti i Node carichino contemporaneamente certificati nuovi — altrimenti si rischia la perdita della comunicazione del cluster. Automatizzate i controlli e gli alert per le date di scadenza, non solo campionamenti manuali.
# Zertifikatsprüfung über mehrere Hosts (Auszug)
for host in pve1 pve2 pve3; do
echo "Checking $host"
openssl s_client -connect ${host}:8006 -servername ${host} /dev/null | openssl x509 -noout -enddate
doneFirmware, Out‑of‑Band und IPMI/Redfish‑Härtung
Controller di gestione (IPMI/Redfish) sono superfici di attacco indipendenti. Segmentate le reti OOB, applicate StrongAuth e automatizzate la gestione degli aggiornamenti firmware. Documentate le credenziali Break‑Glass separatamente dall’inventario normale e testate il ripristino OOB almeno semestralmente.
Automazione, CI/CD e Change‑Control
Se i playbook eseguono modifiche direttamente su Proxmox, test e Canary‑Rollouts devono far parte del processo. Eseguite verifiche sintetiche (p. es. avvio/arresto VM, mount dello storage) in staging e strumentate i rollback: i playbook dovrebbero poter annullare le modifiche in modo idempotente.
SLOs, Monitoring und Eskalation
Definite SLO misurabili per la salute del cluster (disponibilità del quorum), la latenza dello storage e i tempi di risposta delle API. Allarmi senza passaggi di runbook chiari generano rumore; combinate gli alert con diagnosi automatizzate (raccolta log, pveproxy health, corosync status) e un percorso di escalation definito.
Queste operazionalizzazioni colmano il divario tra indurimento tecnico e funzionamento affidabile: chi gestisce i segreti, automatizza i certificati e controlla le modifiche riduce significativamente il rischio residuo.
Anche mettere in sicurezza la Proxmox Firewall e la Proxmox API è importante per questo tema. L’articolo inquadra questi aspetti in modo comprensibile e mostra cosa conta nella pratica quotidiana.