Protokol sertleştirmesi: LDAP, NTLM, SMB ve Kerberos kontrollerini güvenle devreye almak.

1. Core Mechanism / Temel mekanizma

Protokol sertleştirmesi, kimlik doğrulamanın hangi protokolde, hangi kanala ve hangi hedef adına bağlandığını değiştiren bir migration problemidir.

Arabirimler ve belirtimler

• LDAP bind: TLS kullanılmayan SASL signing/sealing, TLS ile korunan simple bind ve TLS + SASL channel binding ayrı koşullarla değerlendirilir.
• NTLM: challenge-response ve relay yüzeyi; audit/deny geçişi bağımlılık envanterinden sonra yapılır.
• SMB: signing mesaj bütünlüğünü sağlar; SMB 3 encryption şifreli bağlantıda gizlilik ve bütünlük sağlar ve bu yolda ayrı signing korumasının yerini alabilir. Signing tek başına gizlilik sağlamaz; davranış protocol/version ve yapılandırmaya bağlıdır.
• Kerberos: SPN/DNS/zaman ve ticket akışı doğru hedef kimliği için gereklidir; fallback davranışı ayrı izlenmelidir.

Kontrolü tehdide bağla

LDAP signing/channel binding ve SMB signing aynı kontrol değildir: biri directory bind kanalını, diğeri SMB mesaj bütünlüğünü hedefler. SMB 3 encryption etkin yol üzerinde gizlilikle birlikte bütünlük de sağlar ve signing korumasını ayrıca yapılandırma gereğini değiştirebilir; signing tek başına içerik gizliliği sağlamaz. NTLM audit ise hangi yolların kaldığını görünür kılar.

Kerberos'u “her durumda güvenli ve otomatik” saymak da doğru değildir: yanlış SPN, DNS veya saat bağımlılığı fallback veya başarısızlık yaratabilir.

Aşamalı devreye alma

Önce audit ve inventory, sonra dar kapsamlı enforcement, sonra başarısız istemci/servisleri düzeltme. Policy'yi tüm domain'de bir anda değiştirmek yerine owner, protokol, hedef ve rollback koşulu yazılı olmalıdır.

Buradan sonraki mekanizmaya

Bir kontrolün OS adı, kurulu build/update ve effective policy koşullarını değişiklik kaydına yaz. 06.04’te RC4 default geçişi açık configuration’dan, 11.04’te certificate mapping Enforcement tarihi tarihsel Compatibility’den ayrılır. LDAP signing’in kendi sürüm ve policy koşulları 03.06’dadır. Bunları tek bir “modern Windows güvenli” etiketiyle kapatma.

Durum ve veri akışı

1. Protokol ve caller envanterini çıkar.
2. Audit sinyalini ve uyumluluk ölçümünü aç.
3. Tek bir service/OU/segment üzerinde enforcement uygula.
4. Başarısız bind/logon/share desenlerini düzelt, sonra kapsamı genişlet.

2. Exploitation / İstismar

Broken trust assumption

Saldırgan, imzasız veya kanala bağlı olmayan bir authentication path arar; sertleştirme migration'ı sırasında açık kalan fallback, relay veya downgrade yüzeyinden yararlanabilir.

Technical prerequisites

• İstemci/servis protokol yetenekleri bilinmiyor.
• LDAP/SMB/NTLM enforcement ile Kerberos bağımlılıkları birlikte test edilmemiş.
• Log toplama, clock ve SPN/DNS görünürlüğü eksik.

Exploitation mechanism / İstismar mekanizması

Red bakışı, “protokol açık” demek yerine çağrıyı hedefe ve kanala bağlayan kontrolün nerede eksik olduğunu arar: LDAP bind için signing/channel binding, SMB için signing/encryption, NTLM için audit-to-deny ve Kerberos için doğru SPN/DNS/zaman. Migration sırasında enforcement dışı kalan tek yol, korunmamış authentication path olarak kalabilir.

Relay ve downgrade sınırı

Signing veya channel binding, karşı tarafın mesajı başka bağlantıda kullanmasını zorlaştıran bağlam sağlar; ancak etkinlik, protokol/istemci desteği ve doğru policy kapsamına bağlıdır. “Policy açık” ile “tüm caller enforcement altında” aynı şey değildir.

Kerberos fallback

Kerberos başarısız olduğunda hangi caller'ın NTLM'e düştüğü, failure ve audit verisi olmadan varsayılamaz. SPN ve DNS düzeltmesi, NTLM deny'dan önce bağımlılık çalışmasının parçasıdır.

3. Defense & Detection / Savunma ve tespit

Telemetry scope

• LDAP signing/channel binding, SMB signing/encryption ve NTLM restriction policy sonuçlarını protokol bazında ölç; tek genel “secure” etiketi kullanma.
• 4624/4776 ve LDAP/SMB sunucu loglarını caller, target, protocol ve zaman ile korele et.
• Kerberos failure/fallback için SPN, DNS ve saat sapmasını ayrı gözlemle; ticket içeriği hakkında kanıtsız yorum yapma.
• Enforcement değişikliğini owner, kapsam, beklenen failure sinyali ve rollback koşuluyla kaydet.

Events and relevant fields

• 4624 artifact'i LogonType 3 ve AuthenticationPackageName değerlerini gösteren sentetik bir oturum kaydıdır; protocol hardening sonucunu tek başına kanıtlamaz.
• Event alanları kimlik doğrulama sonucunu gösterir; signing/channel binding'in her byte düzeyde doğrulandığını iddia etmez.

Blue ölçüm sırası

Önce hangi caller hangi protokolü kullandığını ölç; sonra policy'nin o caller için gerçekten enforcement olduğunu doğrula. 4624 gibi genel olaylar destekleyici sinyaldir, proof değildir.

Sertleştirme bir release'tir

Bir kontrolü açmak, uyumlu istemcilerin çalıştığını varsaymak değildir. Canary kapsamı, failure telemetry, owner'lı rollback ve yeniden ölçüm olmadan genişletme yapılmamalıdır.

Detection logic · KQL

// Schema example; not run. Measures NTLM visibility before enforcement.
SecurityEvent
| where EventID == 4624
| where AuthenticationPackageName in ("NTLM", "Kerberos")
| summarize count() by Computer, AuthenticationPackageName, LogonType

Query assumptions

• SecurityEvent alan adları ve toplama kapsamı bu örnekte varsayılmıştır.
• 4624 içindeki AuthenticationPackageName protokol yolu için sinyaldir; signing/channel binding enforcement kararını tek başına vermez.

False positives

• Uygulama proxy veya servis hesabı gerçek caller'ı gizleyebilir.
• Aynı bilgisayarda farklı protokoller aynı kullanıcı adıyla görünebilir.

Hardening

• TLS kullanılmayan SASL bind için istemcinin signing veya sealing desteğini ve DC’nin signing gereksinimini birlikte doğrula.
• Simple bind için TLS ve sunucu certificate doğrulamasını kullan; şifresiz simple bind’i güvenli kabul etme. TLS + simple bind yolunda CBT bulunmaz.
• TLS + SASL bind için channel binding ve client desteğini ayrıca değerlendir. TLS bu kanalda mesaj korumasını sağlar; SASL signing/sealing’i TLS’in üstüne eklenen bir katman gibi gösterme.
• LDAP TLS + SASL bağlamında CBT, EPA’nın channel-binding uygulamasıdır; “TLS mi EPA mı?” diye alternatif seçme. Başka servislerdeki EPA policy’sini o servisin kapsamıyla değerlendir. Sürüm, güncelleme ve istemci uyumluluğunu kontrol ederek kademeli uygula; önce bind failure nedenlerini topla.
• NTLM kullanımını önce audit et, bağımlılıkları sahipleriyle düzelt, sonra dar kapsamlı restriction/deny uygula.
• SMB signing'i gereken sunucu/istemcilerde zorunlu kıl; encryption ihtiyacını ayrı veri sınıflandırması ve performans ölçümüyle belirle.
• Kerberos için SPN, DNS ve saat senkronizasyonunu koru; NTLM fallback sinyalini migration gate yap.
• Her enforcement değişikliğini geri dönüş koşulu, beklenen olay şeması ve sorumlu owner ile yayınla.

Örnekler üzerinde oku / Read the examples

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event"><System><Provider Name="Microsoft-Windows-Security-Auditing"/><EventID>4624</EventID><Version>0</Version><Level>0</Level><Task>12289</Task><Opcode>0</Opcode><Keywords>0x8020000000000000</Keywords><TimeCreated SystemTime="2026-10-01T10:00:00.0000000Z"/><EventRecordID>12001</EventRecordID><Channel>Security</Channel><Computer>DC01.outreason.example</Computer></System><EventData><Data Name="SubjectUserSid">S-1-5-18</Data><Data Name="TargetUserName">svc-ldap</Data><Data Name="LogonType">3</Data><Data Name="LogonProcessName">Kerberos</Data><Data Name="AuthenticationPackageName">Kerberos</Data><Data Name="IpAddress">10.20.30.40</Data></EventData></Event>

İki yanlış kanı / Two reality checks

Sanılan: LDAP signing, SMB signing, NTLM deny ve Kerberos ayarlarını aynı anda açmak tek adımlı ve risksiz bir hardening'dir.

Gerçekte: Bunlar farklı protokol/kanal kontrolleridir; caller uyumluluğu, audit, canary kapsamı ve rollback koşulları ayrı doğrulanmalıdır.

Sanılan: 4624'te AuthenticationPackageName=Kerberos görünmesi signing ve channel binding'in kesinlikle çalıştığını kanıtlar.

Gerçekte: 4624 authentication package için bir sinyaldir; kanal bağlama ve mesaj signing durumunu tek başına kanıtlamaz. Bunun için ilgili protokolün policy ve telemetry kanıtı gerekir.

Kaynaklar / Sources

• Microsoft Learn · LDAP signing requirements
  LDAP signing and audit/enforcement rollout; client compatibility and policy scope.
• Microsoft Learn · Protect SMB traffic from interception
  SMB signing and encryption interaction; encryption protects confidentiality and integrity on supported encrypted SMB traffic and can supersede separate signing protection on that path.
• Microsoft Learn · NTLM overview
  NTLM challenge-response modeli ve mümkün olduğunda Kerberos'a yönlendirme.
• Microsoft Learn · Kerberos authentication overview
  Kerberos ticket-based authentication, SPN/DNS/zaman bağımlılıklarının genel sınırı.
• Microsoft · 4624 audit event
  AuthenticationPackageName, LogonType ve audit event alanları.
• Microsoft Learn · LDAP signing and channel binding
  LDAP signing ile channel binding ayrımı ve Windows Server sürümüne göre davranış.
• Microsoft · LDAP session security after ADV190023
  Non-TLS SASL, TLS+simple bind and TLS+SASL sections; CBT/EPA relationship.
• Microsoft Open Specifications · MS-ADTS Using SSL/TLS
  5.1.2.2: no SASL-layer message protection on TLS-protected LDAP; channel binding.