如何防範 IP 偽冒攻擊

檢查送件路徑，和決定誰可以進門，是兩件不同的事。來源驗證與身分驗證，各自需要相應的控制措施。

接待櫃台可以確認送件是否經由預期的路徑抵達，收件人仍須決定誰可以進入建築物。網路也有類似分工：先驗證流量宣稱來自哪裡，再對服務存取進行身分驗證。

把第一道檢查放在靠近來源的地方

網路營運者知道哪些位址範圍應該從某位客戶的連線抵達。宣稱來自無關來源的封包，可以在繼續傳送之前，就在那裡被拒絕。這就是 BCP 38描述的來源驗證方式。

對企業網路而言，既要檢查從外部進入的流量，也要檢查送往網際網路的流量。同一條邊界，對一個網路是出口，對另一個則是入口。應為每條連線定義預期來源，包括合法委派的位址範圍，而不是到處套用同一條一概而論的規則。

範圍檢查無法識別封包背後的人，也可能在允許的範圍內留下偽造空間。應把它視為有用的邊界控制，而不是身分證明。

讓反向路徑檢查符合實際路由

單播反向路徑轉送（uRPF）會把封包來源與路由資訊比對。在嚴格模式下，封包進入的介面必須符合所選的回程路徑。當路徑可預測時，這種方式可以運作良好。

然而，合法流量可能從一條連線進來，最佳回程路由卻使用另一條。非對稱路由和採用多家供應商的網路，都會出現這種情況。嚴格檢查此時可能丟棄有效流量。RFC 3704說明了這些取捨。可行路徑方式會考慮允許的替代路徑；寬鬆檢查通常只問路由是否存在，因此提供的檢驗較弱。請依實際拓撲選擇並驗證模式，也要納入故障切換情境。

驗證服務與使用者的身分

位址限制有用的地方可以保留，但不要把它當成敏感存取的唯一身分證明。網頁服務應使用經正確驗證的 TLS；管理作業和網路對等端，則應使用合適且具身分驗證的協定。帳號驗證和權限仍各有自己的工作。

TLS 1.3會驗證伺服器，也能驗證用戶端，並保護應用程式流量。它不會認證每一個 IP 來源位址，也無法阻止流量洪水耗盡一條連線。加密與來源驗證保護的是不同事物。

減少被用來反射的機會

如果你營運遞迴 DNS，請把遞迴查詢限制在你打算提供服務的用戶端。這與權威 DNS 不同，後者可能需要向公眾回覆你的網域查詢。RFC 5358說明了為什麼開放遞迴可能把伺服器變成反射器。

也要檢查其他對外服務，是否存在不必要的可連線範圍或過大的回應。請在事件發生前安排上游 DDoS 支援：如果流量抵達伺服器之前，連線就已經飽和，在自己伺服器上過濾，也無法讓那條連線恢復。

IPv6 也需要做出這些決定

改用 IPv6 不會自動開啟加密，也不會自動防止來源偽冒。IPsec 需要主動設定與金鑰管理，而且兩個 IP 版本都能使用。IPv6 營運安全指引討論了實際需要的控制措施。在雙堆疊網路中，兩條路徑都要評估和測試。

確認防護有效，也不破壞服務

記錄預期位址範圍與路由，測試獲授權的流量和故障切換，再檢查封包丟棄情況與服務健康狀態。入侵偵測系統可以就某些模式發出警報；要阻擋，則需要預防功能或營運者的回應。紀錄應協助解釋發生了什麼，而不是把宣稱的來源當成推定的身分。

一般網際網路使用者應專注於更新、經身分驗證的連線和帳號安全。必要時可以向供應商詢問來源過濾；你無法從瀏覽器修正上游的封包驗證。若想了解背景，請閱讀偽造來源如何運作，或各項控制措施針對哪種攻擊模式。