Güvenlik duvarı aracılığıyla 389 numaralı bağlantı noktasına gelen UDP bağlantısını engelleme
Bu kılavuz, bir Windows Server’ın UDP 389 numaralı bağlantı noktası üzerinden gerçekleştirilen LDAP (CLDAP) yansıma/amplifikasyon DDoS saldırılarına karşı nasıl korunacağını ve sunucunun rolüne bağlı olarak bunun nasıl güvenli bir şekilde yapılacağını açıklamaktadır.
Genel Bakış
LDAP (Lightweight Directory Access Protocol), Active Directory'nin temelini oluşturan uygulama katmanı protokolüdür. Normalde TCP üzerinden çalışır, ancak 389 numaralı UDP bağlantı noktası üzerinden çalışan bağlantısız bir varyantı da vardır: CLDAP (Connectionless LDAP). Windows istemcileri, etki alanı denetleyicilerini bulmak için CLDAP'yi kullanır (DC Locator hizmeti tarafından gerçekleştirilen "LDAP ping"). Windows'un modern sürümleri, birçok senaryoda genellikle DNS tabanlı keşif ve TCP LDAP'ye geri dönebilir, ancak UDP 389 üzerinden CLDAP, DC Locator işlemleri ve etki alanına katılma işlemleri için hâlâ kullanılmaktadır.
Güvenlik sorunu, yansıma (amplifikasyon) suistimalidir. Bir saldırgan, bir sunucunun UDP 389 numaralı bağlantı noktasına küçük, sahte bir CLDAP isteği gönderir ve kaynak IP adresini taklit ederek isteğin kurbandan gelmiş gibi görünmesini sağlar. Sunucu daha sonra kurbanın adresine çok daha büyük bir yanıt gönderir. Bu durum, savunmasız birçok sunucuya yayıldığında kurbanı trafik seliyle boğar. Geçmişte, LDAP yanıtının boyutuna bağlı olarak 50 katı aşan amplifikasyon faktörleri gözlemlenmiştir; bu nedenle savunmasız sunucular yansıtıcı olarak kullanılmaktadır.
Bu kılavuzun amacı, meşru Active Directory işlevlerini bozmadan sunucunuzun bu tür bir yansıtıcı olarak işlev görmesini engellemektir.
Adım 1: Sunucunuzun bir Etki Alanı Denetleyicisi olup olmadığını belirleyin
Bu, neyi (varsa) engellemeniz gerektiğini belirlediği için en önemli adımdır.
Standart bir Windows Server kurulumunda, UDP 389 numaralı bağlantı noktası normalde sunucu bir etki alanı denetleyicisine yükseltildikten sonra yalnızca Active Directory Etki Alanı Hizmetleri tarafından kullanılır. Normal bir Windows Server (web, uygulama, dosya sunucusu vb.) varsayılan olarak UDP 389'u dinlemez; bu nedenle, başka bir uygulama (AD LDS veya üçüncü taraf bir LDAP hizmeti gibi) bu bağlantı noktasında bir CLDAP hizmeti sağlamadıkça, CLDAP yansıtıcısı olarak kötüye kullanılamaz.
PowerShell'i Yönetici olarak açın ve sunucunun etki alanındaki gerçek rolünü kontrol edin:
(Get-CimInstance Win32_ComputerSystem).DomainRole
Sonucun yorumlanması:
- 0 — Bağımsız İş İstasyonu
- 1 — Üye İş İstasyonu
- 2 — Bağımsız Sunucu
- 3 — Üye Sunucu
- 4 — Etki Alanı Denetleyicisi (geçmiş uyumluluk nedeniyle "Yedek Etki Alanı Denetleyicisi" olarak raporlanır — tüm modern Active Directory etki alanı denetleyicileri bu sonucu döndürür)
- 5 — PDC Emülatörü FSMO rolünü üstlenen Etki Alanı Denetleyicisi (geçmiş uyumluluk nedeniyle "Birincil Etki Alanı Denetleyicisi" olarak bildirilir)
Sonuç 4 veya 5 değilse, sunucu bir etki alanı denetleyicisi değildir.
Ayrıca, UDP 389'da gerçekten dinleme yapan bir şey olup olmadığını da doğrulayabilirsiniz:
Get-NetUDPEndpoint -LocalPort 389 -ErrorAction SilentlyContinue
Bu komut hiçbir sonuç döndürmezse, Windows UDP 389 numaralı bağlantı noktasını dinlemiyor demektir; dolayısıyla sunucu CLDAP hizmetleri sunmuyor ve bu saldırıya maruz kalmıyor.
Sunucunuz bir etki alanı denetleyicisi DEĞİLSE
UDP 389'da dinleme yapan hiçbir şey yoktur, bu nedenle sunucu LDAP yansıtıcısı olarak kötüye kullanılamaz. Bu özel tehdit için güvenlik duvarında herhangi bir değişiklik yapılması gerekmez.
Güvenlik politikanızı belgelemek veya açık bir reddetme kuralı uygulamak istiyorsanız, yine de aşağıdaki güvenlik duvarı kuralını oluşturabilirsiniz. UDP 389 numaralı bağlantı noktasında dinleyen hiçbir hizmet olmadığından, bu kuralın pratikte hiçbir etkisi yoktur.
Sunucunuz bir etki alanı denetleyicisiyse
Bir etki alanı denetleyicisi gerçekten UDP 389'da dinleme yapar ve yansıtıcı olarak kötüye kullanılabilir — ancak UDP 389, normal etki alanı çalışması için de gereklidir.
Etki alanı denetleyicisinde gelen tüm UDP 389 trafiğini körü körüne engellemeyin. Etki alanına katılmış istemciler, bir etki alanı denetleyicisini bulmak için CLDAP (UDP 389) kullanır ve etki alanına katılmak için de aynı bağlantı noktası gereklidir. Genel bir engelleme, istemcilerin etki alanı denetleyicisini bulmasını engelleyebilir ve oturum açma ile etki alanına katılma işlemlerini bozabilir.
Etki alanı denetleyicisinde doğru yaklaşım:
İdeal olarak, bir etki alanı denetleyicisine internet üzerinden hiç erişilememelidir. Yansıma kötüye kullanımı dışarıdan gelir, bu nedenle en temiz çözüm, etki alanı denetleyicisini çevre güvenlik duvarının arkasında tutmak ve UDP 389'u kamuya açık hale getirmemektir.
Sunucunun erişime açık olması gerekiyorsa, UDP 389'u genel olarak engellemeyin. Bunun yerine, yalnızca harici/güvenilmeyen IP aralıklarından engelleyin ve iç etki alanı alt ağlarınızı engelleme kapsamı dışında bırakın. Bu, iç istemcilerin çalışmasını sürdürürken, sahtecilik içeren harici istekleri (yansımaya neden olan) durdurur. Bu, aşağıda açıklanan kuralın Kapsam ayarları ile yapılır.
Aynı kapsam ilkesi, Salt Okunur Etki Alanı Denetleyicileri (RODC'ler) için de geçerlidir.
Güvenlik duvarı kuralını oluşturma (gelen UDP 389'u engelleme)
Windows Defender Güvenlik Duvarı'nı açın ve sol taraftaki menüden Gelişmiş ayarlar'ı seçin:

Sol taraftaki menüden Gelen Kurallar'ı seçin:

Üst menüden Eylem → Yeni Kural... seçeneğine tıklayın:

Kural Oluşturma Sihirbazı açılır. Kural türü olarak Bağlantı Noktası'nı seçin ve İleri >'ye tıklayın:

Bir sonraki sayfada, UDP'yi seçin, ardından Belirli yerel bağlantı noktaları altında 389 yazın ve İleri >'ye tıklayın:

Bir sonraki sayfada, Bağlantıyı engelle seçeneğini seçin ve İleri >'ye tıklayın:

Son olarak, kurala bir ad verin (örneğin, UDP LDAP engelleme) ve " Bitir"e tıklayın:

Aynı kural, PowerShell'den de oluşturulabilir; bu, komut dosyası oluşturmak veya kuralı birden fazla sunucuya uygulamak için kullanışlıdır:
New-NetFirewallRule -DisplayName "Block inbound UDP 389 (CLDAP)" -Direction Inbound -Protocol UDP -LocalPort 389 -Action Block
Bir etki alanı denetleyicisinde, burada durmayın. Yukarıdaki kural, tüm kaynaklardan gelen UDP 389'u engeller; bu da iç istemciler için etki alanı denetleyicisinin konumunu bozacaktır. Kuralın kapsamını belirlemelisiniz (sonraki adım).
Kuralın kapsamını belirleyin (etki alanı denetleyicisinde zorunludur)
Kural oluşturulduktan sonra, Özellikler'i açın ve Kapsam sekmesine gidin. Uzak IP adresi altında, Bu IP adresleri'ni seçin ve engellemek istediğiniz harici veya güvenilmeyen aralıkları ekleyin. Buraya iç etki alanı alt ağlarınızı eklemeyin — Uzak IP adresi altında listelenen her aralık, kuralın engelleyeceği bir aralıktır; bu nedenle iç alt ağları listelerseniz kendi istemcilerinizi de engellersiniz. Yerel IP adresi ayarını Herhangi bir IP adresi olarak bırakın.

Bu şekilde engelleme, yalnızca belirttiğiniz güvenilir olmayan harici kaynaklara uygulanır; listelenmemiş iç istemciler ise etkilenmez.
PowerShell'de, aynı kapsam belirleme işlemi yerleşik Internet anahtar sözcüğüyle uygulanabilir. Internet anahtar sözcüğü, yerel bilgisayar, geri döngü ve yaygın yerel ağ aralıkları hariç olmak üzere, Windows Güvenlik Duvarı'nın harici olarak sınıflandırdığı uzak adreslerle eşleşir. Bu, harici trafiği engellerken iç istemcileri etkilemez:
New-NetFirewallRule -DisplayName "Block inbound UDP 389 (CLDAP) from Internet" -Direction Inbound -Protocol UDP -LocalPort 389 -RemoteAddress Internet -Action Block -Profile Public,Private
Doğru şekilde yapılandırılmış bir etki alanı denetleyicisinde, etkin güvenlik duvarı profili normalde " Etki Alanı"dır. Kuralı "Genel" ve "Özel" profillerle sınırlandırmak, kuralın normal etki alanı trafiğini etkilemesini önler. Bir etki alanı denetleyicisinde, yalnızca Internet anahtar sözcüğüne güvenmek yerine, kuralın Kapsamı'nda iç alt ağlarınızı açıkça tanımlamak yine de en güvenli yoldur — ağınız standart dışı özel aralıklar kullanıyorsa, bunlar yanlış sınıflandırılabilir; bu durumda iç aralıklarınızı manuel olarak listeleyin ve geri kalan her şeyi engelleyin.
Sonucu doğrulayın
UDP 389'u doğrulamak için Test-NetConnection komutunu kullanmayın; bu komut yalnızca TCP bağlantılarını test eder ve UDP için yanıltıcı sonuçlar verir.
Bir sunucunun hala CLDAP isteklerine yanıt verip vermediğini doğrulamanın en doğrudan yolu, etki alanına katılmış bir istemciden uygun bir LDAP ping'i göndermektir:
nltest /ping /server:DC_NAME
Bu, doğru biçimlendirilmiş bir CLDAP isteği gönderir ve yanıtı bildirir. DC_NAME kısmını etki alanı denetleyicinizin adıyla değiştirin.
İkincil bir kontrol olarak, başka bir makineden PortQry'yi (ücretsiz bir Microsoft komut satırı aracı) kullanabilirsiniz:
portqry -n SERVER_NAME -p UDP -e 389
Yanıtına bağlı olarak, PortQry LISTENING veya FILTERED durumunu bildirebilir. PortQry'nin tam bir CLDAP LDAP ping'i yerine bir sonda paketi gönderdiğini ve CLDAP hizmetinin bunu geçerli bir istek olarak tanımayabileceğini, bu nedenle bağlantı noktası açık olsa bile FILTERED sonucunu verebileceğini unutmayın. Bu nedenle, nltest /ping komutunu kesin test olarak, PortQry'yi ise kabaca bir ek kontrol olarak değerlendirin.
Bir etki alanı denetleyicisinde, etki alanı konumunun dahili istemciler için hâlâ çalıştığını da doğrulayın:
nltest /dsgetdc:example.com
example.com'u kendi etki alanı adınızla değiştirin. Başarılı bir yanıt, istemcilerin etki alanı denetleyicisini hâlâ bulabildiği anlamına gelir. Tek başına başarılı bir dsgetdc komutunun, UDP üzerinden CLDAP'ın çalıştığını kanıtlamadığını unutmayın; çünkü DC Locator, gerçekleştirilen işleme bağlı olarak CLDAP kullanılamadığında DNS sorgularına ve TCP LDAP'ye geri dönebilir — bu nedenle yukarıdaki nltest /ping kontrolü daha doğrudan bir testtir.
Ek öneriler
Windows'u tamamen güncel tutun. Güvenlik güncellemeleri, LDAP uygulamasının kendisindeki kritik güvenlik açıklarını (uzaktan kod yürütülmesine izin verebilecek kusurlar gibi) giderir ve sunucuyu saldırılara karşı korur. Bu, yansıma kötüye kullanımından ayrı bir konudur — yamalar sunucuyu güçlendirirken, yukarıdaki güvenlik duvarı kapsamı, sunucunun başkalarına karşı bir yansıtıcı olarak kullanılmasını engeller.
LDAP'yi genel olarak güçlendirmek için etki alanı denetleyicilerinde LDAP imzalama ve kanal bağlamayı etkinleştirin.
Hacimsel koruma için, hız sınırlama ve DDoS filtreleme, Windows ana bilgisayarında değil, çevre güvenlik duvarında veya yukarı akış sağlayıcısında gerçekleştirilmelidir.
Özet: UDP 389'u engellemek ne zaman uygundur?
- Sunucu bir etki alanı denetleyicisi değil → herhangi bir işlem gerekmez (UDP 389 dinlemiyor).
- Güvenlik duvarının arkasında bulunan ve internete açık olmayan etki alanı denetleyicisi → herhangi bir işlem gerekmez; bunu genel internetten uzak tutun.
- İnternete açık etki alanı denetleyicisi → kuralın kapsamını, güvenilir iç alt ağları etkilemeden harici kaynakları engelleyecek şekilde ayarlayın.