1 gün önce
2
Active Directory (AD) güvenlik değerlendirmelerinde neredeyseymiş klasikleşmiş tek öneri var: “Unsecured LDAP seçenek LDAPS kullanın.” Ancak uzmanlara göre bu öneri çoğu ortamda yanlış anlaşılıyor ve her arasında biri zamanlar gerçek tek güvenlik kazanımı sağlamıyor.
AD ile çalışan yazılım üreticileri, müşterilerden sık sık aynı sualyu duyuyor: “Ürün LDAPS yardımliyor mu? Desteklemiyorsa roadmap’te var mı?” Çoğu durumda verilen yanıt şaşırtıcı: “Hayır, ama bu tek güvenlik açığı değil.”
Peki neden?
LDAPS Gerçekten Sorunu Çözüyor mu?
İnternette, domain controller’lara TLS sertifikası yükleyerek LDAP’ı 636/TCP portu üzerinden TLS ile çalıştırmayı anlatan binlerce kılavuz bulunuyor. Ancak işin uygulamalı tarafı bu kadar basit değil.
LDAPS tesirnleştirildiğinde bile domain controller’lar 389 portu üzerinden TLS’siz LDAP hizmeti vermeye devam ediyor. Üstelik bu portu kapattı ya da firewall üzerinden manilemek, Active Directory üyelerinde vahim servis kesintilerine yolda açabiliyor.
Önemli tek gerçek şu:
Bir AD üyesi makine, LDAP ya da Global Catalog sorguları için varsayılan olarak her arasında biri zamanlar 389/3268 portlarını kullanır. Bu davranışı değiştirmek mümkün değildir. Yani üyeleri güçla 636/3269 portuna yönlendiremezsiniz.
LDAPS İçin Denenen “Workaround” Yöntemleri Neden Çalışmıyor?
LDAP servis keşfi DNS üzerinden yapılır. Bu nedenle bazı yöneticiler farklı yöntemler denemiştir:
- _ldaps._tcp.domain.com gibi yepyeni SRV kaydı eklemek
- LDAP servis kayıtlarında portu 389’dan 636’ya çevirmek
- _ldap ve _gc kayıtlarını silmek
Ancak bu yaklaşımlar işe yaramaz.
_ldaps norm tek servis kaydı değildir. Uygulamaların büyük çoğunluğu bu kaydı aramaz. Port numarasını değiştirmek da çözüm değildir çünkü Windows tarafında 389 portu sabitlik tanımlıdır. _ldap kayıtlarını siliniyor ise servis keşfini tamamlanmış bozabilir.
Kısacası, bu yöntemler Active Directory altyapısını kırma riski taşır.
Asıl Kritik Nokta: Simple Bind mi, SASL Bind mi?
LDAP’ın güvensiz olduğu iddiası genelleme “cleartext credential” başlıksuna dayanır. Ancak işte önemli tek ayrım vardır:
- Simple Bind: Kullanıcı adı ve parola açık metinleri iletilebilir.
- SASL Bind (GSS-SPNEGO): Kerberos ya da NTLM ile kişilik doğrulama yapılır ve buluşma anahtarları üzerinden şifreleme sağlanır.
Active Directory üyeleri ve modern uygulamaların büyük çoğunluğu basitlik bind kullanmaz. SASL bind kullanır. Bu durumda:
- Parola açık metinleri gönderilmez.
- Oturum zaten şifrelenmiştir.
- TLS katmanına ihtiyaç duyulmadan güvenli iletişim sağlanır.
Bu düzenek yalınce domain üyeleri için değil, elverişli şekilde yapılandırılmış hiç tek başvuru için geçerlidir.
Peki AD LDAP Nasıl Güçlendirilir?
389 portunu kapattı çözüm değildir. Bunun seçenek önerilen yaklaşım şudur:
- Domain controller’larda LDAP signing güçunlu hale getirilmelidir.
- Event log’lar izlenmeli, basitlik bind kullanım durumları belirleme edilmelidir.
- Eğer tek başvuru basitlik bind lüzumtiriyorsa, o başvuru özelinde 636/3269 portu ve sertifika güveni yapılandırılmalıdır.
English (US) ·