🔐 Windows AD 進階安全強化：Kerberos、NTLM 限制、LDAP Signing、模擬攻擊與防禦
在多數企業環境裡，Active Directory（AD）就是「身份與權限」的中樞神經。 一旦 AD 被拿下，不只是單一系統被入侵，而是整個網域、檔案伺服器、Exchange、各種 Line-of-Business 系統全部一起淪陷。
本篇從實務角度出發，整理出 AD 安全強化的幾個關鍵面向：
- Kerberos 設計與安全風險
- NTLM 如何被濫用？如何限制？
- LDAP Signing / Channel Binding 的必要性
- 常見模擬攻擊與防禦（Kerberoasting、Pass-the-Ticket、DCSync…）
- 實務部署路線圖（如何「不炸毀」既有系統的前提下逐步強化）
一、AD 認證基礎：Kerberos 與 NTLM 的角色分工
在 AD 網域中，預設優先使用 Kerberos，只有在下列情況才會退回 NTLM：
- 目標服務無法使用 Kerberos SPN
- WORKGROUP / 舊系統（例如：舊 NAS、舊印表機）
- 跨信任、跨網域環境配置不完整
簡單來說：
- Kerberos：以 Ticket 為主的安全設計，可支援雙向驗證（Client / Service）。
- NTLM：舊式的 Challenge/Response 機制，弱點多、容易被 Pass-the-Hash 濫用。
因此 AD 安全強化的核心思路可以簡化為三句話：
- 盡量讓所有服務都能使用 Kerberos。
- 逐步「限制」乃至關閉 NTLM。
- 對 Kerberos 本身常見攻擊（如 Kerberoasting）進行風險控管。
二、Kerberos 安全強化：從 SPN 到 Ticket 生命周期
1. SPN 規劃與服務帳號控管
Kerberos 使用 Service Principal Name（SPN） 來識別服務，例如：
setspn -S HTTP/webapp01.corp.local CORP\webapp_svc
setspn -S MSSQLSvc\db01.corp.local CORP\sql_svc
幾個實務建議：
- 盡量使用專用服務帳號（Service Account），不要用 Domain Admin 帳號跑服務。
- 定期檢查 SPN 是否重複或錯誤，避免認證失敗或被惡意利用。
- 對高權限服務帳號強制使用長度足夠、複雜度高、定期輪替的密碼，或考慮 gMSA（Group Managed Service Account）。
2. Kerberos Ticket 生命周期與風險
Kerberos 中常見的壽命設定：
- Ticket lifetime：例如 10 小時
- Renew lifetime：例如 7 天
如果壽命過長，被竊取的 Ticket 可以長時間用於橫向移動；過短則可能影響使用者體驗。 建議做法：
- 維持官方預設值（例如：10 小時 / 7 天），但搭配「高敏感資源」採用其他保護（PAW、Jump Host）。
- 對 Domain Admin 等高權限帳號限制登入位置（Log on to），避免在一般工作站留下 Ticket。
三、NTLM 限制策略：從監控到逐步封殺
NTLM 是多數 AD 攻擊鏈中的老朋友，常見的 Pass-the-Hash、Relay 攻擊都與它有關。 完全關閉 NTLM 在現實世界非常困難，但可以循序漸進：
1. 先了解目前有多少 NTLM 流量
在 DC 上啟用相關稽核政策：
電腦設定 → 原則 → Windows 設定 → 安全性設定 →
本機原則 → 稽核原則 → 稽核使用者登入事件 / 稽核登入事件
也可以啟用「NTLM 使用稽核」相關 GPO，讓 Domain Controller 記錄 NTLM 使用來源，之後透過 SIEM 或 Windows 事件檢視器分析：
- 來源 IP / 主機名
- 帳號名稱
- 目標服務
2. 設定「Network security: LAN Manager authentication level」
在 GPMC 中：
電腦設定 → Windows 設定 → 安全性設定 →
本機原則 → 安全性選項 →
Network security: LAN Manager authentication level
建議設定為：
- Send NTLMv2 response only. Refuse LM & NTLM（逐步導入，需事先測試）
實務上可以：
- 先套用在 Test OU → 驗證舊系統是否正常。
- 再擴大到一般使用者 OU。
- 最後再評估是否要在 DC 層級完全拒絕舊式 NTLM。
四、LDAP Signing / Channel Binding：避免中間人夾擊
許多 AD 整合系統會透過 LDAP 查詢使用者資訊，如果是 未加密、未簽章 的 LDAP，容易被中間人攻擊（MITM）篡改結果。
1. LDAP Signing 是什麼？
簡單說就是要求 LDAP 用戶端與伺服器之間的通訊必須：
- 使用 簽章（Signing） 驗證完整性，或
- 直接使用 LDAPS（TCP 636 + TLS）
2. 啟用 LDAP Signing GPO（建議路線）
在 DC 的 GPO 中：
電腦設定 → Windows 設定 → 安全性設定 →
本機原則 → 安全性選項 →
Domain controller: LDAP server signing requirements
建議導入流程：
- 先設為 None + Audit（只稽核不強制，視 Windows 版本而定）。
- 分析事件日誌，找出未支援 LDAP Signing 的應用（舊版裝置 / 程式）。
- 逐步修正應用設定，改用 LDAPS 或支援簽章。
- 最後改為 Require signing。
3. Channel Binding Token（CBT）
對於使用 TLS 的 LDAP（LDAPS），可再透過 Channel Binding 防止憑證被中間人轉接重用。 部分舊系統可能不支援 CBT，因此同樣建議先稽核再強制。
五、常見 AD 模擬攻擊與防禦思路
下列攻擊幾乎是滲透測試與紅隊演練的標配：
- Pass-the-Hash（PtH）：竊取 NTLM Hash，直接模擬身分登入。
- Pass-the-Ticket（PtT）：竊取 Kerberos Ticket，直接取得服務存取權。
- Kerberoasting：大量要求 Service Ticket，離線暴力破解服務帳號密碼。
- DCSync：假裝自己是 DC，從 AD 中把所有 Hash Dump 下來。
- Golden Ticket：掌握 KRBTGT 帳號 Hash 後，偽造任何帳號的 Ticket。
對應防禦對策（高層級策略）
- Tiered Admin 模型：將 Domain Admin、Server Admin、Workstation 分層管理，不在一般工作站登入高權限帳號。
- 使用獨立管理帳號：不要以「一般登入帳號」兼做 Domain Admin。
- 限制高權限帳號登入位置（Log on to）。
- KRBTGT 密碼定期輪替（需謹慎規劃）。
- 啟用進階稽核與集中式日誌，能在攻擊行為早期就發現異常。
六、GPO 實務範例：集中套用安全基準
多數安全設定應透過 GPO 統一控管，避免手動逐台修改。
1. 建議建立的 GPO 分層
- Baseline – Domain Controllers：專門給 DC 的硬化設定。
- Baseline – Member Servers：一般伺服器共通設定。
- Baseline – Workstations：用戶端端點安全基準。
2. 常見可納入的項目（節錄）
- LAN Manager authentication level（拒絕 LM / NTLMv1）。
- NTLM 稽核與限制設定。
- LDAP Signing 要求。
- Kerberos policy：票證壽命、Clock Skew 等（注意與現況相容性）。
- 進階稽核政策：帳號登入、目錄服務存取、權限提升、物件存取…。
七、部署路線建議：不要一次把自己打爆
實務上最怕的不是「設定太鬆」，而是「一次鎖死所有東西，結果 AD 旁邊一堆應用全掛」。 建議的導入順序可以參考：
- 盤點：先開啟稽核、收集現況（NTLM 使用、LDAP 未簽章、舊系統…）。
- 建立 Test OU / Pilot 群組：先鎖測試環境與少量使用者。
- 調整應用與設備設定：NAS、印表機、舊 Web App 等。
- 逐步放大範圍：部門 → 全公司。
- 最後才談「禁止」某些協定，而不是一開始就完全封殺。
八、與既有 AD 架構文章的搭配閱讀
如果你正在部署或重構 AD，這篇文章可以與下列主題搭配閱讀：
- 如何建立穩定的 AD 架構與 DNS：名稱解析錯誤常常是 AD 問題的根源。
- 如何規劃 OU / GPO 繼承，讓安全政策可以「分層」生效。
- 如何搭配 AD CS（憑證服務）讓 LDAP / Web 服務全面上 TLS。
沒有留言: