M04-12 · 列舉防護

10/27 早間：一次學一個核心概念

1. 列舉防護是什麼？

DNS、SMB、SNMP、LDAP 與 RPC 的查詢功能讓系統正常運作，也可能透露主機名稱、帳號、共享資源或服務端點。

列舉防護，就是控制「誰可以從哪裡，查到哪些資料、執行哪些操作」。

像公司的接待櫃檯：公開營業時間可以回答，內部員工資料卻不能全部交給訪客。目標不是讓所有查詢失敗，而是讓回應符合使用需求與安全政策。

2. 用在哪裡？先確認什麼？

用於已授權的資產盤點、安全檢查及設定調整。先確認：

• 哪項服務有必要？
• 哪些來源、哪些身分需要使用？
• 必須提供哪些資料與操作？
• 哪些應公開，哪些應限制？

公開網站查得到 DNS 記錄，通常是正常需求，不是看到資訊就能判定漏洞。例如一般 DNS 查詢與 AXFR 整區傳送是不同功能，可以保留正常解析，另行限制區域傳送對象。RFC 5936

3. 防護要分層看

第一層：服務與網路。

停用不必要功能，管理服務只讓必要來源連線。先確認依賴關係，不是看到埠就全部關掉。

第二層：身分與權限。

Authentication（身分驗證）確認你是誰；Authorization（授權）決定你可以做什麼。

Least Privilege（最小權限）只給工作所需權限。監控人員需要讀設備狀態，不代表需要修改設備設定。NIST SP 800-53，AC-6／CM-7

第三層：資料與傳輸。

限制回傳欄位、共享內容及管理物件，也保護傳輸。加密不會自動縮小查詢權限；LDAP signing 主要保護完整性，不等於加密。Microsoft LDAP signing

第四層：維護與監控。

維持受支援版本、修補漏洞，留下適當日誌，檢查異常查詢與權限變更。換埠或隱藏版本資訊只能輔助，不能代替真正的存取限制。NCSC 防護指引

4. 具體例子：保留監控，限制訪客

以下是合成紙上情境，沒有操作任何設備。

公司交換器需要讓管理網段的監控主機透過 SNMP 讀取狀態，訪客網段不需要這項功能。授權檢查卻發現，訪客也能查到設備名稱。

這只能證明：該來源與身分，在這次查詢中取得名稱。不能因此認定能修改設定，或已取得管理權。

管理者依需求調整來源限制與查詢權限後，要驗證兩面：

• 不應獲准的訪客，是否仍能取得受限資訊？
• 應獲准的監控主機，必要查詢是否仍正常？

如果訪客查不到，但監控也壞了，就還沒有完成符合需求的修正。這是允許與拒絕兩面的測試，不是雙因素認證。

5. 怎麼判讀證據？

把「設定已修改」和「實際行為已驗證」分開記錄。留下查核時間、來源、測試身分、服務、操作、回應及相關日誌；不要記錄密碼或認證秘密。

只有一筆 Timeout，最多只能說「這次沒有收到回應」。也可能是網路不通或服務故障，不能證明所有未授權存取都已阻擋。

較精確的結論是：「在本次指定來源、身分與查詢項目下，受限資訊未再被取得，必要監控仍正常。」不要把有限測試寫成整個系統絕對安全。

小檢核：

調整規則後，訪客查詢逾時。為什麼還不能宣布防護完成？請各說一項：仍要補的阻擋證據，以及正常功能檢查。

一兩句就好。12 核心＋7 選讀是本系列教學設計，不是官方固定數量。下一核心接 M05。