Innholdsfortegnelse

Remote Desktop Protocol (RDP) er en av de vanligste måtene å få tilgang til Windows-servere og -skrivbord eksternt. Det er innebygd i Windows, støttes bredt av tredjeparts klienter, og brukes ofte til administrasjon, støtte og fjernarbeid.

Men når du publiserer fjernadgang til brukere (eller kunder), blir ett spørsmål raskt kritisk for tilkobling og sikkerhet: hvilke porter bruker RDP? I denne artikkelen vil vi gå gjennom standardporter, de "ekstra" portene som kan dukke opp avhengig av oppsettet ditt, og hva du skal gjøre hvis du ønsker fjernadgang uten å eksponere port 3389.

Standard RDP-port

Som standard, RDP bruker TCP-port 3389.

Det er den standard lytteporten på Windows for Remote Desktop-tilkoblinger, og det er porten de fleste brannmurer og NAT-regler videresender når noen "åpner RDP for internett." Microsoft registrerer også 3389 for RDP-relaterte tjenester (ms-wbt-server) for både TCP og UDP.

Er RDP alltid på port 3389?

Det meste av tiden, ja—men ikke alltid. 3389 er standard, noe som betyr at en standard Windows-installasjon med Remote Desktop aktivert vil lytte der med mindre en administrator endrer det. I virkelige miljøer vil du ofte se at RDP flyttes til en annen port for grunnleggende støyreduksjon mot automatiserte skanninger.

Du vil også se RDP-trafikk vises å bruke andre porter når det blir prosessert eller tunnelt (for eksempel gjennom en RD Gateway, VPN eller en fjernaksessportal).

Hovedpoenget: brukerne dine kan "bruke RDP" uten å koble til 3389 direkte, avhengig av hvordan ekstern tilgang er publisert.

Hvorfor bruker RDP både TCP og UDP?

RDP har historisk sett vært avhengig av TCP for pålitelig levering, men moderne RDP kan også bruke UDP (vanligvis på samme portnummer, 3389) for å forbedre responsiviteten. UDP hjelper i scenarier der det er viktig å minimere forsinkelse—musbevegelser, skriving, video og lyd kan føles jevnere fordi UDP unngår noe av overhodet som TCP introduserer når pakker går tapt eller trenger retransmisjon.

I praksis bruker mange oppsett TCP som en basislinje og UDP som en ytelsesforbedring når nettverket tillater det. Hvis UDP er blokkert, fungerer RDP vanligvis fortsatt—bare med redusert ytelse eller en "mer treg" følelse under dårlige nettverksforhold.

UDP og tillegg av portatferd

I tillegg til TCP 3389 RDP kan også involvere:

  • UDP 3389 – Brukt av RDP for å forbedre responsiviteten og redusere latens (når UDP-transport er aktivert og tillatt).
  • TCP 443 – Brukes når du kobler til via Remote Desktop Gateway (RDP innkapslet i HTTPS).
  • UDP 3391 – Vanligvis brukt for “RDP over UDP” via RD Gateway (ytelsesbane gjennom gatewayen).
  • TCP 135 / 139 / 445 – Kan vises i visse miljøer for relaterte Windows-tjenester og omdirigeringsscenarier (f.eks. RPC/SMB-avhengige funksjoner).

Hvis RDP-miljøet ditt sitter bak en brannmur, NAT , eller sikkerhetsgateway, må du ofte validere hvilken RDP-sti som faktisk brukes (direkte 3389 vs. gateway 443/3391) og sikre at retningslinjene samsvarer.

Rask brannmur-sjekkliste for RDP-porter

For å unngå feilsøking gjennom prøving og feiling, bekreft at du har tillatt TCP 3389 (og UDP 3389 hvis du ønsker best ytelse). Hvis du bruker RD Gateway, må du sørge for at TCP 443 (og eventuelt UDP 3391) er åpen på gatewayen, ikke nødvendigvis på målserveren.

Sikkerhetsbekymringer for bedrifter som bruker RDP

Fra et sikkerhetsperspektiv er det en høy-risiko beslutning å publisere TCP 3389 til internett. Det blir grundig skannet, ofte bruteforced , og ofte målrettet under ransomware-kampanjer.

Hvorfor dette er viktig i virkelige distribusjoner:

  • En enkelt eksponert RDP-endepunkt kan bli et konstant mål for passordgjetting.
  • RDP-sikkerhet avhenger sterkt av herding (MFA, kontolås, oppdatering, VPN/gateway-bruk, IP-restriksjoner)
  • “Bare åpne 3389” ender ofte opp med pågående brannmur- og endepunktsvedlikehold
  • Etter hvert som miljøene vokser, blir det vanskelig å håndheve konsistente kontroller på tvers av servere.

For mange organisasjoner blir målet: levere fjernadgang uten å la 3389 være eksponert.

Praktiske herdingstrinn hvis du må bruke RDP

Hvis du ikke kan unngå RDP, reduser eksponeringen ved å kreve MFA, aktivere NLA, håndheve sterke låsepolitikker, begrense tilgang via VPN eller IP-whitelisting, og sørge for at systemene er fullt oppdatert. Når det er mulig, plasser RDP bak en RD Gateway (443) i stedet for å eksponere 3389 direkte.

En sikrere alternativ: TSplus Remote Access

Hvis du ønsker ekstern tilgang samtidig som port 3389 holdes stengt for offentlig internett, TSplus Remote Access gir en praktisk tilnærming: publiser applikasjoner og skrivebord gjennom en webportal ved å bruke standard webporter.

Hvorfor TSplus kan være et bedre valg:

  • Krever ikke eksponering av port 3389 til internett (du kan stole på 80/443 for webtilgang)
  • Nettleserbasert tilgang med HTML5 Web Portal, som reduserer kompleksiteten på klientsiden
  • Kan håndheve HTTPS og standard sikkerhetspraksiser enklere på en kjent weboverflate
  • Fungerer godt for publisering av applikasjoner (RemoteApp-stil) samt fullstendige skrivebord.
  • Kan forsterkes med tillegg som To-Faktor Autentisering og ekstra beskyttelser

For team som trenger å betjene eksterne brukere pålitelig, hjelper dette med å redusere angrepsflaten samtidig som det forenkler distribusjonen og brukeropplæring .

Avsluttende tanker

TCP 3389 er standard RDP-porten—og RDP kan også bruke UDP 3389, samt 443/3391 når en gateway er involvert, sammen med andre Windows-nettverksporter i spesifikke scenarier. Hvis ekstern tilgang er forretningskritisk, vurder om du virkelig ønsker å ha 3389 eksponert.

Mange organisasjoner går over til en tilnærming der brukere kobler seg til en sikker portal via HTTPS (443), og det interne RDP-laget forblir privat.

Hvis du utforsker en tryggere måte å levere fjernadgang på, TSplus Remote Access kan hjelpe deg med å publisere apper og skrivebord gjennom nettet samtidig som du holder infrastrukturen din enklere og mer sikker.

TSplus Fjernaksess Gratis prøveversjon

Ultimate Citrix/RDS-alternativ for skrivebords-/app-tilgang. Sikker, kostnadseffektiv, lokalt/cloud

Videre lesning

back to top of the page icon