RDP-sallintasäännön lisääminen ei kavenna VPN-yhteyttäsi

Suunnitelma kuulostaa järkevältä: jätä nykyinen Etätyöpöydän lupa ennalleen ja lisää pieni lupa sille ainoalle VPN-asiakkaalle, jolla pitäisi olla pääsy. Windowsin palomuuri ei toimi niin. Säännöt eivät ole järjestetty luettelo, jossa tarkin merkintä voittaa, eikä kapea lupa leveän luvan rinnalla muuta mitään, koska leveä päästää edelleen läpi kaikki, jotka se päästi jo ennenkin. Palvelun kaventaminen tarkoittaa sen luvan muokkaamista, joka jo tekee työn.

Lisäämäsi sääntö ei ole se sääntö, jolla on merkitystä

Windowsin palomuuri arvioi kaikki soveltuvat saapuvat säännöt niissä käytäntösäilöissä, jotka koskevat konetta, ja päättää sitten, täsmääkö jokin lupa ja ohittaako jokin estosääntö sen. Säännön lisääminen lisää luvan; se ei poista tai tarkenna lupia, jotka ovat jo olemassa.

Kysymys ei siis koskaan ole siitä, mitä lisäsit. Se on, mitä tehokas käytäntö sisältää sen jälkeen kun paikallinen käytäntö, toimialueen käytäntö ja profiilin oletusarvot on yhdistetty. Työasema, jolla on yksi paikallinen sääntö, on helppo hahmottaa; toimialueeseen liitetty palvelin ei.

Siksi järjestelmänvalvoja voi tehdä oikealta näyttävän muutoksen, testata sen väärältä koneelta ja päätellä, että se toimi. Poissuljettua lähdettä ei koskaan testattu. Testi, joka todistaa vain onnistumisen, todistaa vähemmän kuin puolet siitä, mitä varten muutos tehtiin.

Selvitä, minkä osoitteen palvelin näkee

Ennen kuin rajaat mitään, tarkkaile yhtä sallittua istuntoa Windows-isännässä ja kirjaa lähdeosoite, jonka palvelin ilmoittaa. Se ei aina ole osoite, jonka asiakas luulee itsellään olevan.

Jos VPN-yhdyskäytävä säilyttää asiakkaiden osoitteet, palvelin näkee asiakkaan tunneliosoitteen ja osoitteeseen sidottu sääntö on mielekäs. Jos yhdyskäytävä kääntää osoitteet, jokainen asiakas saapuu yhdyskäytävän osoitteena, ja siihen osoitteeseen rajaaminen antaa pääsyn jokaiselle sen takana olevalle asiakkaalle. Silloin sääntö on täsmällinen väärässä asiassa.

Nämä kaksi mallia tarvitsevat erilaiset vastaukset. Ensimmäinen voidaan ilmaista palomuurisäännössä; toinen on pakotettava siellä, missä identiteetti vielä on, eli itse VPN:ssä tai palvelun edessä olevassa todennetussa yhdyskäytävässä.

Palomuurisuodatin ei voi palauttaa identiteettiä, jonka verkkokäännös heitti pois, niin huolellisesti kuin osoite kirjoitettaisiin.

Vaihda tehokkaan säännön omistaja

Tarkastele tehokasta saapuvaa käytäntöä ja löydä jokainen sääntö, joka tällä hetkellä sallii RDP-liikenteen, mukaan lukien säännöt, joiden näyttönimi ei koskaan mainitse porttia 3389. Myös palveluun ja sovellukseen sidotut säännöt lasketaan, samoin kuin UDP-kuljetus, jonka jotkin RDP-asennukset ottavat käyttöön.

Muokkaa sitten olemassa olevia sääntöjä sen säilön kautta, joka ne omistaa. Paikallinen muutos sääntöön, jonka myös toimialueen käytäntö määrittelee, voidaan yhdistää, jättää huomiotta tai korvata, ja kannattaa tietää, mikä näistä tapahtuu, ennen kuin luottaa siihen.

Nämä komennot löytävät aktiiviset säännöt, näyttävät yhteen niistä liitetyn osoitesuodattimen ja esikatselevat laajuuden muutosta:

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

Sääntöjen nimet ovat tässä paikkamerkkejä sille, mitä katsaus löysi, ja esikatselulippu on olemassa, jotta osoitteen kirjoitusvirhe ei lukitse sinua ulos palvelimesta, jota muokkaat.

Ensin estä, sitten salli on erilainen malli

Muiden palomuurien tapa on kirjoittaa leveä esto ja sitten kapea lupa sen yläpuolelle. Windowsissa nimenomainen esto yleensä voittaa luvan, joten tällainen järjestys tuottaa palvelun, johon kukaan ei pääse, eikä poikkeusta yhdelle asiakkaalle. Tuloksena on katkos, joka näyttää rikkinäiseltä RDP-palvelulta. Se on todellisuudessa prioriteettivirhe, ja korjaus on poistaa esto eikä lisätä uutta lupaa.

Pidä saapuvan liikenteen oletusesto aktiivisissa profiileissa ja kavenna sen sijaan yksittäisiä lupia. Se jättää koneelle yhden ymmärrettävän asennon kahden ristiriitaisen säännön sijaan, joiden vuorovaikutus riippuu prioriteetin yksityiskohdista.

Todista se toisella lähteellä

Testaa sallitusta asiakkaasta ja lähteestä, jonka pitäisi nyt epäonnistua. Yksi onnistunut yhteys todistaa vain, että sallittu polku toimii; se ei kerro mitään juuri tekemästäsi poissulkemisesta.

Toista testi IPv6:n kautta, jos palvelimella on se käytössä, koska vain IPv4:tä koskeva aikomus voi esiintyä leveän IPv6-luvan rinnalla, jota kukaan ei katsonut.

Lopuksi pidä todentaminen erillään saavutettavuudesta. Verkkotason todentaminen, tilin oikeudet ja kirjautumisrajoitukset päättävät edelleen, kuka saa käyttää istuntoa, ja palomuuri päättää vain, kuka saa kysyä. Laitteen myöhemmän poistamisen pitäisi poistaa sekä sen VPN-rekisteröinti että tämä verkko-oikeus, muuten rajaamasi osoite kuuluu jonain päivänä jollekin muulle.