Profili del firewall e uscita VPN: perché pubblico non è un percorso

La regola sembra precisa: consentire il traffico locale sul profilo privato e solo il traffico VPN su quello pubblico. Non lo è, perché un profilo di rete sceglie quale insieme di regole del firewall si applica e non dice nulla su quale adattatore ha trasportato un pacchetto. Trattare il nome del profilo come un requisito di percorso è l'errore che fa sembrare finita una progettazione di uscita ristretta quando non lo è.

Annotate prima i flussi, poi decidete quale meccanismo può davvero imporre ciascuno di essi. Quell'elenco dei flussi è l'unico artefatto che sopravvive al prossimo cambio di regole.

La categoria sceglie le regole, non i percorsi

Quando Windows classifica una rete come pubblica o privata, il firewall applica l'insieme di regole configurato per quel profilo. La classificazione segue la rete a cui si è unito l'adattatore, e l'insieme di regole decide che cosa è consentito su di essa. Nessuno di questi fatti dipende dall'uso del tunnel da parte del traffico di un'applicazione. Proprio questa indipendenza è tutta la difficoltà.

La scelta del percorso spetta all'instradamento, tramite la metrica dell'interfaccia e il prefisso che il tunnel installa. Un profilo può quindi essere etichettato come pubblico mentre la connessione di un'applicazione prende il percorso fisico, e il firewall segnalerà comunque che è stato applicato l'insieme di regole pubblico.

Per questo una regola limitata al profilo non può significare solo tunnel. Le due proprietà sono decise da componenti diversi e l'una non può sostituire l'altra.

Un blocco esplicito prevale su un permesso più ristretto

Le linee guida di Microsoft sulle regole del firewall distinguono un permesso come eccezione a un'azione di blocco predefinita da un blocco esplicito che entra in conflitto con un permesso. I blocchi espliciti vincono quel conflitto, e le regole in uscita obbediscono alla stessa precedenza.

Quindi la ricetta popolare di aggiungere una regola che blocca tutto e affidarsi a un permesso più ristretto posto sopra non fa ciò che il suo autore si aspetta. Il Firewall di Windows non risolve il conflitto con l'ordine delle regole assegnato dall'amministratore. Il blocco si applica semplicemente, e l'applicazione che si connette segnala un timeout. La regola che sembrava l'eccezione non è mai stata in gioco.

La forma supportata è una politica di rifiuto predefinita con regole di permesso approvate, in cui ogni permesso nomina un programma, un servizio o una destinazione con precisione sufficiente per essere riesaminato. Quella progettazione supera un audit, perché ogni eccezione è visibile e nessuna dipende dall'ordine in cui è stata creata.

Due regole che si contraddicono sono peggio di una sola regola, perché il comportamento risultante è corretto e inspiegabile allo stesso tempo.

Date alla politica in uscita un solo proprietario

Un client VPN supportato mantiene già il proprio comportamento di blocco e le proprie eccezioni di endpoint. Aggiungere regole manuali non coordinate può lasciare quel client fuori dal tunnel che gli serve per la configurazione, o lasciare aperto un secondo percorso che nessuno ha notato.

Decidete chi possiede la politica in uscita prima di scrivere regole: la configurazione del client stesso, una politica del firewall gestita o un elenco locale di eccezioni documentato con un proprietario. Poi riconciliate gli strati invece di impilare esperimenti finché qualcosa si connette. Un proprietario con nome è anche la persona a cui si chiede quando due strati non sono d'accordo.

Preservate un canale di ripristino prima di cambiare qualcosa. Una macchina remota bloccata fuori dal proprio percorso di gestione è un esito peggiore del vuoto di politica che stavate chiudendo. La regola di ripristino è più facile da giustificare quando è scritta in anticipo, e più facile da trovare quando un cambiamento va storto a un'ora che nessuno apprezza.

Provate quattro esiti invece di leggere l'etichetta

Una politica vale quanto i casi che distingue, quindi trattate l'etichetta del profilo come un punto di partenza e non come un risultato. Quattro esiti vi dicono se funziona: la richiesta LAN prevista riesce, una richiesta internet coperta riesce, una richiesta diretta vietata fallisce, e il caso di guasto del tunnel si comporta come progettato invece di ripiegare in silenzio. Annotate i quattro risultati accanto al cambio di regole. Un piano di test con quattro casi nominati è abbastanza breve da eseguirlo ogni volta e abbastanza specifico da fallire rumorosamente.

Get-NetConnectionProfile | Select-Object Name,NetworkCategory,InterfaceAlias
Get-NetFirewallProfile | Select-Object Name,DefaultOutboundAction
Get-NetFirewallRule -Direction Outbound -Enabled True | Where-Object Action -eq Block |
  Select-Object DisplayName,Profile

Il primo comando mostra come è classificata ogni rete connessa, che spesso non è ciò che supponeva la persona che ha scritto la regola. Il secondo mostra l'azione predefinita per profilo, e il terzo elenca i blocchi in uscita abilitati, compresi quelli che annulleranno silenziosamente un permesso più ristretto.

Eseguite di nuovo i quattro casi dopo un cambio di rete, perché un profilo può essere riclassificato quando la macchina si unisce a un'altra rete. Un'etichetta di profilo corrispondente non è prova che il percorso fosse quello che intendevate.