Il firewall di Windows e le applicazioni aziendali — Registrare le regole in ingresso dall'installer

«Sulla macchina di sviluppo funziona senza problemi, ma dal cliente il client non arriva al server», «al primo avvio è uscita una sorta di avviso e la persona in campo l’ha annullato», «con netstat la porta è in ascolto, ma dal PC accanto non arriva» — Nei cantieri di introduzione delle app aziendali, questo tipo di richiesta «non si comunica» è tra i più classici. E a restare in cima alle cause è il firewall di Windows (Windows Defender Firewall).

Il fastidio è che sulla macchina di sviluppo il problema non si vede. Sulla macchina di sviluppo, all’esecuzione di debug da Visual Studio, si è premuto Consenti da soli, o si era amministratori, e si spedisce senza accorgersi del blocco in ingresso predefinito. Dal cliente, invece, chi opera è un utente ordinario senza privilegi di amministratore, e la rete è gestita con GPO. Non è «dovrebbe funzionare e non funziona»: la realtà è «la macchina di sviluppo funzionava per caso».

Questo articolo è rivolto agli sviluppatori di app aziendali che, con un’app sviluppata internamente, si trovano di fronte a «dal cliente non si comunica», e al personale IT delle PMI che riceve quelle richieste. Fissati al minimo il comportamento predefinito del firewall di Windows e il meccanismo dei profili, organizza la progettazione delle regole in ingresso, la pratica della registrazione dall’installer, la procedura di triage e i punti di attenzione sotto gestione GPO/Intune, sulla base di fonti primarie ad agosto 2026.

1. Prima di tutto, la conclusione

• Il predefinito del firewall di Windows è «blocca in ingresso, consenti in uscita». Il traffico in ingresso che non è una risposta a una richiesta viene scartato se non corrisponde a una regola.¹
• Una regola in ingresso serve solo alle app di tipo server che si mettono in ascolto su una porta. Un’app client che si collega da sola comunica con i predefiniti. Fate prima questo triage.¹
• I profili sono tre (dominio / privato / pubblico). Il dominio si applica in automatico al rilevamento di un controller di dominio; il pubblico è il predefinito delle reti non identificate. Le regole sono abilitate o disabilitate per profilo.¹
• Non affidate la produzione a quella finestra di «avviso importante». Se l’amministratore annulla, viene creata una regola di blocco; se l’utente non ha privilegi di amministratore, qualunque pulsante si prema viene creata una regola di blocco. Finché non si elimina la regola creata, la finestra non ricompare.²
• La conclusione è «le regole in ingresso delle app aziendali si registrano dall’installer». Microsoft stessa raccomanda di collocare le regole prima del primo avvio e di disabilitare le notifiche in ingresso.²
• Le regole si progettano con privilegio minimo. Asse programma + protocollo + porta, profilo limitato a dominio/privato, IP remoto ristretto alla subnet necessaria. Sul percorso del programma i caratteri jolly non si possono usare.²³
• Il triage è nell’ordine Test-NetConnection → Get-NetFirewallRule → pfirewall.log. Il registro del firewall per default non viene scritto: esce solo quando si abilita la registrazione dei pacchetti scartati.⁴⁵⁶
• La disabilitazione globale fermando il servizio non è supportata. Sotto gestione GPO/Intune l’«unione dei criteri locali» può essere disabilitata, e in quel caso le regole locali non hanno effetto. Si fa richiesta ai sistemi informativi di distribuzione centralizzata delle regole.¹²

Mappa della conoscenza di questo articolo

Il predefinito del firewall di Windows è blocco in ingresso e consenso in uscita, e una regola in ingresso serve solo alle app aziendali di tipo server che si mettono in ascolto su una porta. Se un’app senza regola si mette in ascolto, viene mostrata la finestra di «avviso importante», ma a seconda dell’operazione può bruciarsi una regola di blocco e diventare causa di un guasto «non si comunica»: per principio le regole in ingresso si registrano dall’installer. Sotto gestione GPO/Intune l’unione dei criteri locali può essere disabilitata, e una regola registrata in locale può non essere applicata.

flowchart LR
    accTitle: Mappa della conoscenza del firewall di Windows e delle app aziendali
    accDescr: Diagramma che mostra le relazioni tra firewall di Windows, regole in ingresso, app in ascolto, finestra di «avviso importante», installer e privilegi di amministratore, restringimento delle regole (designazione per programma, limitazione dell'IP remoto), unione dei criteri locali, guasto «non si comunica» e comandi di triage
    windows_firewall["Firewall di Windows"]
    inbound_rule["Regola in ingresso"]
    listen_app["App aziendale in ascolto"]
    installer["Installer"]
    network_profile["Profilo di rete"]
    communication_failure["Guasto «non si comunica»"]
    firewall_notification["Finestra di «avviso importante»"]
    exe_path_change["Cambio del percorso del file eseguibile"]
    pfirewall_log["Registro del firewall (pfirewall.log)"]
    group_policy["Criteri di gruppo"]
    intune["Microsoft Intune"]
    local_policy_merge["Unione dei criteri locali"]
    mpssvc["Servizio firewall (MpsSvc)"]
    port_rule["Regola per porta"]
    over_permission["Consenso eccessivo della regola"]
    test_netconnection["Test-NetConnection"]
    get_netfirewallrule["Get-NetFirewallRule"]
    unsolicited_inbound["Comunicazione in ingresso non richiesta"]
    netsh_advfirewall["netsh advfirewall"]
    new_netfirewallrule["New-NetFirewallRule"]
    admin_rights["Privilegi di amministratore"]
    remote_ip_scope["Limitazione dell'IP remoto"]
    program_rule["Regola per programma"]
    mpssvc_stop["Arresto del servizio MpsSvc"]
    firewall_disable["Disabilitazione del firewall"]
    named_pipe["Named pipe"]
    smb_445["SMB (TCP 445)"]
    get_netconnectionprofile["Get-NetConnectionProfile"]
    block_rule["Regola di blocco"]
    notify_disable["Disabilitazione delle notifiche in ingresso"]
    service_rule["Regola per servizio"]
    profile_limit["Limitazione del profilo"]
    updater_reregistration["Nuova registrazione della regola all'aggiornamento"]
    netstat["netstat"]
    listen_app -->|"richiede"| inbound_rule
    installer -->|"consigliato per"| inbound_rule
    network_profile -.->|"può causare"| communication_failure
    firewall_notification -.->|"può causare"| communication_failure
    exe_path_change -.->|"può causare"| communication_failure
    communication_failure -->|"verificato da"| pfirewall_log
    windows_firewall -->|"configurato da"| group_policy
    windows_firewall -->|"configurato da"| intune
    inbound_rule -.->|"richiede"| local_policy_merge
    mpssvc -->|"implementa"| windows_firewall
    windows_firewall -->|"usa"| network_profile
    port_rule -.->|"può causare"| over_permission
    exe_path_change -.->|"può causare"| firewall_notification
    firewall_notification -->|"configurato da"| group_policy
    communication_failure -->|"verificato da"| test_netconnection
    communication_failure -->|"verificato da"| get_netfirewallrule
    windows_firewall -->|"previene"| unsolicited_inbound
    inbound_rule -->|"configurato da"| netsh_advfirewall
    inbound_rule -->|"configurato da"| new_netfirewallrule
    inbound_rule -->|"richiede"| admin_rights
    remote_ip_scope -->|"mitiga"| over_permission
    program_rule -->|"mitiga"| over_permission
    firewall_notification -->|"sconsigliato per"| inbound_rule
    mpssvc_stop -->|"sconsigliato per"| firewall_disable
    remote_ip_scope -->|"consigliato per"| over_permission
    program_rule -->|"consigliato per"| over_permission
    named_pipe -->|"usa"| smb_445
    network_profile -->|"verificato da"| get_netconnectionprofile
    firewall_notification -.->|"può causare"| block_rule
    block_rule -->|"può causare"| communication_failure
    notify_disable -->|"previene"| firewall_notification
    service_rule -->|"mitiga"| over_permission
    profile_limit -->|"mitiga"| over_permission
    updater_reregistration -->|"consigliato per"| exe_path_change
    communication_failure -->|"verificato da"| netstat

Nel diagramma, una linea continua indica una relazione che vale sempre e una linea tratteggiata indica una relazione condizionale (le condizioni sono nella spiegazione di ciascuna relazione nella pagina di dettaglio). L’elenco completo delle relazioni (in totale 35, con evidenza e livello di certezza) e le definizioni dei concetti principali sono raccolti nella pagina di dettaglio della mappa della conoscenza (in giapponese). Dati: JSON-LD / Turtle

2. Il comportamento predefinito, con precisione — In ingresso blocco predefinito, in uscita consenso predefinito

Per prima cosa fissiamo con precisione le fondamenta. Il firewall di Windows è un firewall host abilitato per default in tutte le edizioni, e il comportamento predefinito si esaurisce in queste due righe.¹

• In ingresso (inbound): tutto bloccato se non è una risposta a una richiesta (solicited) o non corrisponde a una regola
• In uscita (outbound): tutto consentito se non corrisponde a una regola

Da queste due righe esce il triage più importante per le app aziendali. Una regola in ingresso serve solo al «lato in ascolto».

• App client che si collega da sola a un server Web interno, a un server DB, a un sistema core → di regola, nessuna regola. Il pacchetto di ritorno della connessione è una «risposta a una richiesta», quindi passa per default.
• App di tipo server o servizi Windows che aprono una porta e attendono connessioni con TCP, gRPC, un protocollo proprio, ecc. → regola in ingresso obbligatoria.
• Una configurazione che usa named pipe da remoto è un’eccezione. Le named pipe remote non passano dalla porta dell’app stessa ma da SMB (TCP 445), quindi ciò che serve non è una regola dell’app ma una regola lato condivisione file (SMB).
• L’eccezione è un ambiente ad alta sicurezza in cui il predefinito in uscita è stato cambiato esplicitamente in blocco. Questa configurazione c’è solo in alcune organizzazioni, ma in quel caso anche un’app client ha bisogno di una richiesta di regola in uscita.²

flowchart TB
    accTitle: La regola in ingresso serve solo al lato in ascolto
    accDescr: Se ci si collega solo come client la regola in ingresso di regola non è necessaria, e se si apre una porta e si attende connessioni si registra la regola in ingresso dall'installer
    APP["Elencare le comunicazioni dell'app interna"] --> Q{"Apre una porta e<br/>attende connessioni?"}
    Q -- "Non è in ascolto<br/>(si collega solo come client)" --> C1["Regola in ingresso di regola non necessaria<br/>il ritorno della connessione passa come «risposta»"]
    Q -- "È in ascolto<br/>(tipo server, ricezione di callback)" --> S1["Regola in ingresso obbligatoria<br/>→ registrarla dall'installer (capitolo 5)"]
    C1 -.-> EX["Eccezione: in un ambiente ad alta sicurezza<br/>con blocco predefinito in uscita, richiedere una regola in uscita"]

Figura 1: Se una porta è in ascolto la regola in ingresso è obbligatoria; un collegamento solo come client di regola non la richiede.

Il caso in cui «un’app che dovrebbe essere client in realtà è anche in ascolto» (ricezione di callback di risultato, bocca di notifica da altri processi, ecc.) è facile da perdere. Se è ambiguo con quale modo di comunicazione la vostra app è in ascolto, per l’organizzazione in fase di progetto confermate anche «Come scegliere la comunicazione interprocesso».

2.1. Profili e «posizione della rete»

Le regole si applicano per profilo di rete. I profili sono tre.¹

Quale profilo è in applicazione si conferma con Get-NetConnectionProfile; il passaggio privato/pubblico si fa con Set-NetConnectionProfile.¹ L’incidente frequente in campo è che nell’ambiente workgroup del cliente la rete è giudicata «pubblica», e una regola in ingresso fatta solo per dominio/privato non è applicata. Quando «la regola c’è ma non passa», sospettate prima la corrispondenza del profilo, più che il contenuto della regola.

2.2. L’ordine di priorità delle regole

La valutazione quando le regole sono più d’una non è un elenco ordinato con pesi, ma si decide con questi principi coerenti.²

1. Una regola di consenso esplicita ha priorità sul blocco predefinito
2. Una regola di blocco esplicita ha priorità su una regola di consenso in conflitto
3. Nei limiti che non contraddicono i due punti sopra, ha priorità la regola più specifica

L’implicazione pratica è: «se da qualche parte c’è una regola di blocco, per quante regole di consenso aggiungiate dopo non vincete». Come si vede nel capitolo successivo, proprio questa regola di blocco è ciò che quella finestra crea in silenzio.

3. La vera natura della finestra di «avviso importante» — Perché non ci si può affidare

Quando un’app inizia per la prima volta l’ascolto (listen) su una porta, se non esiste né una regola di consenso per quell’app né una regola definita dall’amministratore, Windows mostra la familiare finestra «Avviso di sicurezza di Windows» che dice «alcune funzionalità di questa app sono bloccate da Windows Defender Firewall». La specifica del comportamento è chiara.²

• Se è mostrata a un utente con privilegi di amministratore: «Consenti accesso» crea una regola di consenso. Ma se si preme «Annulla», viene creata una regola di blocco. Di solito sono due, una per TCP e una per UDP.
• Se è mostrata a un utente senza privilegi di amministratore: qualunque scelta si faccia, viene creata una regola di blocco.
• In entrambi i casi, finché non si elimina la regola creata la finestra non ricompare più, e la comunicazione resta bloccata.

flowchart TB
    accTitle: Biforcazione della finestra di «avviso importante»
    accDescr: Se non c'è una regola e le notifiche in ingresso sono abilitate esce la finestra, e con Annulla o con l'operazione di un utente ordinario si crea una regola di blocco e la finestra non esce più
    L["L'app inizia l'ascolto sulla porta"] --> Q1{"Esiste una regola<br/>che corrisponde a quell'app?"}
    Q1 -- "sì" --> R1["Si segue la regola<br/>(la finestra non esce)"]
    Q1 -- "no" --> Q2{"Le notifiche in ingresso<br/>sono abilitate?"}
    Q2 -- "disabilitate" --> R2["Blocco in silenzio<br/>(non si crea una regola)"]
    Q2 -- "abilitate" --> DLG["Finestra di «avviso importante»"]
    DLG -- "l'amministratore preme «Consenti accesso»" --> OK["Viene creata una regola di consenso"]
    DLG -- "l'amministratore preme «Annulla»" --> NG1["Viene creata una regola di blocco"]
    DLG -- "utente senza privilegi di amministratore<br/>(qualunque operazione)" --> NG2["Viene creata una regola di blocco"]
    NG1 --> NEVER["Finché non si elimina la regola<br/>la finestra non esce più"]
    NG2 --> NEVER

Figura 2: Annullare la finestra o l’operazione di un utente senza privilegi crea una regola di blocco; finché non la si elimina la finestra non esce più.

Questa finestra, insomma, sembra «un meccanismo che chiede il consenso all’utente», ma nel cantiere delle app aziendali lavora come «un meccanismo che, nell’istante in cui un utente ordinario la tocca, brucia una regola di blocco». Se il responsabile dell’introduzione avvia la prima volta con un account amministratore e consente dalla finestra, la regola di consenso creata vale per l’intero PC, quindi anche gli utenti ordinari del giorno dopo per il momento comunicano. L’incidente resta però — quando un utente ordinario pesta per primo un ascolto che in verifica di introduzione non si era pestato, quando il profilo di rete applicato è diverso da quello di introduzione, e quando un aggiornamento cambia il percorso dell’exe (capitoli 4 e 5).

Microsoft stessa, per i dispositivi usati da chi non è amministratore, esplicita queste best practice.²

1. Collocare le regole necessarie prima del primo avvio dell’app (installer o distribuzione lato gestione)
2. Disabilitare le notifiche in ingresso (se si tagliano le notifiche, la creazione automatica di regole a runtime non avviene più)

La disabilitazione delle notifiche si imposta con Set-NetFirewallProfile -NotifyOnListen False o con i Criteri di gruppo.⁷ «Quando esce la finestra, fate premere Consenti alla persona in campo» non è una procedura operativa: è la prenotazione di un incidente. Le regole in ingresso si registrano in installazione — questa è la conclusione dell’articolo, e coincide con la raccomandazione di Microsoft.

4. Progettare le regole in ingresso — Designazione per programma, per porta, per servizio

Progettiamo il contenuto della regola da registrare. I modi di designazione sono in sostanza tre famiglie, e si decide se usarli da soli o combinarli.

Sopra a questo, si sovrappone la limitazione dell’ambito. Anche la raccomandazione di progetto di Microsoft è «le regole in ingresso il più specifiche possibile».²

• Limitazione del profilo: una regola in ingresso di un’app aziendale usata solo internamente si limita a dominio/privato e non la si abilita sul pubblico. Si evita l’incidente in cui, nell’istante in cui un portatile si collega a un Wi-Fi esterno, la porta in ascolto si apre al mondo.
• Limitazione dell’IP remoto: se la sorgente della connessione è decisa, si restringe -RemoteAddress a quella subnet. Per reti domestiche e di piccola scala è raccomandata la limitazione con la parola chiave LocalSubnet.²³
• Direzione e numero: se l’ascolto è solo TCP, basta una regola TCP. Non create per inerzia regole sia TCP sia UDP come quelle che la finestra crea in automatico.

«Solo dal destinatario necessario, solo verso la porta necessaria, solo il programma necessario» — la progettazione delle regole in ingresso si esaurisce in questa frase di privilegio minimo.

5. La pratica della registrazione dall’installer — netsh e New-NetFirewallRule

5.1. Premessa: servono i privilegi di amministratore

Aggiungere e eliminare regole del firewall è un cambio di impostazione dell’intero computer, quindi va eseguito con privilegi di amministratore (processo elevato).⁸ Un installer di solito gira già con privilegi di amministratore, quindi è ragionevole mettere la registrazione della regola nel trattamento di installazione. Non è un motivo per far girare il corpo dell’app come amministratore. Questo modo di tracciare la linea è trattato in dettaglio in «Quando servono i privilegi di amministratore».

5.2. Registrazione con netsh advfirewall

Classico, ma facile da chiamare da qualunque installer, è netsh advfirewall firewall add rule.⁸

rem add rule accoda anche se esiste già una regola omonima, quindi in vista di
rem reinstallazione, riparazione e aggiornamento si elimina la regola omonima e poi si registra di nuovo
netsh advfirewall firewall delete rule name="MyCompany OrderServer"

rem Regola di consenso in ingresso con designazione per programma + porta + limitazione di profilo
netsh advfirewall firewall add rule name="MyCompany OrderServer" dir=in action=allow program="C:\Program Files\MyCompany\OrderServer\OrderServer.exe" protocol=TCP localport=50051 profile=domain enable=yes

rem In disinstallazione: eliminazione per nome
netsh advfirewall firewall delete rule name="MyCompany OrderServer"

add rule non sostituisce una regola omonima esistente ma la aggiunge omonima, quindi se non eseguite prima delete rule a ogni riesecuzione le regole proliferano, e dopo un aggiornamento che ha cambiato percorso o ambito sopravvive la vecchia regola di consenso (alla prima esecuzione, il delete rule in testa risponde che «non c’è una regola corrispondente», ma l’esecuzione del batch continua, quindi questa sequenza va bene. Se l’installer giudica il successo con il codice di uscita, guardate il risultato dell’add rule in coda). Si può restringere anche la sorgente, come remoteip=157.60.0.1,172.16.0.0/16,LocalSubnet.⁸ L’eliminazione cancella insieme le regole che corrispondono per nome, quindi rendere univoco il nome della regola con un prefisso aziendale è il modo sicuro.

5.3. Registrazione con PowerShell (New-NetFirewallRule)

Per un controllo più fine, il modulo NetSecurity. -DisplayName è obbligatorio, -Profile accetta più valori separati da virgola (senza spazi).³

# Registrazione (eseguire dall'installer in stato elevato). -Name è un identificatore univoco,
# quindi in reinstallazione, riparazione e aggiornamento la creazione di una regola omonima
# va in errore. Si rende idempotente eliminando la regola omonima esistente e poi ricreandola
Remove-NetFirewallRule -Name "MyCompany-OrderServer-In" -ErrorAction SilentlyContinue
New-NetFirewallRule -Name "MyCompany-OrderServer-In" `
    -DisplayName "MyCompany OrderServer (TCP 50051 in ingresso)" `
    -Direction Inbound -Action Allow `
    -Program "C:\Program Files\MyCompany\OrderServer\OrderServer.exe" `
    -Protocol TCP -LocalPort 50051 `
    -Profile Domain,Private -RemoteAddress LocalSubnet

# In disinstallazione: non andare in errore se non esiste
Remove-NetFirewallRule -Name "MyCompany-OrderServer-In" -ErrorAction SilentlyContinue

C’è un motivo per esplicitare -Name. -Name è l’identificatore univoco della regola; se lo omettete viene assegnato un valore casuale. Il nome visualizzato (-DisplayName) può cambiare a seconda delle impostazioni locali, quindi la chiave con cui uno script identifica la regola è -Name, come indica Microsoft.³ Anche perché il disinstaller elimini con certezza solo la propria regola, considerate obbligatorio fissare -Name.

5.4. Quando un aggiornamento cambia il percorso dell’exe

Una regola con designazione per programma fissa il bersaglio con il percorso completo. Quindi, se un aggiornamento cambia la cartella di installazione o il nome dell’exe, la regola resta ma perde il bersaglio, e l’ascolto torna a essere bloccato. In quel momento, l’exe del nuovo percorso è trattato come «app senza regola», quindi in un ambiente in cui le notifiche sono abilitate la finestra del capitolo 3 ricompare, e se un utente ordinario la tocca si brucia una regola di blocco. In un ambiente in cui, come raccomandato nel capitolo 3, le notifiche sono disabilitate, fallisce in silenzio senza nemmeno la finestra. È un incidente particolarmente facile in un modo di collocare in una cartella con numero di versione, o in un modo in cui l’auto-aggiornamento muove il posto di collocare.

flowchart TB
    accTitle: Se un aggiornamento cambia il percorso dell'exe la regola perde il bersaglio
    accDescr: Una regola con designazione per programma fissa il percorso completo, quindi se cambia il posto di collocare perde il bersaglio, e a seconda delle notifiche la finestra ricompare o si blocca in silenzio
    V1["Si introduce v1.0<br/>la regola punta all'exe della cartella v1.0"] --> UP["L'aggiornamento colloca in una cartella v1.1<br/>il percorso dell'exe eseguito cambia"]
    UP --> MISS["La regola del vecchio percorso perde il bersaglio<br/>(la regola resta ma non ha effetto)"]
    MISS --> Q{"Le notifiche in ingresso<br/>sono abilitate?"}
    Q -- "abilitate" --> DLG["La finestra ricompare<br/>se un utente ordinario la tocca, regola di blocco"]
    Q -- "disabilitate" --> SILENT["Senza nemmeno la finestra<br/>blocco in silenzio"]
    MISS -.->|"contromisura"| FIX["Fissare il percorso attraverso gli aggiornamenti<br/>oppure nel trattamento di aggiornamento eliminare la vecchia regola e registrarla di nuovo"]

Figura 3: Se un aggiornamento cambia il percorso dell’exe la vecchia regola perde il bersaglio; fissate il percorso o registratela di nuovo all’aggiornamento.

La contromisura è semplice, e è una di queste.

• Fissare la cartella di installazione e fare in modo che il percorso completo dell’exe non cambi attraverso gli aggiornamenti
• In un aggiornamento che cambia il percorso, far sì che l’updater elimini la vecchia regola e la registri di nuovo con il nuovo percorso (eseguire i comandi di 5.2/5.3 anche nel trattamento di aggiornamento)

Con MSI, la registrazione della regola si incorpora come custom action eseguita dopo il collocare dei file (in disinstallazione, la custom action lato eliminazione): è la prassi. Toolset come WiX hanno anche estensioni che descrivono in modo dichiarativo le regole del firewall. Il posto di implementazione cambia a seconda del modo di distribuzione scelto, quindi si veda anche «Scegliere un metodo di distribuzione per app Windows». Un altro incidente classico in distribuzione dal cliente, i falsi positivi dell’antivirus, è trattato in «Gestire i falsi positivi di Microsoft Defender».

6. Risoluzione dei problemi — Il flusso di triage di «non si comunica»

Fissiamo in ordine la procedura quando arriva una richiesta. Il flusso complessivo è il seguente.

flowchart TB
    accTitle: Triage di «non si comunica»
    accDescr: Si confermano in ordine l'ascolto del server, la raggiungibilità del client, la corrispondenza del profilo, le regole di ActiveStore e i DROP nel registro
    S["«Dal client non si comunica»"] --> N["Lato server: netstat -ano"]
    N -- "non è in ascolto" --> APP["Problema precedente al firewall<br/>indagare lato app o servizio"]
    N -- "è LISTENING" --> T["Lato client: Test-NetConnection"]
    T -- "TcpTestSucceeded=True" --> OTHER["La raggiungibilità è normale<br/>indagare lo strato app (autenticazione, protocollo)"]
    T -- "False" --> P["Lato server: Get-NetConnectionProfile<br/>confermare il profilo in applicazione"]
    P -- "non corrisponde al bersaglio della regola" --> FIXP["Rivedere la designazione di profilo della regola"]
    P -- "corrisponde" --> R["Get-NetFirewallRule -PolicyStore ActiveStore<br/>confermare presenza di regole di consenso e mescolanza di regole di blocco"]
    R --> LOGCHK["Misurare gli scarti (DROP) in pfirewall.log"]

Figura 4: Isolamento meccanico: netstat → Test-NetConnection → profilo → regole di ActiveStore → pfirewall.log.

Una nota al passo 4. Le condizioni di porta e programma non stanno sul corpo della regola ma sull’oggetto filtro, quindi per risalire dalla porta alla regola si interroga via filtro.⁵⁷

# Risalire alle regole relative alla porta 50051
Get-NetFirewallPortFilter | Where-Object { $_.LocalPort -eq 50051 } | Get-NetFirewallRule

# Tracciare la provenienza della regola (locale o GPO)
Get-NetFirewallRule -PolicyStore ActiveStore -TracePolicyStore |
    Select-Object Name, DisplayName, PolicyStoreSourceType, PolicyStoreSource

Il registro del firewall del passo 5 (pfirewall.log) per default non registra nulla. Il percorso predefinito è %windir%\system32\logfiles\firewall\pfirewall.log, la dimensione massima predefinita è 4.096 KB, e viene scritto solo quando si abilita «Registra i pacchetti scartati» o «Registra le connessioni riuscite».⁶ Su una macchina singola si abilita così.⁶

netsh advfirewall set allprofiles logging droppedconnections enable
netsh advfirewall set allprofiles logging allowedconnections enable

Il registro è un file di testo: per ogni riga si registra se è scarto (DROP) o consenso (ALLOW), protocollo, IP e porta di sorgente/destinazione, quindi qui si chiude se il SYN dal client è arrivato e è stato scartato, o se non è nemmeno arrivato. In un ambiente in cui il registro è configurato per policy, può succedere che il file non si crei per mancanza di permesso di scrittura sulla cartella del registro (FullControl del servizio mpssvc); in quel caso servono la creazione della cartella e la concessione ACL.⁶

Per scavare ancora, abilitando il criterio di controllo «Scarto pacchetti della piattaforma di filtro» si registra l’evento di sicurezza 5152 a ogni scarto. La quantità di eventi è però enorme, e Microsoft raccomanda di usare l’evento 5157 (connessione della piattaforma di filtro), registrato per connessione. Non è uno strumento da uso quotidiano: lo si abilita solo per il tempo del triage.⁹

Infine, chiariamo il triage da non fare. La disabilitazione in blocco fermando il servizio del firewall (MpsSvc) non è supportata e provoca problemi lato sistema operativo, come il menu Start che non funziona o l’aggiornamento delle app dello Store che fallisce. Se proprio volete disabilitare per verificare, lasciate il servizio in esecuzione, disabilitate i profili con Set-NetFirewallProfile -Profile Domain,Public,Private -Enabled False e appena confermato tornate indietro.¹⁷ E una volta chiuso che la causa è il firewall, la correzione non è rendere permanente la disabilitazione ma aggiungere una regola corretta.

7. Punti di attenzione sotto gestione organizzativa — Ambienti in cui le regole locali non hanno effetto, e il modo di fare richiesta

Anche se registrate la regola dall’installer, ci sono ambienti in cui non ha effetto. Nelle organizzazioni che gestiscono il firewall in modo centralizzato con GPO o Intune (CSP), si può disabilitare per profilo l’«unione dei criteri locali» (AllowLocalPolicyMerge). Se questa impostazione è disabilitata, una regola creata da un amministratore locale (installer compreso) non viene applicata, e le regole delle app che hanno bisogno di connessioni in ingresso devono essere distribuite in modo centralizzato da GPO/CSP.²

flowchart TB
    accTitle: Se l'unione dei criteri locali è disabilitata la registrazione dell'installer non ha effetto
    accDescr: In un ambiente in cui AllowLocalPolicyMerge è disabilitata la regola locale esiste ma non viene applicata, e si passa alla distribuzione centralizzata con GPO o CSP
    GPOR["Regole distribuite con GPO/Intune"] --> EFF["Insieme delle regole che hanno davvero effetto<br/>(ActiveStore)"]
    LOCAL["Regole create in locale<br/>(inclusa la registrazione dell'installer)"] --> Q{"Unione dei criteri locali<br/>(AllowLocalPolicyMerge)"}
    Q -- "abilitata (predefinito)" --> EFF
    Q -- "disabilitata" --> DROP["La regola esiste ma non viene applicata<br/>→ passare alla distribuzione centralizzata con GPO/CSP"]

Figura 5: Se l’unione dei criteri locali è disabilitata le regole dell’installer non si applicano; serve la distribuzione centralizzata con GPO/CSP.

La preparazione realistica lato sviluppo e lato introduzione è la seguente.

• La registrazione della regola dell’installer va progettata perché «non fallisca» (la registrazione in sé riesce, quindi non si rileva con un errore. Includete nella procedura una conferma di comunicazione dopo l’introduzione)
• Con il passo 4 del capitolo 6 (-TracePolicyStore) confermate se la provenienza della regola che ha effetto è locale o GPO⁵
• Se capite che le regole locali non hanno effetto, passate alla richiesta di distribuzione della regola al reparto sistemi informativi

Nella richiesta consegnate insieme le informazioni seguenti. Una regola del firewall si può creare solo quando direzione, programma, porta e ambito sono allineati, quindi questa tabella diventa così com’è la «specifica di rete dell’app aziendale».

Anche dal lato sistemi informativi, la quantità di lavoro tra una richiesta con questa tabella e una senza è del tutto diversa. Al contrario, un «aprite, per favore» solo con il numero di porta tende, come si è visto nel capitolo 4, a un consenso eccessivo. I requisiti di comunicazione intorno a condivisione file e autenticazione in un ambiente di dominio stanno cambiando anche per un’altra stretta, distinta dal firewall (obbligo di firma ecc.). Si veda insieme «SMB signing e LDAP channel binding».

8. Conclusione

• Il predefinito del firewall di Windows è blocco in ingresso e consenso in uscita. Una regola in ingresso serve solo alle app di tipo server in ascolto; se ci si collega solo come client, di regola non serve.
• Le regole si applicano per profilo (dominio / privato / pubblico). Il primo sospettato di «la regola c’è ma non passa» è la mancata corrispondenza del profilo.
• La finestra di «avviso importante», con Annulla o con l’operazione di un utente senza privilegi, crea una regola di blocco e da allora non ricompare. Non affidate l’operazione di produzione a questa finestra.
• Le regole in ingresso delle app aziendali si registrano dall’installer — questo è l’unico principio. La registrazione è con privilegi di amministratore, e si implementa fissando -Name fino all’eliminazione.
• Le regole si restringono con asse programma + protocollo + porta, profilo e IP remoto. Se un aggiornamento cambia il percorso dell’exe, non dimenticate di registrare di nuovo la regola.
• Il triage è meccanico, nell’ordine netstat → Test-NetConnection → conferma del profilo → Get-NetFirewallRule (ActiveStore) → pfirewall.log. La disabilitazione fermando il servizio non è supportata.
• Sotto gestione GPO/Intune l’unione dei criteri locali può essere disabilitata. In quel caso si fa richiesta di distribuzione ai sistemi informativi, allineando nome della regola, direzione, programma, porta, IP remoto e profilo.

Articoli correlati

• Come scegliere la comunicazione interprocesso su Windows — Tabella di decisione per named pipe / TCP / gRPC / memoria condivisa / COM
• Scegliere un metodo di distribuzione per app Windows - MSI/MSIX/ClickOnce/xcopy/Updater personalizzato
• Quando servono davvero i privilegi di amministratore su Windows? - UAC, aree protette e come distinguerlo in progettazione
• Se l’app Windows sviluppata internamente viene trattata come virus — Gestire i falsi positivi di Microsoft Defender e convivere con l’impatto sulle prestazioni
• SMB signing e LDAP channel binding — Chiudere in pratica l’«altra metà» delle difese NTLM
• Come creare e gestire i servizi Windows — Dalla scelta tra Task Scheduler e servizi fino a trasformare un BackgroundService in un servizio

Aree di consulenza correlate

KomuraSoft LLC si occupa della progettazione dell’installer di app aziendali di tipo server (inclusa la registrazione e l’eliminazione delle regole del firewall), dell’indagine della causa di «non si comunica» nell’ambiente del cliente, e dell’organizzazione dei requisiti di rete in vista della distribuzione sotto gestione GPO. Si può partire dal triage di «sulla macchina di sviluppo funziona, dal cliente no».

• Sviluppo di applicazioni Windows
• Analisi dei bug e delle cause
• Consulenza tecnica e revisione del progetto
• Contattaci

Riferimenti

Articoli correlati

Articoli recenti con gli stessi tag per approfondire argomenti vicini.

Argomenti correlati

Queste pagine collocano l’argomento in un contesto più ampio di servizi e decisioni.

Servizi collegati all’argomento

L’articolo è direttamente collegato ai servizi seguenti.

Domande frequenti

Domande che ricorrono nelle consulenze sull’argomento dell’articolo.

Un'app che si collega al server solo come client ha bisogno di una regola del firewall?

Di regola no. Il predefinito del firewall di Windows è «blocca in ingresso, consenti in uscita», quindi un'app client che avvia solo connessioni verso l'esterno comunica bene con i predefiniti. Una regola in ingresso serve solo al lato che apre una porta e attende le connessioni — cioè alle app di tipo server. Ci sono però due eccezioni. Negli ambienti ad alta sicurezza anche il predefinito in uscita può essere stato cambiato in blocco, e in quel caso serve anche una richiesta di regola in uscita. E anche un'app «client», se è progettata per mettersi in ascolto su una porta per ricevere notifiche di risultato, ha bisogno di una regola in ingresso per quella parte.

Non basta premere «Consenti accesso» sulla finestra «Avviso di sicurezza di Windows»?

In quel momento sì, ma non ci si può affidare per l'operazione di produzione. Se un utente con privilegi di amministratore annulla questa finestra, viene creata una regola di blocco. Peggio: se l'utente non ha privilegi di amministratore, una regola di blocco viene creata qualunque pulsante si prema. Finché non si elimina la regola creata, la finestra non ricompare più e la comunicazione continua a fallire. Nelle app aziendali in cui chi opera sul PC in campo è un utente ordinario, è banale finire in uno stato in cui «qualcuno ha annullato una volta, e da allora non si collega più». Microsoft stessa raccomanda di collocare la regola prima del primo avvio dell'app, proprio per evitarlo.

Una regola in ingresso va costruita intorno alla porta o intorno al programma?

La base è combinarle, non usarle da sole. La designazione per programma restringe il bersaglio con il percorso completo dell'exe, ma se un aggiornamento cambia il percorso la regola perde il bersaglio (i caratteri jolly non si possono usare). La designazione per porta rende chiara la richiesta ai sistemi informativi, ma fa passare anche un altro processo in ascolto sulla stessa porta. Nelle app aziendali di produzione l'asse è «programma + protocollo + porta», si limita il profilo a dominio/privato e si restringe l'IP remoto alla subnet in cui stanno i client: è il modello del privilegio minimo. La designazione per programma da sola si usa solo se la porta è dinamica.

La regola registrata dall'installer sul PC del cliente sembra non avere effetto. Perché?

È molto probabile che il firewall del cliente sia gestito in modo centralizzato con GPO o Intune, e che l'«unione dei criteri locali» (AllowLocalPolicyMerge) sia disabilitata. Se questa impostazione è disabilitata, una regola creata in locale esiste sul profilo ma non viene applicata, e non resta che distribuire la regola in modo centralizzato dal lato GPO/CSP. Confermate l'insieme delle regole effettive con Get-NetFirewallRule -PolicyStore ActiveStore e fate richiesta di distribuzione della regola al reparto sistemi informativi. Se nella richiesta consegnate insieme nome della regola, direzione, percorso del programma, protocollo e porta, intervallo IP remoto e profilo, passa al primo colpo.

Per il triage della comunicazione, si può disabilitare temporaneamente il firewall?

Evitate assolutamente la disabilitazione fermando il servizio (MpsSvc). È un'operazione non supportata da Microsoft e provoca problemi lato sistema operativo, come il menu Start che non funziona o l'aggiornamento delle app dello Store che fallisce. Se proprio volete disabilitare per il triage, il modo corretto è lasciare il servizio in esecuzione e disabilitare i profili con Set-NetFirewallProfile -Enabled False. Limitate però anche questo all'uso di verificare in pochi minuti se la causa è il firewall, e appena confermato tornate indietro. Lasciare disabilitato in operazione è scambiare un problema che si risolve aggiungendo una regola con l'indifesa dell'intero PC.

Profilo dell’autore

Pagina di presentazione dell’autore dell’articolo.

Go Komura

Rappresentante di KomuraSoft LLC

Specializzato nello sviluppo di software Windows, nella consulenza tecnica e nell’analisi dei malfunzionamenti, soprattutto nei progetti con sistemi esistenti e guasti difficili da riprodurre.