RDP leidimo taisyklės pridėjimas nesusiaurina jūsų VPN prieigos

Planas skamba pagrįstai: palikite esamą Nuotolinio darbalaukio leidimą tokį, koks jis yra, ir pridėkite mažą leidimą tam vieninteliam VPN klientui, kuris turėtų turėti prieigą. Windows Firewall taip neveikia. Taisyklės nėra surikiuotas sąrašas, kuriame laimi pats konkretiausias įrašas, o siauras leidimas šalia plataus nieko nekeičia, nes platusis vis tiek įleidžia visus, kuriuos jau įleido. Susiaurinti paslaugą reiškia redaguoti leidimą, kuris jau atlieka darbą.

Taisyklė, kurią pridedate, nėra svarbi taisyklė

Windows Firewall įvertina visas taikomas gaunamąsias taisykles politikos saugyklose, kurios taikomos kompiuteriui, tada nusprendžia, ar koks nors leidimas atitinka ir ar kokia nors blokada jį viršija. Taisyklės pridėjimas prideda leidimą; jis nepašalina ir nepataiso jau esamų leidimų.

Taigi klausimas niekada nėra, ką pridėjote. Klausimas yra, ką apima veiksminga politika sujungus vietinę politiką, domeno politiką ir profilio numatytąsias reikšmes. Darbo stotį su viena vietine taisykle lengva apgalvoti; prie domeno prijungtą serverį ne.

Štai kodėl administratorius gali atlikti teisingai atrodantį pakeitimą, išbandyti jį netinkamame kompiuteryje ir padaryti išvadą, kad jis veikė. Pašalintas šaltinis niekada nebuvo išbandytas. Testas, įrodantis tik sėkmę, įrodo mažiau nei pusę to, dėl ko pakeitimas buvo daromas.

Išsiaiškinkite, kokį adresą mato serveris

Prieš ką nors apribodami, stebėkite vieną leistiną sesiją Windows hoste ir užrašykite šaltinio adresą, kurį praneša serveris. Tai ne visada adresas, kurį klientas mano turįs.

Jei VPN šliuzas išsaugo klientų adresus, serveris mato kliento tunelio adresą, ir adresu apribota taisyklė turi prasmę. Jei šliuzas verčia adresus, kiekvienas klientas atvyksta kaip šliuzo adresas, o apribojimas tuo adresu suteikia prieigą kiekvienam klientui už jo. Tada taisyklė yra tiksli ne to dalyko atžvilgiu.

Šie du projektai reikalauja skirtingų atsakymų. Pirmasis gali būti išreikštas ugniasienės taisykle; antrasis turi būti įgyvendintas ten, kur tapatybė dar egzistuoja, tai yra pačiame VPN arba autentifikuotame šliuze prieš paslaugą.

Ugniasienės filtras negali atkurti tapatybės, kurią tinklo vertimas išmetė, kad ir kaip kruopščiai būtų įvestas adresas.

Pakeiskite veiksmingos taisyklės savininką

Patikrinkite veiksmingą gaunamąją politiką ir raskite kiekvieną taisyklę, kuri šiuo metu leidžia RDP srautą, įskaitant taisykles, kurių rodomas pavadinimas niekada nemini prievado 3389. Taip pat skaičiuojamos paslaugos ir programos apribotos taisyklės, o taip pat UDP transportas, kurį įjungia kai kurie RDP diegimai.

Tada redaguokite esamas taisykles per saugyklą, kuriai jos priklauso. Vietinis taisyklės, kurią taip pat apibrėžia domeno politika, pakeitimas gali būti sujungtas, ignoruojamas arba perrašytas, ir verta žinoti, kuris iš šių atvejų įvyks, prieš juo pasikliaujant.

Šios komandos randa aktyvias taisykles, parodo su viena jų susietą adresų filtrą ir peržiūri apimties pakeitimą:

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

Taisyklių pavadinimai čia yra peržiūros rastų dalykų pakaitiniai žymekliai, o peržiūros vėliavėlė egzistuoja tam, kad rašybos klaida adrese neužrakintų jūsų nuo serverio, kurį redaguojate.

Pirmiausia užblokuoti, paskui leisti yra kitas modelis

Kitų ugniasienių įprotis yra parašyti plačią blokadą ir tada siaurą leidimą virš jos. Windows aiški blokada paprastai laimi prieš leidimą, todėl tokia tvarka sukuria paslaugą, kurios niekas negali pasiekti, o ne išimtį vienam klientui. Rezultatas yra sutrikimas, kuris atrodo kaip sugedusi RDP paslauga. Iš tikrųjų tai prioriteto klaida, o pataisa yra pašalinti blokadą, o ne pridėti dar vieną leidimą.

Išlaikykite numatytąjį gaunamojo srauto blokavimą aktyviuose profiliuose ir vietoj to susiaurinkite konkrečius leidimus. Tai palieka kompiuterį su viena suprantama pozicija, o ne dviem prieštaraujančiomis taisyklėmis, kurių sąveika priklauso nuo prioriteto detalių.

Įrodykite tai antruoju šaltiniu

Išbandykite iš leistino kliento ir iš šaltinio, kuris dabar turėtų nepavykti. Vienas sėkmingas ryšys įrodo tik tai, kad leistinas kelias veikia; jis nieko nesako apie ką tik padarytą išimtį.

Pakartokite testą per IPv6, jei serveris jį turi įjungtą, nes ketinimas tik IPv4 gali egzistuoti kartu su plačiu IPv6 leidimu, į kurį niekas nepažiūrėjo.

Galiausiai laikykite autentifikavimą atskirai nuo pasiekiamumo. Tinklo lygmens autentifikavimas, paskyros teisės ir prisijungimo apribojimai vis dar nusprendžia, kas gali naudotis sesija, o ugniasienė nusprendžia tik, kas gali klausti. Vėliau pašalinus įrenginį reikėtų pašalinti ir jo VPN registraciją, ir šį tinklo leidimą, kitaip apribotas adresas kada nors priklausys kam nors kitam.