Å legge til en RDP-tillatelsesregel innsnevrer ikke VPN-tilgangen din

Planen høres rimelig ut: la den eksisterende tillatelsen for Eksternt skrivebord være, og legg til en liten for den eneste VPN-klienten som skal ha tilgang. Windows Firewall fungerer ikke slik. Regler er ikke en ordnet liste der den mest spesifikke oppføringen vinner, og en smal tillatelse ved siden av en bred endrer ingenting, fordi den brede fortsatt slipper inn alle den allerede slapp inn. Å snevre inn tjenesten betyr å redigere tillatelsen som allerede gjør jobben.

Regelen du legger til er ikke regelen som betyr noe

Windows Firewall vurderer alle gjeldende innkommende regler i policy-lagrene som gjelder for maskinen, og avgjør deretter om en tillatelse passer og om en blokkering overstyrer den. Å legge til en regel legger til en tillatelse; den fjerner eller presiserer ikke tillatelsene som allerede finnes.

Så spørsmålet er aldri hva du la til. Det er hva den effektive policyen inneholder etter at lokal policy, domenepolicy og profilens standardverdier er slått sammen. En arbeidsstasjon med én lokal regel er lett å tenke gjennom; en server tilknyttet et domene er det ikke.

Derfor kan en administrator gjøre en endring som ser riktig ut, teste den fra feil maskin og konkludere med at den virket. Kilden som ble utelukket, ble aldri testet. En test som bare beviser suksess, beviser mindre enn halvparten av det endringen var ment for.

Finn ut hvilken adresse serveren ser

Før du avgrenser noe, observer én tillatt økt på Windows-verten og noter kildeadressen serveren rapporterer. Det er ikke alltid adressen klienten tror den har.

Hvis VPN-gatewayen bevarer klientadresser, ser serveren tunneladressen til klienten, og en adresseavgrenset regel gir mening. Hvis gatewayen oversetter, kommer hver klient som gatewayens adresse, og avgrensning til den adressen gir tilgang til hver klient bak den. Da er regelen presis om det gale.

Disse to designene trenger ulike svar. Det første kan uttrykkes i en brannmurregel; det andre må håndheves der identiteten fortsatt finnes, altså i selve VPN-en eller i en autentisert gateway foran tjenesten.

Et brannmurfilter kan ikke gjenopprette en identitet som nettverksoversettelsen kastet, uansett hvor nøye adressen er skrevet.

Endre eieren av den effektive regelen

Undersøk den effektive innkommende policyen og finn hver regel som for tiden tillater RDP-trafikk, inkludert regler hvis visningsnavn aldri nevner port 3389. Tjenesteavgrensede og applikasjonsavgrensede regler teller også, og det samme gjør UDP-transporten som enkelte RDP-distribusjoner aktiverer.

Rediger deretter de eksisterende reglene gjennom lagret som eier dem. En lokal endring av en regel som domenepolicyen også definerer, kan bli slått sammen, ignorert eller overskrevet, og det er verdt å vite hvilket som skjer før du stoler på den.

Disse kommandoene finner de aktive reglene, viser adressefilteret som er knyttet til en av dem, og forhåndsviser en endring av 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 plassholdere for det gjennomgangen fant, og forhåndsvisningsflagget finnes for at en skrivefeil i en adresse ikke skal låse deg ute fra serveren du redigerer.

Blokker-først-tillat-så er en annen modell

Vanen fra andre brannmurer er å skrive en bred blokkering og deretter en smal tillatelse over den. I Windows vinner en eksplisitt blokkering vanligvis over en tillatelse, så den rekkefølgen gir en tjeneste ingen når frem til i stedet for et unntak for én klient. Resultatet er et avbrudd som ser ut som en ødelagt RDP-tjeneste. Det er egentlig en prioritetsfeil, og rettelsen er å fjerne blokkeringen i stedet for å legge til nok en tillatelse.

Behold standardoppførselen for blokkering av innkommende trafikk på de aktive profilene, og snevre i stedet inn de konkrete tillatelsene. Det lar maskinen sitte igjen med én forståelig holdning i stedet for to motstridende regler der samspillet avhenger av prioritetsdetaljer.

Bevis det med en andre kilde

Test fra den tillatte klienten og fra en kilde som nå skal feile. Én vellykket tilkobling beviser bare at den tillatte veien virker; den sier ingenting om utelukkelsen du nettopp gjorde.

Gjenta testen over IPv6 hvis serveren har det aktivert, fordi en hensikt kun for IPv4 kan eksistere sammen med en bred IPv6-tillatelse som ingen har sett på.

Til slutt, hold autentisering atskilt fra nåbarhet. Nettverksnivåautentisering, kontorettigheter og påloggingsbegrensninger avgjør fortsatt hvem som kan bruke økten, og brannmuren avgjør bare hvem som kan spørre. Å fjerne en enhet senere bør fjerne både VPN-registreringen og denne nettverkstillatelsen, ellers vil adressen du avgrenset en gang tilhøre noen andre.