• Guide, Sicurezza, Sistemi Operativi
• 23 Febbraio 2026

Quando progettate la sicurezza di un’infrastruttura Hyper-V, spesso vi concentrate su firewall perimetrali, segmentazione di rete e soluzioni di micro-segmentation. Tuttavia, c’è un livello di controllo ancora più granulare che potete applicare direttamente alle schede di rete virtuali delle macchine: le Extended Port Access Control Lists. Si tratta di uno strumento potente, integrato nell’hypervisor, che vi consente di definire con precisione quali flussi di traffico sono consentiti o negati, basandovi su indirizzi IP, protocolli, porte e direzione del traffico.

In questo articolo analizzeremo come funzionano le Extended Port ACL in Hyper-V, qual è la logica con cui vengono elaborate e in quali scenari possono fare la differenza rispetto alle ACL tradizionali. Partiremo dall’approccio via PowerShell, indispensabile per comprendere a fondo la struttura delle regole e la loro priorità, per poi vedere come gestire le stesse configurazioni anche attraverso Windows Admin Center, così da integrare il controllo di rete direttamente nelle vostre attività operative quotidiane.

L’obiettivo è mettervi nelle condizioni di utilizzare queste funzionalità in modo consapevole, non solo per bloccare traffico indesiderato, ma per costruire policy di sicurezza coerenti con l’architettura della vostra infrastruttura virtuale.

Architettura e principi di funzionamento delle Extended Port Access Control Lists in Hyper-V

Le Extended Port Access Control Lists in Hyper-V lavorano a livello di vNIC della macchina virtuale e vengono applicate direttamente sulla porta del virtual switch. Il filtraggio avviene quindi nell’hypervisor, prima che il traffico raggiunga il sistema operativo guest.

Ogni regola può filtrare in base a IP sorgente e destinazione, protocollo, porta e direzione (Inbound o Outbound). Questo vi permette di controllare in modo molto preciso i flussi tra macchine virtuali o verso l’esterno, senza dover intervenire sul firewall interno della VM.

La valutazione segue una logica semplice: le regole vengono elaborate in ordine di priorità crescente. La prima che corrisponde al traffico viene applicata e il processo si ferma. Per questo motivo la gestione della priorità è fondamentale: una regola troppo generica, con priorità più alta, può rendere inutile una regola più specifica definita dopo.

Se nessuna regola intercetta il traffico, il comportamento dipende da come avete progettato la policy. Se volete un approccio “default deny”, dovete prevedere esplicitamente una regola finale di blocco.

Capire questa logica è essenziale: le Extended Port ACL non sono un firewall completo, ma uno strumento di controllo puntuale integrato nello stack di rete di Hyper-V, pensato per segmentare e proteggere il traffico a livello di host in modo deterministico.

Differenze tra ACL tradizionali ed Extended Port ACL

Le ACL tradizionali in Hyper-V consentono un controllo piuttosto basilare del traffico: potete permettere o negare comunicazioni in base all’indirizzo IP e alla direzione. Sono utili per scenari semplici di isolamento tra macchine virtuali, ma non offrono un livello di dettaglio particolarmente elevato.

Le Extended Port ACL introducono un modello molto più granulare. Oltre a IP sorgente e destinazione, potete filtrare per protocollo, porta sorgente e porta di destinazione. Questo significa che non vi limitate a dire “questa VM può parlare con quest’altra”, ma potete stabilire come può farlo, su quali porte e con quali protocolli.

La differenza sostanziale è proprio nella granularità del controllo. Con le ACL tradizionali lavorate a livello di indirizzo; con le Extended Port ACL entrate nel dettaglio del flusso applicativo. Questo vi consente di implementare logiche di segmentazione più aderenti ai requisiti di sicurezza, riducendo la superficie di attacco senza introdurre complessità eccessiva nell’infrastruttura.

Di fatto, le Extended Port ACL vi permettono di spostare parte del controllo del traffico direttamente nell’hypervisor, con un approccio più preciso e coerente rispetto alle ACL di base.

Configurazione tramite PowerShell

Per lavorare con le Extended Port ACL in Hyper-V vi muovete sempre attorno alla vNIC della VM: prima individuate l’adapter corretto, poi aggiungete le regole e infine verificate cosa è stato applicato.

Il punto di partenza è recuperare la scheda di rete della VM con Get-VMNetworkAdapter:

A quel punto potete creare una regola con Add-VMNetworkAdapterExtendedAcl. I parametri “critici” sono quelli che determinano davvero il match: Direction, Action, RemoteIPAddress / LocalIPAddress, Protocol, LocalPort / RemotePort e soprattutto Priority (più basso = viene valutato prima).

Esempio tipico: consentire solo TCP 443 in uscita verso un IP specifico:

Se invece volete chiudere tutto ciò che non avete autorizzato (approccio “default deny”), la regola finale è di blocco, con priorità più “bassa” in precedenza (quindi numero più alto rispetto alle allow specifiche):

Per verificare rapidamente cosa è stato applicato alla vNIC usate Get-VMNetworkAdapterExtendedAcl:

Quando dovete fare pulizia o correggere una policy, rimuovete le regole con Remove-VMNetworkAdapterExtendedAcl (di solito filtrando per Weight o per le proprietà della regola che vi interessano):

Il flusso ideale è sempre lo stesso: identificate la vNIC, aggiungete regole molto specifiche con priorità più “alta” (numero più basso), mettete una deny finale se vi serve un blocco di default, e controllate l’ordine con Get-VMNetworkAdapterExtendedAcl ordinato per Weight.

Nota: per ogni vNIC è possibile configurare fino a 4096 regole di Extended Port ACL. Il parametro Weight accetta valori interi compresi tra 0 e 65535; le regole vengono elaborate in ordine crescente; quindi 0 rappresenta la precedenza massima e 65535 quella minima.

Figura 1: Configurazione tramite PowerShell delle Extended Port ACL

Supporto a protocolli non TCP/UDP con le Extended Port ACL

Non tutto il traffico in un datacenter utilizza TCP o UDP. Alcune applicazioni si basano su protocolli IP specifici identificati direttamente dal numero di protocollo nel campo Protocol dell’header IP. Un esempio tipico è IGMP (Internet Group Management Protocol), utilizzato negli scenari di IP multicast.

Come riportato nella documentazione ufficiale Microsoft, IGMP utilizza il numero di protocollo IP 0x02, ovvero 2 in formato decimale. Quando lavorate con Add-VMNetworkAdapterExtendedAcl, dovete specificare il valore numerico del protocollo.

Se volete consentire traffico IGMP sia in ingresso sia in uscita per una VM, le regole saranno simmetriche: nessuna restrizione su IP o porte (non rilevanti per IGMP), ma filtro basato esclusivamente sul numero di protocollo.

Esempio corretto in PowerShell:

In questo caso Protocol 2 identifica IGMP, non vengono specificati indirizzi o porte, quindi valgono implicitamente Any e il Weight 20 assegna una precedenza relativamente alta alla regola.

Stateful ACL rules nelle Extended Port ACL

Per impostazione predefinita, le Extended Port ACL in Hyper-V sono stateless. Questo significa che ogni pacchetto viene valutato in modo indipendente, senza tenere traccia dello stato della connessione. Se autorizzate traffico in uscita su una determinata porta, dovete creare esplicitamente anche la regola di ritorno per consentire il traffico in ingresso.

La documentazione ufficiale Microsoft prevede però la possibilità di configurare regole stateful, abilitando il parametro -Stateful nel cmdlet Add-VMNetworkAdapterExtendedAcl.

Quando una regola è configurata come stateful:

• il traffico iniziale viene valutato secondo la regola definita
• il traffico di risposta viene automaticamente consentito
• non è necessario creare una regola speculare per il flusso di ritorno

Esempio: consentire traffico HTTPS in uscita in modalità stateful:

In questo scenario, la VM può aprire connessioni TCP verso la porta 443 e ricevere automaticamente le risposte, senza dover configurare una regola inbound separata.

L’utilizzo di regole stateful semplifica la configurazione, soprattutto quando adottate un modello “default deny” con una regola finale di blocco. Va però utilizzato con consapevolezza: la semplificazione operativa non deve ridurre la chiarezza del modello di sicurezza che state implementando.

Figura 2: onfigurazione di una regola Stateful per traffico HTTPS in uscita

Consentire traffico inbound solo dopo una connessione inizializzata dal server locale

Un’esigenza abbastanza comune è questa: volete che la VM possa ricevere traffico in ingresso da un server remoto solo se è stata lei ad avviare la comunicazione. In altre parole, niente connessioni inbound spontanee, ma solo traffico di risposta.

Questo scenario si implementa utilizzando una regola stateful in uscita, combinata con una regola di blocco inbound.

La logica è semplice:

• consentite il traffico outbound verso il server remoto con -Stateful $true
• negate il traffico inbound non esplicitamente consentito
• lasciate che sia il meccanismo stateful a permettere solo le risposte legittime

Esempio pratico: la VM può aprire connessioni HTTPS verso 203.0.113.10 e ricevere solo le risposte relative a quelle sessioni.

Poi definite una regola di blocco inbound generica con peso maggiore (quindi valutata dopo eventuali allow specifiche):

Il risultato è questo: la VM non accetta connessioni iniziate dall’esterno, ma può ricevere traffico di risposta relativo alle sessioni che ha aperto lei. È un modello molto vicino al comportamento di un firewall stateful tradizionale, ma applicato direttamente a livello di hypervisor tramite le Extended Port ACL di Hyper-V.

Figura 3: Configurazione di modello “stateful outbound + deny inbound”

Rimuovere tutte le Extended Port ACL da una VM

In un laboratorio può essere utile azzerare completamente la configurazione delle Extended Port ACL applicate a una vNIC, soprattutto dopo una serie di test.

Per rimuovere tutte le regole da una VM specifica, potete utilizzare la pipeline tra Get-VMNetworkAdapterExtendedAcl e Remove-VMNetworkAdapterExtendedAcl, come previsto dalla documentazione ufficiale Microsoft:

Il comando recupera tutte le regole associate alla vNIC della VM e le passa direttamente al cmdlet di rimozione.

Se la VM ha più schede di rete e volete essere ancora più espliciti, potete prima identificare l’adapter con Get-VMNetworkAdapter e poi filtrare per nome.

Dopo la rimozione, potete verificare che non siano più presenti regole con:

Se il comando non restituisce output, significa che la vNIC non ha più Extended Port ACL configurate ed è tornata al comportamento predefinito.

Gestione delle Extended Port ACL tramite Windows Admin Center

Se lavorate quotidianamente con ambienti virtualizzati, non sempre volete passare da PowerShell per ogni modifica. Con Windows Admin Center potete gestire le Extended Port ACL direttamente dall’interfaccia web, integrandole nel vostro flusso operativo senza cambiare contesto.

All’interno della gestione della macchina virtuale, nella sezione dedicata alla rete, potete intervenire sulla scheda di rete virtuale e definire le regole di filtro specificando direzione, azione, protocollo, indirizzi e porte. I parametri che in PowerShell configurate con Add-VMNetworkAdapterExtendedAcl vengono esposti in modo guidato, riducendo il rischio di errori sintattici e permettendovi di visualizzare immediatamente le regole già applicate.

Il vantaggio operativo è evidente: avete una vista centralizzata delle configurazioni, soprattutto in ambienti con più host o in cluster. Potete verificare rapidamente quali VM hanno policy attive, controllare l’ordine di elaborazione basato sul Weight e intervenire senza dover accedere interattivamente a ciascun nodo.

Figura 4: Gestione centralizzata delle Extended Port ACL in Windows Admin Center

Figura 5: Visualizzazione delle Extended Port ACL direttamente dalla VM in Windows Admin Cente

Selezionando la VM dal cluster e accedendo alla sezione Extended port ACL Rules, è possibile creare una nuova regola tramite il pulsante New. Si apre un pannello laterale che consente di configurare graficamente:

• Action (Allow o Deny)
• Direction (Inbound o Outbound)
• Local e Remote IP address
• Protocol
• Weight
• Opzione Stateful
• Scheda di rete virtuale a cui applicare la regola

In questo modo potete definire le Extended Port ACL senza utilizzare PowerShell, operando direttamente nel contesto della VM.

Nota: La gestione delle Extended Port ACL tramite Windows Admin Center (attualmente in modalità Preview) non espone tutti i parametri disponibili nel cmdlet Add-VMNetworkAdapterExtendedAcl. In particolare, nell’interfaccia grafica non è possibile specificare LocalPort e RemotePort: le regole create via GUI lavorano quindi a livello di protocollo e indirizzo IP, ma non consentono un filtraggio puntuale sulle porte.

Figura 6: Creazione di una regola ICMP inbound con filtro su IP locale da Windows Admin Center

Figura 7: Regola ICMP inbound creata dal Windows Admin Center

Scenari pratici e casi d’uso reali

Le Extended Port ACL in Hyper-V diventano particolarmente interessanti quando volete introdurre una segmentazione “leggera” direttamente a livello di host, senza ricorrere a firewall dedicati o soluzioni di micro-segmentazione più complesse.

Un primo scenario tipico è la segmentazione tra macchine virtuali che condividono lo stesso virtual switch. Pensate a un ambiente di laboratorio o a un cluster con più workload applicativi: potete consentire la comunicazione solo tra specifiche VM e bloccare tutto il resto. In questo modo evitate che una macchina compromessa possa comunicare liberamente con le altre presenti sullo stesso host.

Un altro caso molto concreto riguarda le restrizioni su porte e protocolli. Se una VM espone solo un servizio web, potete autorizzare esclusivamente il traffico TCP sulla porta 443 e negare qualsiasi altra comunicazione in ingresso. Oppure potete consentire l’accesso RDP solo da un indirizzo IP amministrativo specifico. Questo tipo di controllo, applicato tramite Add-VMNetworkAdapterExtendedAcl, vi permette di ridurre drasticamente la superficie di attacco senza intervenire sulla configurazione interna del sistema operativo guest.

Le ACL estese sono utili anche per limitare le comunicazioni in uscita. In molti ambienti server non è necessario che una VM possa comunicare liberamente verso Internet o verso altre subnet interne. Consentire solo le destinazioni strettamente necessarie (ad esempio Domain Controller, server DNS o repository di aggiornamento) e applicare una regola di blocco finale è un modo semplice ed efficace per contenere eventuali movimenti laterali.

In tutti questi scenari il vantaggio è lo stesso: spostate una parte del controllo del traffico a livello di hypervisor, rendendolo indipendente dalla configurazione del sistema operativo della VM. Le Extended Port ACL non sostituiscono un firewall completo, ma rappresentano uno strumento preciso e deterministico per rafforzare l’isolamento e migliorare la postura di sicurezza dell’infrastruttura virtuale.

E se la VM è clusterizzata?

Quando la VM è clusterizzata (ad esempio gestita tramite Failover Cluster Manager su più host Hyper-V), le Extended Port ACL continuano a funzionare esattamente allo stesso modo: le regole vengono applicate alla vNIC della macchina virtuale, quindi alla porta dello virtual switch dell’host che in quel momento la ospita.

Ci sono però alcune considerazioni operative importanti.

Le ACL sono parte della configurazione della VM e vengono mantenute anche in caso di Live Migration. Quando la VM si sposta su un altro nodo del cluster, le impostazioni della scheda di rete virtuale, incluse le Extended Port ACL, vengono trasferite insieme alla macchina. Non è necessario ricreare manualmente le regole su ogni host.

È invece fondamentale che il virtual switch di destinazione abbia lo stesso nome e configurazione su tutti i nodi, la versione di Hyper-V e le funzionalità siano coerenti tra gli host e che eventuali configurazioni SDN o estensioni di switch siano uniformi. Se l’infrastruttura non è omogenea, durante una migrazione potreste ricevere errori nell’applicazione delle impostazioni di porta, simili a quelli mostrati in precedenza.

Dal punto di vista della gestione, in ambiente clusterizzato ha ancora più senso utilizzare Windows Admin Center, perché vi permette di vedere e modificare le Extended Port ACL direttamente dal contesto del cluster, senza dovervi collegare al singolo nodo proprietario della VM in quel momento.

Troubleshooting, best practice e impatto prestazionale

Quando lavorate con le Extended Port ACL in Hyper-V, il troubleshooting parte sempre da un presupposto: le regole vengono valutate in ordine crescente di Weight e la prima corrispondenza determina l’azione. Se il traffico non si comporta come previsto, il problema è quasi sempre legato all’ordine delle regole o a una condizione troppo generica che intercetta il traffico prima di quella corretta.

Il primo passo è verificare lo stato reale della configurazione con Get-VMNetworkAdapterExtendedAcl, ordinando per Weight. Questo vi permette di capire immediatamente quale regola viene valutata per prima. È buona norma controllare anche che non esistano duplicati di peso o regole sovrapposte che rendono il comportamento meno prevedibile.

In ambiente clusterizzato, vale la pena verificare anche il nodo attivo e assicurarsi che lo virtual switch sia coerente tra gli host. Errori come 0x80070057 indicano spesso parametri non validi o configurazioni non uniformi.

Dal punto di vista operativo, alcune best practice sono piuttosto chiare:

• assegnate valori di Weight con una logica ordinata (ad esempio intervalli di 10 o 100) per facilitare modifiche future
• inserite sempre una regola di blocco finale se volete un modello “default deny”
• evitate regole troppo generiche con priorità alta
• documentate lo scopo di ogni ACL, soprattutto in ambienti con molte VM

Per quanto riguarda l’impatto prestazionale, le Extended Port ACL operano a livello di virtual switch e sono integrate nello stack di rete dell’hypervisor. In scenari normali il loro impatto è trascurabile, perché il motore di filtering è ottimizzato e lavora in kernel mode. Tuttavia, un numero molto elevato di regole per singola vNIC (ricordando il limite di 4096) può aumentare la complessità della valutazione e rendere più difficile la diagnosi di problemi.

Quindi le Extended Port ACL non sono un collo di bottiglia prestazionale, ma uno strumento di controllo. Il vero rischio non è la performance, bensì la complessità: più la policy cresce in modo disordinato, più diventa difficile prevederne il comportamento. Mantenerle semplici, coerenti e ben strutturate è la chiave per usarle in modo efficace.

Conclusioni

Le Extended Port ACL in Hyper-V rappresentano uno strumento semplice ma efficace per introdurre un livello aggiuntivo di controllo del traffico direttamente nell’hypervisor. Consentono di segmentare le macchine virtuali, limitare porte e protocolli, implementare modelli “default deny” e ridurre concretamente la superficie di attacco, senza intervenire sulla configurazione interna dei sistemi guest.

Abbiamo visto come configurarle tramite PowerShell, quando serve il massimo livello di granularità, e come gestirle tramite Windows Admin Center per un controllo più immediato e centralizzato, soprattutto in ambienti clusterizzati. La chiave resta sempre la stessa: comprendere la logica di valutazione basata sul Weight e progettare le regole in modo coerente e ordinato.

Per approfondimenti tecnici, sintassi completa dei cmdlet e scenari avanzati, vi rimando alla documentazione ufficiale Microsoft: https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/create-security-policies-extended-port-access-control-lists