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

27.09.2015
20

Ağa bağlı Windows işletim sistemlerini uzak bilgisayarlar üzerinden yönetirken kullanabileceğiniz servislerden birisi de Uzak Masaüstü Hizmetleridir yani Remote 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 isim 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ı.

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 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çerisinde yer alırlar. Ama örneğin internet üzerinden 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 tedbirlere çok daha fazla ihtiyaç duyarlar. 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 önlemlerden 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 zaman kaybetmeden 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 ya da implementasyon 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. Eğer bir zafiyet için public olmuş exploit 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 şekilde kullanabilmek için birkaç ufak yapılandırma gerekir.

ⓘ  TLS ve CredSSP gibi şeyler RDP güvenliğini artırmak için kullanıldığında -ki bunlara enhanced RDP security ayarları denir- 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 gerçekleşir.

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 trafik daima TLS ile şifrelenir. Bu iş için sunucu üzerinde bir self-signed sertifika vardır. Eğer istemci TLS desteklemiyorsa bu sefer de iletişim RDP standart şifreleme seviyelerinden biri kararlaştırılarak şifrelenir.

ⓘ  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 de şudur: İstemci örneğin bir HTTPS iletişimi veya bir RDP bağlantısı öncesinde güvenilmeyen sertifika ile karşılaştığında “yine de devam et” dediğinde, istemci sertifikaya güvenmediği halde yine de trafik şifreleme işlemleri için kullanır. Tam da bu sayede Windows Server’lar kendi üzerlerindeki bir self-signed sertifikayı -istemciler güvenmediği halde- RDP trafiğini şifreleme sırasında kullanabiliyorlar.

Ş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 hedef sunucu olup olmadığını doğrulama şansı yoktur ki örneğin yol üzerinde araya girmiş bir saldırgan (MITM) olabilir. Çözüm bağlantı sırasında sunucu isimi ve dış güvenlik protokolleri yardımıyla sağlanan sertifika tabanlı kimlik doğrulama kullanmak.

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: sunucu1.serhatakinci.com gibi.
  2. Sunucu ismi ile eşleşen geçerli 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 şekilde 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.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 well-known 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 basit bir dijital sertifika da 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ümlerinde ayarlamak istediğinizde ise işler biraz karışıyor çünkü 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ı, rolü yüklediğinizde bile 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 gerekiyor. 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. 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 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. Neyse ki 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.

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 ş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, tıpkı 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 fark ettim. Ancak herhangi bir yönetim konsolundan bu alana müdahale etme şansınız bulunmuyor. 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"}

rdp-security-tls-SSLCertificateSHA1Hash

Ardından 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)

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

rdp-guvenlik-uyarisi

Tabi bu gibi durumlardan haberdar olmak için istemci tarafında her zaman “Warn me” seçili olmalıdır. Şayet bir sunucuya RDP yaparken sunucunun kimliğinin doğrulanması aşamasında bir problem yaşanırsa, bu seçenek sayesinde 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 credential bilgisi beklenirdi. 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’ler 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 credentila bilgisi bir logon screen’e değil de mesela mstsc.exe gibi istemcilerin oluşturduğu pop-up pencerelerine giriyoruz.

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

rdp-guvenligi-network-level-authentication-nla

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 ve yönlendirmek genelde en pratik ve doğru seçenektir.

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 credential bilgileri yerine özgün hesap isimleri ve güçlü 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. Bu gibi hesap kilitlenme durumlarına karşı sunucular üzerinde yedek bir hesap bulundurmak da iyi bir fikirdir.

rdp-account-lockout-policy

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 ki hatta olmalısınız.

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. 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 ve bu sayede 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 kaybedebilirsiniz. Sonra sunucunun yanına gitmeniz ya da credential 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.

rpd-port-firewall-guvenlik

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 (mutlaka) 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.

Yorumlar (20)

  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?

  8. Yeliz Karaagac

    Elinize sağlık, toplu güvenlik paketi gibi olmuş.

  9. Hakan

    Güvenlik Duvarı Üzerinde IP bazlı kısıtlamaya bağlanacak bilgisayarların IP lerini yazarsanız tanımlı IP ler haricinde bağlantı yapılamıyor. Oldukça kullanışlı ve başarılı bir önlem.

  10. Hakan

    Bir şey daha, IP ile kısıtlayabiliyoruz ama MAC ile kısıtlayamazmıyız? Yani IP lerimiz sabit olmasın ama spesifik makinalar server üzerine incoming trafic olarak gelsin ve whitelistte olanlar bağlansın, Lan da mümkün olduğunu biliyorum ama uzak masaüstünde çok araştırdım bulamadım.

  11. Serhat AKINCI

    MAC bazlı block/allow/filtering işlemleri Switch/Router gibi fiziksel katmanlarda uygulanabilir.

  12. Şakir

    Merhaba

    SSL sertifikası ayarlarını yaptıktan sonra ip adresi yazarak yine de bağlantı yapılabiliyor. Bunu sunucu tarafında engellenebilir mi? Sadece http://www.remotesunucu.com şeklinde sertifikada mevcut olan isimle bağlanılması mümkün müdür? Biraz araştırdım ama bulamadım. Teşekkürker.

  13. Soner G

    SErhat hocam merhabalar. 8. maddeyi uyguluyorum şu şekilde:
    Server 2008 Foundation R2 sunucumuz var. Dışarıdan da bu sunucuya ipsi sabit olan bir bilgisayardan uzak masaüstü bağlantısı yapıyorum. Bunun için server da Gelen KUralları kısmında Uzak Masaüstü(TCP-Gelen) kuralına çift tıklayıp açılan pencereden Kapsam kısmına girip Uzak IP adresi kısmında Bu IP adresleri yazan kısma sadece bağlanmasını istediğim dış ip yi yazıyorum. Hizmetler kısmında Uzak Masaüstü Hizmetleri ile Uzak Masaüstü Yapılandırmasını da yeniden başlatıyorum. Fakat dış ipye yazdığım ipnin dışından da uzak masaüstü bağlantısını kabul ediyor.

    Bu arada güvenlik duvarı kapalı. Güvenlik duvarını açtığımda hiçbir şekilde uzakmasaüstünden bağlantı sağlayamıyorum. Sizce nerede yanlış yapıyorum? Şimdiden teşekkürler.

  14. burakco

    windows firewall üzerinden IP Kısıtlama yapmış olmama rağmen hala dışarıdan erişim oluyor. sebebi ne olabilir?

    windows defender ve firewall aktif.

    bitdefender antivirüs kurulu.

    asus dsl n55u modem kullanıyorum. modemde 192.168.1.31 için 3389 port yönlendirmesi mevcut.

    ip engeli koyamadığım için bilgisayara sürekli virüs bulaşıyor. yardımcı olur musunuz?

  15. ÖZGÜR

    Ellerine sağlık üstad çok güzel bir makale olmuş .

  16. hasan

    Serhat Hocam merhaba, server 2016 ürününde birkaç gün oldu sanırım RDP ana bilgisayarında istemcilerin kullanabileceği lisans sayısı 0 diyor. lakin lisanslar kurulu lisans yöneticisinde görünüyor. herşey normal iken lisans sunucusunun pasif duruma düşmesi nasıl olmuş olabilir.

  17. Emre

    Herkese Merhaba, çalıştığım firmamda 3 Adet fiziki sunucu var server OS 2012R2 bu üç sunucu birbirine cluster olarak çalışmakta.

    – sunucular arada kendi kendine kapanıyor bunu nasıl engellerim ?
    – bazen de sunucular off görünüyor fakat kendi local in de çalışmaktalar fakat domain ortamında ping almıyor yani kapalı gibi görünüyor. Böyle bir durumda uzak bağlantı yapamıyorum haliyle, tesise gidip fiziken restart yapmak zorunda kalıyorum. Bu gibi bir durumda off olmuş sunuculara nasıl ulaşıp uzaktan erişebilirim ?

  18. Özgür

    Hocam selamlar. Ben sistem içerisinde bulunan 2 ayrı sunucuya özel rdp eklemek istiyorum. Yani konuyu açmam gerekirse dışarıdan bağlanacak başka bir kullanıcı için sadece o sunucuya özel rdp tanıtmak ve sadece o sunucu üzerinde tüm yetkilere sahip olmasını istiyorum. Bunu nasıl gerçekleştirebilirim?

  19. İbrahim köseoğlu

    Serhat bey merhaba . Benim bi sorum olacak .şirketimde 1 adet server 2012 yüklü pc be 2 adet aynı ağa bağlı bilgisayar var. Bu 3 bilgisayar intranet ağında çalışıyor.Bizim bu 3 bilgisayarda yapılan herşeyin log kaydını tutmamız lazım . Server üzerinde bunu yapabilirmiyiz

  20. Yavuz

    Merhaba Serhat Hocam,
    2012 R2 RDS sunucuya login olunduktan sonra desktop gelmiyor, siyah ekranda tam olarak 3 dakika bekledikten sonra desktop geliyor. Siyah ekranda Ctrl+Alt+End çalışıyor, task manager vb açılabiliyor.

    Server restart edilince bu sorun ortadan kalkıyor fakat bir müddet sonra yine tekrarlıyor. 3 RDS sunucumuz var, 3’ünde de farklı zamanlarda bu durum oluşuyor. Sunucuların her biri farklı ESXi 6.5 host’lar üzerinde çalışıyor. Tüm güncellemeler tamam.

    Farklı işletim sistemlerindeki RDP client’lar ile de aynı sorun oluyor. Server ile client arasından firewall çıkarılıp deneyinde de bir fark olmuyor. RDP client üzerinde tavsiye edilen bitmap caching vb bir çok seçeneği de denedik bir sonuca ulaşamadık.

    Bir öneriniz olur mu?

Yorum Ekle

* Gerekli

* Gerekli

* Tercihen