Een RDP-toestemmingsregel toevoegen verkleint je VPN-toegang niet

Het plan klinkt redelijk: laat de bestaande toestemming voor Extern bureaublad staan en voeg een kleine toe voor de enige VPN-client die toegang zou moeten hebben. Windows Firewall werkt niet zo. Regels zijn geen geordende lijst waarin de meest specifieke vermelding wint, en een smalle toestemming naast een brede verandert niets, omdat de brede nog steeds iedereen doorlaat die hij al doorliet. De dienst inperken betekent de toestemming bewerken die het werk al doet.

De regel die je toevoegt is niet de regel die ertoe doet

Windows Firewall beoordeelt alle toepasselijke inkomende regels in de beleidsopslagen die voor de machine gelden, en beslist dan of een toestemming overeenkomt en of een blokkering die overstemt. Een regel toevoegen voegt een toestemming toe; hij verwijdert of preciseert de toestemmingen die er al zijn niet.

Dus de vraag is nooit wat je hebt toegevoegd. Het is wat het effectieve beleid bevat nadat lokaal beleid, domeinbeleid en de profielstandaarden zijn samengevoegd. Een werkstation met één lokale regel is makkelijk te doordenken; een server die aan een domein is gekoppeld niet.

Daarom kan een beheerder een wijziging doorvoeren die er correct uitziet, die vanaf de verkeerde machine testen en concluderen dat het werkte. De uitgesloten bron werd nooit getest. Een test die alleen succes bewijst, bewijst minder dan de helft van waarvoor de wijziging bedoeld was.

Zoek uit welk adres de server ziet

Observeer, voordat je iets begrenst, één toegestane sessie op de Windows-host en noteer het bronadres dat de server meldt. Dat is niet altijd het adres waarvan de client denkt dat hij het heeft.

Als de VPN-gateway clientadressen bewaart, ziet de server het tunneladres van de client, en een op adres begrensde regel is zinvol. Als de gateway vertaalt, komt elke client binnen als het adres van de gateway, en begrenzing tot dat adres geeft toegang aan elke client erachter. Dan is de regel precies over het verkeerde.

Die twee ontwerpen vragen verschillende antwoorden. Het eerste kan in een firewallregel worden uitgedrukt; het tweede moet worden afgedwongen waar identiteit nog bestaat, dus in de VPN zelf of in een geauthenticeerde gateway vóór de dienst.

Een firewallfilter kan een identiteit die de netwerkvertaling heeft weggegooid niet terugkrijgen, hoe zorgvuldig het adres ook is getypt.

Wijzig de eigenaar van de effectieve regel

Inspecteer het effectieve inkomende beleid en vind elke regel die op dit moment RDP-verkeer toestaat, inclusief regels waarvan de weergavenaam nooit poort 3389 noemt. Regels die op dienst en toepassing zijn begrensd tellen ook, en dat geldt ook voor het UDP-transport dat sommige RDP-implementaties inschakelen.

Bewerk vervolgens de bestaande regels via de opslag die ze bezit. Een lokale wijziging van een regel die ook het domeinbeleid definieert, kan worden samengevoegd, genegeerd of overschreven, en het is de moeite waard te weten welk geval optreedt voordat je erop vertrouwt.

Deze opdrachten vinden de actieve regels, tonen het adresfilter dat aan een ervan is gekoppeld en geven een voorbeeld van een bereikwijziging:

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

De regelnamen hier zijn plaatsaanduidingen voor wat de beoordeling heeft gevonden, en de voorbeeldfunctie bestaat zodat een typefout in een adres je niet buiten de server sluit die je bewerkt.

Eerst blokkeren en dan toestaan is een ander model

De gewoonte uit andere firewalls is een brede blokkering te schrijven en daar boven een smalle toestemming. In Windows wint een expliciete blokkering doorgaans van een toestemming, dus die volgorde levert een dienst op die niemand kan bereiken in plaats van een uitzondering voor één client. Het resultaat is een storing die op een kapotte RDP-dienst lijkt. Het is in werkelijkheid een prioriteitsfout, en de oplossing is de blokkering verwijderen in plaats van nog een toestemming toe te voegen.

Behoud het standaard blokkeren van inkomend verkeer op de actieve profielen en begrens in plaats daarvan de specifieke toestemmingen. Dat laat de machine achter met één begrijpelijke houding in plaats van twee tegenstrijdige regels waarvan de interactie van prioriteitsdetails afhangt.

Bewijs het met een tweede bron

Test vanaf de toegestane client en vanaf een bron die nu zou moeten falen. Eén geslaagde verbinding bewijst alleen dat het toegestane pad werkt; hij zegt niets over de uitsluiting die je net hebt gemaakt.

Herhaal de test over IPv6 als de server dat heeft ingeschakeld, omdat een bedoeling die alleen IPv4 betreft kan samengaan met een brede IPv6-toestemming waar niemand naar heeft gekeken.

Ten slotte: houd authenticatie gescheiden van bereikbaarheid. Netwerkniveau-authenticatie, accountrechten en aanmeldingsbeperkingen bepalen nog steeds wie de sessie mag gebruiken, en de firewall bepaalt alleen wie mag vragen. Het later verwijderen van een apparaat zou zowel de VPN-inschrijving als deze netwerkmachtiging moeten verwijderen, anders zal het adres dat je hebt begrensd ooit van iemand anders zijn.