RDP atļaujas noteikuma pievienošana nesašaurina jūsu VPN piekļuvi

Plāns izklausās saprātīgi: atstājiet esošo Attālās darbvirsmas atļauju tādu, kāda tā ir, un pievienojiet mazu atļauju vienīgajam VPN klientam, kuram vajadzētu būt piekļuvei. Windows Firewall tā nedarbojas. Noteikumi nav sakārtots saraksts, kurā uzvar viskonkrētākā ieraksts, un šaura atļauja blakus plašai neko nemaina, jo plašā joprojām ielaiž visus, kurus tā jau ielaida. Pakalpojuma sašaurināšana nozīmē rediģēt atļauju, kas jau veic darbu.

Noteikums, kuru pievienojat, nav svarīgais noteikums

Windows Firewall novērtē visus piemērojamos ienākošos noteikumus politikas krātuvēs, kas attiecas uz datoru, pēc tam izlemj, vai kāda atļauja atbilst un vai kāds bloķējums to pārspēj. Noteikuma pievienošana pievieno atļauju; tā nenoņem un neprecizē jau esošās atļaujas.

Tāpēc jautājums nekad nav par to, ko pievienojāt. Jautājums ir, ko satur faktiskā politika pēc vietējās politikas, domēna politikas un profila noklusējumu apvienošanas. Darbstaciju ar vienu vietēju noteikumu ir viegli pārdomāt; domēnam pievienotu serveri ne.

Tāpēc administrators var veikt pareizi izskatāmu izmaiņu, pārbaudīt to no nepareizā datora un secināt, ka tā darbojās. Izslēgtais avots nekad netika pārbaudīts. Tests, kas pierāda tikai panākumus, pierāda mazāk nekā pusi no tā, kālab izmaiņa tika veikta.

Noskaidrojiet, kādu adresi serveris redz

Pirms kaut ko ierobežojat, novērojiet vienu atļautu sesiju Windows resursdatorā un pierakstiet avota adresi, ko serveris ziņo. Tā ne vienmēr ir adrese, kuru klients domā, ka tam ir.

Ja VPN vārteja saglabā klientu adreses, serveris redz klienta tuneļa adresi, un ar adresi ierobežots noteikums ir jēgpilns. Ja vārteja tulko, katrs klients ierodas kā vārtejas adrese, un ierobežošana ar šo adresi piešķir piekļuvi katram klientam aiz tās. Tad noteikums ir precīzs par nepareizo lietu.

Šiem diviem dizainiem vajadzīgas atšķirīgas atbildes. Pirmo var izteikt ugunsmūra noteikumā; otrais jāievieš tur, kur identitāte vēl pastāv, tas ir, pašā VPN vai autentificētā vārtejā pakalpojuma priekšā.

Ugunsmūra filtrs nevar atgūt identitāti, ko tīkla tulkošana izmetusi, lai cik rūpīgi adrese būtu ievadīta.

Mainiet faktiskā noteikuma īpašnieku

Pārbaudiet faktisko ienākošo politiku un atrodiet katru noteikumu, kas pašlaik atļauj RDP datplūsmu, tostarp noteikumus, kuru parādītais nosaukums nekad nemin portu 3389. Tiek skaitīti arī pakalpojuma un lietojumprogrammas ierobežoti noteikumi, kā arī UDP transports, ko iespējo daži RDP izvietojumi.

Pēc tam rediģējiet esošos noteikumus caur krātuvi, kurai tie pieder. Vietēja noteikuma, ko definē arī domēna politika, izmaiņa var tikt apvienota, ignorēta vai pārrakstīta, un ir vērts zināt, kurš no šiem gadījumiem notiek, pirms paļauties uz to.

Šīs komandas atrod aktīvos noteikumus, parāda ar vienu no tiem saistīto adrešu filtru un priekšskata darbības jomas izmaiņas:

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

Noteikumu nosaukumi šeit ir aizvietotāji tam, ko atrada pārskats, un priekšskatījuma karodziņš pastāv, lai adreses drukas kļūda neaizslēgtu jūs ārpus servera, kuru rediģējat.

Vispirms bloķēt, pēc tam atļaut ir cits modelis

Citu ugunsmūru paradums ir rakstīt plašu bloķējumu un pēc tam šauru atļauju virs tā. Operētājsistēmā Windows skaidrs bloķējums parasti uzvar atļauju, tāpēc šāda secība rada pakalpojumu, kuram neviens nevar piekļūt, nevis izņēmumu vienam klientam. Rezultāts ir pārtraukums, kas izskatās kā bojāts RDP pakalpojums. Tā patiesībā ir prioritātes kļūda, un labojums ir noņemt bloķējumu, nevis pievienot vēl vienu atļauju.

Saglabājiet noklusēto ienākošās datplūsmas bloķēšanu aktīvajos profilos un tā vietā sašauriniet konkrētās atļaujas. Tas atstāj datoru ar vienu saprotamu nostāju, nevis diviem pretrunīgiem noteikumiem, kuru mijiedarbība ir atkarīga no prioritātes detaļām.

Pierādiet to ar otru avotu

Pārbaudiet no atļautā klienta un no avota, kuram tagad vajadzētu neizdoties. Viens veiksmīgs savienojums pierāda tikai to, ka atļautais ceļš darbojas; tas neko nepasaka par tikko veikto izslēgšanu.

Atkārtojiet testu ar IPv6, ja serverī tas ir iespējots, jo nodoms tikai ar IPv4 var pastāvēt līdzās plašai IPv6 atļaujai, kuru neviens nav apskatījis.

Visbeidzot, turiet autentifikāciju atsevišķi no sasniedzamības. Tīkla līmeņa autentifikācija, konta tiesības un pieteikšanās ierobežojumi joprojām izlemj, kas drīkst izmantot sesiju, un ugunsmūris izlemj tikai to, kas drīkst jautāt. Ierīces vēlāka noņemšana būtu jānoņem gan tās VPN reģistrāciju, gan šo tīkla atļauju, citādi ierobežotā adrese kādreiz piederēs kādam citam.