AD域控伺服器問題解決記錄–lsass.exe流量異常
前序
公司對技術部門要求做AD域控的計劃，在落實這個計劃的過程中，會碰到一些奇奇怪怪的問題，再解決問題後，記錄一下過程和事後的感受。
出現
在落實域控的過程中，由于技術部門的資産中，有一部分在雲上，一部分在本地機房，為了實作統一的LDAP管理，通過一些标準的AD域控接口和插件來實作登陸時的賬戶和密碼驗證。于是，在本地防火牆上，對域控伺服器AD-1的389端口做了外網映射，以便雲端通過這個端口來進行AD驗證。
在一兩天後，每天下午，測試部門的夥伴開始在群裡說，雲上jenkins無法拉取本地svn代碼編譯。由于伺服器線路和辦公線路網絡時分開的。是以在辦公區域浏覽網頁什麼的都沒有什麼感覺。但是伺服器上通過PING百度等都延遲相當高，甚至會未響應。通過觀察，早上的伺服器網絡都是正常的。一到下午2點之後，伺服器網絡就開始高延遲。
排查
首先，懷疑時營運商問題。之前有段時間，營運商把我們伺服器的固定IP網絡拉到他們内網去了，是以跨網通路延遲有點高。但是雲端裝置的網絡時混合網絡接入，應該不是營運商的鍋。
在防火牆上，看流量監控。發現，排行ip流量第一的就是AD-1。每天跑4-5T的流量。通過觀察，域控伺服器每日早上的資料流量正常，最高也就200Kbps，大部分時間是0-10Kbps波動，一到下午，開始出現1-6Mbps，而且是持續長時間。在關閉了AD-1後，發現每日下午的伺服器網絡高延遲不見了。雲端裝置連接配接本地資源都正常了。那基本能确定是這台AD-1的鍋了。
AD-1系統是新裝的，沒有裝太多軟體。就安裝了Azure的AzureADConnect用于Azure和本地AD的同步。難道是同步流量？
通過同步的兩個服務，進行跟蹤，
AzureADConnectHealthSyncInsights
AzureADConnectHealthSyncMonitor
找到監控端口的同步用戶端，經過以斷時間的觀察，流量是正常的。即使每個小時同步的時候，實際流量都是非常小，不影響整個網絡的使用。
名稱 PID 本地位址 本地端口 遠端位址 遠端端口 資料包丢失 (%) 延遲時間 (ms)
Microsoft.Identity.Health.AadSync.MonitoringAgent.Startup.exe 1076 192.168.1.231 54379 40.116.232.96 443 - -
通過資源螢幕中，網絡活動的排序，找到幾個活動量最大的，一排序，都是同一個程式，唯一的差別就是遠端位址不同，一直在對外發送資料。
名稱 PID 位址 發送(位元組/秒) 接收(位元組/秒) 總數(位元組/秒)
lsass.exe 644 169.235.24.133 14802 184 3320876
lsass.exe 644 153.19.50.62 23256 125 2532345
lsass.exe 644 41.210.252.16 14532 57 1013212
lsass.exe 644 129.107.60.14 6435 5 101232
是以lsass.exe這貨瘋狂上傳資料，才是導緻整個伺服器網絡阻塞的最大兇手了？
那我是不是結束這個程序就可以讓網絡恢複呢？
然而，結束完後，系統就重新開機了。。。
解決
Local Security Authority Subsystem Service
本地安全機構子系統服務（LSASS）是Microsoft Windows 作業系統中的一個過程，負責在系統上實施安全政策。它驗證登入到Windows計算機或伺服器的使用者，處理密碼更改并建立通路令牌。[1]它還寫入Windows安全日志。
強制終止lsass.exe将導緻“歡迎”螢幕丢失其帳戶，進而提示重新啟動計算機。
由于lsass.exe是至關重要的系統檔案，是以其名稱經常被惡意軟體僞造。Windows使用的lsass.exe檔案位于目錄中 %WINDIR%\System32。如果從任何其他位置運作，則lsass.exe很可能是病毒，間諜軟體，特洛伊木馬或蠕蟲。由于某些系統顯示字型的方式，惡意開發人員可能會将該檔案命名為Isass.exe（大寫的“ I”而不是小寫的“ l”），以誘使使用者安裝或執行惡意檔案而不是受信任的系統。檔案。
難道是病毒？可是通過一系列檢查都沒有發現lsass程式被感染。在找到問題發生源，但是沒有找出實際發生問題的原因時，以先處理目前故障恢複生産為第一準則。在沒辦法永久結束程序的時候，通過伺服器内安全軟體的程序限速和防火牆的IP限速，先把AD-1這台的資料上傳量控制下來。降速下來後，網絡恢複了正常。但是連接配接域控的其他域内使用者出現了登陸緩慢等跟域通信有關的問題。這是為何呢？
如上面解釋的，lsass負責驗證登陸到windows計算機或伺服器的使用者,而域使用者登陸也是通過這個程式和域控伺服器進行通信驗證。但是即使lsass被我限速了，它還是滿速在上傳資料，還是影響了其他使用者使用lsass。
那我是否可以限制隻有本地使用者可以使用通路lsass.exe.在伺服器系統防火牆上，看到涉及到lsass.exe程序的項目有
于是在每個對應規則中，正常-選擇了隻允許安全操作
遠端計算機-添加了Domain Users.隻允許域控使用者連接配接。
在暫時恢複後，某個周末，公司都沒有人使用網絡的時候，我重新取消了所有的限制，然後用Wireshark進行抓包分析。
發現通過篩選，指向莫名IP的資料包，都是通過CLDAP協定，進行search ROOT
這又是什麼鬼協定。看起來好像跟LDAP有一毛錢關系呀。
Connection-less Lightweight Directory Access Protocol
無連接配接輕量目錄通路協定（CLDAP）
使用LDAP版本3 [1]涉及正常的TCP / IP連接配接設定對于某些應用程式可能構成不希望的開銷，特别是在隻有未經身份驗證的請求執行。通常用于快速輕量級隻讀必須将等待時間降至最低的用戶端或向多個LDAP伺服器發出大量請求。
以上是tools.ietf.org裡關于CLDAP的原理。表示沒看懂。就看到了最後幾個字，大量請求。敲黑闆，劃重點了，必考題。
這是連結： CLDAP
于是，搜尋走一波科普。于是作案兇手，就浮出了水面。
CLDAP DRDoS
輕量目錄通路協定（LDAP）被定義在RFC2251（LDAPv3）中，由于LDAP是以TCP位元組流的方式進行資料傳輸，其必要的綁定操作和頻繁的資料搜尋查詢會在一定程度消耗較多的TCP連接配接資源，于是IETF在1995年釋出了面向無連接配接的輕量目錄通路協定（CLDAP），官方文檔為RFC1798（2003年RFC3352将CLDAP置為曆史狀态）。在CLDAP中隻提供三種操作：searchRequest、searchResponse （searchResEntry和searchResDone）、abandonRequest，在不提供身份驗證功能的情況下，用戶端可以使用UDP資料報對LDAP伺服器389端口發起操作請求。由于用戶端發起searchRequest後服務端将傳回searchResEntry和searchResDone兩條應答消息，一般情況下執行該操作将具有較小資料包反射出較大資料包的效果，這一缺陷随即被利用進行反射放大DDoS攻擊。
根據Akamai SIRT釋出的報告，目前捕獲到的CLDAP DRDoS最高峰值流量為24Gbps，最大反射倍數為70倍。由于CLDAP未被廣泛運用，開源LDAP軟體openLDAP早已不再支援UDP協定的請求。事實上，目前進行CLDAP DRDoS攻擊被利用最多的服務是Windows伺服器的活動目錄服務Active Directory（AD）。通常AD服務會在TCP端口389上監聽來自用戶端的LDAP操作請求，同時也會在UDP端口389上使用CLDAP協定來等待執行rootDSE的搜尋操作（rootDSE條目在AD服務配置時建立，且允許未經身份驗證的用戶端對伺服器的配置狀态、功能和擴充屬性進行查詢，也被稱作“AD ping”）。一些Windows伺服器的AD服務監聽端口暴露在公網，進而被利用來執行rootDSE查詢産生放大反射DDoS攻擊
重點：
389端口
反射較大資料包
rootDSE
端口暴露公網
是不是跟之前排查到的都能一一對上了。
于是我關閉了映射到外網的389端口。而伺服器上防護都撤除。巨大的流量上傳戛然而止。目前，由于雲端的AD同步插件寫死了389端口為同步，是以不開放389，就意味着無法讓雲端裝置和本地域控做驗證。而防護這個攻擊除了不暴露外網端口一個辦法外，還有就是我之前使用的用戶端白名單。由于公司的防火牆太低端，無法做端口上的白名單通路。而我之前使用伺服器上做白名單又影響其他域控使用者驗證。隻好關閉外網端口。那麼新的問題又出現了，如何讓雲端裝置也能向本地域控伺服器做LDAP驗證。