Aggiungere una regola di autorizzazione RDP non restringe l'accesso VPN

Il piano sembra ragionevole: lascia com'è l'autorizzazione esistente per Desktop remoto e aggiungine una piccola per l'unico client VPN che dovrebbe avere accesso. Il firewall di Windows non funziona così. Le regole non sono un elenco ordinato in cui vince la voce più specifica, e un'autorizzazione stretta accanto a una ampia non cambia nulla, perché quella ampia ammette ancora tutti quelli che già ammetteva. Restringere il servizio significa modificare l'autorizzazione che sta già facendo il lavoro.

La regola che aggiungi non è la regola che conta

Il firewall di Windows valuta tutte le regole in ingresso applicabili negli archivi di criteri che valgono per la macchina, poi decide se qualche autorizzazione corrisponde e se qualche blocco la supera. Aggiungere una regola aggiunge un'autorizzazione; non rimuove né precisa le autorizzazioni già presenti.

Quindi la domanda non è mai cosa hai aggiunto. È cosa contiene il criterio effettivo dopo che criterio locale, criterio di dominio e valori predefiniti del profilo sono stati uniti. Una workstation con una sola regola locale è facile da ragionare; un server unito a un dominio no.

È anche per questo che un amministratore può fare una modifica che sembra corretta, provarla dalla macchina sbagliata e concludere che ha funzionato. L'origine esclusa non è mai stata provata. Un test che dimostra solo il successo dimostra meno della metà di ciò per cui la modifica era stata fatta.

Scopri quale indirizzo vede il server

Prima di delimitare qualcosa, osserva una sessione consentita sull'host Windows e annota l'indirizzo di origine che il server riporta. Non è sempre l'indirizzo che il client crede di avere.

Se il gateway VPN conserva gli indirizzi dei client, il server vede l'indirizzo del tunnel del client e una regola limitata per indirizzo ha senso. Se il gateway traduce, ogni client arriva come l'indirizzo del gateway, e limitare a quell'indirizzo dà accesso a ogni client dietro di esso. Allora la regola è precisa sulla cosa sbagliata.

Questi due progetti richiedono risposte diverse. Il primo può essere espresso in una regola del firewall; il secondo va applicato dove l'identità esiste ancora, cioè nella VPN stessa o in un gateway autenticato davanti al servizio.

Un filtro del firewall non può recuperare un'identità che la traduzione di rete ha scartato, per quanto l'indirizzo sia stato digitato con cura.

Cambia il proprietario della regola effettiva

Ispeziona il criterio in ingresso effettivo e trova ogni regola che attualmente ammette traffico RDP, comprese le regole il cui nome visualizzato non menziona mai la porta 3389. Contano anche le regole limitate per servizio e per applicazione, e così il trasporto UDP che alcune distribuzioni RDP abilitano.

Poi modifica le regole esistenti tramite l'archivio che le possiede. Una modifica locale a una regola che anche il criterio di dominio definisce può essere unita, ignorata o sovrascritta, e vale la pena sapere quale di queste cose accade prima di fidarsi.

Questi comandi trovano le regole attive, mostrano il filtro degli indirizzi associato a una di esse e visualizzano in anteprima un cambio di ambito:

Get-NetFirewallRule -PolicyStore ActiveStore -Direction Inbound | Where-Object DisplayName -match RDP
Get-NetFirewallAddressFilter -AssociatedNetFirewallRule (Get-NetFirewallRule -Name Reviewed-RDP-TCP)
Set-NetFirewallRule -Name Reviewed-RDP-TCP -RemoteAddress 10.63.4.17 -WhatIf

I nomi delle regole qui sono segnaposto per ciò che la revisione ha trovato, e il flag di anteprima esiste perché un errore di battitura in un indirizzo non ti chiuda fuori dal server che stai modificando.

Blocca e poi consenti è un modello diverso

L'abitudine di altri firewall è scrivere un blocco ampio e poi un'autorizzazione stretta sopra di esso. In Windows un blocco esplicito generalmente prevale su un'autorizzazione, quindi quell'ordine produce un servizio che nessuno può raggiungere invece di un'eccezione per un client. Il risultato è un'interruzione che sembra un servizio RDP rotto. In realtà è un errore di precedenza, e la correzione è rimuovere il blocco invece di aggiungere un'altra autorizzazione.

Mantieni il comportamento predefinito di blocco in ingresso sui profili attivi e restringi invece le autorizzazioni specifiche. Questo lascia la macchina con una postura comprensibile invece di due regole contraddittorie la cui interazione dipende da dettagli di precedenza.

Dimostralo con una seconda origine

Prova dal client consentito e da un'origine che ora dovrebbe fallire. Una sola connessione riuscita dimostra solo che il percorso consentito funziona; non dice nulla sull'esclusione che hai appena fatto.

Ripeti il test su IPv6 se il server lo ha abilitato, perché un'intenzione solo IPv4 può convivere con un'autorizzazione IPv6 ampia che nessuno ha guardato.

Infine, tieni l'autenticazione separata dalla raggiungibilità. L'autenticazione a livello di rete, i diritti dell'account e le restrizioni di accesso decidono ancora chi può usare la sessione, e il firewall decide solo chi può chiedere. Rimuovere un dispositivo in seguito dovrebbe rimuovere sia la sua registrazione VPN sia questa autorizzazione di rete, altrimenti l'indirizzo che hai delimitato apparterrà un giorno a qualcun altro.