Windows RDP Güvenliği için Öneriler

27.09.2015 | 16:00 Güvenlik , Windows Server 7 Yorum

Ağa bağlı Windows tabanlı sunucuları farklı bilgisayarlar üzerinden yönetirken kullanabileceğiniz servislerden birisi de Uzak Masaüstü Hizmetleridir (Remore Desktop Services). İnsanlar çeşitli uzak masaüstü araçları kullanarak hem yönetici seviyesinde işlemler gerçekleştirmek üzere (administrative mode), hem de son kullanıcı oturum/masaüstü/uygulama sanallaştırma hizmetlerinden faydalanmak için Microsoft Remote Desktop Services çalıştıran sunuculara bağlanırlar.

Genellikle RDP olarak anılan bu uzaktan erişim yöntemin asıl ismi Remote Desktop Connection yani Uzak Masaüstü Bağlantısı’dır. RDP ise uzak masaüstü bağlantısı sırasında istemci ve sunucu arasında kullanılan protokolün ismi yani Remote Desktop Protocol. Ama Windows sistem yöneticileri arasında o kadar yer etmiş ki RDP deyince herkes aynı şeyi anlıyor; protokol değil uzak masaüstü bağlantısı :)

guvenli-rdp-secure

Bir sistem yöneticisi olarak RDP bağlantısıyla eriştiğiniz sunucuda oturum açtığınızda genellikle doğrudan masaüstüne ulaşırsınız ve hesap yetkileri dahilinde neredeyse tüm yönetimsel işlemleri gerçekleştirebilirsiniz. Bu yüzden RDP güvenliği oldukça önemlidir. Bu açıdan bakıldığında iç ağdaki sunucular nispetten daha korunaklıdır çünkü -beklenmedik durumlar dışında- genellikle sadece belirli bir grup istemciyle iletişim halindedirler ve muhtemelen kuruluşun güvenlik çemberi içinde yer alırlar. Ama mesela internete üzerinde ulaşılabilen, servis sağlayıcılarda veya korunaksız uzak şubelerde çalışan RDP erişimi açık sunucular daha fazla risk altındadır ve güvenliği artırmak için özel tedbirler alınması gerekir.

Bu yazıda özellikle sistem yöneticilerini ilgilendiren Windows RDP güvenliğiyle ilgili bir grup öneri bulabilirsiniz.

Daha Güvenli RDP Bağlantısı İçin Öneriler

RDP ile bağlandığınız Windows tabanlı sunucuları daha güvenli hale getirmek için aşağıdaki özelliklerden faydalanabilirsiniz. Bu maddelerin birçoğu doğrudan internete açık sunucular için daha anlamlı olabilir, ama eğer imkanınız varsa VPN arkasındaki veya doğrudan iç ağda çalışan sunucular için de devreye almak iyi bir fikirdir.

1) Güvenlik Güncellemelerini ve Duyuruları Takip Edin

Aslında bakarsanız sadece RDP erişimi açık sunucular için değil tüm sunucular için düzenli olarak Windows güvenlik güncelleştirmelerini takip edin. Bu işi kolaylaştırmak için güncellemeleri otomatik olarak indirip yükleyip sunucuyu yeniden başlatacak şekilde ayarlayabilirsiniz. Her ne kadar çok sık yaşanmasa da ansızın ortaya çıkabilecek bir protokol zafiyetinde (ki mesela bu, bu veya bu) çoğu zaman tek korunma yöntemi Windows güvenlik güncelleştirmelerini yüklemektir. Bu süre zarfında RDP’yi kapatmak ise ancak geçici çözüm olur. Şu aklınızda bulunsun: Eğer bir zafiyet için publicly disclosed gibi özel durumlar yoksa, Windows güvenlik güncellemeleri periyodik olarak her ayın 2. Salı günü yayınlanır.

2) Sertifika Tabanlı TLS ve Kimlik Doğrulama Kullanın

Güvenlik seviyesini artırmak için dış güvenlik protokollerinin desteğiyle sağlanan TLS tabanlı trafik şifrelemeyi ve sertifika tabanlı kimlik doğrulamayı devreye alın. Ayrıca sunucuya erişirken isim (hostname, fqdn, dns name, vb) kullanın.

Uzak masaüstü bağlantısı, protokol tasarımı gereği varsayılan olarak 4 farklı seviyede şifreleme yapabilir. Bu şifreleme seviyelerine native RDP encryption veya RDP standart şifreleme seviyeleri denir. Bağlantı sırasında hangi seviye şifrelemenin kullanılacağına ise çoğu zaman sunucu karar verir/vermelidir ve istemcinin de (os/mstsc.exe) seçilen şifreleme seviyesine uyum sağlayabilmesi gerekir. Aksi durumda bağlantı gerçekleşmez.

RDP Standart Şifreleme Seviyeleri:

  1. Low: Sadece istemciden sunucuya giden trafik şifrelenir. Şifreleme için 56-bit’lik anahtarlar kullanılır.
  2. Client Compatible: İstemci ve sunucu arasındaki trafik çift yönlü olarak şifrelenir. Şifreleme için istemcinin desteklediği maksimum anahtar uzunluğu dikkate alınır ve genellikle ortamda 128-bit ve yukarısını desteklemeyen istemciler varsa kullanılır.
  3. High: İstemci ve sunucu arasındaki trafik 128-bit’lik anahtarlar kullanılarak çift yönlü olarak şifrelenir.
  4. FIPS: İstemci ve sunucu arasındaki trafik çift yönlü olarak şifrelenir. Şifreleme için Federal Information Processing Standard (FIPS) uyumlu metotlar kullanılır: karşılıklı TLS anahtar değişimi için RSA, bulk encryption için Triple DES ve diğer bazı hashing operasyonları için SHAx gibi. Zamanında U.S. hükümetinin belirli kriterlerini karşılamak üzere Windows’a eklenen bu seviye bugün pek önerilmez, çünkü…

Yukarıdaki liste remote desktop protocol tasarımıyla gelen standart şifreleme seviyeleridir. Bir de dış güvenlik protokolleri yardımıyla sağlanan şifreleme seviyesi vardır (TLS 1.0) ve doğru bir şekilde kullanabilmek için birkaç ufak yapılandırma gerekir.

TLS 1.0 ve CredSSP gibi gelişmiş RDP güvenlik özellikleri kullanıldığında -ki bunlara enhanced RDP security diyoruz- varsayılan olarak gelen standart RDP güvenlik özellikleri devre dışı kalır ve encryption, decryption, data integrity checks ve server authentcation gibi şeyler dış güvenlik protokolleri yardımıyla çalışır.

Bir Windows Server’da RDP için varsayılan şifreleme (security layer) davranışı Negotiate olarak ayarlıdır. Yani eğer istemci destekliyorsa, sunucunun kimliği doğrulanmamış olsa dahi iletişim her zaman TLS 1.0 ile şifrelenir. Bu iş için sunucu üzerinde bir self-signed sertifika vardır. Eğer istemci TLS desteklemiyorsa iletişim RDP standart şifreleme seviyelerinden biri kararlaştırılarak şifrelenir (RDP Security Layer).

Basic TLS handshake mimarisinde görev yapan dijital sertifikalar sanılanın aksine istemci ile sunucu arasındaki tüm trafiği şifrelemek için değil, trafiği şifrelemek için kullanılacak Master Secret key’i üretirken kullanılan PreMasterSecret key’i şifrelemek için kullanılır. Ardından şifreleme sürecindeki görevi biter ve tüm trafik Master Secret key’ler aracılığıyla şifrelenir ve çözülür.

Uyarlamaya göre değişmekle birlikte birçok servis açısından TLS’le ilgili yanlış bilinen bir diğer mesele ise şudur: Eğer istemci güvenilmeyen bir sertifika ile karşılaşır ve mesela bir HTTPS iletişimi veya bir RDP bağlantısı öncesinde “yine de devam et” derse, istemci sertifikaya güvenilmediği halde tüm trafik yine TLS tabanlı olarak şifrelenir. Tam da bu sayede Windows Server’lar kendi üzerlerindeki bir self-signed sertifikayı -istemciler güvenmediği halde- RDP trafiğini TLS 1.0 ile şifrelemek için kullanabiliyorlar.

Şifreleme tamam, peki ya sunucu kimliğinin doğrulanması?

Remote desktop protocol tasarımında bağlantı yaptığınız sunucunun gerçekten bağlanmak istediğiniz sunucu olduğunu doğrulayacak bir authentication (kimlik doğrulama) mekanizması yer almaz. Bağlantı sırasında sunucu tarafından bilinen bir username/password girildiği için sunucu istemciyi kolaylıkla doğrulayabilir. Ama istemci (yani sen) varsayılan ayarlarla çalışan bir sunucuya bağlandığında o sunucunun gerçekten hedeflediğin sunucu olup olmadığını doğrulama şansın yoktur; mesela yol üzerinde araya girmiş bir saldırgan (MITM) olabilir. Çözüm bağlantı sırasında sunucu isim ve dış güvenlik protokolleri yardımıyla sağlanan sertifika tabanlı kimlik doğrulama kullanmak.

Toparlıyorum.

Bir RDP bağlantısının şifreleme seviyesini güçlendirmek ve aynı zamanda bağlantı öncesinde uzak sunucunun kimliğini doğrulamak için yapmanız gereken 3 şey var.

  1. Sunucuya erişirken sertifika tabanlı kimlik doğrulamanın sorunsuz çalışabilmesi için mutlaka sunucu ismi kullanın. Hani sunucu1.serhatakinci.com:35buçuk gibi.
  2. Uygun bir dijital sertifika edinin ve sunucuya yükleyin.
  3. Sertifika tabanlı kimlik doğrulamayı devreye alın ve TLS ile şifrelemeyi zorunlu kılın.

Bu 3 adımı aşağıdaki gibi gerçekleştirebilirsiniz.

1) DNS servisiniz üzerinde, uzak masaüstü bağlantısı gerçekleştireceğiniz sunucuya erişimde kullanılacak DNS kaydını oluşturun. Eğer bu mümkün değilse istemci tarafından Hosts dosyası da kullanabilirsiniz. Bu kayıt ismi, kimlik doğrulama için kullanılacak dijital sertifika içerisinde de yer alıyor olmalı. IP adresi işe yaramaz çünkü dijital sertifikalar içerisine IP adresi ekleyemezsiniz. Mesela elimde bu ismi karşılayan hazır bir dijital sertifika olduğu için www.serhatakinci.com kullanacağım.

2) Sertifika tabanlı kimlik doğrulama için öncelikle geçerli bir dijital sertifika edinin ve RDP servisine atayın. Ayrıca dijital sertifika içerisinde bağlantı için kullanacağınız ismin yer aldığından da emin olun. Sunucu ismi sertifikanın subject’inde veya SAN bölümünde yer alabileceği gibi wildcard (*) ile de sağlanıyor olabilir. Bu sertifikanın RDP yapacağınız sunucuda MMC > Certificate > Computer > Personal > Certificates altında yüklü olması gerekiyor.

Bu aşamada global sertifika sağlayıcılarından temin edilmiş bir dijital sertifika kullanabileceğiniz gibi Active Directory Certificate Service veya OpenSSL veya tamamen self-signed bir sertifika da kullanabilirsiniz. Önemli olan dijital sertifikanın aşağıdaki 4 koşulu yerine getirebiliyor olması.

  • Geçerli ve en az Server Authentication (1.3.6.1.5.5.7.3.1) yapabilen bir x.509 sertifika.
  • Sertifikanın sunucu ismini içermesi. (Subject’de, SAN’de veya Wildcard olabilir)
  • Sertifikanın sunucuda yüklü olması. (Computer > Personal)
  • Güven ilişkisi için sertifikayı imzalayan yayıncının kök ve varsa zincir sertifikalarının istemci üzerinde yüklü olması. (Trusted Root CAs ve gerekli ise Intermediate CAs bölümlerinde)

Eğer global sağlayıcılar dışındaki yöntemlerle oluşturulmuş bir sertifika kullanırsanız muhtemelen bağlantı sırasında “a revocation check could not be performed for the certificate” uyarısı alırsınız ve büyü bozulur :) Bu uyarıyı aşmak için sertifikayı imzalayan CA’e ait CA revocation list’in (CRL) yayınlanmış ve istemci tarafından kontrol amaçlı erişilebiliyor olması gerekir. Veya hiç bu işlerle uğraşmadan yıllık 15$-20$ karşılığında satın alabileceğiniz bir dijital sertifika kullanabilirsiniz. Eğer hazır bir PKI yapınız yoksa sanırım en zahmetsizi bu.

3) Dijital sertifikanız hazırsa bu sertifikayı sunucu üzerinde RDP hizmetine atamanız gerekiyor. Burası biraz karışık çünkü yine, yine ve yine işletim sistemi sürümüne göre farklılıklar var. Ömrümüzü yedi bu sürümler arası farklar… En kısa yoldan şöyle özetleyebilirim.

Eğer Windows Server 2008 veya Windows Server 2008 R2 sürümlerde RDP için sertifika tabanlı kimlik doğrulamayı ve TLS tabanlı protokol şifrelemeyi devreye almak istiyorsanız aşağıdaki adımları izleyin.

  1. Remote Desktop Session Host Configuration > Connections > RDP-Tcp > Properties > General tab’ına gidin.
  2. Select butonu ile sertifikayı gösterin. Eğer sertifika doğru yerde yüklü değilse bu aşamada listelenmez.
  3. Security Layer bölümünde TLS 1.0’ı seçin. Böylece TLS’i zorunlu kılmış olursunuz. Ancak TLS 1.0 destelemeyen istemcilerin bağlanamayacağını da unutmayın. (Kaldı mı ki öyle bir istemci?)
  4. Encryption Level bölümünde High seçin.

windows-server-2008-r2-rdp-security

Windows Server 2012 ve Windows Server 2012 R2 sürümlere geldiğimizde ise işler biraz karışıyor. Neden mi? :)

Windows Server 2012 ile birlikte RDS yapısında önemli değişiklikler oldu. Rol ve görevlerin dağılımı bir tarafa, birçok yönetimsel araç doğrudan Server Manager’da birleştirildi ve ayrıca PowerShell tabanlı yönetim desteği sağlandı. Mesela rol yüklü olmasa dahi orada olan Remote Desktop Session Host Configuration yönetim aracı artık yok. Bu yüzden sertifikayı gösterecek bir yer bulamıyorsunuz. Yeni araçlara ve hatta tam fonksiyon çalışan PowerShell RDS modülüne dahi ulaşmak için Remote Desktop Services rolünün yüklenmesi şart. Tamam hadi rolleri yükledin diyelim, bu sefer de lisans servisi geri saymaya başlayacak…

Bir diğer mesele ise şu: Windows Server 2012 ve sonrasında Server Manager’a bağlı RDS yönetim ara yüzünü başlatabilmek için sunucunun domain member olması gerekiyor. Mesela VDI için optimize edilmiş Remote Desktop Services installation seçeneğiyle de kurulum yapma şansınız yok. O da AD domain üyeliği istiyor. Ne hoş değil mi :)

Workgroup sunuculara RDS rolleri role-based seçeneği ile yüklenebiliyor ama sunucu Workgroup olduğu bir çok yönetim aracını çalıştırma şansınız olmuyor. Bu da bir başka problem.

server-2012-rdp-management-console

Yukarıdaki sertifika atama işlemini gerçekleştirmek adına en az kurulum ile bu işi halletmek için yapılabilecek şey ise role-based seçeneğiyle ilerleyip sanırım sadece Remote Desktop Gateway servisini yüklemek ve sunucu Workgroup olsa dahi çalışan RD Gateway Manager MMC aracını kullanmak. Ama Remote Desktop Gateway servisi de beraberinde Network Policy Server, birçok alt feature’la beraber Web Server (IIS) gibi servisler getiriyor ve yüklüyor. Yahu ben sadece bir sertifika atamak istiyorum neden sunucumda bir NPS, bir IIS çalışsın ki? Ayrıca yine şifreleme ve güvenlik seviyelerini belirlemek için Local Policy’e gitmek gerekecek çünkü bunlar da o konsolda yok.

Neyse… ki her zaman bir arka yol vardır.

Eğer herhangi bir rol yüklemeden Windows Server 2012 veya Windows Server 2012 R2 sürümlerde RDP için sertifika tabanlı kimlik doğrulamayı ve TLS tabanlı protokol şifrelemeyi devreye almak istiyorsanız aşağıdaki adımları izleyin.

Öncelikle sunucu üzerinde yüklü sertifikaların Thumbprint bilgilerini listeleyin ve RDP iletişimine atayacağınız sertifikanın Thumbprint bilgisini not alın. Aşağıdaki PowerShell satırı ile kolayca listeleyebilirsiniz.

Get-ChildItem -path cert:\LocalMachine\My | select Subject,FriendlyName,Issuer,NotBefore,NotAfter,Thumbprint | ft

certificate-thumbprint

Uzun listeleri ft ile tablo şeklinde almak çıktıyı daha okunabilir kılıyor ama bu sefer de verilerin bazı bölümleri tabloda görünmüyor. Satır sonundaki | ft bölümünü çıkartıp çalıştırırsanız ilgili alanlardaki veriler açık bir şekilde ancak alt alta listelenir ve kullanmak istediğiniz sertifikaya ait Thumbprint değerini kopyalayabilirsiniz.

Asıl magic ise şimdi: Windows Server 2012 sonrasında sertifika atamak için RDS rolü falan gerekiyor dedik ama o gereklilik ölümlüler için :) Azıcık dikkatliyseniz herhangi bir özel yapılandırma uygulanmamış Windows Server 2012 ve sonrasına RDP yaptığınızda, aynı eski sürümlerde olduğu gibi sizi bir sertifika uyarısının karşıladığını fark edebilirsiniz. Yani arka planda RDP servisine atanmış bir self-signed sertifika olduğundan eminiz. Biraz kurcalayınca bu sertifika bilgisinin root\cimv2\terminalservices namespace’i altındaki Win32_TSGeneralSetting WMI class’ında tutulduğunu öğrendim. Ancak herhangi bir yönetim konsolundan bu alana müdahale etme şansınız yok. O zaman seni seçtim PowerShell!!

Aşağıdaki iki satır kod ile az önce belirlediğiniz sertifikaya ait Thumbprint’i SSLCertificateSHA1Hash isimli property’e yazarsanız, bundan sonra RDP sırasında size bu sertifika gösterilir. Thumbprint değerini değiştirmeyi unutmayın.

$path = (Get-WmiObject -class “Win32_TSGeneralSetting” -Namespace root\cimv2\terminalservices -Filter “TerminalName=’RDP-tcp'”).__path
Set-WmiInstance -Path $path -argument @{SSLCertificateSHA1Hash=”FD1473B49A6XXXXXXXXXXXXXXXXXXXXXXXXXXXXX”}

rdp-security-tls-SSLCertificateSHA1Hash

Ardından aşağıdaki Local Policy ayarlarını Computer seviyesinde uygulayarak TLS 1.0’ı zorunlu kılın ve yine High şifreleme seviyesini seçin.

gpedit.msc > Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Securty altında;

  • Set client connection encryption level > Enabled > High Level
  • Require use of specific security layer for remote (RDP) connections > Enabled > SSL (TLS 1.0)

rdp-security-policy-settings

Ardından sunucuyu restart edin. Açıldığında bağlantı için hazırsınız.

Sertifikada yer alan ve DNS kaydını (veya hosts) oluşturduğunuz ismi kullanarak sunucuya RDP yapın. Eğer her şey yolunda ise username/password girişinden sonra bar’da aşağıdaki simgeyi görebilirsiniz.

rdp-bar-secure-guvenlik

Mesela IP ile veya sunucuyu işaret eden ama sertifika içerisinde yer almayan bir isim ile bağlanmayı denerseniz aşağıdaki gibi uyarı alırsınız. Eğer onaylarsanız bağlantı gerçekleşir ve bağlantı süresince TLS yine devrededir. Ama sunucunun kimliği doğrulanamadı için bar’da kilit simgesini göremezsiniz. Ya arada biri varsa?

rdp-guvenlik-uyarisi

Tabi bu gibi durumlardan haberdar olmak için istemci tarafında (mstsc.exe) her zaman Warn me seçili olmalı. Şayet bir sunucuya RDP yaparken sunucunun kimliğinin doğrulanması aşamasında bir problem yaşanırsa, bu seçenek sayesinde (yukarıda da olduğu gibi) sunucuya bağlantı kurulmadan (yani credentials gönderilmeden) hemen önce durumdan haberdar edilirsiniz. Bu konuda size düşen görev ise azıcık uyanık olmak.

rdp-guvenlik-uyarilari

3) Network Level Authentication Kullanın

Basit ama etkili bir özellik. Windows Server 2003 R2 ve önceki sürümlerde Terminal Server oturumu açmak isteyen bir istemci için henüz kimlik doğrulama aşaması gerçekleşmeden önce o sunucu üzerinde bir oturum başlatılır (logon screen) ve credentials bilgisi beklenir. Bu durum Csrss.exe, Winlogon.exe gibi sistem process’leri açısında bir miktar iş yükü ve sistem geneli için kaynak kullanımı demek. İşte bu durum, tasarım gereği remote desktop protocol’ü DOS ataklara elverişli hale getiriyor; Başarılı oturum açmayacak 100’lerce bağlantının aynı anda gerçekleştiğini ve her biri için sunucu üzerinde ayrı logon screen (oturum) açıldığını düşünün.

Network Level Authantication (NLA) destekleyen Windows Server 2008 ve sonrasında ise Remote Desktop bağlantısı gerçekleştirmek isteyen bir istemci gerekli credentials bilgisini RDP session açılmadan önce hazırlar ve CredSSP isimli bir güvenlik protokolü vasıtasıyla sunucuya önden gönderir. Sunucu aldığı credentials bilgisini kontrol eder ve ancak yetkili bir kullanıcı ise RDP session’ı oluşturup kullanıcıyı içeri alır. İşte tam da bu yüzden yeni Windows Server’lara RDP yaparken credentilas bilgisi bir logon screen’e değil de mesela mstsc.exe gibi istemcilerin oluşturduğu pop-up kutucuklarına girilir.

Kimlik doğrulama işlemi RDP session öncesinde ve ağ seviyesinde gerçekleştiği için bu modele aynı zamanda front authentication da denir.

NLA’in sağladığı 2 temel avantaj var:

  1. Henüz kimlik doğrulamamış istemciler için RDP session açılmadığından Csrss.exe, Winlogon.exe gibi sistem process’lerine daha az iş düşer. Bu da kaynakları verimli kullanmaya yardımcı olur.
  2. Protokol tasarımından kaynaklı denial-of-service (DOS) atak riskini azaltır.

NLA’i aşağıdaki gibi kolayca devreye alabilirsiniz.

rdp-guvenligi-network-level-authentication-nla

NLA aktif bir sunucuya bağlanmak isteyen istemcinin CredSSP (vasıtasıyla NLA) desteklemesi şart. Windows XP SP3 + Remote Desktop Connention 6.0 ve sonraki sistemlerin tamamı NLA ile giriş yapabilecek yetenektedir.

4) Varsayılan RDP Portunu Değiştirin

Varsayılan RDP hizmet portunu 3389 dışında bir port ile değiştirebilirsiniz. Çok bilindik bir önlem ama güvenlik açısından etkisi tartışılır. Bana göre bahçe kapısının yerini değiştirmekten farksız. Sonuçta hala bir kapı ve bu kapının konumu için 65535 ihtimal var. Ama en azından otomatik olarak interneti tarayan ve 3389 numaralı port’tan yanıt aldığı sunulara brute force denemesi yapan ilkel kodlarla muhatap olmazsınız.

Bu arada RDP portunu sunucu üzerinde değil de NAT işlevi gören cihaz/yazılım üzerinde değiştirmek genelde en pratik çözümdür. Mesela end-point firewall veya eşdeğer sistem üzerinde 13534 numaralı portu sunucunun 3389’una yönlendirmek gibi.

5) Özgün Hesap İsimleri ve Güçlü Parolalar Kullanın

Sanırım bu konu için fazla söze gerek yok. Administrator, admin, root gibi varsayılan hesap isimleri ve 123456, Passw0rd, 123123 gibi kolay tahmin edilebilir credentials bilgileri yerine özgün hesap isimleri ve güçlü (karakter sayısı fazla ve karmaşık) parolalar tercih edin. Rastgele tahmin veya planlı brute force ataklara karşı daha güvende olmanıza yardımcı olur.

6) Account Lockout Policy’leri Devreye Alın

Özellikle RDP port’u tespit edildikten sonra yapılabilecek brute force ataklara karşı hız kesmek ve elimine etmek için RDP açık sunucular üzerinde aşağıdaki Account Lockout Policy’leri devreye alabilirsiniz. Arka arkaya gelen belirli sayıdaki hatalı giriş denemesi sonrasında ilgili hesap belirli bir süre boyunca otomatik olarak kilitlenir. Böylece hesap kilidi açılana kadar saldırganın yeni parola deneme şansı olmaz.

secpol.msc > Security Settings > Acount Lockout Policy

rdp-account-lockout-policy

  • Account lockout threshold – Geçerli bir hesabın kaç kez hatalı parola denemesi gerçekleştiğinde kilitleneceğini belirler. Mesela 5 deneme.
  • Reset account lockout counter after – Bir hesap için hatalı parola denemelerini tutan sayacın kaç dakika sonra sıfırlanacağını belirler.
  • Account lockout duration – Şayet bir hesap kilitlenirse, ne kadar süre boyunca kilitli kalacağını belirler. Kilitlenen hesapların belirli bir süre sonra açılması iyi olur çünkü belki siz de giremeyebilirsiniz :)

Bu gibi hesap kilitlenme durumlarına karşı sunucular üzerinde yedek bir hesap bulundurmak iyi bir fikirdir.

7) Security Event Log Takibi Yapın

RDP için her bir başarılı giriş olayı veya başarısız giriş denemesi varsayılan olarak Event Viewer > Windows Logs > Security altına kayıt edilir. Bu event’leri çeşitli araçlarla takip ederek başarılı girişlerden veya başarısız giriş denemelerinden anında haberdar olabilirsiniz. Hatta olmalısınız da :)

Başarılı RDP girişleri için oluşan event log bilgisi:

  • Keywords : Audit Success
  • Event ID : 4624
  • Source : Microsoft Windows security
  • Message : Logon Type 10

Başarısız RDP giriş denemeleri için oluşan event log bilgisi:

  • Keywords : Audit Failure
  • Event ID : 4625
  • Source : Microsoft Windows security
  • Message : Logon Type 10 veya Logon Type 3

Bu event’leri takip etmek için kuruluşunuza ait monitoring çözümünden faydalanabilir veya çeşitli script’ler oluşturabilirsiniz. Mesela ben özellikle uzak lokasyonlardaki standalone sunucular için basit bir VBS kullanıyorum.

Event takibi için kullandığım VBS’in yetenekleri şöyle:

  • Bir startup script olarak başlıyor ve çalıştığı sunucu üzerinde oluşan Security event’leri takip ediyor.
  • İçerisinde email gönderimi için bir fonksiyon yer alıyor; SMTP server adresi ile from ve to adresleri tanımlı.
  • Yeni event’leri anlamak için \root\cimv2 namespace’i altındaki Win32_NTLogEvent class’a bakıyor. Bu sayede oluşan son event’i anlamak kolay ve zahmetsiz olurken Get-EventLog cmdlet’inden daha verimli çalışıyor.
  • Eğer 4624 id’li ve Logon Type’ı 10 olan yeni bir event oluşursa (başarılı giriş) bunu yakalıyor ve email göndermeden önce source IP adresini kontrol ediyor. Eğer logon işlemi 17. satırdaki 1.1.1.1 ve 2.2.2.2 IP adreslerinden birinden geliyor ise email göndermiyor çünkü bunlar bana ait adresler, yani safe list. Eğer source ip adresi bu safe list dışında ise belirlediğim adreslere email gönderiyor.
  • Eğer 4625 id’li ve Logon Type’ı 10 veya 3 olan yeni bir event oluşursa (başarısız giriş denemesi) bunu yakalıyor ve source ip adresine bakmaksızın belirlediğim adreslere email gönderiyor.
  • Email içerisine event message bilgisini de ekliyor; bağlantı deneyen IP adresi ve varsa workstation name gibi bilgileri de anında görebiliyorum.

Bu işi yapan Visual Basic Script (.vbs) kodunu aşağıya ekledim. SMTP server, from, to gibi satırların yanı sıra 17. satırdaki örnek source ip’leri (safe list) kendinize göre uyarlayarak kullanabilirsiniz.

strComputer = “.”

Set objWMIService = GetObject(“winmgmts:{(Security)}\\” & _
strComputer & “\root\cimv2”)

Set colEvents = objWMIService.ExecNotificationQuery _
(“Select * From __InstanceCreationEvent Where ” _
& “TargetInstance isa ‘Win32_NTLogEvent'”)

Do
Set objEvent = colEvents.NextEvent

‘Successful RDP Logon
If objEvent.TargetInstance.EventCode = 4624 Then
If InStr(LCase(objEvent.TargetInstance.Message), “logon type:   10″) Then
idxEnd = Instr(objEvent.TargetInstance.Message,”Detailed Authentication Information:”)
If (InStr(LCase(objEvent.TargetInstance.Message), “source network address: 1.1.1.1”)) or (InStr(LCase(objEvent.TargetInstance.Message), “source network address: 2.2.2.2”)) Then
Else
SendEMail mid(objEvent.TargetInstance.Message,1,idxEnd-1), “Successful RDP Logon Detected”
End If
End If
End If

‘Failed RDP Logon
If objEvent.TargetInstance.EventCode = 4625 Then
If (InStr(LCase(objEvent.TargetInstance.Message), “logon type:   10”)) Or (InStr(LCase(objEvent.TargetInstance.Message), “logon type:   3″)) Then
idxEnd = Instr(objEvent.TargetInstance.Message,”Detailed Authentication Information:”)
SendEMail mid(objEvent.TargetInstance.Message,1,idxEnd-1), “Failed RDP Logon Detected”
End If
End If

Loop

Function SendEmail(body,subject)

Set objEmail = CreateObject(“CDO.Message”)
objEmail.From = “rdp@inprowise.com” ‘ Email – from address
objEmail.To = “sakinci@inprowise.com;others@inprowise.com” ‘Email – to addresses
objEmail.Textbody = body
objEmail.Subject = subject

objEmail.Configuration.Fields.Item _
(“http://schemas.microsoft.com/cdo/configuration/sendusing”) = 2
objEmail.Configuration.Fields.Item _
(“http://schemas.microsoft.com/cdo/configuration/smtpserver”) = _
“smtp.mail.inprowise.com” ‘Email – SMTP server address
objEmail.Configuration.Fields.Item _
(“http://schemas.microsoft.com/cdo/configuration/smtpserverport”) = 25
objEmail.Configuration.Fields.Update
objEmail.Send

End Function

Bu event’ler bir PowerShell script ile de takip edilebilir ve bence çok daha renkli şeyler ortaya çıkar. Ama bazen eldekiyle yetinmeyi bilmek gerekiyor :)

8) Güvenlik Duvarı Üzerinde IP ve Port Kısıtlama Uygulayın

Eğer RDP yapılan source ip adresleri belli ise sizin, ISP’nin veya en azından Windows Server’ın güvenlik duvarı üzerinde bir safe list oluşturup hangi source ip adreslerinden RDP kabul edileceğini belirleyebilirsiniz. Ama bunu yaparken dikkatli olun çünkü hatalı bir yapılandırma uygulandığında sunucuya uzaktan erişimi kaybetme ihtimaliniz var. Sonra sunucunun yanına gitmeniz veya credentials bilgilerini bir aracıya vermeniz gerekebilir.

rpd-port-firewall-guvenlik

Ayrıca yine güvenlik duvarı yardımıyla RDP ve gerekli diğer servisler dışındaki port’lara erişimi tamamen engellemek de iyi bir fikirdir.

9) Eğer Mümkünse Üst Sürüm İşletim Sistemlerini Tercih Edin

Her zaman pek mümkün olamayabiliyor sonuçta maliyet ve bazen de uyumluluk. Ama eğer şansınız varsa, çoğu zaman daha güncel teknolojilere sahip oldukları için istemci ve sunucu tarafında son sürüm işletim sistemlerini tercih edin. Eğer bunu sağlayamıyorsanız en azından işletim sistemlerini, uzak masaüstü istemcisini (mstsc.exe) ve uzak masaüstü servislerini güncel tutmaya özen gösterin.

10) VPN Kullanabilirsiniz

Bu çoğu zaman devreye alması zor ve bazen de pahalı bir çözümdür ama yeterli yatırıma sahipseniz veya servis sağlayıcınızdan bu hizmeti kiralayabiliyorsanız RDP yaptığınız sunucuları VPN arkasına alarak ekstra güvenlik sağlamak mümkün. Duruma göre tercih edebilirsiniz.

Bu maddeler arasından birkaçını veya tamamını devreye aldığınızda birçok açıdan güvenli RDP erişimi gerçekleştirmek mümkün. Ama o kadar sıkılaştırma yaptınız diye de sakın rehavete kapılmayın; bilgi güvenliğinde altın kural tedbiri elden bırakmamak ve daima uyanık olmak.

Son olarak; Bu yazıyı hazırlarken birkaç konuyu araştırmam gerekti ve bu sırada 10 yıl önce olympos.org’da uzak masaüstü bağlantısı nasıl yapılandırılır gibilerinden hazırladığım bir yazıya denk geldim :) Yazım ve noktalama hatalarını saymazsak bence hala gideri var :) Bu içerik üzerine ne kadar çok soru gelmişti ki hala da gelir… O değil de bir keresinde çalıştığım kuruluşlardan birinde şöyle bir soru almıştım: “Bu uzak masaüstü bağlantısı ne kadar uzağa bağlanabiliyor?” Ya işte bu da böyle bir anımdır. Hoşça kalın :)

Yazı Etiketleri: , , ,

Sayfa Başı ▲

Yorumlar (7)

  1. Efe

    Hocam selam,

    default olan 3389 portunu değiştirerek bağlantı sağlıyorum sizce yeterli olur mu?

    Teşekkürler

  2. Serhat AKINCI

    Bence yukarıdaki 10 maddenin 10’unu da uygulasak “yeterli” diyemeyiz. Ama birçok bilinen saldırı yöntemine karşı tedbir aldık diyebiliriz.

  3. ercan

    Elinize sağlık hocam harika olmuş

  4. pcwalidator

    ekran kilit programi kurun 2km lik sifre bile yapabilirsiniz ordu gelse cozemez :)

  5. Emre

    Güzel ve açıklayıcı bir yazı benim için. Teşekkürler

  6. taylan

    Merhabalar,

    3 adet statik ip adresine sahip şubem var, merkez şubeme 3 adet statik ip adresi dışında kimsenin uzak masaüstü bağlantı kurmasını istemiyorum.

    Bu konu ile alakalı bir çözüm var mı ?

  7. Murat

    Hocam merhaba,
    verdiğiniz event-mail scriptinde kendime göre değişiklikleri yaptım fakat Line:1 Character:14 de yani bilgisayar isminin yazılacağı satırda hata veriyor Nasıl çözebilirim?

Yorum Ekle