[IT Security][轉貼]詢問微軟安全性相關問題

轉載自
Microsoft

作者：Joel Scambray2000 年 5 月
您將是贏家
上週我問讀者：NT/2000 密碼的適當長度是多少，哪些字元可構成最安全的密碼？ 經常有人問及這類問題，這是應該的。 因為在我參加過的幾乎所有得到授權的滲透測試中，至少有一個 NT/2000 系統遭到針對 SAM 檔案的遠端密碼猜測的攻擊或本機字典的攻擊。 在考慮多重使用者環境的安全性時，密碼的構成應當是您要注意的首要大事。
你們當中有幾個人寄信到「安全性問答」(以前稱為 AUAS) 信箱，信中提出正確的答案，但對於尚未找到正確答案的讀者，我們在下列內容告訴您快速提示：
1. 令人驚訝的是， 在 NT 上，當密碼長度為 14 個字元時，密碼是最安全的，這樣的長度是使用者管理員 GUI 可用的最大長度。 但誰能記住由 14 個字元所組成的密碼呢？ 下一個最好的「神奇數字」是 7 個字元。 這是因為，在對密碼進行加密之前，用來將密碼儲存在 SAM 檔案中的 LANMan 演算法會將密碼分割成以 7 個字元作為單元的片段。 因此，10 個字元長的密碼實際上是 7 個字元加 3 個。這 3 個字元可用現代密碼攻擊工具輕易地猜出，並且它將提供猜測其它 7 個字元組成的線索 (例如，順著鍵盤敲打出來的密碼 QWERTYUIOP，如果破解最後 3 個字元，就很可能猜到其餘 7 個)。
Win 2000 引入有趣的方法。 14 個字元的限制已增加到 127 個，但為了向後相容，仍然使用 LANMan 雜湊演算法。因此，對於與 NT 相同類型的攻擊，其密碼依舊很脆弱。 而且，如果您的環境中有使用非 Win 2000 的用戶端，而它們不支援長度超過 14 個字元的密碼，這時候您可能會被這種限制搞糊塗。 無論如何，對大多數人為介面的應用程式來說，強制使用大於 14 個字元的密碼仍然不切實際，所以最好在 Win 2000 中使用同樣的神奇數字： 7 個字元組成最好的密碼。
2. 任何從 Service Pack 2 之後版本建置 passfilt DLL 的人，都知道什麼樣的字元可以構成安全的密碼： 不同的大小寫、數字和特殊字元 (例如 !$%&)。 其中基本的構想是使攻擊者為了成功猜出您的密碼而不得不搜索非常巨大的字元範圍。 比較鮮為人的是，非列印 ASCII 字元更能增加字元範圍，並且這樣有其它好處，亦即防止大多數密碼猜測軟體的野蠻攻擊 (野蠻攻擊與字典攻擊的不同之處，在於野蠻攻擊只猜測隨機產生的字串，直到發現正確密碼為止)。 藉由設定 NUMLOCK 鍵，並在鍵入適當的三位數 ASCII 代碼 (例如 255) 時按住 ALT，您即可存取非列印的 ASCII 字元。 這對每天需要輸入密碼的使用者來說，顯然是很麻煩的要求，但對於絕對不可使用互動方式登入的服務帳戶來說，非列印的 ASCII 代碼是非常好的密碼組成字元。
明智地使用這些原則將使攻擊者不得不花費很長時間來猜測。 Win 2000 同樣適用這些基本原則，雖然它因使用強大的加密來儲存密碼，或將密碼整個儲存在 Active Directory (如果有安裝) 內，而使此類攻擊更加難以發動。
刪除內建的帳戶
本週有讀者問到；關於刪除或停用內建系統管理員 (Administrator) 帳戶的問題，目的在於防止針對著名目標進行無限制的密碼猜測。 目前仍然不可能達成 (甚至在 Win 2000 之下)，但可以重新命名該帳戶，並使用 NT Resource Kit 中提供的 passprop 公用程式來鎖定系統管理員。 最近有人在 ntsecurity.nu 張貼一個稱為 DelGuest 的工具，此工具可讓您刪除來賓 (Guest） 帳戶，這在以前是不可能的。 雖然來賓帳戶可以停用或鎖定，而且若無 passprop，它也不如系統管理員帳戶那樣具有吸引力。但是，藉由使用 user2sid/sid2user 工具並啟動攻擊它們的密碼猜測，攻擊者仍然可以判斷哪個帳戶是系統管理員，哪個是來賓。 而 DelGuest 提供的機制可以稍微減少這種攻擊機會。 如果您正在使用來賓帳戶來提供網域的匿名存取，則 DelGuest 顯然將造成破壞。 遭到破壞可能是件好事，因為你無論如何都不可以這樣做！ 警告： 作者表示，「DelGuest 使用了絕對不受 Microsoft 支援的方法來存取 SAM 資料庫，使我非常難確定這項技術是否在任何情況下絕不會導致 SAM 資料庫遭到損毀。 所以，您必須知道 DelGuest 可能損毀 SAM 資料庫的危險，這將是非常嚴重的問題。」 我個人已在 NT 4 Workstation 上使用過該工具，沒有發現副作用。
新的防火牆 API
另一個讀者來信表示，他聽說了一些有關新 NT 防火牆 API 的消息，希望了解詳細資訊。 本週我很感謝 Ron Cully (Windows Networking 的 Lead Product Manager)，他騰出一些時間來回答這個問題 (下面的內容主要由 Ron 提供，並附上一些解釋)。
Windows 2000 包含 API， 防火牆解決方案使用這個API來攔截傳輸，以執行檢查和篩選操作。 此 API 在 OS 的核心模式層執行。 在傳輸進入 IP 堆疊之前，您可以使用多個篩選器鉤取和攔截該傳輸。 這個層面位於 IPSec 層和 IP 堆疊之間。 如果 IPSec 正在使用中，當封包到達時，防火牆可以在傳輸解密之後和進入 IP 之前加以檢查。 在輸出傳輸由 IPSec 加密之前，防火牆還可加以檢查。 所有 Win 2000 的版本都包含防火牆 API，所以對於 Windows 2000 Professional 以及其它使用 Server 版本的傳統網路存取控制產品而言，有可能建立個人的防火牆工具。 這些 API 可以利用 Win 2000 對 NT 4 網路傳輸量的許多改進。這對購買企業級防火牆系統的使用者來說，網路傳輸量通常是決定性因素 (最近由 University of Washington、Nortel Networks、Microsoft 和其它組織所進行的點對點 WAN 測試中，Win 2000 Professional 持續獲得了 2.4 Gbps 的成績。據報導，這是單一系統在業界創下的新記錄)。 同時，由於防火牆勾點是在核心模式中執行，因此可藉由消除環境切換來提昇效能。 據說，Win 2000 在高傳輸量環境中的封包轉寄性能未經公開測試，因此沒有正確利用這些 API 的廠商可能無法獲得預期的效果。
IIS 稽核工具
一名好奇的系統管理員本週來信詢問有關可用來對 IIS 執行安全稽核的工具的問題。 除了通常用來檢查基礎 OS 安全性的工具之外 (此處有很好的說明文件)，最近有人向我推薦 mdutil.exe，這是在 NT Option Pack 光碟中附帶的 IIS Metabase 操作工具。 此處提供了 IIS Metabase 以及 mdutil 功能的完整說明。
從安全性觀點來看，mdutil 是將 IIS 的所有組態資料傾印到命令提示字元下的便捷工具。 所得到的 blob 可以方便地與指定的原則與標示的衝突進行比較。 例如，使用者可以使用 mdutil 來檢查系統上非法的匿名 FTP 服務，詳情如下所示：
mdutil get msftpsvc/1/AllowAnonymous
Metabase 在本質上就是 IIS 的「登錄表」，它同樣包含每個實際可用的組態參數，其中包括與安全性相關的參數。 若要詳細了解它的階層結構，請執行「mdutil enum /」來檢視最高階 hive，然後用「mdutil - help」來檢視可用來執行 GET 指令的參數，如上述命令行一樣。 當然，情形與「登錄表」一樣，使用 mdutil 時必須非常注意，因為它還可用來將值寫入 Metabase。 AUAS 信箱歡迎您提出有關形成 IIS 安全性稽核基礎而與安全相關的 Metabase 參數清單的任何建議。
請將這些電子郵件查詢傳送到下列位址，我將在下個月的專欄中密切注意哪些問題會對安全造成重大影響。
Joel Scambray是Foundstone的負責人。 最近，他在 Osborne-McGraw Hill 與別人合作撰寫了Hacking Exposed: Network Security Secrets & Solutions。
請將您遇到的安全性問題傳送到「詢問安全相關問題」信箱。如果您的問題獲選，即可在隨後的專欄中看到答案。
身為 Microsoft Corporation 的工作人員，我們希望這裏提供的資訊能對您有所幫助。 但是，使用本文所含的資訊可能導致的風險只能由您自己承擔。 本文中的全部資訊均以「原樣」提供，對於其準確性、完整性、特定用途的適用性、所有權和不侵犯原則，並沒有任何明示或暗示的保證。本文提及的任何協力廠商產品和資訊，Microsoft Corporation 都並未參與創作，也不向您推薦、支援或提出任何保證。 對使用該資訊而造成的任何損失，Microsoft Corporation 將不承擔任何責任，不論是直接的、間接的、特別的，還是偶然的或必然的，即使這種損失的可能性已經經過考慮。