Přidání pravidla povolení pro RDP nezúží váš přístup přes VPN

Plán zní rozumně: ponechte stávající povolení pro Vzdálenou plochu a přidejte malé pro jediného klienta VPN, který má mít přístup. Windows Firewall tak nefunguje. Pravidla nejsou seřazený seznam, kde vyhrává nejkonkrétnější položka, a úzké povolení vedle širokého nic nemění, protože široké stále propouští všechny, které už propouštělo. Zúžit službu znamená upravit povolení, které už tu práci dělá.

Pravidlo, které přidáte, není pravidlo, na kterém záleží

Windows Firewall vyhodnocuje všechna použitelná příchozí pravidla v úložištích zásad, která se na počítač vztahují, a pak rozhodne, zda některé povolení odpovídá a zda ho některé blokování přebíjí. Přidání pravidla přidá povolení; neodebere ani neupřesní povolení, která už existují.

Otázka tedy nikdy není, co jste přidali. Je to co obsahuje efektivní zásada poté, co se sloučí místní zásada, zásada domény a výchozí hodnoty profilu. Pracovní stanici s jedním místním pravidlem lze snadno promyslet; server připojený k doméně ne.

Proto může správce provést změnu, která vypadá správně, otestovat ji ze špatného počítače a dojít k závěru, že fungovala. Vyloučený zdroj nebyl nikdy otestován. Test, který dokazuje jen úspěch, dokazuje méně než polovinu toho, kvůli čemu se změna dělala.

Zjistěte, kterou adresu server vidí

Než cokoli omezíte, pozorujte na hostiteli Windows jedno povolené sezení a zapište zdrojovou adresu, kterou server hlásí. Ne vždy je to adresa, o které se klient domnívá, že ji má.

Pokud brána VPN zachovává adresy klientů, server vidí adresu tunelu klienta a pravidlo omezené adresou má smysl. Pokud brána adresy překládá, každý klient přichází jako adresa brány a omezení na tuto adresu dává přístup všem klientům za ní. Pravidlo je pak přesné ohledně špatné věci.

Tyto dva návrhy potřebují různé odpovědi. První lze vyjádřit v pravidle firewallu; druhý se musí prosadit tam, kde identita ještě existuje, tedy v samotném VPN nebo v ověřené bráně před službou.

Filtr firewallu nemůže obnovit identitu, kterou síťový překlad zahodil, ať je adresa napsána jakkoli pečlivě.

Změňte vlastníka efektivního pravidla

Prohlédněte efektivní příchozí zásadu a najděte každé pravidlo, které nyní propouští provoz RDP, včetně pravidel, jejichž zobrazovaný název nikdy nezmiňuje port 3389. Počítají se i pravidla omezená službou a aplikací a také transport UDP, který některá nasazení RDP zapínají.

Potom upravte stávající pravidla prostřednictvím úložiště, které je vlastní. Místní úprava pravidla, které definuje i zásada domény, může být sloučena, ignorována nebo přepsána, a vyplatí se vědět, která z těchto možností nastane, než se na ni spolehnete.

Tyto příkazy najdou aktivní pravidla, zobrazí filtr adres připojený k jednomu z nich a zobrazí náhled změny rozsahu:

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

Názvy pravidel jsou zde zástupné pro to, co revize našla, a příznak náhledu existuje proto, aby vás překlep v adrese nezamkl za serverem, který upravujete.

Nejprve blokovat, potom povolit je jiný model

Zvyk z jiných firewallů je napsat široké blokování a nad něj úzké povolení. Ve Windows explicitní blokování obvykle vítězí nad povolením, takže takové pořadí vytvoří službu, ke které se nikdo nedostane, místo výjimky pro jednoho klienta. Výsledkem je výpadek, který vypadá jako rozbitá služba RDP. Ve skutečnosti je to chyba priority a opravou je blokování odstranit, nikoli přidat další povolení.

Ponechte výchozí chování blokování příchozího provozu na aktivních profilech a místo toho zúžte konkrétní povolení. Počítač tak zůstane v jednom srozumitelném stavu místo dvou protichůdných pravidel, jejichž souhra závisí na podrobnostech priority.

Dokažte to druhým zdrojem

Testujte z povoleného klienta a ze zdroje, který by nyní měl selhat. Jediné úspěšné připojení dokazuje jen to, že povolená cesta funguje; o vyloučení, které jste právě provedli, neříká nic.

Opakujte test přes IPv6, pokud ho server má zapnutý, protože záměr jen pro IPv4 může existovat vedle širokého povolení pro IPv6, na které se nikdo nepodíval.

Nakonec držte ověřování oddělené od dostupnosti. Ověřování na úrovni sítě, práva účtu a omezení přihlášení stále rozhodují, kdo smí sezení používat, a firewall rozhoduje jen o tom, kdo se smí zeptat. Odebrání zařízení později by mělo odebrat jak jeho registraci ve VPN, tak toto síťové povolení, jinak adresa, kterou jste omezili, jednou bude patřit někomu jinému.