Remote Desktop (RDP) 3389 Port Değişikliği ve Erişim Güvenliği

Remote Desktop Protocol (RDP), Microsoft tarafından geliştirilen ve Client-Server mimarisi üzerine kurulu bir protokoldür. Kullanıcının uzak bir sistemde oturum açarak grafiksel arayüz üzerinden çalışmasını sağlar. Sunucu tarafında bağlantıları Remote Desktop Services (TermService) servisi karşılar ve varsayılan olarak TCP 3389 Port'unu dinler. Yeni sürümlerde aynı Port üzerinde UDP transport'u da kullanılır.

3389, internet üzerinde sürekli taranan Port'ların başında gelir. Bu yüzden RDP'nin dinlediği Port'u değiştirmek, otomatik taramalarda sistemin görünürlüğünü azaltmak için sık başvurulan bir yöntemdir. Bu makalede Port değişikliğinin neyi sağlayıp neyi sağlamadığını, değişikliği Registry ve PowerShell üzerinden nasıl yaptığımı, Firewall ve doğrulama adımlarını, geri alma yolunu ve RDP erişimini gerçek anlamda koruyan katmanları anlatıyorum. Remote Desktop'ın etkinleştirilmesi ve RDS rollerinin kurulumu bu makalenin kapsamı dışındadır.

1- Varsayılan RDP Port'unun Riskleri

3389 Port'u Shodan, Nmap ve Masscan gibi araçlarla dakikalar içinde tespit edilir. Internet'e açık bir sunucuda bu Port erişilebilir durumdaysa sistem, hiçbir hedefleme yapılmadan otomatik saldırı listelerine girer. Aşağıdaki tablo, açık bir RDP Port'unun davet ettiği başlıca riskleri özetliyor.

2- Port Değişikliği Neyi Sağlar, Neyi Sağlamaz

Port değişikliği, yalnızca 3389'u tarayan botların sistemi bulmasını zorlaştırır ve Log'lardaki gürültüyü belirgin şekilde azaltır. Tüm Port aralığını tarayan bir saldırgan ise yeni Port'u kısa sürede bulur ve RDP'nin cevap verdiğini görür. Yani bu değişiklik görünürlüğü azaltır, saldırı yüzeyini değiştirmez.

Aynı nedenle Port değişikliği bir açığa karşı koruma da sağlamaz. BlueKeep gibi bir açıktan korunmanın yolu güncellemeler ve NLA'dır. Parola denemelerine karşı koruma ise Account Lockout Policy, MFA ve erişimin ağ seviyesinde kısıtlanmasıyla sağlanır. Bu katmanları 8. ve 9. bölümlerde anlatıyorum.

3- Ön Kontrol Listesi

Değişikliğe başlamadan önce aşağıdaki maddeleri doğruluyorum.

Port seçiminde 0-1023 arası Well-Known Port'lardan ve 49152-65535 arası Dynamic aralıktan kaçınıyorum. Dynamic aralık Windows'un giden bağlantılar için kullandığı ephemeral Port'ları içerir ve buradan seçilen bir Port ileride çakışmaya yol açabilir. Bu örnekte 5011 kullanıyorum.

Mevcut Port değerini yönetici yetkisiyle açtığım PowerShell'de aşağıdaki komutla okuyorum.

Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name 'PortNumber'

PortNumber   : 3389
PSPath       : Microsoft.PowerShell.Core\Registry::HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp
PSParentPath : Microsoft.PowerShell.Core\Registry::HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations
PSChildName  : RDP-Tcp
PSDrive      : HKLM
PSProvider   : Microsoft.PowerShell.Core\Registry

Çıktıda PortNumber : 3389 görüyorsam sunucu varsayılan Port'u dinliyordur. Ardından yeni Port'un boş olduğunu kontrol ediyorum. Komut hiçbir çıktı döndürmüyorsa 5011 TCP tarafında kullanımda değildir.

Get-NetTCPConnection -LocalPort 5011 -ErrorAction SilentlyContinue
Get-NetUDPEndpoint -LocalPort 5011 -ErrorAction SilentlyContinue

4- RDP Port'unun Registry Üzerinden Değiştirilmesi

RDP'nin dinlediği Port, HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp anahtarı altındaki PortNumber (REG_DWORD) değerinde tutulur. Aynı değer hem TCP hem UDP Listener için geçerlidir. Değişikliği önce Registry Editor üzerinden adım adım yapıyorum, bölümün sonunda aynı işlemin PowerShell karşılığını veriyorum.

Adım 1 - Registry Editor'ün Açılması

Çalıştır (Run) ekranına regedt32 yazıyorum. Windows XP ve Windows Server 2003'ten bu yana regedt32 ile regedit aynı Registry Editor'ü açar, aralarında özellik farkı yoktur.

Adım 2 - Find Penceresinin Açılması

Registry Editor açıldığında menüde Edit'e, ardından Find...'a tıklıyorum.

Adım 3 - RDP-Tcp Anahtarının Aranması

Find penceresinde RDP-Tcp yazıp Find Next'e tıklıyorum. Arama ilk olarak ControlSet001 gibi başka bir Control Set altındaki kopyaya ulaşabilir. Doğru konum CurrentControlSet altındaki anahtardır, farklı bir konuma ulaşırsam F3 ile aramaya devam ediyorum. Adres çubuğuna anahtar yolunu doğrudan yapıştırmak da aynı sonucu verir.

Adım 4 - RDP-Tcp Anahtarının Bulunması

Registry Editor, RDP-Tcp anahtarını bulup seçili hale getiriyor. Sağ panelde Port değerini tutan PortNumber kaydını görüyorum.

Adım 5 - PortNumber Değerinin Değiştirilmesi

PortNumber kaydına çift tıklıyorum. Açılan pencerede değer varsayılan olarak Hexadecimal gösterilir ve 3389 burada d3d olarak görünür. Önce Base alanını Decimal'e çeviriyorum, ardından 3389 değerini 5011 ile değiştirip OK'a tıklıyorum.

Adım 6 - Değişikliğin Kontrol Edilmesi

PortNumber kaydının Data sütununda yeni değeri görüyorum.

Kontrol Noktası
Data sütununda 0x00001393 (5011) görünüyor olmalı. Değer bu aşamada yalnızca Registry'ye yazılmıştır, servis yeniden başlatılana kadar RDP hâlâ 3389'u dinler.

PowerShell ile Aynı İşlem

Registry Editor yerine PowerShell kullanmak, aynı değişikliği birden fazla sunucuda tekrarlanabilir şekilde yapmamı sağlar. Yönetici yetkisiyle açtığım PowerShell'de aşağıdaki komutu çalıştırıyorum. 5011 değerini kendi seçtiğiniz Port ile değiştirin.

$portValue = 5011
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name 'PortNumber' -Value $portValue

5- Firewall Kuralı ve Servisin Yeniden Başlatılması

Windows Defender Firewall'daki hazır Remote Desktop - User Mode (TCP-In) ve (UDP-In) kuralları 3389'a bağlıdır ve yeni Port'u kapsamaz. Sunucunun gelen bağlantıyı kabul etmesi için yeni Port'a TCP ve UDP olmak üzere iki Inbound kural ekliyorum. Sunucu bağlantıyı yalnızca kabul ettiği için Outbound kurala gerek yoktur.

$portValue = 5011
New-NetFirewallRule -DisplayName 'RDP-5011-TCP-In' -Profile Domain,Private -Direction Inbound -Action Allow -Protocol TCP -LocalPort $portValue
New-NetFirewallRule -DisplayName 'RDP-5011-UDP-In' -Profile Domain,Private -Direction Inbound -Action Allow -Protocol UDP -LocalPort $portValue

Microsoft Learn'deki örnek komut yalnızca Public profilini kullanır. Domain'e üye bir sunucuda ağ bağlantısı genellikle Domain profilindedir ve kural yanlış profile yazılırsa bağlantıya izin vermez. Sunucunun hangi profilde olduğunu Get-NetConnectionProfile ile görüp -Profile değerini buna göre belirliyorum. Erişimi yalnızca yönetim ağıyla sınırlamak için kurala -RemoteAddress parametresiyle izin verilen IP aralığını eklemek de mümkündür.

Sunucu ile Client arasında başka bir Firewall veya NAT cihazı varsa, yeni Port'un orada da açılması gerekir. Port'un hazır olduğundan emin olduktan sonra servisi yeniden başlatıyorum. PortNumber değeri servis başlarken okunduğu için yeni Port ancak bu adımdan sonra devreye girer.

Restart-Service -Name TermService -Force

6- Yeni Port'un Doğrulanması ve Client'tan Bağlantı

Sunucu tarafında yeni Port'un dinlenip dinlenmediğini PowerShell'de kontrol ediyorum. İlk komutta State sütununda Listen, ikinci komutta ise 5011 için bir UDP Endpoint görüyorsam Listener yeni Port'ta çalışıyordur. Aynı kontrol Command Prompt'ta netstat -an | findstr :5011 ile de yapılabilir, burada LISTENING satırı aranır.

Get-NetTCPConnection -LocalPort 5011 -State Listen
Get-NetUDPEndpoint -LocalPort 5011

Sunucunun Port'u dinliyor olması, Client'ın ona ulaşabildiği anlamına gelmez. Aradaki Firewall'ları da kapsayan asıl doğrulamayı Client üzerinden Test-NetConnection ile yapıyorum. {Sunucu Adı} yerine kendi sunucunuzun adını veya IP adresini yazın. Çıktıda TcpTestSucceeded : True görülmelidir.

Test-NetConnection -ComputerName {Sunucu Adı} -Port 5011

Bağlantıyı kurarken Remote Desktop Connection (mstsc) adres alanına sunucu adını veya IP adresini, iki nokta üst üste ile yeni Port numarasını yazıyorum. Örneğin 10.26.5.100:5011. Port belirtilmezse Client 3389'a bağlanmaya çalışır. Client tarafında Port'u yönlendiren bir GPO ayarı yoktur, Port adres alanında veya .rdp dosyasında belirtilir.

Ortamda Remote Desktop Gateway kullanılıyorsa, RD RAP (Resource Authorization Policy) içindeki Allowed ports ayarı varsayılan olarak yalnızca 3389'a izin verir. Bu ayar yeni Port'u içerecek şekilde güncellenmezse Gateway üzerinden yapılan bağlantılar reddedilir.

7- Geri Alma ve Sorun Giderme

Değişikliği geri almak için PortNumber değerini 3389'a çekip servisi yeniden başlatıyorum ve yeni Port için oluşturduğum Firewall kurallarını kaldırıyorum. Bu işlemi de RDP üzerinden yapıyorsam, 3389 için hazır kuralların etkin olduğunu önce kontrol ediyorum.

Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name 'PortNumber' -Value 3389
Restart-Service -Name TermService -Force
Remove-NetFirewallRule -DisplayName 'RDP-5011-TCP-In','RDP-5011-UDP-In'

Yeni Port'a bağlanılamıyorsa kontrolleri sunucudan dışarıya doğru yapıyorum.

8- TLS, NLA ve Kullanıcı Hakları

TLS ve Sunucu Sertifikası

RDP bağlantısının şifrelenmesi, Require use of specific security layer for remote (RDP) connections GPO ayarıyla belirlenen güvenlik katmanına bağlıdır. Varsayılan değer Negotiate'tir ve Client destekliyorsa TLS kullanılır. Bu ayarı SSL olarak sabitlemek, bağlantının her zaman TLS ile kurulmasını sağlar. GPO'daki SSL adı tarihseldir, kullanılan protokol TLS'tir.

Hangi TLS sürümünün kullanılacağını ise Windows'un Schannel yapılandırması belirler. TLS 1.0 ve 1.1'in varsayılan olarak açık olup olmadığı Windows sürümüne bağlıdır. Eski sürümlerde bu protokoller açık gelir ve bağlantının yalnızca TLS 1.2 veya üzeriyle kurulması için Schannel üzerinden devre dışı bırakılmaları gerekir. Bu değişiklik RDP dışındaki uygulamaları da etkilediği için önce uyumluluk kontrol edilmelidir.

MITM riskinin asıl kaynağı çoğu zaman protokol sürümü değil, sunucunun Self-Signed sertifikasıdır. Kullanıcılar her bağlantıda gördükleri sertifika uyarısını onaylamaya alıştığında, araya giren sahte bir sunucunun uyarısı da aynı şekilde onaylanır. Kurumsal ortamda RDP için iç CA'dan verilen bir sertifikanın GPO ile dağıtılması bu uyarıyı ortadan kaldırır.

Network Level Authentication (NLA)

NLA etkin olduğunda kullanıcı, sunucuda bir oturum oluşturulmadan önce CredSSP ile kimlik doğrulamak zorundadır. Bu sayede kimlik doğrulamadan geçemeyen bir bağlantı sunucuda oturum kaynağı tüketmez ve kimlik doğrulama öncesinde istismar edilen açıkların saldırı yüzeyi daralır. NLA, BlueKeep'in istismarını da kimlik bilgisi gerektirir hale getirir.

NLA parola denemelerini engellemez, yalnızca denemelerin oturum açılmadan önce yapılmasını sağlar. Brute-Force'a karşı koruma Account Lockout Policy ve MFA ile sağlanır. NLA, Require user authentication for remote connections by using Network Level Authentication GPO ayarıyla zorunlu hale getirilebilir.

Kullanıcı Hakları

Bir kullanıcının RDP ile oturum açabilmesi için aşağıdaki koşulların birlikte sağlanması gerekir.

9- Katmanlı RDP Güvenliği ve Önerilen Mimari

Port değişikliği, aşağıdaki katmanlardan biri değil, bunların üzerine eklenen bir görünürlük azaltma adımıdır. Asıl hedef RDP Port'unun internetten hiç erişilebilir olmamasıdır.

Bu katmanların işe yarayıp yaramadığını Log'lar gösterir. Windows'ta RDP oturumlarının video kaydı yerleşik olarak alınmaz, ancak bağlantı ve oturum olayları aşağıdaki Event ID'lerle izlenebilir. Bu kayıtların merkezi bir SIEM'e veya Log toplama sistemine iletilmesi, başarısız deneme yoğunluğunu ve beklenmeyen kaynaklardan gelen oturumları görmeyi kolaylaştırır.

Yeni Port Listen durumunda görünüyor, Client'tan Test-NetConnection başarılı dönüyor ve mstsc ile sunucu:5011 adresine oturum açılabiliyorsa Port değişikliği tamamlanmıştır. Bu noktadan sonra 3389 için hazır Firewall kurallarını devre dışı bırakabilir ve aynı değişikliği diğer sunuculara PowerShell komutlarıyla uygulayabilirsiniz. RDP erişimini internete açmadan önce ise 9. bölümdeki katmanların en azından VPN veya RD Gateway, NLA ve Account Lockout Policy düzeyinde hazır olması gerekir.

Faydalı olması dileğiyle...