Windows RDP Güvenliği İçin Tavsiyeler

Ağa bağlı Windows işletim sistemlerini uzak 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 (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 sistemlere 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 aslında uzak masaüstü bağlantısı sırasında istemci ve sunucu arasında kullanılan protokolün ism kısaltması oluyor yani Remote Desktop Protocol. Ama Windows sistem yöneticileri arasında o kadar yer etmiş ki RDP deyince herkes aynı şeyi anlıyor; uzak masaüstü bağlantısı…

 

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 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 istemci ile iletişim halindedirler ve muhtemelen kuruluşun güvenlik çemberi içinde yer alırlar. Ama örneğin internet üzerinde ulaşılabilen, servis sağlayıcılarda veya korunaksız uzak şube yapılarında çalışan RDP erişimi açık sunucular daha fazla risk altındadır ve güvenliği artırmak için bazı ek tedbirler alınması gerekebilir.

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 internet’e açık sunucular için daha anlamlı olabilir, ama eğer imkanınız varsa VPN arkasındaki veya 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 ve gecikmeden yükleyin. 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 çoğu zaman tek korunma yöntemi Windows güvenlik güncelleştirmelerini yüklemek veya ilgili protokol kullanımını devre dışı bırakmak olacaktır. Ş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 katkısıyla sağlanan TLS tabanlı trafik şifrelemeyi ve sertifika tabanlı kimlik doğrulamayı devreye alın. Ayrıca sunucuya erişirken IP adresi yerine TLS sertifikasıyla eşleşen isim (hostname, fqdn, dns name, vb) kullanım alışkanlığı edinin.

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 istemci tarafının da seçilen şifreleme seviyesine uyum sağlaması 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. 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 protokol tasarımıyla gelen standart şifreleme seviyeleridir. Bir de dış güvenlik protokolleri yardımıyla sağlanan şifreleme seviyesi vardır (TLS) ve doğru bir şekilde kullanabilmek için birkaç ufak yapılandırma gerekir.

Bir Windows Server’da RDP için varsayılan şifreleme davranışı Negotiate olarak ayarlıdır. Yani eğer istemci destekliyorsa, sunucunun kimliği doğrulanmamış olsa dahi iletişim her zaman TLS 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.

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

Remote desktop protokol tasarımında bağlantı yaptığınız sunucunun gerçekten bağlanmak istediğiniz sunucu olup olmadığını 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 bir istemcinin varsayılan ayarlarla çalışan bir sunucuya bağlandığında o sunucunun gerçekten hedeflediği sunucu olup olmadığını doğrulama şansı 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.zekisagir.com gibi.
2. Sunucu ismi ile eşleşen 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ında 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.zekisagir.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)

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 2012 ve Windows Server 2012 R2 sürümlere geldiğimizde ise işler biraz karışıyor.

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ı atayacak 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.

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 sunucuda 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.

Ama daima 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.

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 ş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.

Ama 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”}

Ardından aşağıdaki Local Policy ayarlarını Computer seviyesinde uygulayarak TLS’i 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)

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 kilit simgesini görebilirsiniz

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.

Tabi bu gibi durumlardan haberdar olmak için istemci tarafında 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.

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 credential 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 ekstra 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 1000’lerce bağlantının aynı anda gerçekleştiğini ve her biri için sunucu üzerinde ayrı logon screen oluşturulduğunu 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 credential 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.

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

1. Henüz kimlik doğrulamamış istemciler için RDP session başlatılmadığından Csrss.exe, Winlogon.exe gibi sistem process’lerine daha az iş düşer. Bu da gereksiz kaynak tüketimini ortadan kaldırır.
2. Protokol tasarımından kaynaklı denial-of-service (DOS) atak riskini azaltır.

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

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ığı sistemlere 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ı port’u 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

• 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 🙂

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 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

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.

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 maliyetli 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 kurallardan biri tedbiri elden bırakmamak ve daima uyanık olmaktır.