Hvilke porte bruger RDP? Standard RDP-port 3389 og almindelige alternativer

Remote Desktop Protocol (RDP) er en af de mest almindelige måder at få adgang til Windows-servere og -desktops på afstand. Det er indbygget i Windows, bredt understøttet af tredjeparts-klienter og ofte brugt til administration, support og fjernarbejde.

Men når du offentliggør remote access til brugere (eller kunder), bliver et spørgsmål hurtigt kritisk for forbindelse og sikkerhed: hvilke porte bruger RDP? I denne artikel vil vi gennemgå de standardporte, de "ekstra" porte, der kan optræde afhængigt af din opsætning, og hvad du skal gøre, hvis du ønsker remote access uden at eksponere port 3389.

Standard RDP-port

Som standard, RDP bruger TCP-port 3389.

Det er den standard lytteport på Windows for Remote Desktop-forbindelser, og det er den port, de fleste firewalls og NAT-regler videresender, når nogen "åbner RDP til internettet." Microsoft registrerer også 3389 for RDP-relaterede tjenester (ms-wbt-server) for både TCP og UDP.

Er RDP altid på port 3389?

Det meste af tiden, ja - men ikke altid. 3389 er standarden, hvilket betyder, at en standard Windows-installation med Remote Desktop aktiveret vil lytte der, medmindre en administrator ændrer det. I virkelige miljøer vil du ofte se RDP flyttet til en anden port for grundlæggende støjreduktion mod automatiserede scanninger.

Du vil også se RDP-trafik vises at bruge andre porte, når det bliver proxied eller tunneleret (for eksempel gennem en RD Gateway, VPN eller en fjernadgangsportal).

Hovedpunktet: dine brugere kan være "i brug af RDP" uden at oprette forbindelse til 3389 direkte, afhængigt af hvordan fjernadgang er offentliggjort.

Hvorfor bruger RDP både TCP og UDP?

RDP har historisk set været afhængig af TCP for pålidelig levering, men moderne RDP kan også bruge UDP (typisk på det samme portnummer, 3389) for at forbedre reaktiviteten. UDP hjælper i scenarier, hvor det er vigtigt at minimere forsinkelse—musbevægelser, skrivning, video og lyd kan føles mere glatte, fordi UDP undgår noget af den overhead, som TCP introducerer, når pakker går tabt eller skal genudsendes.

I praksis bruger mange opsætninger TCP som baseline og UDP som en præstationsforbedring, når netværket tillader det. Hvis UDP er blokeret, fungerer RDP normalt stadig—bare med nedsat ydeevne eller en "mere forsinket" følelse under dårlige netværksforhold.

UDP og yderligere portadfærd

Udover TCP 3389 RDP kan også involvere:

• UDP 3389 – Bruges af RDP til at forbedre reaktiviteten og reducere latenstid (når UDP-transport er aktiveret og tilladt).
• TCP 443 – Bruges, når du opretter forbindelse gennem Remote Desktop Gateway (RDP indkapslet i HTTPS).
• UDP 3391 – Almindeligt anvendt til “RDP over UDP” via RD Gateway (ydelsessti gennem gatewayen).
• TCP 135 / 139 / 445 – Kan forekomme i visse miljøer for relaterede Windows-tjenester og omdirigeringsscenarier (f.eks. RPC/SMB-afhængige funktioner).

Hvis dit RDP-miljø sidder bag en firewall, NAT eller sikkerhedsgateway, skal du ofte validere, hvilken RDP-sti der faktisk bruges (direkte 3389 vs. gateway 443/3391) og sikre, at politikkerne stemmer overens.

Hurtig firewall-tjekliste for RDP-porte

For at undgå trial-and-error fejlfinding, bekræft at du har tilladt TCP 3389 (og UDP 3389, hvis du ønsker den bedste ydeevne). Hvis du bruger RD Gateway, skal du sørge for, at TCP 443 (og eventuelt UDP 3391) er åbent på gatewayen, ikke nødvendigvis på målserveren.

Sikkerhedsproblemer for virksomheder, der bruger RDP

Fra et sikkerhedsmæssigt synspunkt er det en højrisiko beslutning at offentliggøre TCP 3389 til internettet. Det bliver kraftigt scannet, hyppigt brute-forcet , og ofte målrettet under ransomware-kampagner.

Hvorfor dette er vigtigt i virkelige implementeringer:

• Et enkelt eksponeret RDP-endepunkt kan blive et konstant mål for adgangskodegætning.
• RDP-sikkerhed afhænger i høj grad af hærdning (MFA, kontolåsning, opdatering, VPN/gateway-brug, IP-restriktioner)
• “Bare åbn 3389” ender ofte med løbende firewall- og endpointvedligeholdelse
• Efterhånden som miljøerne vokser, bliver det vanskeligt at håndhæve ensartede kontroller på tværs af servere.

For mange organisationer bliver målet: at levere remote access uden at efterlade 3389 eksponeret.

Praktiske hærdningstrin, hvis du skal bruge RDP

Hvis du ikke kan undgå RDP, skal du reducere eksponeringen ved at kræve MFA, aktivere NLA, håndhæve stærke låsepolitikker, begrænse adgangen via VPN eller IP-whitelisting og sikre, at systemerne er fuldt opdaterede. Når det er muligt, skal du placere RDP bag en RD Gateway (443) i stedet for at eksponere 3389 direkte.

En sikrere alternativ: TSplus Remote Access

Hvis du ønsker fjernadgang, mens port 3389 holdes lukket for det offentlige internet, TSplus Remote Access giver en praktisk tilgang: offentliggør applikationer og skriveborde gennem en webportal ved hjælp af standard webporte.

Hvorfor TSplus kan være et bedre valg:

• Kræver ikke at åbne port 3389 for internettet (du kan stole på 80/443 for webadgang)
• Browser-baseret adgang med HTML5 Webportalen, der reducerer kompleksiteten på klientsiden
• Kan lettere håndhæve HTTPS og standard sikkerhedspraksis på en velkendt weboverflade
• Fungerer godt til publicering af applikationer (RemoteApp-stil) såvel som fulde skriveborde
• Kan forstærkes med tilføjelser som To-Faktor Autentifikation og yderligere beskyttelser

For teams der har brug for at betjene fjernbrugere pålideligt, hjælper dette med at reducere angrebsoverfladen, mens det forenkler implementeringen og bruger onboarding .

Afsluttende tanker

TCP 3389 er den standard RDP-port—og RDP kan også bruge UDP 3389, samt 443/3391 når en gateway er involveret, sammen med andre Windows-netværksporte i specifikke scenarier. Hvis fjernadgang er forretningskritisk, så overvej om du virkelig ønsker at holde 3389 eksponeret.

Mange organisationer bevæger sig mod en tilgang, hvor brugere opretter forbindelse gennem HTTPS (443) til en sikker portal, og det interne RDP-lag forbliver privat.

Hvis du undersøger en sikrere måde at levere remote access på, TSplus Remote Access kan hjælpe dig med at publicere apps og skriveborde gennem nettet, mens du holder din infrastruktur enklere og mere sikker.