有關AD的攻擊及預防措施知識簡介二
繼上文常見AD攻擊及預防措施詳解一這篇文章之后，我們繼續介紹AD的攻擊和預防措施的知識。
攻擊四：基于過度創建AD對象的DoS攻擊
具有管理員權限的用戶過度創建新的對象會引發針對AD的拒絕服務（DoS）攻擊。例如，授權用戶不斷創建AD對象，直到耗盡域控制器的磁盤空間，會導致AD服務器崩潰。另一個例子則是授權用戶用一個命令將幾千個成員添加到一個組中，同樣會導致服務器崩潰。
攻擊四預防措施
要預防這種攻擊，必須對授予AD對象創建權限的人要特別小心。還可以采用在WindowsServer2003中的AD對象配額這個功能，而Windows2000里的對象配額功能有限。
AD對象配額會限定AD命名關聯（NamingContext，NC）或根據特定安全項建立的目錄分區中可以擁有的對象數量。每個ADNC和目錄分區都可以獨立設置和管理AD對象配額。不過，在SchemaNC中不能定義AD對象配額。對于每個ADNC和分區，可以定義默認的配額，如果沒有特別定義，則配額沒有限制。
對于安全項擁有的ADtombstone對象，也計入AD對象配額。tombstone對象是AD對象被刪除時創建的臨時對象，用于在AD的域控制器之間保持被刪除對象數據的一致性。對于每個NC和分區，可以指定tombstone配額參數，確定tombstone對象在配額中的權重。例如，為NC或分區指定tombstone的配額參數是25，即分區中一個tombstone對象被計算為一個普通AD對象的0.25。默認的每個分區中tombstone配額參數是100，也就是說，一個tombstone對象和一個普通AD對象具有相同的權重。
對于每個安全項，都可以分配配額，包括用戶、計算機、組和inetOrg-Person。一個安全項可以有多個配額，例如，用戶可以被分配獨立的配額，他所屬的組又具有一個配額，在這種情況下，配額將采用最大的那個設置。域管理員組和企業管理員組成員沒有AD對象配額限制。
AD對象配額保存在ADNC或分區的NTDSQuotas容器中，屬于msDS-QuotaControl類的對象。在Accounting的域NC中設置用戶Joe的AD對象配額為10，可以使用下列Dsadd命令：
- Dsaddquota
- -partDC=Accounting,DC=COM
- -acctAccounting\Joe
- -qlimit10
- -desc"QuotaforJoe"
設置Accounting域NC的tombstone配額參數為25，可以使用下列Dsmod命令：
- Dsmod
- partitionDC=Accounting,DC=COM
- -qtmbstnwt25
將Accounting域NC的默認對象配額設置為0，可以使用下列Dsmod命令：
- Dsmod
- partitionDC=Accounting,DC=COM
- -qdefault0
只有運行WindowsServer2003的域控制器可以強制配額，只能在發起目錄操作時強制配額，而不能用于復制操作中。要想在AD域目錄分區有效使用AD對象配額，域中所有的域控制器必須運行WindowsServer2003。而在AD配置分區使用AD對象配額，則森林中的所有域控制器都必須運行WindowsServer2003（例如，所有域和森林必須運行WindowsServer2003功能level2）。
AD對象配額功能本身和任何指定的功能級別并沒有關系——在任何WindowsServer2003域控制器上都可以使用。如果定義了配額的WindowsServer2003域中有Windows2000域控制器，用戶可以繼續連接這些域控制器，同時受到配額的限制。
與WindowsServer2003AD的配額系統相比，Windows2000的配額功能十分有限。在Windows2000中，管理員可以限制某個用戶帳號創建計算機帳號的數量，必須使用AD域對象中的ms-DS-MachineAccountQuota屬性，這個限制并不適用于域管理員組和帳號操作員組的成員。WindowsServer2003支持ms-DS-MachineAccountQuota屬性（默認值為10）。如果想禁止添加計算機帳號，可以將該屬性值設置為0。
對于認證用戶組來說，在用戶權限中刪除“向域中添加工作站”也可以達到同樣的目的。在WindowsServer2003和Windows2000中，認證用戶組默認具有該權限。
攻擊五：基于MaxTokenSize屬性的DoS攻擊
微軟擴展了基本的Kerberos協議，利用Kerberos認證ticket包含認證數據。WindowsKerberosticket和TicketGrantingTicket（TGT）都包含一個特殊的區域，稱之為權限屬性驗證（PrivilegeAttributeCertificate，PAC），可以利用Kerberos協議傳輸認證數據，如在Kerberos認證ticket中的用戶組成員和用戶權限。
Kerberosticket具有固定的大小，間接限制了PAC的大小。如果用戶屬于很多的組（比如100個或更多），他的ticket大小可能會超出限制，Windows認證和組策略處理就會失敗。因此具有AD創建和修改組權限的用戶可以利用這個漏洞針對管理員帳號發起拒絕服務攻擊（DoS），這種攻擊將導致管理員帳號無法登錄網絡。
攻擊五預防措施
為了預防這種攻擊，必須相當仔細地為組管理委派AD管理權限，還必須限制管理管理員帳號組成員的權限。因為在森林中，管理員可以管理本地和全局組，添加任何用戶帳號并不需要特殊的權限，所以在AD中限制默認權限很困難。因此，必須將企業管理員組或域管理員組的帳號放置在一個特殊的組織單元（OU）中，不給被委派的管理員讀取的權限。
此外，可以設置注冊表
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters\
MaxTokenSize的值增加Kerberosticket的最大尺寸，
可以參考微軟知識庫文章“解決用戶屬于多個組出現問題的新方法”（http://support.microsoft.com/kb/327825）。
對于用戶使用Kerberos登錄域的所有Windows系統，都需要修改MaxTokenSize（REG_DWORD）的值。在Windows2000中，MaxTokenSize的默認值是8000字節；在Windows2000SP2和后續版本以及WindowsServer2003中，MaxTokenSize的默認值為12000字節。
為了減少PAC的大小，微軟在Window2000SP4中還采用了新的方法在PAC中存儲認證數據。新的PAC認證數據存儲方法如下：
如果是本地組或來自其它域，組的全部SID（例如S-1-5-21-1275210071-789336058-1957994488-3140）將保存在PAC中。
如果用戶所屬的全局組在用戶所屬的域的本地，則只存儲組的相對識別號（RelativeIdentifier，RID）。
微軟在Windows認證過程中采用特殊的處理過程，在客戶端和服務器端將RID重新分解成SID格式。需要注意的是，即使采用新的PAC認證數據存儲方法，仍然需要修改MaxTokenSize或減少用戶所屬組的數量。
為了避免Kerberostiket的PAC域的空間浪費，從WindowsNT4.0域遷移到WindowsServer2003域或Windows2000域時，應該刪除AD帳號的SIDHistory屬性，可以參見微軟知識庫文章“如何使用VisualBasic腳本清除SidHistory”（http://support.microsoft.com/kb/295758）。
微軟發布了Tokensz工具，用于解決Kerberos令牌大小相關的問題，該工具可以從http://www.microsoft.com/downloads/details.aspx?familyid=4a303fa5-cf20-43fb-9483-0f0b0dae265c&displaylang=en下載。下列Tokensz命令列出了當前系統的MaxTokenSize值和當前的令牌大小：
- tokensz/compute_tokensize
- /package:negotiate
- /use_delegation
- /target_server:
關于如何使用Tokensz，可以參見微軟的白皮書“解決Kerberos錯誤”（http://www.microsoft.com/downloads/details.aspx?familyid=7dfeb015-6043-47db-8238-dc7af89c93f1&displaylang=en）。
全方位較量
本文提到的這些攻擊手段說明了采用多種措施保護AD架構的重要性。除了技術上的安全措施，還必須考慮物理上和組織上的安全措施。物理上的安全措施包括對Windows域控制器、網絡設施和公司建筑物的物理安全訪問；組織上的安全措施包括建立安全規則和操作步驟，定期對AD架構進行外部安全審計，不斷培訓管理員和用戶的安全風險知識和操作實踐。在公司內，保護AD的安全是一項重要的工作，應該列為高優先級，應該從技術上、物理上和組織上建立聯合的團隊共同完成。
希望系統管理員通過本文對AD的攻擊和預防措施的介紹能夠引起對AD安全的重視。
【編輯推薦】
