Dodavanje RDP pravila dopuštenja ne sužava vaš VPN pristup

Plan zvuči razumno: ostavite postojeće dopuštenje za Udaljenu radnu površinu na miru i dodajte malo za jedinog VPN klijenta koji bi trebao imati pristup. Windows Firewall ne radi tako. Pravila nisu uređena lista u kojoj pobjeđuje najspecifičniji unos, a usko dopuštenje uz široko ne mijenja ništa, jer široko i dalje propušta sve koje je već propuštalo. Sužavanje usluge znači uređivanje dopuštenja koje već obavlja posao.

Pravilo koje dodate nije pravilo koje je važno

Windows Firewall procjenjuje sva primjenjiva ulazna pravila u skladištima pravila koja se odnose na mašinu, pa odlučuje da li se neko dopuštenje poklapa i da li ga neka blokada nadjačava. Dodavanje pravila dodaje dopuštenje; ono ne uklanja niti precizira dopuštenja koja već postoje.

Zato pitanje nikada nije šta ste dodali. Pitanje je šta sadrži efektivna politika nakon spajanja lokalne politike, domenske politike i zadanih vrijednosti profila. Radnu stanicu s jednim lokalnim pravilom lako je promisliti; server pridružen domeni nije.

Zato administrator može napraviti promjenu koja izgleda ispravno, testirati je s pogrešne mašine i zaključiti da je uspjela. Isključeni izvor nikada nije testiran. Test koji dokazuje samo uspjeh dokazuje manje od polovine onoga zbog čega je promjena napravljena.

Saznajte koju adresu server vidi

Prije nego što bilo šta ograničite, posmatrajte jednu dopuštenu sesiju na Windows hostu i zapišite izvornu adresu koju server prijavljuje. To nije uvijek adresa za koju klijent misli da je ima.

Ako VPN gateway čuva adrese klijenata, server vidi tunelsku adresu klijenta i pravilo ograničeno na adresu ima smisla. Ako gateway prenosi adrese, svaki klijent dolazi kao adresa gatewaya, a ograničavanje na tu adresu daje pristup svakom klijentu iza nje. Tada je pravilo precizno u pogledu pogrešne stvari.

Ta dva dizajna traže različite odgovore. Prvi se može izraziti u firewall pravilu; drugi se mora provesti tamo gdje identitet još postoji, a to je sam VPN ili autentificirani gateway ispred usluge.

Firewall filter ne može povratiti identitet koji je mrežno prevođenje odbacilo, koliko god pažljivo adresa bila upisana.

Promijenite vlasnika efektivnog pravila

Pregledajte efektivnu ulaznu politiku i pronađite svako pravilo koje trenutno dopušta RDP saobraćaj, uključujući pravila čije prikazano ime nikada ne spominje port 3389. Pravila ograničena na uslugu i na aplikaciju također se računaju, kao i UDP transport koji neka RDP postavljanja omogućavaju.

Zatim uredite postojeća pravila kroz ono skladište koje ih posjeduje. Lokalna izmjena pravila koje definira i domenska politika može biti spojena, zanemarena ili prepisana, a vrijedi znati koje se od toga događa prije nego što se na to oslonite.

Ove naredbe pronalaze aktivna pravila, prikazuju filter adresa vezan za jedno od njih i pregledavaju promjenu opsega:

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

Imena pravila ovdje su zamjenski tekst za ono što je pregled pronašao, a zastavica pregleda postoji da vas greška u adresi ne zaključa izvan servera koji uređujete.

Prvo blokiraj-pa-dopusti je drugačiji model

Navika s drugih firewallova je napisati široku blokadu i zatim usko dopuštenje iznad nje. Na Windowsu eksplicitna blokada uglavnom pobjeđuje dopuštenje, pa takav redoslijed stvara uslugu do koje niko ne može doći umjesto izuzetka za jednog klijenta. Rezultat je prekid koji izgleda kao pokvarena RDP usluga. To je zapravo greška prioriteta, a popravka je ukloniti blokadu umjesto dodati još jedno dopuštenje.

Zadržite zadano ponašanje blokiranja ulaznog saobraćaja na aktivnim profilima i umjesto toga suzite konkretna dopuštenja. Tako mašina ostaje s jednim razumljivim stanjem umjesto s dva proturječna pravila čija interakcija zavisi od detalja prioriteta.

Dokažite to drugim izvorom

Testirajte s dopuštenog klijenta i s izvora koji sada treba da ne uspije. Jedna uspješna veza dokazuje samo da dopušteni put radi; ne govori ništa o isključenju koje ste upravo napravili.

Ponovite test preko IPv6 ako ga server ima omogućenog, jer namjera samo za IPv4 može postojati uz široko IPv6 dopuštenje u koje niko nije pogledao.

Na kraju, držite autentifikaciju odvojeno od dostupnosti. Autentifikacija na mrežnom nivou, prava računa i ograničenja prijave i dalje određuju ko smije koristiti sesiju, a firewall samo određuje ko smije pitati. Uklanjanje uređaja kasnije treba ukloniti i njegovu VPN registraciju i ovo mrežno dopuštenje, inače će adresa koju ste ograničili jednom pripasti nekome drugom.