Active Directory Güvenliği ve Sertleştirme (Hardening)

Bu seride önce kurumsal bir Active Directory yapısını sıfırdan kurduk, ardından OU, kullanıcı ve grup yönetimiyle bu yapının içini doldurduk. Kurulum tamamlanıp her şey çalıştıktan sonra sıra, ortamı saldırılara karşı sertleştirmeye (hardening) gelir.

Bu yazıda en sık atlanan ama en yüksek getirili sertleştirme başlıklarını ele alacağız: LDAP güvenliği (channel binding + signing), bunların olay günlüğünden izlenmesi, DNS proxy ile derinlemesine savunma (defense-in-depth) ve built-in Administrator hesabının yönetimi — break-glass yaklaşımı ve katmanlı yönetim (tiering) dahil.

Örnekler, kurulum yazısındaki hogwarts.local ortamını temel alır:

LDAP Güvenliği: Channel Binding ve Signing

LDAP/LDAPS’i NTLM relay saldırılarına karşı sertleştirmek için iki ayar birlikte kullanılır: LDAP channel binding ve LDAP signing (Microsoft ADV190023 sertleştirme tavsiyesi). İkisi birden, çalınan bir kimlik doğrulamanın başka bir servise relay edilmesini engeller.

Hatırlatma: DC’ler arası replication ve iç LDAP sorguları, kurulum yazısındaki trafik akışı bölümünde gösterdiğimiz gibi Kerberos ile zaten imzalı ve şifrelidir. Buradaki iki ayar, bu korumayı zorunlu hâle getirerek imzasız bind kabul eden kapıyı — yani relay yüzeyini — kapatır.

1) Channel binding — LdapEnforceChannelBinding: Kimlik doğrulamayı, üzerinde aktığı TLS kanalına bağlar; böylece bir LDAPS oturumu çalınıp başka yere relay edilemez. Her DC’de şu registry değeriyle ayarlanır:

HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\LdapEnforceChannelBinding

# Her iki DC'de (DUMBLEDORE-DC01 ve MCGONAGALL-DC02) — tek satır
New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Parameters" -Name "LdapEnforceChannelBinding" -Value 1 -PropertyType DWORD -Force

Güvenli geçiş (rollout): Doğrudan 2‘ye atlamayın — 2, CBT desteklemeyen (eski Windows, Linux/Java LDAP istemcileri, bazı appliance’lar) istemcileri reddeder. Önce 1 yapın; bir süre Directory Service olay günlüğünde Event ID 3074/3075 (uyumsuz istemci) olup olmadığını izleyin; hiç çıkmıyorsa 2‘ye yükseltin. Bu ayar reboot gerektirmez ve yalnızca LDAPS/TLS bağlantıları için geçerlidir.

2) LDAP signing: Channel binding’i tamamlar (relay’in diğer yarısını kapatır). GPO ile zorlayın:

• Domain controller: LDAP server signing requirements → Require signing
• Network security: LDAP client signing requirements → Require signing

Bu iki ayarı da kademeli uygulayın: önce denetim/uyumluluk modunda istemcileri gözleyin, imzalamayı desteklemeyen istemci kalmadığından emin olduktan sonra Require signing’e geçin.

İzleme: Directory Service günlüğü ve LDAP Event ID’leri

Kademeli geçişin kalbi izlemedir: zorlamayı (enforcement) açmadan önce, hangi istemcilerin uyumsuz olduğunu Directory Service olay günlüğünden tespit edersiniz.

# Son 7 günün LDAP güvenlik olaylarını listele (her iki DC'de çalıştırın)
Get-WinEvent -FilterHashtable @{
  LogName   = "Directory Service"
  Id        = 2886,2887,2889,3074,3075
  StartTime = (Get-Date).AddDays(-7)
} | Select-Object TimeCreated, Id, Message

# 2889 (imzasız bind yapan istemcinin IP'si) için LDAP arayüz tanılamasını aç (2 = temel seviye)
New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics" `
  -Name "16 LDAP Interface Events" -Value 2 -PropertyType DWORD -Force

Hiç uyumsuz istemci görünmüyorsa LdapEnforceChannelBinding‘i 2‘ye, signing ayarlarını Require signing’e yükseltebilirsiniz. Uyumsuz istemci varsa önce onu (güncelleme/yapılandırma ile) düzeltin — aksi halde zorlama açıldığında o istemci sessizce erişimini kaybeder.

DNS Proxy ve Koşullu Yönlendirme (Defense-in-Depth)

Büyük ortamlarda istemciler, DNS sorgularını doğrudan Domain Controller’lara değil, önce ayrı bir DNS proxy‘ye (örn. Linux üzerinde BIND veya ayrı bir Windows DNS) gönderir. Bu proxy yalnızca AD bölgesine ait sorguları DC’lere koşullu yönlendirir (BIND’de type forward; forward only; forwarders { 192.168.1.231; 192.168.1.232; };), kalan trafiği internete çıkarır. Faydası: DNS yönetimi merkezîleşir ve DC’ler DNS sorgu katmanında doğrudan tüm istemcilere açık durmaz; bu da derinlemesine savunmanın (defense-in-depth) bir parçasıdır.

Önemli sınır — gizleme değil, katman: Bu yöntem DC’lerin IP adresini tamamen gizlemez. Kimlik doğrulama (Kerberos/LDAP) ve dinamik DNS kaydı, tasarım gereği DC’ye doğrudan bağlanır; ayrıca dönen SRV/A kayıtları DC’nin IP’sini içerir. Dolayısıyla DNS proxy’yi bir “IP gizleme” aracı değil, DNS mimarisini sadeleştiren ve sorgu yüzeyini azaltan bir adım olarak görün. Gerçek izolasyon için firewall, VLAN segmentasyonu ve katmanlı yönetim (tiering) gerekir. Bu kurguda DC’ler kendi DNS ayarlarında yine birbirini/loopback’i gösterir; AD bölgesi DC’lerde AD-entegre kalır (proxy’ye kopyalanmaz).

Built-in Administrator Hesabının Yönetimi

İlk Domain Controller’ı kurarken built-in Administrator hesabını kullanmak kaçınılmazdır; makine henüz Domain’e dahil değilken tek yetkili hesap budur. Kurulum yazısında Install-ADDSForest çalıştığında bu hesap otomatik olarak Domain Administrator‘a (HOGWARTS\Administrator) dönüşmüştü. Buraya kadar her şey normaldir.

Asıl mesele kurulum sonrasıdır: built-in Administrator (SID’i ...-500 ile biten) hesabını günlük yönetim için kullanmak kötü bir pratiktir, çünkü:

• Kilitlenmez (lockout uygulanmaz) → brute-force saldırıları için ideal hedeftir.
• SID’i bilinir (-500); saldırganların ilk denediği hesaptır.
• Herkes aynı hesabı kullanırsa denetlenebilirlik (auditing) kaybolur; log’larda kimin ne yaptığı belli olmaz.

Devre dışı bırakmadan ÖNCE yapılması gerekenler

Kritik: Administrator’ı devre dışı bırakmadan önce, yerine geçecek ayrı yönetici hesaplarını oluşturup test edin. Aksi halde kendinizi Domain’den kilitleyebilirsiniz.

1. Kendinize ayrı bir yönetici hesabı açın ve Domain Admins grubuna ekleyin:

New-ADUser -Name "Murat Admin" -SamAccountName "murat.admin" `
  -UserPrincipalName "murat.admin@hogwarts.local" `
  -AccountPassword (Read-Host -AsSecureString "Parola") `
  -Enabled $true
Add-ADGroupMember -Identity "Domain Admins" -Members "murat.admin"

2. Yeni hesapla oturum açıp DC yönetimi, GPO gibi işlerin çalıştığını doğrulayın.
3. DSRM parolasını güvenli sakladığınızdan emin olun; Administrator devre dışı olsa bile felaket kurtarmada DSRM gerekir.
4. Ancak bundan sonra built-in Administrator’ı devre dışı bırakın:

Disable-ADAccount -Identity "Administrator"

Devre dışı bırakmak mı, “break-glass” mı?

Tamamen devre dışı bırakmak yerine, birçok kurum Administrator’ı “kırılması gereken cam” (break-glass) hesabı olarak saklar:

• Çok uzun ve karmaşık bir parola verilir, fiziksel kasada veya parola kasasında (vault) tutulur.
• Normalde hiç kullanılmaz, sadece acil durumda (örn. tüm yetkili hesaplara erişim kaybı) açılır.
• Üzerine denetim/alarm kurulur; her oturum açma denemesi SIEM’e bildirilir.

İki yaklaşım da kabul edilebilir; önemli olan hesabın günlük işlerde asla kullanılmamasıdır.

Bir adım ileri: katmanlı yönetim (tiering)

• Domain Admin hesaplarını yalnızca DC yönetimi için kullanın; internet, e-posta veya iş istasyonu oturumları için asla kullanmayın.
• Günlük işleriniz için standart (yetkisiz) bir hesap kullanın; yönetim gerektiğinde runas ile ayrı admin hesabına yükselin.
• Bu, Tier 0 / Tier 1 / Tier 2 modelinin temelidir ve bir saldırganın iş istasyonundan Domain Controller’a sıçramasını (lateral movement) ciddi biçimde zorlaştırır.

Tiering’in günlük operasyondaki en somut karşılığı, OU ve grup yönetimi yazısında gösterdiğimiz yetki devridir (delegation): bir OU’nun yönetimini, Domain Admin yetkisi vermeden yalnızca o OU ile sınırlı olarak devredersiniz.

Sonuç

Sertleştirme, kurulumun bittiği yerde başlar ve bu yazıda üç yüksek getirili başlığı ele aldık:

• LDAP channel binding + signing, NTLM relay’e karşı birlikte uygulanır; doğru sıra önce denetim (değer 1 / uyumluluk modu), izleme (Event ID 2886/2887/2889, 3074/3075), sonra zorlamadır.
• DNS proxy, DC’lerin sorgu yüzeyini azaltan bir derinlemesine savunma katmanıdır — ama IP gizlemez; gerçek izolasyon firewall, VLAN segmentasyonu ve tiering ister.
• Built-in Administrator günlük işlerde asla kullanılmaz: ya devre dışı bırakılır ya break-glass hesabı olarak kasada saklanır; yönetim, katmanlı model (tiering) ile ayrı hesaplara bölünür.

Bu adımlar, kurulum ve kullanım yazılarında kurduğumuz yapının üzerine oturur. Peki bu sertleştirmenin gerçekten işe yaradığını nasıl doğrularsınız? Active Directory Güvenlik Denetim Araçları yazısında, ortamınızı bir saldırganın gözünden tarayan (PingCastle, BloodHound, Certipy ve diğer) araçlarla açıkları kendiniz bulmayı ele alıyoruz. Bir sonraki adım olarak Group Policy (GPO) ile güvenlik ayarlarını (parola politikaları, audit politikaları, kısıtlamalar) merkezî olarak dağıtmayı öğrenmek ise bu sertleştirmeyi kalıcı ve ölçeklenebilir hâle getirecektir.