At tilføje en RDP-tilladelsesregel indsnævrer ikke din VPN-adgang

Planen lyder rimelig: lad den eksisterende tilladelse til Fjernskrivebord være og tilføj en lille til den eneste VPN-klient, der bør have adgang. Windows Firewall fungerer ikke sådan. Regler er ikke en ordnet liste, hvor den mest specifikke post vinder, og en smal tilladelse ved siden af en bred tilladelse ændrer intet, fordi den brede stadig lukker alle ind, som den allerede lukkede ind. At indsnævre tjenesten betyder at redigere den tilladelse, der allerede gør arbejdet.

Den regel, du tilføjer, er ikke den regel, der betyder noget

Windows Firewall vurderer alle relevante indgående regler i de politiklagre, der gælder for maskinen, og afgør derefter, om en tilladelse matcher, og om en blokering tilsidesætter den. At tilføje en regel tilføjer en tilladelse; den fjerner eller kvalificerer ikke de tilladelser, der allerede findes.

Så spørgsmålet er aldrig, hvad du tilføjede. Det er hvad den effektive politik indeholder efter at lokal politik, domænepolitik og profilstandarderne er slået sammen. En arbejdsstation med én lokal regel er let at gennemskue; en server, der er tilmeldt et domæne, er ikke.

Det er også derfor, en administrator kan foretage en ændring, der ser rigtig ud, teste den fra den forkerte maskine og konkludere, at den virkede. Den udelukkede kilde blev aldrig testet. En test, der kun beviser succes, beviser mindre end halvdelen af det, ændringen var beregnet til.

Find ud af, hvilken adresse serveren ser

Før du afgrænser noget, skal du observere én tilladt session på Windows-værten og notere den kildeadresse, serveren rapporterer. Det er ikke altid den adresse, klienten tror, den har.

Hvis VPN-gatewayen bevarer klientadresser, ser serveren klientens tunneladresse, og en adresseafgrænset regel giver mening. Hvis gatewayen oversætter, ankommer hver klient som gatewayens adresse, og afgrænsning til den adresse giver adgang til hver klient bag den. Så er reglen præcis om det forkerte.

De to design kræver forskellige svar. Det første kan udtrykkes i en firewallregel; det andet skal håndhæves der, hvor identiteten stadig findes, altså i selve VPN'et eller i en autentificeret gateway foran tjenesten.

Et firewallfilter kan ikke genskabe en identitet, som netværksoversættelsen har kasseret, uanset hvor omhyggeligt adressen er skrevet.

Skift ejeren af den effektive regel

Undersøg den effektive indgående politik, og find hver regel, der i øjeblikket tillader RDP-trafik, herunder regler, hvis viste navn aldrig nævner port 3389. Tjenesteafgrænsede og programafgrænsede regler tæller også, og det samme gør den UDP-transport, som nogle RDP-udrulninger aktiverer.

Rediger derefter de eksisterende regler gennem det lager, der ejer dem. En lokal ændring af en regel, som domænepolitikken også definerer, kan blive sammenlagt, ignoreret eller overskrevet, og det er værd at vide, hvilket af disse der sker, før du stoler på den.

Disse kommandoer finder de aktive regler, viser det adressefilter, der er knyttet til en af dem, og forhåndsviser en ændring af omfanget:

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

Regelnavnene her er pladsholdere for det, gennemgangen fandt, og forhåndsvisningsflaget findes, så en tastefejl i en adresse ikke låser dig ude af den server, du redigerer.

Bloker-derefter-tillad er en anden model

Vanen fra andre firewalls er at skrive en bred blokering og derefter en smal tilladelse oven over den. På Windows vinder en eksplicit blokering generelt over en tilladelse, så den rækkefølge giver en tjeneste, som ingen kan nå, i stedet for en undtagelse for én klient. Resultatet er et afbrud, der ligner en ødelagt RDP-tjeneste. Det er i virkeligheden en prioritetsfejl, og rettelsen er at fjerne blokeringen i stedet for at tilføje endnu en tilladelse.

Behold standardadfærden for blokering af indgående trafik på de aktive profiler, og indsnævr i stedet de konkrete tilladelser. Det efterlader maskinen med én forståelig holdning i stedet for to modstridende regler, hvis samspil afhænger af prioritetsdetaljer.

Bevis det med en anden kilde

Test fra den tilladte klient og fra en kilde, der nu bør fejle. En enkelt vellykket forbindelse beviser kun, at den tilladte vej virker; den siger intet om den udelukkelse, du netop har lavet.

Gentag testen over IPv6, hvis serveren har det aktiveret, fordi en hensigt, der kun gælder IPv4, kan sameksistere med en bred IPv6-tilladelse, som ingen har kigget på.

Endelig skal du holde godkendelse adskilt fra tilgængelighed. Netværksniveau-godkendelse, kontorettigheder og logonbegrænsninger afgør stadig, hvem der må bruge sessionen, og firewallen afgør kun, hvem der må spørge. Fjernelse af en enhed senere bør fjerne både dens VPN-tilmelding og denne netværkstilladelse, ellers vil den adresse, du afgrænsede, med tiden tilhøre en anden.