Az RDP-engedélyezési szabály hozzáadása nem szűkíti a VPN-hozzáférést

A terv ésszerűnek hangzik: hagyja a meglévő Távoli asztal engedélyt úgy, ahogy van, és adjon hozzá egy kicsit az egyetlen VPN-ügyfélnek, amelynek hozzáféréssel kell rendelkeznie. A Windows tűzfala nem így működik. A szabályok nem rendezett lista, amelyben a legkonkrétabb bejegyzés nyer, és egy szűk engedély a széles mellett semmit sem változtat, mert a széles továbbra is beenged mindenkit, akit eddig beengedett. A szolgáltatás szűkítése azt jelenti, hogy azt az engedélyt kell szerkeszteni, amely már végzi a munkát.

A hozzáadott szabály nem az a szabály, amely számít

A Windows tűzfala kiértékeli az összes alkalmazható bejövő szabályt a géphez tartozó házirend-tárolókban, majd eldönti, hogy illeszkedik-e valamelyik engedély, és felülírja-e valamelyik blokk. Egy szabály hozzáadása engedélyt ad hozzá; nem távolítja el és nem pontosítja a már meglévő engedélyeket.

A kérdés tehát soha nem az, mit adott hozzá. Hanem az, mit tartalmaz a tényleges házirend a helyi házirend, a tartományi házirend és a profil alapértékeinek összevonása után. Egy helyi szabállyal rendelkező munkaállomást könnyű átgondolni; egy tartományhoz csatlakozó kiszolgálót nem.

Ezért fordulhat elő, hogy egy rendszergazda helyesnek látszó változtatást végez, rossz gépről teszteli, és arra jut, hogy működött. A kizárt forrást soha nem tesztelték. Az a teszt, amely csak a sikert bizonyítja, kevesebb mint a felét bizonyítja annak, amiért a változtatás történt.

Derítse ki, melyik címet látja a kiszolgáló

Mielőtt bármit behatárolna, figyeljen meg egy engedélyezett munkamenetet a Windows-gazdagépen, és jegyezze fel a forrás címet, amelyet a kiszolgáló jelent. Ez nem mindig az a cím, amelyet az ügyfél hisz magáénak.

Ha a VPN-átjáró megőrzi az ügyfélcímeket, a kiszolgáló az ügyfél alagút-címét látja, és a címhez kötött szabály értelmes. Ha az átjáró fordít, minden ügyfél az átjáró címeként érkezik, és az adott címre szűkítés minden mögötte lévő ügyfélnek hozzáférést ad. Akkor a szabály a rossz dologra pontos.

Ez a két terv különböző válaszokat igényel. Az első kifejezhető tűzfalszabályban; a másodikat ott kell kikényszeríteni, ahol az identitás még létezik, azaz magában a VPN-ben vagy a szolgáltatás előtti hitelesített átjáróban.

A tűzfalszűrő nem tudja visszaszerezni azt az identitást, amelyet a hálózati fordítás eldobott, akármilyen gondosan írták be a címet.

Módosítsa a tényleges szabály tulajdonosát

Vizsgálja meg a tényleges bejövő házirendet, és keresse meg az összes szabályt, amely jelenleg engedi az RDP-forgalmat, beleértve azokat is, amelyek megjelenített neve soha nem említi a 3389-es portot. A szolgáltatáshoz és alkalmazáshoz kötött szabályok is számítanak, valamint az UDP-szállítás, amelyet egyes RDP-telepítések engedélyeznek.

Ezután szerkessze a meglévő szabályokat azon tárolón keresztül, amely birtokolja őket. Egy olyan szabály helyi módosítása, amelyet a tartományi házirend is meghatároz, összevonható, figyelmen kívül hagyható vagy felülírható, és érdemes tudni, melyik történik, mielőtt támaszkodna rá.

Ezek a parancsok megtalálják az aktív szabályokat, megmutatják az egyikhez kapcsolt címfiltert, és előnézetben megjelenítik a hatókör módosítását:

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

A szabálynevek itt helyőrzők arra, amit a felülvizsgálat talált, és az előnézeti jelző azért van, hogy egy címben lévő elírás ne zárja ki a szerkesztett kiszolgálóról.

Először blokkolni, aztán engedélyezni más modell

A többi tűzfal szokása, hogy széles blokkot írnak, majd föléje szűk engedélyt. A Windowsban a kifejezett blokk általában felülkerekedik az engedélyen, így ez a sorrend olyan szolgáltatást hoz létre, amelyet senki nem ér el, nem pedig kivételt egy ügyfélnek. Az eredmény egy kiesés, amely törött RDP-szolgáltatásnak látszik. Valójában prioritáshiba, és a javítás a blokk eltávolítása, nem pedig egy újabb engedély hozzáadása.

Tartsa meg az alapértelmezett bejövő blokkolási viselkedést az aktív profilokon, és inkább szűkítse a konkrét engedélyeket. Ez egyetlen érthető állapotot hagy a gépen két ellentmondó szabály helyett, amelyek kölcsönhatása a prioritás részleteitől függ.

Bizonyítsa egy második forrással

Teszteljen az engedélyezett ügyféltől és egy olyan forrásból, amelynek most meg kellene hiúsulnia. Egyetlen sikeres kapcsolat csak azt bizonyítja, hogy az engedélyezett útvonal működik; semmit nem mond a most létrehozott kizárásról.

Ismételje meg a tesztet IPv6-on, ha a kiszolgálón engedélyezve van, mert egy csak IPv4-re vonatkozó szándék együtt létezhet egy széles IPv6-engedéllyel, amelyre senki nem nézett.

Végül tartsa külön a hitelesítést az elérhetőségtől. A hálózati szintű hitelesítés, a fiókjogosultságok és a bejelentkezési korlátozások továbbra is eldöntik, ki használhatja a munkamenetet, a tűzfal pedig csak azt dönti el, ki kérdezhet. Egy eszköz későbbi eltávolításakor a VPN-regisztrációját és ezt a hálózati engedélyt is el kell távolítani, különben a behatárolt cím előbb-utóbb valaki másé lesz.