Che cosa sono le regole in uscita del firewall Windows?
Le regole in uscita del firewall Windows governano le connessioni che lasciano un computer Windows. L’azione predefinita in uscita di un profilo determina cosa accade quando nessuna regola applicabile consente o blocca quel traffico. Un progetto pilota di blocco predefinito parte da una popolazione definita e da un insieme documentato di connessioni necessarie, poi verifica se tali connessioni funzionano ancora con i criteri previsti.
Questa scelta di rafforzamento comporta costi operativi. Microsoft consiglia di consentire il traffico in uscita per impostazione predefinita nella maggior parte delle distribuzioni e considera il blocco predefinito per alcuni ambienti con requisiti di sicurezza elevati. Un rilievo sull’azione predefinita raccolta avvia quindi una revisione; non stabilisce un requisito universale di bloccare il traffico in uscita in tutto il dominio. Consultare le indicazioni Microsoft sulle regole di Windows Firewall.
La questione pratica è se l’organizzazione può mantenere una lista di autorizzazione utile per i computer scelti. Stabilire chi è responsabile delle modifiche, quali applicazioni devono comunicare e come verranno ripristinate le dipendenze non funzionanti prima di cambiare l’impostazione predefinita. Criteri che interrompono gli aggiornamenti o la gestione remota senza una via di ripristino possono compromettere lo scopo dell’esercizio.
Funzionamento: l’impostazione predefinita di un profilo è diversa da una regola di blocco
I profili Domain, Private e Public hanno impostazioni separate. Scegliere deliberatamente il profilo del progetto pilota e verificare quello utilizzato sulla rete di destinazione. Una configurazione del profilo Domain non dimostra cosa accade quando lo stesso computer utilizza una rete Private o Public.
Occorre distinguere due modelli. Con un’azione predefinita in uscita impostata su Block, una regola esplicita di autorizzazione applicabile può consentire il traffico necessario. Con una regola esplicita di blocco esteso, una normale regola di autorizzazione in conflitto non ripristina quel traffico: le regole esplicite di blocco hanno la precedenza. Un’autorizzazione più specifica non aggira un blocco esplicito sovrapposto. Questi comportamenti di precedenza valgono anche per le regole in uscita.
Anche gli archivi dei criteri sono rilevanti. Una regola salvata in una GPO di gestione descrive la configurazione prevista. L’ActiveStore della destinazione rappresenta i criteri attualmente attivi, assemblati dagli archivi applicabili. L’unione delle regole locali può influenzare le eccezioni che partecipano; esaminare le impostazioni effettive di unione e le origini delle regole invece di presumere che un’eccezione creata localmente venga utilizzata. La guida Microsoft alla gestione da riga di comando documenta le operazioni locali e tramite GPO.
Tenere separate le restrizioni di autenticazione da quelle di connettività. La nostra guida per bloccare NTLM in uscita dai sistemi Tier 0 tratta la limitazione di un meccanismo di autenticazione coinvolto nella coercizione e nel relay. Questa decisione non definisce una lista di autorizzazione del firewall per applicazione e destinazione, e un’impostazione predefinita in uscita del firewall non stabilisce che l’autenticazione NTLM sia disabilitata.
Rilevamento: confrontare i dati GPO raccolti con la destinazione
Registrare il computer, il contesto di rete, l’ambito previsto dei criteri e l’ora di raccolta. Eseguire separatamente i seguenti comandi di lettura in PowerShell su una destinazione Windows rappresentativa. Sono esempi basati sulla documentazione, non misurazioni effettuate per questo articolo.
Passaggio 1: leggere le impostazioni dei profili attivi
Microsoft documenta Get-NetFirewallProfile con ActiveStore:
Get-NetFirewallProfile -PolicyStore ActiveStore
Esaminare Name, Enabled e DefaultOutboundAction per ciascun profilo, insieme alle impostazioni di unione delle regole locali e di registrazione. Conservare l’output restituito. Confermare quale profilo di rete utilizza effettivamente il progetto pilota; un valore Block su un profilo inattivo non è una prova sufficiente che il flusso testato sia stato filtrato.
Confrontare il risultato Domain con il valore WindowsFirewall/DomainProfile/DefaultOutboundAction della GPO raccolto da Registry.pol. Nella rappresentazione del rilevatore, 0 significa Allow e 1 significa Block. Quando il valore GPO è assente o diverso da quello della destinazione, indagare l’applicazione dei criteri e le origini di configurazione concorrenti. Non sostituire il risultato attivo del computer con il valore scelto dal collector.
Passaggio 2: esaminare le regole in uscita e le loro origini
Utilizzare il riferimento di Get-NetFirewallRule per recuperare le regole in uscita dai criteri attivi e risalire agli archivi di origine:
Get-NetFirewallRule -Direction Outbound -PolicyStore ActiveStore -TracePolicyStore
Esaminare lo stato di abilitazione, l’azione, il profilo, l’origine e i filtri associati per applicazione, servizio, indirizzo e porta. Gli oggetti regola da soli non mostrano completamente tutti i filtri associati; esaminare questi dettagli in Windows Firewall with Advanced Security o tramite i cmdlet di filtro NetSecurity corrispondenti. Individuare le regole di blocco sovrapposte e le autorizzazioni troppo ampie prima di interpretare un test di connettività.
La nostra guida ai quattro controlli di sicurezza GPO usa lo stesso metodo di verifica: confrontare l’intento dei criteri, i computer che li ricevono e la protezione effettivamente in uso. I suoi controlli LLMNR, WSUS, LSA e UNC non stabiliscono la copertura del firewall in uscita. Applicare qui il metodo con prove specifiche del firewall sulla destinazione.
Passaggio 3: osservare il traffico necessario e rifiutato
Leggere il LogFileName configurato del profilo invece di presumere che tutti i computer usino lo stesso percorso. La guida da riga di comando mostra %SystemRoot%\System32\LogFiles\Firewall\pfirewall.log. Il riferimento di Set-NetFirewallProfile documenta la registrazione dei pacchetti accettati e scartati. Correlare le voci conservate con l’operazione dell’applicazione, il timestamp, il protocollo e gli endpoint che si stanno testando.
Per un progetto pilota di laboratorio isolato e gestito localmente, questo comando abilita entrambe le opzioni di registrazione per Domain:
Set-NetFirewallProfile -Profile Domain -LogAllowed True -LogBlocked True
Per i computer gestiti, configurare invece la registrazione nei criteri che li governano e verificarla in ActiveStore. Le modifiche alla registrazione sono separate dall’impostazione predefinita in uscita. Registrare le impostazioni precedenti e pianificare la conservazione affinché le prove per la risoluzione dei problemi restino disponibili. Un pacchetto scartato è un punto di partenza per l’indagine, non una prova di malware; il silenzio di un log non dimostra che tutti i percorsi applicativi siano consentiti.
Correzione: progettare un pilota circoscritto di blocco predefinito (Remediation)
Passaggio 1: decidere se il blocco predefinito è adatto alla popolazione
Documentare la motivazione aziendale e di sicurezza del progetto pilota, i computer scelti e il confine del profilo Domain. Selezionare una popolazione gestibile con responsabili delle applicazioni disponibili per i test. Identificare le finestre di manutenzione, le responsabilità di monitoraggio e una via di ripristino indipendente. Decidere quali prove consentiranno l’estensione e quale errore richiederà il rollback.
Se l’inventario delle dipendenze è incompleto o nessuno può mantenerlo, registrare tale limite e affrontarlo prima di applicare le restrizioni. L’obiettivo è una politica di connettività sostenibile. Chiudere un rilievo di configurazione cambiando un’impostazione predefinita nell’intero dominio senza comprenderne l’effetto non è un criterio utile di successo.
Passaggio 2: inventariare le applicazioni e le loro dipendenze
Per ogni applicazione e servizio, registrare l’eseguibile o l’identità del servizio, le destinazioni previste, il protocollo, le porte di destinazione, gli orari di funzionamento e il responsabile. Includere esplicitamente nella revisione la risoluzione DNS, il recupero degli aggiornamenti, gli agenti di gestione, l’amministrazione remota e gli strumenti di ripristino. Inventariare sia le operazioni abituali sia le attività di manutenzione poco frequenti; una sessione interattiva riuscita non verifica un aggiornamento o un backup pianificato.
Utilizzare i requisiti dei fornitori e le operazioni legittime osservate per costruire la lista. Distinguere le destinazioni necessarie direttamente all’applicazione dall’infrastruttura di supporto, come un proxy o un resolver. Quando gli endpoint cambiano nel tempo, registrare come verrà mantenuta la lista di autorizzazione. Non dedurre una mappa completa delle dipendenze da una breve cattura di pacchetti e non approvare automaticamente ogni connessione osservata.
Passaggio 3: predisporre regole di autorizzazione documentate
Creare le eccezioni necessarie prima di abilitare il blocco predefinito. Associare a ogni regola un responsabile, uno scopo, un profilo e una decisione di revisione. Verificare che le regole raggiungano il progetto pilota tramite l’archivio dei criteri previsto e risolvere i conflitti con blocchi espliciti. Esaminare l’unione delle regole locali per trattare deliberatamente le regole installate dalle applicazioni e le eccezioni create dagli amministratori.
La seguente regola illustrativa utilizza i parametri documentati da New-NetFirewallRule. Il percorso, l’indirizzo, la porta, il dominio e la GPO sono esempi da sostituire con valori di inventario verificati; questa regola non va distribuita senza modifiche:
New-NetFirewallRule -DisplayName "Pilot application to approved service" -Direction Outbound -Action Allow -Profile Domain -Program "C:\Program Files\Example\client.exe" -Protocol TCP -RemoteAddress 192.0.2.10 -RemotePort 443 -PolicyStore "corp.contoso.com\Outbound Pilot"
Una sola eccezione di esempio non costituisce un inventario delle dipendenze applicative. Aggiungere solo le regole giustificate dal carico di lavoro reale, inclusi i suoi servizi di supporto. Esaminare anche le autorizzazioni ampie esistenti: il blocco predefinito ha un valore limitato se un’eccezione generale consente ancora le connessioni che si volevano limitare.
Passaggio 4: modificare solo l’ambito scelto del profilo Domain
Per la GPO del progetto pilota di esempio, i parametri documentati di Set-NetFirewallProfile possono esprimere l’impostazione predefinita selezionata:
Set-NetFirewallProfile -Profile Domain -DefaultOutboundAction Block -PolicyStore "corp.contoso.com\Outbound Pilot"
Confermare che questa GPO sia applicata solo alla popolazione selezionata prima di modificarla. Conservare l’impostazione precedente e mantenere il firewall abilitato. Dopo l’applicazione dei criteri, ripetere le query ActiveStore sui profili e sulle regole dei computer di destinazione. Un comando di gestione riuscito scrive la configurazione; non dimostra che ogni destinazione prevista l’abbia applicata.
Passaggio 5: misurare i flussi e provare il rollback
Eseguire ogni operazione registrata con il profilo Domain attivo. Verificare il comportamento applicativo, la risoluzione dei nomi, i controlli degli aggiornamenti, l’accesso di gestione e quello di ripristino. Confrontare gli errori con il traffico scartato e i dettagli delle regole. Quando una connessione è necessaria, documentarne lo scopo prima di aggiungere o correggere l’eccezione appropriata; poi ripetere il test dell’operazione originale.
Definire un test controllato per il traffico che i criteri devono rifiutare, utilizzando una destinazione e un carico di lavoro di test approvati. Registrare il risultato previsto e le prove effettive sulla destinazione. Evitare di interpretare un singolo rifiuto riuscito come prova che tutte le uscite indesiderate siano bloccate. Conservare insieme i registri delle operazioni consentite e rifiutate affinché i revisori possano valutare l’intento di sicurezza e la compatibilità.
Se l’impostazione predefinita precedente registrata per la GPO di esempio era Allow, il suo comando di rollback è:
Set-NetFirewallProfile -Profile Domain -DefaultOutboundAction Allow -PolicyStore "corp.contoso.com\Outbound Pilot"
Ripristinare lo stato effettivo precedente dei criteri quando era diverso, inclusa un’impostazione non configurata ove appropriato. Esaminare separatamente le regole del progetto pilota e le modifiche alla registrazione. Un blocco esplicito rimasto può ancora impedire la connettività dopo che l’impostazione predefinita torna ad Allow. Ricontrollare ActiveStore e ripetere l’operazione aziendale non riuscita prima di dichiarare concluso il ripristino. Estendere solo quando l’inventario, le responsabilità, i test e il registro del rollback giustificano la popolazione successiva.
Come EtcSec rileva questa configurazione
L’implementazione Detect() di etc-collector esaminata espone un controllo pertinente qui: FIREWALL_OUTBOUND_NOT_BLOCKED. Inizializza un rilievo di gravità Low con Count = 0, poi cerca l’intero raccolto FirewallOutboundAction. Se la ricerca restituisce nil o un valore diverso da 1, imposta Count = 1. Un valore restituito di 1 lascia Count = 0.
Il parser Registry.pol popola quel campo solo da una chiave corrispondente a WindowsFirewall e DomainProfile, con il nome di valore DefaultOutboundAction. I valori dei profili Private e Public sono fuori dall’ambito di questo controllo. La funzione ausiliaria per gli interi cerca prima un valore non nil in Default Domain Controllers Policy, poi in Default Domain Policy e infine in un’altra GPO disponibile. Il meccanismo di fallback itera una mappa Go; non determina la precedenza dei criteri Windows.
Questi confini sono rilevanti quando si esamina un rilievo. L’assenza di un valore GPO raccolto attiva il controllo senza misurare l’impostazione predefinita effettiva o l’applicazione reale su un computer. Count = 1 non conta gli endpoint esposti e non dimostra traffico di comando e controllo. Count = 0 non convalida l’abilitazione del firewall, le regole di autorizzazione necessarie, i conflitti con blocchi espliciti, le eccezioni locali o il buon funzionamento del progetto pilota.
Utilizzare questo segnale per avviare l’indagine circoscritta descritta sopra. Allegare alla revisione il profilo attivo della destinazione, le regole effettive, i test applicativi e le prove di rollback. Decidere se il blocco predefinito è appropriato per quella popolazione, poi risolvere la questione di configurazione con le prove ottenute invece di basarsi solo sulla ricerca aggregata nelle GPO.
Esplora le pagine di identity security collegate a questo tema