Adăugarea unei reguli de permisie pentru RDP nu restrânge accesul la VPN

Planul sună rezonabil: lăsați permisia existentă pentru Desktop la distanță așa cum este și adăugați una mică pentru singurul client VPN care ar trebui să aibă acces. Windows Firewall nu funcționează așa. Regulile nu sunt o listă ordonată în care câștigă intrarea cea mai specifică, iar o permisie îngustă lângă una largă nu schimbă nimic, pentru că cea largă primește în continuare pe toți cei pe care îi primea deja. A restrânge serviciul înseamnă a edita permisia care face deja treaba.

Regula pe care o adăugați nu este regula care contează

Windows Firewall evaluează toate regulile de intrare aplicabile din depozitele de politici care se aplică mașinii, apoi decide dacă vreo permisie se potrivește și dacă vreun blocaj o anulează. Adăugarea unei reguli adaugă o permisie; nu elimină și nu nuanțează permisiile care există deja.

Deci întrebarea nu este niciodată ce ați adăugat. Este ce conține politica efectivă după ce politica locală, politica de domeniu și valorile implicite ale profilului sunt fuzionate. O stație de lucru cu o singură regulă locală este ușor de analizat; un server unit la un domeniu nu este.

De aceea un administrator poate face o modificare care pare corectă, o poate testa de pe mașina greșită și poate concluziona că a funcționat. Sursa exclusă nu a fost testată niciodată. Un test care dovedește doar succes dovedește mai puțin de jumătate din scopul modificării.

Aflați ce adresă vede serverul

Înainte de a limita ceva, observați o sesiune permisă pe gazda Windows și notați adresa sursă pe care o raportează serverul. Nu este întotdeauna adresa despre care clientul crede că o are.

Dacă poarta VPN păstrează adresele clienților, serverul vede adresa tunelului clientului, iar o regulă limitată după adresă are sens. Dacă poarta traduce, fiecare client ajunge ca adresa porții, iar limitarea la acea adresă dă acces fiecărui client din spatele ei. Atunci regula este precisă despre lucrul greșit.

Aceste două modele au nevoie de răspunsuri diferite. Primul poate fi exprimat într-o regulă de firewall; al doilea trebuie impus acolo unde identitatea mai există, adică în VPN-ul însuși sau într-o poartă autentificată în fața serviciului.

Un filtru de firewall nu poate recupera o identitate pe care traducerea de rețea a aruncat-o, oricât de atent ar fi scrisă adresa.

Schimbați proprietarul regulii efective

Inspectați politica de intrare efectivă și găsiți fiecare regulă care admite în prezent trafic RDP, inclusiv regulile al căror nume afișat nu menționează niciodată portul 3389. Se iau în calcul și regulile limitate după serviciu și aplicație, precum și transportul UDP pe care unele implementări RDP îl activează.

Apoi editați regulile existente prin depozitul care le deține. O modificare locală a unei reguli pe care o definește și politica de domeniu poate fi fuzionată, ignorată sau suprascrisă, și merită să știți care dintre acestea se întâmplă înainte de a vă baza pe ea.

Aceste comenzi găsesc regulile active, afișează filtrul de adrese atașat uneia dintre ele și previzualizează o modificare a domeniului de aplicare:

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

Numele regulilor de aici sunt substituenți pentru ceea ce a găsit revizuirea, iar indicatorul de previzualizare există pentru ca o greșeală de tastare într-o adresă să nu vă închidă în afara serverului pe care îl editați.

Întâi blochează, apoi permite este un alt model

Obiceiul din alte firewall-uri este să scrieți un blocaj larg și apoi o permisie îngustă deasupra. În Windows un blocaj explicit câștigă de obicei în fața unei permisii, așa că acea ordine produce un serviciu la care nimeni nu poate ajunge în loc de o excepție pentru un client. Rezultatul este o întrerupere care arată ca un serviciu RDP stricat. Este de fapt o greșeală de prioritate, iar remedierea este să eliminați blocajul în loc să adăugați o altă permisie.

Păstrați comportamentul implicit de blocare a traficului de intrare pe profilele active și, în schimb, restrângeți permisiile concrete. Asta lasă mașina cu o singură poziție de înțeles în loc de două reguli contradictorii a căror interacțiune depinde de detalii de prioritate.

Dovediți-o cu o a doua sursă

Testați de la clientul permis și de la o sursă care ar trebui să eșueze acum. O singură conexiune reușită dovedește doar că traseul permis funcționează; nu spune nimic despre excluderea pe care tocmai ați făcut-o.

Repetați testul prin IPv6 dacă serverul îl are activat, pentru că o intenție doar IPv4 poate coexista cu o permisie IPv6 largă la care nimeni nu s-a uitat.

În final, țineți autentificarea separată de accesibilitate. Autentificarea la nivel de rețea, drepturile contului și restricțiile de conectare decid în continuare cine poate folosi sesiunea, iar firewall-ul decide doar cine poate întreba. Eliminarea ulterioară a unui dispozitiv ar trebui să elimine atât înregistrarea lui în VPN, cât și această permisiune de rețea, altfel adresa pe care ați limitat-o va aparține într-o zi altcuiva.