Active Directory'de LDAP Servis Hesaplarını Korumak: Mirket NHI LDAP Proxy

Güvenlik duvarı, VPN, NAC, yazıcı sunucusu, ERP ve eski uygulamaların neredeyse hepsi Active Directory'ye LDAP üzerinden, parolası hiç değişmeyen bir servis hesabıyla bağlanır. Mirket Security, yeni yayımladığı üç dakikalık videoda bu hesapların nasıl ele geçirildiğini ve Mirket NHI – LDAP Proxy ile nasıl korunabileceğini anlatıyor. Bu yazıda videodaki yaklaşımı ve devreye almadan önce bilinmesi gerekenleri özetliyoruz.

Parolası hiç değişmeyen hesaplar neden bu kadar riskli?

İnsan olmayan kimlikler (non-human identity, NHI) arasında en yaygın ve en az yönetilen grup LDAP servis hesaplarıdır. Mirket'in çözüm özetinde sorun üst üste binen beş katman olarak tarif ediliyor:

• Açık metin: 389/tcp üzerinden yapılan basit bind işleminde kullanıcı adı ve parola ağda şifresiz dolaşır; tek bir paket yakalamak yeterlidir.
• Rotasyon felci: Aynı parola her ürünün yapılandırmasında, yedeklerinde, kurulum dokümanlarında ve destek kayıtlarında durur. Değiştirmek onlarca ürüne dokunmak demek olduğu için pratikte hiç değiştirilmez.
• Geniş okuma yetkisi: Varsayılan dizin okuma izni ürün bazında nadiren daraltılır; her entegrasyon kullanıcıları, grupları, OU'ları, SPN'leri ve açıklama alanına yazılmış parolaları listeleyebilir.
• LDAPS tek başına yetmez: Bazı ürünler LDAPS desteklemez, bazıları sertifika doğrulamasını kapatır. LDAPS konuşamayan tek bir eski ürün, etki alanı denetleyicisinde LDAP imzalama ve channel binding sıkılaştırmasını engeller.
• Tespit boşluğu: Geçerli bir servis hesabıyla yapılan keşif başarısız oturum açma üretmez, olağan trafiğin içinde kaybolur.

Güvenlik açığı gerektirmeyen saldırı zinciri

Videoda anlatılan senaryoyu çarpıcı kılan, hiçbir adımda bir zafiyetin istismar edilmemesi. Saldırganın izlediği yol şöyle:

1. Ağda trafiği görebileceği bir konum elde eder.
2. Basit bind sırasında servis hesabının kimlik bilgisini yakalar.
3. Bu bilgiyle herhangi bir noktadan etki alanı denetleyicisine bağlanır.
4. Dizinin tamamına yakınını okur.
5. Topladığı bilgiyle hedefli bir yetki yükseltme saldırısı kurgular.

Servis hesabında MFA olmadığı ve parola yıllardır aynı kaldığı için, yakalanan kimlik bilgisi saldırganın elinde süresiz geçerli bir anahtara dönüşür.

Mirket NHI LDAP Proxy bu zinciri nerede kırıyor?

Çözüm, ürünlerle etki alanı denetleyicileri arasına politika uygulayan tek bir geçiş noktası koyuyor. İki bileşen var: trafiği sonlandıran, kararı uygulayan ve bind işlemlerini kaydeden LDAP Proxy ajanı ile kimlik bilgisinin durumunu, kaynak IP'yi, DN kapsamını ve MFA'yı değerlendiren Mirket Portal. Proxy kendi başına karar vermez; karar Portal'dan gelir.

Sanal kimlik bilgileri

Her ürüne yalnızca Mirket'in tanıdığı, Active Directory'de karşılığı olmayan ayrı bir sanal kimlik bilgisi verilir. Gerçek AD parolası ürün yapılandırmasına hiç girmez. Böylece hangi bind işleminin hangi üründen geldiği ayırt edilir, tek bir ürünün erişimi diğerlerine dokunmadan iptal edilebilir ve çalınan sanal kimlik bilgisi Kerberos, SMB ya da başka sistemlerde işe yaramaz.

Günlük otomatik parola rotasyonu

Gerçek parolayı yalnızca Mirket bildiği için, AD tarafındaki parola hiçbir ürüne dokunmadan her gün değiştirilebilir. Yıllardır ertelenen rotasyon bir proje olmaktan çıkar, arka planda çalışan bir rutine dönüşür.

Kaynak IP ve DN kapsamı

Her kimlik bilgisi yalnızca tanımlı kaynak IP adreslerinden kabul edilir ve belirli bir DN kapsamıyla sınırlanır; örneğin VPN ürünü yalnızca VPN kullanıcılarının bulunduğu OU'yu sorgulayabilir. Kapsam dışı aramaları proxy reddeder. Çalınan bir kimlik bilgisi başka bir makineye taşınamaz.

Protokol yükseltme ve ADV190023

Ürün proxy'ye düz LDAP ile konuşsa bile proxy etki alanı denetleyicisine LDAPS ya da imzalı LDAP ile bağlanır. Açık metin dolaşan bölüm ürün ile proxy arasına iner ve Microsoft'un ADV190023 önerisindeki LDAP imzalama ile channel binding sıkılaştırması, eski ürünlere dokunmadan açılabilir hâle gelir. Sertifikalar da tek noktadan yönetilir.

Yalnızca LDAP konuşan eski uygulamalara MFA

RADIUS, SAML ya da OIDC desteklemeyen eski uygulamalarda ikinci faktör için bir aşama yoktur. Proxy, son kullanıcı bind işlemlerini Portal'a yönlendirir; kullanıcının telefonuna bir push bildirimi gider, onaylanırsa bind iletilir, reddedilir ya da yanıtsız kalırsa engellenir. Servis hesaplarının bind işlemleri bu adımdan muaftır ve uygulama kodunda değişiklik gerekmez.

Yerleşik honeytoken

Sanal kimlik bilgisinin proxy dışında bir yerde görülmesi meşru bir açıklaması olmayan bir olaydır; bu yüzden Mirket bunu yanlış pozitif oranı sıfıra yakın bir ihlal sinyali olarak ele alır. Politika dışı kaynaktan gelen deneme hem engellenir hem de güvenlik olayı üretir. Bu sinyal, Mirket ITDR ile yürütülen kimlik tabanlı tehdit tespitini tamamlar.

Öncesi ve sonrası

Devreye almadan önce bilinmesi gerekenler

Çözüm özeti, geçişin sırasını ve sınırlarını da açıkça yazıyor. Planlama yaparken şu noktalar öne çıkıyor:

• Önce envanter: Hangi ürünün nereden, nasıl bind ettiği etki alanı denetleyicisindeki 2886, 2887, 2888 ve 2889 numaralı olaylardan çıkarılır. Bu olaylar LDAPS ve imzalı istemcileri göstermediği için ağ seviyesinde yakalama ile desteklenmelidir.
• Global Catalog unutulmamalı: Kontrol 389 ve 636'nın yanında 3268 ve 3269 numaralı portları da kapsamalıdır; aksi hâlde anlamını yitirir.
• “Proxy dışında her şeyi engelle” kuralı yazılamaz: Grup ilkesi, sertifika otomatik kaydı ve denetleyiciler arası sorgular LDAP'a ihtiyaç duyar. Engelleme üçüncü taraf kaynaklarla sınırlı tutulur.
• Ürünler tek tek taşınır: Her ürün için sanal kimlik bilgisi oluşturulur, LDAP sunucu adresi proxy'ye çevrilir ve doğrulama yapılır. Portlar ve imzalama sıkılaştırması ancak bundan sonra devreye alınır; otomatik rotasyon ve MFA en sonda, önce pilot grupla açılır.
• Kesinti senaryosu yazılı olmalı: Proxy aktif-aktif, Portal yedekli kurulur. Karar katmanına ulaşılamadığında isteklerin reddedileceği mi yoksa süreli bir istisna yolunun mu işleyeceği kurumun risk tercihine göre önceden belirlenir.
• İmzalama şifreleme değildir: Gizlilik için LDAPS, StartTLS ya da SASL sealing gerekir.

Mirket, çözümü ADV190023'ün yanı sıra ISO/IEC 27001:2022, PCI DSS v4 (Gereksinim 8.6) ve GDPR Madde 32 ile ilişkilendiriyor; ancak bu eşlemeyi yol gösterici olarak sunuyor ve uyum ekibiyle teyit edilmesini öneriyor.

Videoyu izleyin

Yaklaşık üç dakikalık video; sorunu, saldırı zincirini ve yukarıdaki yetenekleri sırasıyla gösteriyor: How to Secure LDAP Service Accounts in Active Directory | Mirket NHI.

Ortamınızda kaç ürünün Active Directory'ye LDAP ile bağlandığını ve bu hesapların en son ne zaman değiştirildiğini birlikte çıkarmak isterseniz, siber güvenlik çözümleri ekibimizle iletişime geçebilirsiniz.