--- title: "日蝕攻擊：隔離、偵測與節點防禦" description: "了解日蝕攻擊如何隔離區塊鏈節點、為何有效資料仍可能造成虛假網路視圖，以及節點多樣性和獨立核驗如何降低風險。" image: "https://wiki.fcontext.com/og.png" --- > Documentation Index > Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt > Use this file to discover all available pages before exploring further. # 日蝕攻擊：隔離、偵測與節點防禦 > 僅供教育用途，不構成投資建議。投資可能導致損失。 ## 直接回答 **日蝕攻擊**透過控制目標節點的全部或足夠多的網路連線，將其與誠實節點隔離。隨後，攻擊者可以延遲、壓制或選擇性轉送區塊和交易，使受害節點看到由攻擊者塑造的網路視圖。 受害節點可能仍在驗證簽章、工作量證明和所有其他共識規則，但這並不代表它看到的視圖完整或處於最新狀態。一個執行完整驗證的節點可以拒絕無效資料，卻仍可能被困在一條有效但陳舊的分支上、無法看到衝突交易，或被誤導其對更廣泛網路已接受內容的判斷。 這與全網範圍的多數攻擊不同。攻擊者在點對點網路層針對一個節點或有限數量的節點，無須控制網路的大部分挖礦算力或權益。女巫攻擊可以透過提供大量由攻擊者控制的身分或位址來協助日蝕攻擊，但兩者並不相同：女巫攻擊描述身分倍增，日蝕攻擊描述成功隔離受害者的資訊視圖。 ## 隔離如何實現 點對點用戶端會探索候選位址、儲存位址、選擇出站節點、接受部分入站節點，並在連線失敗或重新啟動後再次連線。具體演算法因用戶端和版本而異。攻擊者會尋找辦法，使足夠多的選擇偏向其控制的基礎設施。 一種典型的攻擊路徑分為 4 個階段： 1. **準備攻擊者控制的節點。** 攻擊者在多個位址上運行可連線的節點或身分，而受害節點的節點選擇規則很可能把這些位址視為彼此獨立。 2. **使候選集產生偏差。** 惡意節點散播由攻擊者控制的位址，或以其他方式試圖把誠實項目擠出受害節點的位址管理器。實際可行性取決於儲存桶設計、網路群組規則、速率限制，以及已儲存位址的品質。 3. **觸發或等待重新連線。** 重新啟動、連線頻繁變動、阻斷服務或路由中斷，都可能迫使目標替換誠實節點。當目標缺少獨立路徑，或一開始的位址資料庫較弱時，更容易被隔離。 4. **壟斷連線並過濾資訊。** 一旦受害節點的相關連線都通向攻擊者，攻擊者便只轉送其選定的區塊和交易，而且往往仍遵守共識規則，以免立刻被拒絕。 2015 年的 USENIX 研究針對當時的比特幣點對點實作展示了此類攻擊，並說明了包括基於確認的雙花、自私挖礦協助以及對抗性分叉在內的後果。其具體資源估算和用戶端細節屬於歷史情況，並不是目前 Bitcoin Core 或其他網路普遍適用的常數。 現代用戶端可以藉助隨機化且分段的位址儲存、節點來源多樣性、測試連線、受保護的出站或區塊中繼連線、跨重啟錨點、驅逐規則以及位址轉送限制，提高隔離攻擊的成本。這些措施是分層緩解手段，並不能證明日蝕攻擊絕無可能發生。 ## 支付範例與應對 假設商家的節點收到一筆付款並顯示 `6 confirmations`。若攻擊者已對該節點實施日蝕攻擊，就可能向它展示一條包含該付款、由攻擊者私下維護的有效分支，而誠實網路已接受一筆衝突交易。如果商家僅依據這個被隔離節點便交付不可追回的商品，顯示的確認數並不能證明誠實網路已經確認該付款。 事件應變應先保存證據，再進行會造成中斷的變更： - 記錄回報的鏈尖、累計工作量、近期區塊雜湊、節點清單、連線方向、網路類型、可用時對應的自治系統，以及最後收到區塊的時間戳記。 - 將鏈尖和交易狀態與獨立營運的節點進行比較，並確保這些節點透過真正分離的網路和管理路徑存取。公共區塊瀏覽器只有在其基礎設施同樣獨立時才有參考價值。 - 當獨立視圖不一致時，暫停高價值結算或自動交付。來自同一個隔離視圖的更多確認無法解決問題。 - 切換到已知可靠的軟體和設定，調查 DNS、路由、防火牆、Proxy 和主機是否遭入侵，並按照用戶端記載的復原流程重建節點狀態。 - 逐步重新連線，並核實節點、網路群組、區塊到達、鏈工作量和交易觀察是否變得多樣。不要盲目還原可能已被污染的節點資料庫。 - 保留日誌，並將事件上報給節點或協定安全團隊。疑似日蝕攻擊可能與一般故障、路由事件或範圍更廣的主機入侵同時發生。 在 Bitcoin Core 30.0 中，`getpeerinfo` 會提供 `network`、`mapped_as`、`inbound`、`last_block`、`synced_headers`、`synced_blocks` 和 `connection_type` 等欄位。這些欄位有助於調查，但沒有任何一個欄位能單獨證明節點已被隔離。監控系統應建立正常基準，並把節點集中度與獨立的鏈觀察結果關聯起來。 ## 風險與控制措施 - **針對收款方的雙花：** 受害者可能看到攻擊者控制的分支上產生了確認。對於高價值或不可撤銷的交付，應要求獨立觀察，並設定與結算風險相符的限額。 - **挖礦或驗證者中斷：** 被隔離的營運方可能根據陳舊資訊工作、損失收入，或幫助形成對抗性分支。應在生產節點之外監控鏈工作量、鏈頭時效和節點多樣性。 - **選擇性審查：** 攻擊者無須傳送無效資料，也能隱藏交易或延遲區塊。應針對異常的區塊到達間隔，以及獨立觀察者之間的分歧發出警報。 - **跨鏈橋、預言機和 RPC 故障：** 信任單一上游節點的鏈下服務可能轉送陳舊狀態，或漏掉鏈重組。應採用由不同主體獨立管理、透過不同網路連線的多個資料來源，並制定明確的門檻和時效規則。 - **連線數量造成的虛假信心：** 由同一組織、同一網路或同一位址來源控制的 20 個節點，其獨立性可能還不如一個規模更小但更多樣的節點集合。應衡量多樣性，而不只是數量。 - **固定節點造成的中心化：** 手動設定一個可信節點可以繞過被污染的候選池，卻會形成單點故障。如果適合使用固定錨點，應採用多條獨立營運的路徑，並保留隨機連線。 節點營運方應持續使用仍受支援的用戶端版本，了解特定用戶端的節點管理預設值，保護管理權限，並同時監控入站和出站拓撲。支付和協定營運方應將簽署、廣播、鏈觀察和交付決策彼此分離，使一個被隔離的節點無法自行授權不可逆操作。 ## 常見誤解 - **完整節點不會被騙。** 完整節點會拒絕違反共識的無效資料，但它不會自動知道誠實節點是否對其隱瞞了一條更優的有效鏈。 - **確認數高就一定足夠安全。** 確認只有相對於目前觀察到的鏈視圖才有意義。當存在隔離可能時，觀察路徑的獨立性非常重要。 - **增加節點總能解決問題。** 只有當更多節點的所有權、網路路徑、探索來源和故障模式足夠獨立時，它們才有幫助。 - **日蝕攻擊和女巫攻擊是同一種攻擊。** 女巫攻擊的資源可以讓隔離更容易實現，但日蝕攻擊指的是攻擊者最終控制了受害節點的節點視圖。 - **只要一個區塊瀏覽器的結果一致，就能證明節點健康。** 該瀏覽器可能與受影響系統共用上游服務商、網路路徑或管理網域。 - **任何陳舊節點都遭到了攻擊。** 軟體缺陷、網路壅塞、維護、路由故障和資源耗盡都可能產生類似症狀。應將日蝕攻擊視為一個假設，並透過多個訊號進行檢驗。 ## 相關主題 - [完整節點](/zh-tw/crypto/full-node/) - [點對點網路](/zh-tw/crypto/peer-to-peer-network/) - [女巫攻擊](/zh-tw/crypto/sybil-attack/) - [區塊確認](/zh-tw/crypto/block-confirmation/) - [鏈重組](/zh-tw/crypto/chain-reorg/) ## 來源 - [Eclipse Attacks on Bitcoin's Peer-to-Peer Network](https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/heilman) - USENIX Association（存取日期：2026-08-20） - [Bitcoin Core RPC: getpeerinfo](https://bitcoincore.org/en/doc/30.0.0/rpc/network/getpeerinfo/) - Bitcoin Core（存取日期：2026-08-20） - [Bitcoin Core: connection_types.cpp](https://github.com/bitcoin/bitcoin/blob/v30.0/src/node/connection_types.cpp) - Bitcoin Core（存取日期：2026-08-20） Source: https://wiki.fcontext.com/zh-tw/crypto/eclipse-attack/index.mdx