Vilka portar använder RDP?

Remote Desktop Protocol (RDP) är ett av de vanligaste sätten att få åtkomst till Windows-servrar och skrivbord på distans. Det är inbyggt i Windows, stöds i stor utsträckning av tredjepartsprogram och används ofta för administration, support och distansarbete.

Men när du publicerar fjärråtkomst till användare (eller kunder) blir en fråga snabbt avgörande för anslutning och säkerhet: vilka portar använder RDP? I den här artikeln kommer vi att gå igenom standardportarna, de "extra" portar som kan dyka upp beroende på din konfiguration, och vad du ska göra om du vill ha fjärråtkomst utan att exponera port 3389.

Standard RDP-port

Som standard, RDP använder TCP-port 3389.

Det är den standardlyssningsporten på Windows för Remote Desktop-anslutningar, och det är den port som de flesta brandväggar och NAT-regler vidarebefordrar när någon "öppnar RDP för internet." Microsoft registrerar också 3389 för RDP-relaterade tjänster (ms-wbt-server) för både TCP och UDP.

Är RDP alltid på port 3389?

Det mesta av tiden, ja—men inte alltid. 3389 är standard, vilket innebär att en standardinstallation av Windows med Remote Desktop aktiverat kommer att lyssna där om inte en administratör ändrar det. I verkliga miljöer ser du ofta att RDP flyttas till en annan port för grundläggande brusreducering mot automatiserade skanningar.

Du kommer också att se RDP-trafik dyka upp att använda andra portar när det proxas eller tunnlas (till exempel genom en RD Gateway, VPN eller en fjärråtkomstportal).

Huvudpunkten: dina användare kan "använda RDP" utan att ansluta direkt till 3389, beroende på hur fjärråtkomst publiceras.

Varför använder RDP både TCP och UDP?

RDP har historiskt förlitat sig på TCP för pålitlig leverans, men modern RDP kan också använda UDP (vanligtvis på samma portnummer, 3389) för att förbättra responsiviteten. UDP hjälper i scenarier där det är viktigt att minimera fördröjning—musrörelser, skrivande, video och ljud kan kännas smidigare eftersom UDP undviker en del av den overhead som TCP introducerar när paket går förlorade eller behöver återutsändas.

I praktiken använder många installationer TCP som en grund och UDP som en prestandaförbättring när nätverket tillåter det. Om UDP blockeras fungerar RDP vanligtvis fortfarande—bara med minskad prestanda eller en "segare" känsla under dåliga nätverksförhållanden.

UDP och ytterligare portbeteende

Utöver TCP 3389 RDP kan också involvera:

UDP 3389 – Används av RDP för att förbättra responsiviteten och minska latens (när UDP-transport är aktiverad och tillåten).
TCP 443 – Används när du ansluter via Remote Desktop Gateway (RDP inkapslat i HTTPS).
UDP 3391 – Vanligtvis använt för “RDP över UDP” via RD Gateway (prestandaväg genom gatewayen).
TCP 135 / 139 / 445 – Kan förekomma i vissa miljöer för relaterade Windows-tjänster och omdirigeringsscenarier (t.ex. funktioner som är beroende av RPC/SMB).

Om din RDP-miljö ligger bakom en brandvägg, NAT eller säkerhetsgateway, måste du ofta validera vilken RDP-väg som faktiskt används (direkt 3389 vs. gateway 443/3391) och säkerställa att policys matchar.

Snabb brandväggskontrollista för RDP-portar

För att undvika felsökning genom trial-and-error, bekräfta att du har tillåtit TCP 3389 (och UDP 3389 om du vill ha bästa prestanda). Om du använder RD Gateway, se till att TCP 443 (och eventuellt UDP 3391) är öppet på gatewayen, inte nödvändigtvis på måltjänst.

Säkerhetsproblem för företag som använder RDP

Från ett säkerhetsperspektiv är det en hög risk att publicera TCP 3389 på internet. Det skannas intensivt, frekvent bruteforcead , och vanligtvis måltavlor under ransomware-kampanjer.

Varför detta är viktigt i verkliga implementationer:

Ett enda exponerat RDP-slutpunkt kan bli ett konstant mål för lösenordsgissning.
RDP-säkerhet beror starkt på härdning (MFA, kontolåsning, patchning, VPN/gateway-användning, IP-restriktioner)
“Öppna bara 3389” blir ofta till pågående brandväggs- och slutpunktunderhåll
När miljöer växer blir det svårt att upprätthålla konsekventa kontroller över servrar.

För många organisationer blir målet: att leverera fjärråtkomst utan att lämna 3389 exponerad.

Praktiska härdningssteg om du måste använda RDP

Om du inte kan undvika RDP, minska exponeringen genom att kräva MFA, aktivera NLA, genomdriva starka låsningpolicyer, begränsa åtkomst via VPN eller IP-whitelisting, och säkerställa att systemen är helt uppdaterade. När det är möjligt, placera RDP bakom en RD Gateway (443) istället för att exponera 3389 direkt.

En säkrare alternativ: TSplus Remote Access

Om du vill ha fjärråtkomst samtidigt som port 3389 hålls stängd för allmänna internet, TSplus Remote Access ger en praktisk metod: publicera applikationer och skrivbord genom en webbportal med hjälp av standardwebbportar.

Varför TSplus kan vara en bättre lösning:

Kräver inte att port 3389 exponeras mot internet (du kan lita på 80/443 för webbåtkomst)
Webbläsartillgång med HTML5 Web Portal, vilket minskar komplexiteten på klientsidan
Kan enklare genomdriva HTTPS och standard säkerhetspraxis på en bekant webbplats.
Fungerar bra för publicering av applikationer (RemoteApp-stil) såväl som fullständiga skrivbord.
Kan förstärkas med tillägg som Tvåfaktorsautentisering och ytterligare skydd.

För team som behöver betjäna fjärranvändare på ett tillförlitligt sätt, hjälper detta att minska angreppsyta samtidigt som det förenklar distributionen och användarintroduktion .

Slutliga tankar

TCP 3389 är den standard RDP-porten—och RDP kan också använda UDP 3389, samt 443/3391 när en gateway är involverad, tillsammans med andra Windows-nätverksportar i specifika scenarier. Om fjärråtkomst är affärskritisk, överväg om du verkligen vill ha 3389 exponerad.

Många organisationer går över till en metod där användare ansluter via HTTPS (443) till en säker portal och det interna RDP-lagret förblir privat.

Om du utforskar ett säkrare sätt att leverera fjärråtkomst, TSplus Remote Access kan hjälpa dig att publicera appar och skrivbord via webben samtidigt som du håller din infrastruktur enklare och mer säker.