DNS Sinkhole 解析：如何阻止惡意軟體回連
DNS Sinkhole 會將惡意軟體查詢重新導向至誘餌，進而阻止回連並找出受感染的裝置。深入瞭解其運作方式與部署位置。
Published 2026年11月2日
訪客將筆記型電腦連線至您咖啡廳的 WiFi，開啟瀏覽器，開始進行他們的日常活動。在背景中，該筆記型電腦上的惡意軟體試圖聯絡其控制程式。您無法在每位訪客的裝置上都安裝安全軟體，但您可以控制網路如何回應這些裝置對網際網路目標的請求。
DNS Sinkhole 提供了一種中斷該反向連線並記錄值得調查之證據的方法。有用的問題不僅在於它封鎖了什麼，還包括您是否能識別受影響的裝置、證明您的策略適用，並在規則出錯時恢復合法的存取權限。
目錄
- 白話解說 DNS 洞坑 (DNS Sinkhole)
- 洞坑如何回應惡意查詢
- 讓洞坑技術成為業界標準的 Conficker 病毒爆發事件
- 將洞坑命中轉化為受感染裝置的追蹤線索
- 共享與訪客網路的部署模式
- 誤報以及如何快速復原
- 評估洞坑技術是否適合您的網路環境
用通俗語言解釋何謂 DNS Sinkhole
受感染的筆記型電腦需要先找到其控制器，才能要求指令。如果惡意軟體使用網域名稱，該筆記型電腦會先要求 DNS 解析器將該名稱轉換為 IP 位址。
您可以將 DNS 視為電話簿。網域是您要查找的姓名，而 IP 位址則是您需要撥打的電話號碼。防護解析器會檢查是否應該提供該號碼。
DNS 坑道 (Sinkhole) 會將已知不良網域的回應替換為受控目的地，或直接封鎖該回應，使裝置無法利用該查詢來聯繫攻擊者。
嚴格來說，DNS 坑道 (Sinkholing) 指的是將流量重導向至受控端點。管理員也會更廣泛地將此術語用於抑制惡意查詢且不提供目的地的 DNS 策略。
電話簿的比喻有助於將名稱查詢與後續的連線分開。
DNS 阻擋不等於 IP 阻擋
DNS Sinkhole 會在裝置使用解析結果連線至該目的地之前，先對要求的名稱採取行動。普通防火牆規則通常會使用封包的目的地 IP 位址來評估封包，並可拒絕初始連線嘗試。防火牆不需要等待連線建立完成。
當合法服務與惡意服務共用託管基礎架構時，這項差異就非常重要。封鎖整個 IP 位址可能會影響無關的服務，而 DNS 原則則可以針對特定主機名稱進行封鎖。這兩種方法無法完全取代彼此。
在共享的 WiFi 上，解析器非常實用，因為營運商不需要具備筆記型電腦的管理員權限。然而，停止反向連線並不能消除感染。它為營運商提供了遏制威脅的機會，並在具備適當日誌的情況下，提供調查的線索。
Sinkhole 如何回應惡意查詢
DNS 查詢 是索取資訊的請求，而非直接連線至所要求的網站。解析器的回應決定了裝置接下來可以嘗試的動作。
基本路徑區分了裝置、策略檢查和受控目的地。
- 裝置請求其回連網域。 裝置向其設定的解析器傳送查詢。
- 解析器確認哪項策略適用於來源網路，例如訪客 SSID 或員工 VLAN。
- 比對名稱與威脅情報及本機規則，包含中繼站 (C2)、網路釣魚與惡意軟體類別。
- 若符合封鎖條件，解析器會提供受控位址、傳回無此名稱回應，或是拒絕/壓制回應。
- 裝置會嘗試連線至誘餌，或無法取得可用的目的地。允許的名稱則正常解析。
在裝置開啟網站或應用程式之前，會先向 DNS 詢問其位置，而 Shield 會套用該網路的政策進行回覆。若網域遭到封鎖，與該目的地的連線將完全不會啟動，裝置則會顯示客戶自訂品牌的封鎖頁面。這種面向使用者的體驗，不應與惡意軟體重試失敗的回呼混為一談。
根據您需要的證據來選擇回應方式
Sinkhole 回應選擇及其所揭露的資訊
| 回應方式 | 裝置所產生的體驗 | 防禦人員獲得的資訊 | 主要權衡考量 |
|---|---|---|---|
| 無此名稱 (NXDOMAIN) | 查詢失敗且連線從未建立 | 曾有人嘗試進行查詢但遭封鎖 | 可阻止回連，但無法提供後續連線行為資訊 |
| Sinkhole 位址 | 查詢傳回受控伺服器的位址 | 來源 IP、回連時間、重試模式與可觀察的協定 | 需要受監控的端點與謹慎的日誌儲存管理 |
| 拒絕或壓制回應 | 解析器拒絕查詢或不予回應 | 除了嘗試本身之外幾乎無額外資訊，除非啟用了解析器日誌記錄 | 套用快速，但部分用戶端會進行激進重試 |
NXDOMAIN 不會抹除來源或時間戳記資訊。解析程式可以同時記錄這兩者。該次失敗的查尋所無法收集到的，是惡意軟體原本在之後會建立的連線。
一份 經過同儕審查的 Sinkhole 封包擷取評估 指出，採用進階收集設計時，其惡意封包擷取能力較傳統實作提升了五倍。這是關於收集架構的實證，並非保證每個 Sinkhole 都能提供相同的提升效果。
此影片提供了另一種瞭解該機制的方法。
您選擇的回應會決定後續可以觀察到的行為。請保持收集器隔離，並且切勿假設重導向能為每個加密的應用程式產生乾淨的警告頁面。
使 Sinkhole 成為標準配備的 Conficker 大爆發
Conficker 展示了防禦者如何將惡意軟體搜尋指令的過程轉化為情報來源。研究人員無需檢查每台受感染的電腦，而是直接攔截該蠕蟲預先設定聯絡的目的地。
CAIDA 的 Conficker 檔案庫 描述了首次於 2008 年 11 月偵測到的爆發事件，早期的變種每天產生大約 250 個偽隨機網域名稱。蠕蟲會透過 HTTP 連線至產生的名稱，以取得指令或額外的惡意軟體。
研究人員與網路營運者在犯罪分子使用前搶先註冊了特定網域，然後將這些名稱指向受控伺服器。受感染的電腦隨後便會呼叫由防禦者運營的基礎架構。
查詢成為量測點
這些反向連線有助於應變人員識別受感染的系統、估算蠕蟲的傳播範圍，並追蹤清除進度，而無需直接與犯罪控制網路通訊。因此，成功的攔截不僅僅是拒絕更新，更能記錄下仍試圖取得更新的電腦。
- 關於控制措施，應變人員防止了特定名稱導向攻擊者控制的基礎架構。
- 關於調查研究，回呼記錄識別出了需要處理的系統。
- 關於修復追蹤，持續發生的回呼代表清理工作尚未完成。
Conficker 後期的變種擴大了生成的名稱池，並加入了對等網路 (P2P) 更新。應對人員必須協調註冊與封鎖作業，而非依賴小型且靜態的清單。
歷史上的部署方式也與組織的本機篩選策略不同。研究人員變更了其所控制網域的目的地，進而影響了透過普通 DNS 解析這些名稱的受感染電腦。場域營運商通常改為在其自己的遞迴解析器上套用策略。
涵蓋範圍是這兩種情況下的限制因素。防禦者可以攔截對其控制下名稱的回呼，但這並不意味著所有可能的更新途徑都已消失。Conficker 將 DNS 沉洞技術（Sinkholing）確立為一種控制技術與測量工具，而非取代修復受感染電腦的方案。
將 Sinkhole 事件轉化為受感染裝置的線索
如果用戶端反覆查詢已被封鎖的中繼站 (C2)網域，該裝置就值得關注。即使您沒有終端代理程式、封包檢查或詳細的防火牆記錄，這種模式也能提供極有價值的線索。
此依賴關係非常重要：亞利桑那大學殭屍網路防禦論文 指出，有效的 DNS 重新導向需要識別殭屍網路的 C2 基礎架構，並取得殭屍網路所使用的 DNS 營運商之配合。命中記錄僅代表特定請求遇到了您的政策，並不代表您已發現所有的通訊路徑。
保留足夠的情境資訊以找出用戶端
請將這些欄位記錄在一起，而不是分散在未連接的儀表板中：
- 時間戳記：將事件與網路租約和驗證記錄進行比對。
- SSID 或 VLAN：識別涉及的網路和政策邊界。
- 用戶端識別碼：保留可用的裝置參考資訊，而非僅保留場地的公開位址。
- 查詢的網域：保留觸發規則的精確主機名稱。
- 政策類別：將威脅分類與內容限制區分開來。
- 回應動作：記錄解析程式是重新導向、拒絕，還是傳回 NXDOMAIN。
同一個閘道背後的許多訪客可能會共用同一個公開來源 IP。若要識別單一裝置，請將終端觀察結果與解析器及網路記錄進行比對。不要因為收集器看到了共用位址，就標示整個場地都已受到感染。
調查規則：將觸發 Sinkhole 的事件視為帶有支援情境的線索，而非直接對裝置所有人做出自動判決。
驗證訊號並維持涵蓋範圍
將重複比對成功的紀錄與該網路上的正常行為進行比較，並對照最新的 威脅情資來源 來檢查分類。演算法生成的網域名稱、快速變更的託管服務、硬編碼的位址以及備用管道都可能留下漏洞。缺乏比對成功的紀錄並不代表裝置就是乾淨的。
網域名稱狀態也需要持續審查。一項 2019 年針對惡意網域名稱下架的研究 發現，在前十個月內下架的網域名稱中，有超過 14%隨後重新回到了商業網域名稱市場。
定期審查規則的出處、擁有權和分類。如果您自行營運註冊的 Sinkhole 網域，請保護其 DNS 設定與續約。限制對用戶端層級日誌的存取，並設定符合當地法律和您調查需求的保留期限。
共享網路與訪客網路的部署模型
Sinkhole（DNS 阻陷區）能保護您所控制的 DNS 路徑。但訪客的瀏覽器或應用程式可能會選擇外部加密解析器，導致您的本機策略無法進行任何評估。
一份 加密 DNS 技術分析 解釋了為何外部 DNS-over-HTTPS 可以繞過傳統的 DNS 監控。因此，部署的決策關鍵在於解析程式的強制執行與用戶端行為，而不僅僅是封鎖清單的品質。
共享網路的 Sinkhole 部署模型
| 模式 | 控制措施位置 | 最適合情境 | 主要限制 |
|---|---|---|---|
| 訪客 WiFi 上的網路解析器 WiFi | 由網路分配給每個用戶端的解析器 | 飯店、酒吧、公共 WiFi WiFi | 內建寫死或採用加密解析器的用戶端可繞過此限制 |
| 防火牆 DNS 檢查 | 位於現有防火牆或閘道內部 | 具備完善防火牆資產的辦公室 | 傳統 DNS 檢查會遺漏以 HTTPS 傳輸的外部 DoH |
| 受控瀏覽器或裝置原則 | 由瀏覽器或作業系統指定解析器並停用替代 DoH | 受控企業或學校裝置 | 無法涵蓋未受控的個人裝置 |
| 雲端保護性 DNS | 網路 DNS 所指向的供應商託管解析器 | 多據點場地與大型資產 | 仰賴供應商的正常運作時間與遙測資料存取權限 |
加密與強制執行是不同的選擇
加密 DNS 提高了用戶端與解析程式之間的機密性。這並不一定會削弱過濾功能：經核准的防護解析程式可以接收加密查詢並繼續套用策略。當用戶端選擇了不執行您規則的外部解析程式時，就會出現可見度的問題。
對於受控裝置，瀏覽器和作業系統策略可以指定核可的服務。在訪客網路中，您需要對替代加密 DNS、使用者隱私和許可的例外情況制定明文立場。封鎖所有加密 Web 流量以停止 DoH 並非可行的通用策略。
將控制措施放置於您可以測試的邊界上
透過網路設定發佈核可的解析器。將直接向外發出的傳統 DNS 限制為僅能使用核可的解析器，涵蓋兩種傳輸協定與兩種 IP 家族。透明重新導向可以擷取傳送到其他地方的傳統 DNS，但無法透明化地解決任意加密 DNS。
使用 網路分段 來區分員工、訪客和特定用途裝置的原則。限制性的訪客規則不應干擾醫療設備或員工應用程式。
- 測試一般解析：確認允許的應用程式仍可正常運作。
- 測試繞過路徑：檢查瀏覽器選擇的解析器和其他允許的通道。
- 測試歸因：確認受控的策略比對結果顯示在正確的網路與用戶端項目中。
網路層級的 DNS 變更可以在不為每台裝置安裝軟體的情況下，對參與的裝置套用篩選機制。請透過測試證明覆蓋率，而非直接假設發送解析器位址就能強制每個應用程式都使用它。
誤報以及如何快速復原
較長的封鎖清單並不代表自動更安全。針對共享雲端基礎架構設定過於寬泛的規則，可能會在中斷供應商門戶、付款工作流程或學習應用程式運作的同時，無法提升針對目標威脅的防護能力。
一份 2025 年 DNS 污水坑（Sinkholing）實施研究 報告指出，誤判情況需要人工管理允許清單與受訓員工的協助。運作管理權應屬於部署計畫的一部分，而非僅放在事件處理佇列中。
復原程序應考量共享服務和範圍狹窄的例外情況。
在不移除保護的情況下恢復存取權限
在議定的觀察期內，以僅限記錄模式啟動新策略。擷取用戶端、類別和比對規則，以便為日後的決策提供證據軌跡。
DNS 坑道症狀、可能原因與首要處置
| 症狀 | 可能原因 | 首要處置 |
|---|---|---|
| 員工裝置無法連線至供應商網站 | 共享雲端網域因類別遭到封鎖 | 檢查日誌記錄的類別，然後將確切的主機名稱列入允許清單，而非整個網域 |
| 單一訪客裝置每分鐘觸發 Sinkhole 命中 | 裝置遭感染或應用程式進行激進重試 | 識別並隔離該用戶端，隨後安排裝置檢查 |
| 變更策略後，遭封鎖的查詢急劇增加 | 廣泛的封鎖清單項目或萬用字元規則 | 回滾上次的變更，並檢視其 SSID 或 VLAN 範圍 |
| 應用程式運作正常，但其中一個 SSID 未顯示任何封鎖 | 用戶端可能在解析器之外使用加密的 DNS | 執行可控的策略測試，並檢查解析器設定與外發 DNS 路徑 |
單憑空白報告無法證實存在繞過行為。可能只是網路並未產生任何符合條件的請求。
請衡量已阻止的有害連線、誤報率、申訴解決時間以及每個場地的例外情況。僅憑被封鎖的查詢數量可能會因為應用程式重複重試而上升。
在啟用規則之前，請確認：
- 分類：支援該網域的威脅類別。
- 共享使用：企業應用程式不依賴相同的主機或父網域。
- 復原：已記錄先前的政策和還原程序。
- 範圍：預期的 SSID 或 VLAN 是明確的。
- 負責人：由指定人員處理例外狀況請求並審查其到期日。
評估 Sinkhole 是否適合您的網路
對於擁有託管端點的小型辦公室，請先從 DNS 記錄與端點策略著手。您可能已經具備直接調查可疑請求所需的裝置控制項，因此請避免新增無法維護的收集器。
對於訪客、公眾或學生網路，請優先考慮邊界強制執行與用戶端屬性辨識。未管理的裝置使得解析器層級的控制變得很有用，但營運人員仍需要一種安全的方式來調查或封鎖裝置，而不是過早指控其所有者。
使營運模型與資產規模相匹配
多據點機構可受益於集中管理的解析器策略、特定網路例外情況，以及整合式報告。評估各項服務時，應依據其呈現的實證與您可測試的控制項，而非僅看其類別數量。
當您能夠掌握完整流程（策略、涵蓋範圍、調查、例外狀況與復原）時，請選擇 Sinkhole。
從小規模部署開始：
- 對應解析器路徑。 識別每個網路所使用的解析器，以及替代 DNS 或通道可能繞過策略的位置。
- 執行記錄說明的僅限日誌觀察期。記錄符合的請求及其用戶端、類別與網路，隨後檢視合法的應用程式依賴關係。
- 優先啟用高信心度的封鎖。 先從已確認的 C2 及惡意軟體目的地開始，保留書面的回滾計畫，並指定例外狀況負責人。
請將終端修復與網路封鎖分開處理。成功封鎖回連連線代表已完成干預，但該裝置仍需要進一步調查。當員工能夠示範控制封鎖，並安全地恢復合法存取權限時，您的部署才算準備就緒。
Purple Shield 提供具備特定網路政策與報表功能的安全防護 DNS，因此您可以在評估封鎖惡意網域效果的同時，取得管理該政策所需的佐證資料。請造訪 Purple Shield 來安排 30 天免費試用，將您網路的 DNS 指向 Shield，即可在現有網路上測試過濾功能，無需安裝新硬體或裝置代理程式。