RDP lubamisreegli lisamine ei kitsenda teie VPN-i juurdepääsu

Plaan kõlab mõistlikult: jätke olemasolev Kaugtöölaua luba puutumata ja lisage väike luba sellele ainsale VPN-kliendile, kellel peaks juurdepääs olema. Windowsi tulemüür ei tööta nii. Reeglid ei ole järjestatud loend, kus võidab kõige spetsiifilisem kirje, ja kitsas luba laia kõrval ei muuda midagi, sest lai lubab endiselt sisse kõiki, keda ta juba lubas. Teenuse kitsendamine tähendab selle loa muutmist, mis juba tööd teeb.

Reegel, mille lisate, ei ole reegel, mis loeb

Windowsi tulemüür hindab kõiki masinale kohalduvaid sissetulevaid reegleid poliitikahoidlates ja otsustab seejärel, kas mõni luba sobib ja kas mõni blokk selle üle kirjutab. Reegli lisamine lisab loa; see ei eemalda ega täpsusta juba olemasolevaid lube.

Seega ei ole küsimus kunagi selles, mida te lisasite. Küsimus on, mida sisaldab tegelik poliitika pärast kohaliku poliitika, domeenipoliitika ja profiili vaikeväärtuste ühendamist. Ühe kohaliku reegliga tööjaama on lihtne läbi mõelda; domeeniga liidetud serveriga mitte.

Seetõttu võib administraator teha õigesti näiva muudatuse, testida seda valelt masinalt ja järeldada, et see toimis. Välistatud allikat ei testitud kunagi. Test, mis tõestab ainult edu, tõestab vähem kui pool sellest, mille jaoks muudatus tehti.

Tehke kindlaks, millist aadressi server näeb

Enne kui midagi piirama hakkate, jälgige ühte lubatud seanssi Windowsi hostis ja kirjutage üles lähteaadress, millest server teatab. See ei ole alati aadress, mille klient arvab endal olevat.

Kui VPN-lüüs säilitab kliendi aadresse, näeb server kliendi tunneliaadressi ja aadressiga piiratud reegel on mõttekas. Kui lüüs tõlgib, saabub iga klient lüüsi aadressina ja selle aadressiga piiramine annab juurdepääsu igale kliendile selle taga. Siis on reegel täpne vale asja suhtes.

Need kaks lahendust vajavad erinevaid vastuseid. Esimest saab väljendada tulemüürireeglis; teine tuleb jõustada seal, kus identiteet veel eksisteerib, see tähendab VPN-is endas või teenuse ees olevas autenditud lüüsis.

Tulemüürifilter ei suuda taastada identiteeti, mille võrgutõlge ära viskas, ükskõik kui hoolikalt aadress on sisestatud.

Muutke tegeliku reegli omanikku

Kontrollige tegelikku sissetulevat poliitikat ja leidke iga reegel, mis praegu RDP-liiklust lubab, sealhulgas reeglid, mille kuvatav nimi ei maini kunagi porti 3389. Teenusega ja rakendusega piiratud reeglid loevad samuti, nagu ka UDP-transport, mille mõned RDP-paigaldused lubavad.

Seejärel muutke olemasolevaid reegleid selle hoidla kaudu, mis neid omab. Kohalik muudatus reeglis, mille määrab ka domeenipoliitika, võib olla ühendatud, eiratud või üle kirjutatud, ja tasub teada, milline neist juhtub, enne kui sellele loote.

Need käsud leiavad aktiivsed reeglid, näitavad ühega seotud aadressifiltrit ja eelvaatavad ulatuse muudatust:

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

Reeglite nimed on siin asendajad selle jaoks, mille ülevaatus leidis, ja eelvaate lipp on olemas selleks, et aadressi trükiviga ei lukustaks teid välja serverist, mida muudate.

Kõigepealt blokeeri, siis luba on teistsugune mudel

Teiste tulemüüride harjumus on kirjutada lai blokk ja seejärel kitsas luba selle kohale. Windowsis võidab selgesõnaline blokk üldiselt loa üle, nii et selline järjestus loob teenuse, kuhu keegi ei pääse, mitte erandi ühele kliendile. Tulemuseks on katkestus, mis näeb välja nagu katkine RDP-teenus. See on tegelikult prioriteediviga ja parandus on blokk eemaldada, mitte veel üks luba lisada.

Jätke aktiivsetel profiilidel sissetuleva liikluse vaikimisi blokeerimine alles ja kitsendage selle asemel konkreetseid lube. See jätab masina ühe mõistetava hoiakuga, mitte kahe vastuolulise reegliga, mille koostoime sõltub prioriteedi üksikasjadest.

Tõestage seda teise allikaga

Testige lubatud kliendist ja allikast, mis peaks nüüd ebaõnnestuma. Üksainus edukas ühendus tõestab ainult seda, et lubatud tee töötab; see ei ütle midagi välistamise kohta, mille just tegite.

Korrake testi IPv6 kaudu, kui serveril see lubatud on, sest ainult IPv4 mõeldud kavatsus võib eksisteerida koos laia IPv6 loaga, mille peale keegi ei vaadanud.

Lõpuks hoidke autentimine juurdepääsetavusest eraldi. Võrgu tasandi autentimine, kontoõigused ja sisselogimispiirangud otsustavad endiselt, kes tohib seanssi kasutada, ja tulemüür otsustab ainult, kes tohib küsida. Seadme hilisem eemaldamine peaks eemaldama nii selle VPN-registreeringu kui ka selle võrguõiguse, muidu kuulub piiratud aadress kunagi kellelegi teisele.