)
)
Introduktion
En effektiv RDP-hærdningsstrategi begynder med at spørge, om Remote Desktop Protocol overhovedet skal aktiveres. Når RDP er nødvendigt, bør administratorer begrænse, hvor forbindelserne stammer fra, beskytte legitimationsoplysninger, reducere sessionstilladelser og verificere, at hver kontrol fungerer som tilsigtet på tværs af arbejdsstationer, standalone-servere, domænemiljøer og Remote Desktop Services-implementeringer.
Hvad er RDP-hærdning?
RDP-hærdning er processen med at reducere angrebsfladen forbundet med Remote Desktop Protocol, samtidig med at den adgang, som legitime brugere og administratorer har brug for, bevares. Det kombinerer Windows-konfiguration, netværkskontroller, identitetsbeskyttelse, sessionsbegrænsninger, opdatering og overvågning.
Hærdning er ikke begrænset til at ændre port 3389 eller aktivere en firewallregel. Administratorer skal vurdere, hvilke systemer der accepterer forbindelser, hvor brugerne opretter forbindelse fra, hvilke konti der er tilladt, hvordan godkendelse fungerer, og hvilke ressourcer der kan bevæge sig gennem en session.
CISA anbefaler deaktivering af risikable og unødvendige tjenester , herunder RDP, hvor de ikke er nødvendige. Den første hærdningsbeslutning er derfor, om en enhed virkelig har brug for at eksponere det.
Hvad skal en RDP-hærdningscheckliste indeholde?
Brug denne tjekliste som en hurtig revision, før du gennemgår hver kontrol i detaljer. Den nøjagtige konfiguration bør afspejle systemrollen, brugerpopulationen og netværksarkitekturen.
| Prioritet | RDP hærdningskontrol | Forventet tilstand |
|---|---|---|
| Kritisk | Deaktiver RDP, hvor det er unødvendigt | Kun godkendte systemer accepterer fjernsessioner |
| Kritisk | Forhindre direkte interneteksponering | Forbindelser bruger en gateway, VPN, bastion eller whitelist |
| Kritisk | Styrk autentificering | NLA og MFA beskytter fjernadgang |
| Kritisk | Begræns RDP-brugere | Kun godkendte konti og grupper kan oprette forbindelse |
| Høj | Beskyt trafik og legitimationsoplysninger | Pålidelige TLS-certifikater og passende legitimationskontroller anvendes |
| Høj | Begræns sessionens funktioner | Omdirigering, inaktiv tid og frakoblede sessioner følger politikken |
| Høj | Hærd Windows-værten | Systemer er opdateret, segmenteret og med minimale rettigheder |
| Høj | Overvåg RDP-aktivitet | Logs er centraliserede, og mistænkelig adfærd genererer alarmer. |
| Operationel | Test og gennemgå baseline | Adgang, blokering, genopretning og konfigurationsdrift valideres |
Disse kontroller danner en lagdelt baseline. De følgende sektioner forklarer, hvordan man implementerer og validerer hvert område.
Hvordan skal du reducere RDP-eksponering?
Deaktiver RDP på systemer, der ikke har brug for det
Lad ikke Remote Desktop være aktiveret blot fordi det måske bliver nyttigt senere. Arbejdsstationer, backend-servere og applikationsværter, der ikke administreres gennem RDP, bør ikke acceptere fjernsessioner.
Brug gruppepolitik til at forhindre nye indkommende forbindelser:
Computerkonfiguration > Administrative skabeloner > Windows-komponenter > Fjernskrivebordsservices > Fjernskrivebords-session vært > Forbindelser > Tillad brugere at oprette forbindelse eksternt ved hjælp af Fjernskrivebordsservices
Efter deaktivering af RDP, fjern forældede firewall-regler, NAT-mappinger, cloud-sikkerhedsgruppeindgange og port-forwarding-konfigurationer. En lokal kontrol kan identificere en aktiv lytter:
Get-NetTCPConnection -LocalPort 3389 -State Listen -ErrorAction SilentlyContinue
Et tomt resultat beviser ikke, at værten er utilgængelig fra ethvert netværk. Bekræft ændringen med ekstern scanning og firewall-gennemgange.
Undgå at offentliggøre port 3389 direkte til internettet
En offentlig RDP-lytter kan opdages og målrettes med password spraying, credential stuffing og sårbarhedsscanning. Stærke adgangskoder og Network Level Authentication forbedrer sikkerheden, men de fjerner ikke risikoen skabt af en ubegribelig internet-facing service.
En praktisk Risiko score for Remote Desktop kan hjælpe administratorer med at rangere udsatte tjenester, svag autentificering og alt for bred adgang, før de vælger korrigerende foranstaltninger.
Placer ekstern adgang bag et passende kontrollag, såsom:
- RD Gateway
- En korrekt sikret VPN
- En bastion eller jump host
- En Zero Trust adgangstjeneste
- En browserbaseret fjernadgangsportal
- Adgang til just-in-time firewall
- En streng kilde-IP tilladelsesliste
Fast administrative placeringer kan passe til en tilladelsesliste, mens mobile medarbejdere normalt har brug for en identitetsbevidst gateway. RD Gateway kan give et administreret indgangspunkt og integrere med Network Policy Server og Microsoft Entra multifaktorautentifikation, hvilket forhindrer interne RDP-værter i at blive offentliggjort direkte.
Begræns RDP Firewall-reglen
En indgående firewallregel bør ikke acceptere trafik fra enhver adresse, medmindre der findes en anden effektiv begrænsning foran den. Begræns intern administration til administrationsnetværk, VPN-puljer eller udpegede jump hosts.
For cloud-systemer, gennemgå både Windows Firewall og udbyderens netværkskontroller. En restriktiv Windows-regel kan stadig blive undermineret af bredere eksponering andre steder.
RDP bruger almindeligvis TCP og kan bruge UDP for forbedret transportydelse. Når du ændrer lytteporten, skal du oprette tilsvarende TCP- og UDP-regler og teste hver understøttet forbindelsesvej.
Skal du ændre den standard RDP-port?
Ændring af port 3389 kan reducere grundlæggende scanningsstøj, men det forbedrer ikke autentificering, kryptering eller autorisation. En beslutsom scanner kan stadig opdage tjenesten.
Behandl en tilpasset port som en valgfri driftsforanstaltning. Dokumenter den nye værdi, opdater overvågnings- og firewallregler, og test alle klienter. Microsoft gemmer lytterindstillingen under:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp
Et genstart er påkrævet efter ændring af
Portnummer
værdi.
Hvordan skal du styrke RDP-godkendelse?
Aktivér netværksniveau godkendelse
Netværksniveauautentifikation kræver, at brugerne autentificerer sig, før Windows opretter en fuld fjernsession. Dette reducerer uautentificeret ressourceforbrug og placerer en autentificeringsbarriere før den interaktive logonskærm.
Aktiver følgende politik:
Computerkonfiguration > Administrative skabeloner > Windows-komponenter > Fjernskrivebordsservices > Fjernskrivebords-session vært > Sikkerhed > Kræv brugerautentifikation for fjernforbindelser ved hjælp af netværksniveauautentifikation
NLA bør normalt forblive aktiveret. Midlertidig deaktivering kan hjælpe med kontrolleret fejlfinding, men det er at foretrække at erstatte forældede klienter frem for at svække baseline permanent.
Krav om multifaktorautentifikation
NLA er ikke multifaktorautentifikation. Det flytter autentifikationen tidligere i forbindelsesprocessen, men kan stadig være afhængig af et brugernavn og en adgangskode.
MFA bør beskytte eksternt tilgængelige RDP-stier og privilegeret fjernadministration. Implementeringen afhænger af arkitekturen. Traditionelle RDS-miljøer håndhæver ofte MFA gennem RD Gateway, Network Policy Server, Microsoft Entra ID og NPS-udvidelsen. Andre miljøer kan bruge en serveragent, Zero Trust-gateway eller fjernadgangsplatform.
Plan MFA omkring tilmelding, genopretning, servicekonti, nedbrud, logning og en beskyttet break-glass proces. Nød-konti bør forblive stramt kontrolleret.
Begræns hvem der kan logge ind via RDP
Brug dedikerede grupper i stedet for at give adgang bredt gennem medlemskab af lokale administratorer. Gennemgå disse politikker:
Computer Configuration > Windows Settings > Security Settings > Local Policies > User Rights Assignment
De to mest relevante indstillinger er:
- Tillad logon via Remote Desktop Services
- Nægt logon gennem Remote Desktop Services
Afvisningspolitikken har forrang. Gennemgå tildelinger omhyggeligt for at undgå at blokere legitime administratorer.
List lokale medlemskaber med:
Get-LocalGroupMember -Group "Remote Desktop Users" Get-LocalGroupMember -Group "Administrators"
På domæneforbundne systemer skal du gennemgå indlejrede grupper og fjerne tidligere ansatte, midlertidige leverandører, servicekonti og brede grupper, der ikke længere har brug for interaktiv adgang.
Adskil administrative og standardkonti
Administratorer bør ikke bruge privilegerede identiteter til e-mail, browsing eller dagligt arbejde. Giv separate konti til RDP-administration og begræns, hvor disse identiteter kan logge ind.
Domæneadministrator- og tilsvarende konti bør ikke bruges på almindelige medlemsservere og arbejdsstationer. Hvis en lavere tillidsværdig vært bliver kompromitteret, kan legitimationsoplysninger eller adgangstokens fra en administrativ session understøtte lateral bevægelse.
Windows LAPS kan administrere og sikkerhedskopiere unikke lokale administratoradgangskoder på understøttede Windows-systemer. Dette undgår genbrug af én privilegeret adgangskode på tværs af flere maskiner.
Beskyt legitimationsoplysninger med Remote Credential Guard
Remote Credential Guard beskytter legitimationsoplysninger under understøttede direkte RDP-forbindelser ved at omdirigere Kerberos-anmodninger til klientenheden. Legitimationsoplysninger og deres afledte sendes ikke til den fjerne vært, hvilket reducerer risikoen for tyveri fra en kompromitteret destination.
Denne kontrol kræver Kerberos og understøttede Windows-klienter og -værter. Det understøttes ikke for forbindelser gennem RD Gateway eller Remote Desktop Connection Broker, så administratorer skal validere kompatibilitet med den faktiske adgangsvej.
Brug moderne adgangskode- og låsepolitikker
Konti, der kan åbne RDP-sessioner, har brug for stærke, unikke adgangskoder. Den nuværende NIST-vejledning understreger lange adgangskoder, screening af kompromitterede adgangskoder og ændringer efter mistanke om kompromittering frem for vilkårlige sammensætningsregler og rutinemæssig rotation. Kombiner lange adgangssætninger, MFA, sikker opbevaring og fjernelse af delte eller standard legitimationsoplysninger.
Konfigurer låsegrænser og varigheder som en del af en RDP bruteforce-beskyttelsesstrategi, der bremser automatiseret gætning uden at skabe en nem denial-of-service-tilstand. Basér indstillingerne på angrebsvolumen, overvågningskapacitet og supportkrav.
Hvordan skal du sikre RDP-kryptering og certifikater?
Krav om et passende sikkerhedslag
RDP kan bruge Transport Layer Security til at autentificere serveren og beskytte forbindelsen. Ifølge Microsoft Learn, certifikater sikrer Remote Desktop Services implementeringer og forbindelserne mellem RDS-serverroller.
Gennemgå denne politik:
Computerkonfiguration > Administrative skabeloner > Windows-komponenter > Fjernskrivebordsservices > Fjernskrivebords-session vært > Sikkerhed > Kræv brug af specifik sikkerhedslag til fjernforbindelser
Brug et certifikat, hvis emne eller emnealternativnavn matcher det værtsnavn, som brugerne indtaster. Klienter bør stole på den udstedende certifikatmyndighed og bør ikke trænes til at ignorere identitetsadvarsler.
Politikken for krypteringsniveauet for klientforbindelse gælder for native RDP-kryptering, ikke sessioner beskyttet med SSL/TLS. Overvåg certifikatfornyelse og binding, da et udløbet eller forkert tildelt certifikat kan gøre en hærdet lytter eller gateway utilgængelig.
Hvilke RDP-sessionfunktioner skal du begrænse?
Deaktiver unødvendig enheds- og ressourceomdirigering
RDP kan omdirigere lokale ressourcer ind i en fjernsession. Disse funktioner forbedrer produktiviteten, men skaber også veje for malware, filoverførsler og datatab.
Gennemgå om brugerne reelt har brug for adgang til udklipsholderen, lokal drevkortlægning, printere, USB-enheder, lydoptagelse, kameraer, smartkort eller webautentificeringsomdirigering.
Politikker findes under:
Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Enheds- og ressourceomdirigering
Microsoft leverer kontroller til drevkortlægning og retning af udklipsholderoverførsel. For eksempel kan administratorer tillade almindelig tekst, mens de blokerer for rigere indhold eller deaktivere overførsel i én retning.
Deaktiver ikke hver funktion uden at teste. En applikationsleveringsserver kan kræve printeromdirigering, mens en privilegeret jump host muligvis ikke har brug for udklipsholder- eller drevoverførsel.
Forhindre adgangskodegemning hvor det er passende
Gemte RDP-legitimationsoplysninger øger eksponeringen på administratorarbejdsstationer og delte slutpunkter. Brug klientpolitikken:
Computerkonfiguration > Administrative skabeloner > Windows-komponenter > Fjernskrivebordsservices > Fjernskrivebordsforbindelseskunde > Tillad ikke, at adgangskoder gemmes
Når det er aktiveret, deaktiveres muligheden for at gemme adgangskoder, og gemte adgangskoder fjernes fra RDP-filer. Par denne kontrol med en godkendt credential-management proces.
Konfigurer grænser for inaktive og frakoblede sessioner
At lukke et RDP-vindue logger ikke nødvendigvis brugeren af. Applikationer kan forblive aktive, og sessionen kan genoptages senere.
Konfigurer grænser under:
Computerkonfiguration > Administrative skabeloner > Windows-komponenter > Fjernskrivebordsservices > Fjernskrivebords-session vært > Sessionstidgrænser
Indstil passende værdier for inaktive sessioner, frakoblede sessioner, maksimal aktiv varighed og RemoteApp logoff. Undgå en aggressiv timeout på tværs af hver arbejdsbyrde, da tvungen logoff kan afbryde opgaver eller usparet arbejde.
Privilegerede systemer retfærdiggør normalt kortere grænser end applikationsservere, der understøtter langvarige forretningsprocesser. Nyere Windows-politikker kan også afbryde fjernsessioner, når sessionen er låst.
Hvordan skal du sikre Windows-værten?
Hold RDP-servere og -klienter opdaterede
RDP-sikkerhed afhænger af begge sider af forbindelsen. En opdateret server kan stadig tilgås fra en kompromitteret administratorarbejdsstation, mens en forældet klient kan være udsat, når den opretter forbindelse til en ondsindet vært.
En bredere endpoint holdningsgennemgang bør også dække lokal administratoromfang, gemte legitimationsoplysninger og aktiv endpointbeskyttelse, før en vært godkendes til remote access.
Vedligehold understøttede versioner af Windows, Windows Server, Remote Desktop-klienter, RDS-roller, identitetskomponenter, adgangsporte og endpoint-sikkerhedsagenter. Prioriter opdateringer, der påvirker fjernkodeudførelse, autentificering og håndtering af legitimationsoplysninger.
Testopdateringer mod repræsentative applikationer, print, omdirigering og autentificeringsarbejdsgange. Kompatibilitetstestning bør ikke blive en grund til at lade kritiske systemer være uopdaterede i det uendelige.
Segment RDP-systemer
En autentificeret RDP-session bør ikke automatisk give adgang til hver intern subnet. Brug netværkssegmentering og vært-firewalls til at kontrollere, hvad en RDP-server kan nå efter login.
Adskil administrative jump-værter, RD Session Hosts, domænecontrollere, filservere, databaseservere, backup-infrastruktur, administrationsgrænseflader og brugerarbejdsstationer, hvor det er relevant.
Anvend udgående restriktioner, når serverrollen tillader det. Hvis en angriber kompromitterer en RDP-session, kan segmentering begrænse lateral bevægelse, adgang til sikkerhedskopier og kommunikation med ekstern kommandoinfrastruktur.
Fjern unødvendig software og privilegier
Hver tjeneste, applikation og administrationsværktøj, der er installeret på en RDP-vært, udvider det miljø, der skal opdateres og overvåges.
Fjern forældede applikationer, ubrugte Windows-funktioner og forladte agenter. Begræns softwareinstallation, PowerShell, kommandolinjeværktøjer og administrative grænseflader i henhold til serverrollen.
For multi-user applikationsservere kan applikationskontrol og stramt afgrænsede filsystemtilladelser forhindre en bruger i at få adgang til en anden brugers data eller starte uautoriserede eksekverbare filer.
Hvordan skal du overvåge RDP-aktivitet?
Aktiver og centraliser Windows-revision
Lokale logs er nyttige til fejlfinding, men er ikke tilstrækkelige, hvis en angriber kan ændre eller slette beviser efter at have kompromitteret serveren. Send vigtige begivenheder til en SIEM, Windows Event Collector eller en anden beskyttet logningsplatform.
Indsaml mindst:
- Succesfulde og mislykkedes logonforsøg
- Konto låsninger
- Ændringer i gruppe-medlemskab
- Nye eller ændrede brugerkonti
- Oprettelse og afbrydelse af fjernsession
- Firewall ændringer
- Serviceinstallation
- Tildeling af privilegier
- Endpoint-sikkerhedsalarmer
Sikkerhedshændelser 4624 og 4625 registrerer succesfulde og mislykkede logins. For RDP-analyse skal du inspicere logintypen, kontoen, arbejdsstationen og kilde netværksoplysningerne. Interaktive fjernlogins identificeres ofte som logintype 10.
Terminal Services operationelle logfiler tilføjer sessionskontekst, mens hændelse 4779 registrerer frakobling fra en Windows-station.
Advarsel om adfærd, ikke kun individuelle fejl
En enkelt mislykket adgangskode kan være en brugerfejl. Detektionsregler bør se efter mønstre såsom mange fejl fra én adresse, én kilde, der tester flere brugernavne, fejl på tværs af flere servere eller en succesfuld login efter gentagne fejl.
Nyttige signaler inkluderer også adgang fra et nyt land, privilegeret brug uden for normale arbejdstider, inaktiv-konto aktivitet, nyt gruppemedlemskab efterfulgt af RDP, deaktivering af sikkerhedsværktøjer eller usædvanlig filkryptering. En avanceret sikkerhedsløsning kan hjælpe med at centralisere disse opdagelser og automatisere svar på mistænkelig RDP-adfærd. Tærsklerne skal afspejle normal adfærd og organisationens driftsmodel.
Forbered en RDP hændelsesresponsprocedure
Hærdning kan ikke garantere, at ingen kontoer eller servere vil blive kompromitteret. Administratorer har brug for en dokumenteret reaktionsproces, før en advarsel opstår.
Proceduren bør dække isolation, blokering af fjendtlige IP-adresser, nulstilling af konti, tilbagekaldelse af sessioner, bevarelse af logfiler, kontrol af nabosystemer, gennemgang af vedholdenhed, betroet genopretning og genbekræftelse af baseline.
Oprethold en konsol, cloud kontrolplan eller en out-of-band genoprettelsesvej. Ellers kan en forkert firewall- eller gruppepolitikændring efterlade administratorer ude af stand til at nå serveren under en hændelse.
Hvordan kan du validere en RDP-hærdningsbaseline?
En indstilling implementeres ikke blot fordi den vises i et Group Policy Object. Bekræft, at den tilsigtede politik når den målrettede enhed og giver det forventede resultat.
Nyttige kommandoer inkluderer:
gpresult /h C:\Temp\RDP-Policy.html Get-NetFirewallRule -DisplayGroup "Remote Desktop" | Select-Object DisplayName, Enabled, Direction, Action Get-LocalGroupMember -Group "Remote Desktop Users" Test-NetConnection server.example.com -Port 3389
Validering bør dække både succesfulde og mislykkede tilfælde. Bekræft, at godkendte brugere kan oprette forbindelse, uautoriserede brugere og kilder blokeres, MFA vises, certifikater er betroede, omdirigeringsbegrænsninger forbliver aktive, og sessionsgrænser fungerer.
Bekræft, at central logning modtager succesfulde og mislykkede forsøg, og at administratorer kan bruge genoprettelsesruten. Test restriktive ændringer på et repræsentativt system, og registrer undtagelser med en ejer og udløbsdato.
Hvor ofte skal du gennemgå RDP-hærdningschecklisten?
Gennemgå baseline efter større Windows-opdateringer, netværksændringer, identitetsmigrationer, nye RDS-implementeringer og sikkerhedshændelser. Planlæg formelle gennemgange i henhold til organisationens risikoprofil.
Mellem anmeldelserne skal du være opmærksom på konfigurationsdrift, herunder at RDP bliver genaktiveret, nye offentlige firewallregler, tilføjede Remote Desktop-brugere, deaktiveret NLA, udløbne certifikater, uovervågede servere, MFA-undtagelser, nyaktiveret omdirigering og forældede leverandørkonti.
Automatiseret konfigurationsstyring kan opdage disse afvigelser mere pålideligt end lejlighedsvise manuelle kontroller.
Styrk RDP-beskyttelse med TSplus
Native Windows-kontroller giver fundamentet for RDP-hærdning. TSplus Advanced Security tilføjer centraliserede beskyttelser for Windows og Remote Desktop-servere, herunder automatiseret blokering af brute-force, geografiske restriktioner, ransomware-beskyttelse, kontroller af betroede enheder, politikker for arbejdstid og beskyttelse mod ondsindede IP-adresser.
Disse kontroller kan forstærke baseline ved automatisk at reagere på fjendtlig adfærd og indsnævre, hvor, hvornår og hvordan fjernbrugere opretter forbindelse. De erstatter ikke Windows-hærdning, men de kan forenkle håndhævelse og overvågning på tværs af flere systemer.
Konklusion
En sikker RDP-implementering begynder med at fjerne unødvendige lyttere og undgå direkte interneteksponering. Systemer, der stadig kræver RDP, bør kombinere NLA, MFA, begrænsede brugerrettigheder, betroede TLS-certifikater, beskyttelse af legitimationsoplysninger, begrænset omdirigering, opdatering, segmentering og centraliseret overvågning.
Den endelige baseline skal matche rollen for hvert system. En intern administrationsserver, cloud virtuel maskine, multi-bruger RD Session Host og kontraktøradgangsmiljø kræver ikke identiske kontroller. Dokumenter den valgte konfiguration, test den mod reelle arbejdsgange og gennemgå hver undtagelse regelmæssigt.
)
)
)
