主持人 > 博客 > 管理 > 一切都很糟糕或是一種新型的流量攔截

一切都很糟糕或是一種新型的流量攔截

13 月 XNUMX 日致 RIPE 反濫用工作小組 已收到報價 將 BGP 劫持 (hjjack) 視為違反 RIPE 策略。 如果該提案被接受，受到流量攔截攻擊的網路供應商將有機會發送特殊請求來揭露攻擊者。 如果審查小組收集到足夠的支持證據，作為 BGP 攔截源的 LIR 將被視為入侵者，並可能被剝奪其 LIR 狀態。 也出現了一些爭論 反對這個 變化。

在本出版物中，我們希望展示一個攻擊範例，其中不僅有真正的攻擊者，而且還有受影響的前綴的整個清單。 此外，此類攻擊再次引發了人們對未來攔截此類流量的動機的質疑。

在過去的幾年裡，只有像 MOAS（多源自治系統）這樣的衝突才被媒體報道為 BGP 攔截。 MOAS是一種特殊情況，兩個不同的自治系統通告與AS_PATH中對應的ASN（AS_PATH中的第一個ASN，以下簡稱源ASN）衝突的前綴。 然而，我們至少可以說 3 種附加類型 流量攔截，允許攻擊者出於各種目的操縱 AS_PATH 屬性，包括繞過現代過濾和監控方法。 已知攻擊類型 皮洛索瓦-卡佩利 - 此類攔截的最後一種類型，但並不重要。 這很可能正是我們過去幾週看到的那種攻擊。 這種事件的性質是可以理解的，而且後果也相當嚴重。

那些尋找 TL;DR 版本的人可以滾動到“完美攻擊”副標題。

網路背景

（幫助您更了解本次事件所涉及的流程）

如果您要傳送封包，且路由表中有多個包含目標 IP 位址的前綴，那麼您將使用長度最長的前綴的路由。 如果路由表中同一前綴有幾條不同的路由，您將選擇最好的一條（根據最佳路徑選擇機制）。

現有的過濾和監控方法試圖透過分析AS_PATH屬性來分析路由並做出決策。 路由器可以在通告期間將該屬性變更為任何值。 只需在 AS_PATH 的開頭添加所有者的 ASN（作為原始 ASN）可能就足以繞過當前的原始檢查機制。 此外，如果存在從受攻擊的 ASN 到您的路由，則可以提取該路由的 AS_PATH 並在您的其他通告中使用。 對您精心設計的公告的任何僅 AS_PATH 驗證檢查最終都會通過。

還有一些限制值得一提。 首先，在上游供應商進行前綴過濾的情況下，如果前綴不屬於上游配置的客戶端錐，則您的路由仍可能被過濾（即使使用正確的 AS_PATH）。 其次，如果所建立的路由以錯誤的方向通告，則有效的 AS_PATH 可能會變得無效，從而違反路由策略。 最後，任何具有違反 ROA 長度的前綴的路由都可能被視為無效。

事件

幾週前，我們收到了一位用戶的投訴。 我們看到帶有他的原始 ASN 和 /25 前綴的路由，而該用戶聲稱他沒有公佈它們。

TABLE_DUMP2|1554076803|B|xxx|265466|78.163.7.0/25|265466 262761 263444 22356 3491 2914 9121|INCOMPLETE|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.7.128/25|265466 262761 263444 22356 3491 2914 9121|INCOMPLETE|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.18.0/25|265466 262761 263444 6762 2914 9121|INCOMPLETE|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.18.128/25|265466 262761 263444 6762 2914 9121|INCOMPLETE|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.226.0/25|265466 262761 263444 22356 3491 2914 9121|INCOMPLETE|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.226.128/25|265466 262761 263444 22356 3491 2914 9121|INCOMPLETE|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.164.7.0/25|265466 262761 263444 6762 2914 9121|INCOMPLETE|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.164.7.128/25|265466 262761 263444 6762 2914 9121|INCOMPLETE|xxx|0|0||NAG||
2019年XNUMX月上旬公告範例

路徑中的 NTT /25 前綴使其特別可疑。 事件發生時，LG NTT 並不知道這條路線。 所以，是的，某些操作員為這些前綴創建了整個 AS_PATH！ 檢查其他路由器會發現一個特定的 ASN：AS263444。 在查看了該自治系統的其他路由後，我們遇到了以下情況：

TABLE_DUMP2|1554076800|B|xxx|265466|1.6.36.0/23|265466 262761 263444 52320 9583|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.6.38.0/23|265466 262761 263444 52320 9583|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.23.143.0/25|265466 262761 263444 22356 6762 9498 9730 45528|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.23.143.128/25|265466 262761 263444 22356 6762 9498 9730 45528|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.24.0.0/17|265466 262761 263444 6762 4837|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.24.128.0/17|265466 262761 263444 6762 4837|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.26.0.0/17|265466 262761 263444 6762 4837|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.26.128.0/17|265466 262761 263444 6762 4837|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.64.96.0/20|265466 262761 263444 6762 3491 4760|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.64.112.0/20|265466 262761 263444 6762 3491 4760|IGP|xxx|0|0||NAG||
試著猜測這裡出了什麼問題

看來有人從路由中獲取了前綴，將其分成兩部分，並為這兩個前綴使用相同的 AS_PATH 來通告路由。

TABLE_DUMP2|1554076800|B|xxx|263444|1.6.36.0/23|263444 52320 9583|IGP|xxx|0|0|32:12595 52320:21311 65444:20000|NAG||
TABLE_DUMP2|1554076800|B|xxx|263444|1.6.38.0/23|263444 52320 9583|IGP|xxx|0|0|32:12595 52320:21311 65444:20000|NAG||
TABLE_DUMP2|1554076800|B|xxx|61775|1.6.36.0/23|61775 262761 263444 52320 9583|IGP|xxx|0|0|32:12595 52320:21311 65444:20000|NAG||
TABLE_DUMP2|1554076800|B|xxx|61775|1.6.38.0/23|61775 262761 263444 52320 9583|IGP|xxx|0|0|32:12595 52320:21311 65444:20000|NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.6.36.0/23|265466 262761 263444 52320 9583|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.6.38.0/23|265466 262761 263444 52320 9583|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|28172|1.6.36.0/23|28172 52531 263444 52320 9583|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|28172|1.6.38.0/23|28172 52531 263444 52320 9583|IGP|xxx|0|0||NAG||
拆分前綴對之一的範例路由

幾個問題同時出現。 有人在實踐中實際嘗試過這種類型的攔截嗎？ 有人走過這些路線嗎？ 哪些前綴受到影響？

這就是我們一連串失敗的開始，也是對當前網路健康狀況的又一輪失望。

失敗之路

首先要事。 我們如何確定哪些路由器接受了此類攔截的路由以及哪些流量今天可以重新路由？ 我們認為我們應該從 /25 前綴開始，因為它們「根本無法進行全球分發」。 正如你所猜的，我們錯了。 事實證明，這個指標噪音太大，甚至來自一級運營商的路由也會出現帶有此類前綴的路由。 例如，NTT 有大約 1 個這樣的前綴，並將其分發給自己的客戶。 另一方面，這個指標很糟糕，因為如果操作員使用這樣的前綴，則可以過濾掉 過濾小前綴，在各個方向。 因此，該方法不適合用於查找所有因此類事件而流量被重定向的運營商。

我們認為的另一個好主意是看看 POV。 特別是違反相應 ROA 的 maxLength 規則的路由。 透過這種方式，我們可以找到對給定 AS 可見的狀態為無效的不同來源 ASN 的數量。 然而，有一個“小”問題。 這個數字（不同來源 ASN 的數量）的平均值（中位數和眾數）約為 150，即使我們過濾掉小前綴，它仍保持在 70 以上。這種情況有一個非常簡單的解釋：只有很少有業者已經在入口點使用帶有「重置無效路由」策略的ROA 過濾器，因此無論現實世界中出現ROA 違規的路由，它都可以向各個方向傳播。

最後兩種方法允許我們找到看到我們事件的操作員（因為事件相當大），但一般來說它們不適用。 好吧，但是我們能找到入侵者嗎？ AS_PATH 操作的一般特徵是什麼？ 有幾個基本假設：

  • 該前綴以前從未在任何地方見過；
  • Origin ASN（提醒：AS_PATH中的第一個ASN）有效；
  • AS_PATH 中的最後一個 ASN 是攻擊者的 ASN（以防其鄰居在所有傳入路由上檢查鄰居的 ASN）；
  • 該攻擊源自單一提供者。

如果所有假設都正確，那麼所有不正確的路由都將呈現攻擊者的 ASN（原始 ASN 除外），因此，這是一個「關鍵」點。 真正的劫機者是 AS263444，儘管有其他劫機者。 即使我們不考慮事件路線。 為什麼？ 即使對於正確的路線，關鍵點也可能仍然是關鍵的。 這可能是由於某個地區的連通性較差或我們自身的可見性受到限製造成的。

因此，有一種方法可以檢測攻擊者，但前提是滿足上述所有條件，並且只有當攔截量大到足以通過監控閾值時。 如果其中一些因素不滿足，那麼我們能否識別遭受此類攔截的前綴？ 對於某些運營商來說 - 是的。

當攻擊者創建更具體的路由時，真正的所有者不會通告這樣的前綴。 如果您有一個包含所有前綴的動態列表，那麼您就可以進行比較並找到扭曲的更具體的路由。 我們使用 BGP 會話收集此前綴列表，因為我們不僅獲得了運營商當前可見的路由的完整列表，而且還獲得了其想要向全世界通告的所有前綴的列表。 不幸的是，現在有幾十個 Radar 用戶沒有正確完成最後一部分。 我們會盡快通知他們並嘗試解決此問題。 其他人現在就可以加入我們的監控系統。

如果我們回到最初的事件，攻擊者和分佈區域都被我們透過尋找關鍵點發現了。 令人驚訝的是，AS263444 並沒有向所有客戶端發送偽造的路由。 雖然也有陌生的時刻。

BGP4MP|1554905421|A|xxx|263444|178.248.236.0/24|263444 6762 197068|IGP|xxx|0|0|13106:12832 22356:6453 65444:20000|NAG||
BGP4MP|1554905421|A|xxx|263444|178.248.237.0/24|263444 6762 197068|IGP|xxx|0|0|13106:12832 22356:6453 65444:20000|NAG||
最近嘗試攔截我們的地址空間的範例

當為我們的前綴建立更具體的前綴時，將使用專門建立的 AS_PATH。 然而，這個 AS_PATH 不能從我們之前的任何路由中取得。 我們甚至沒有與 AS6762 進行通訊。 看看事件中的其他路由，其中​​一些有以前使用過的真實AS_PATH，而另一些則沒有，即使它看起來像真實的。 此外，更改 AS_PATH 沒有任何實際意義，因為流量無論如何都會被重定向到攻擊者，但具有「壞」AS_PATH 的路由可以透過 ASPA 或任何其他檢查機制進行過濾。 這裡我們思考一下劫機者的動機。 我們目前沒有足夠的資訊來確認這起事件是一次有計劃的襲擊。 儘管如此，這是可能的。 讓我們嘗試想像一種情況，雖然仍然是假設的，但可能非常真實。

完美攻擊

我們有什麼？ 假設您是一家為客戶廣播路線的交通提供者。 如果您的客戶有多個存在（多主），那麼您將只收到他們的一部分流量。 但流量越多，你的收入就越多。 因此，如果您開始使用相同的 AS_PATH 通告這些相同路由的子網路前綴，您將收到其其餘流量。 結果，剩下的錢。

ROA 在這裡有幫助嗎？ 也許是的，如果您決定完全停止使用它 最長長度。 此外，非常不希望 ROA 記錄具有相交的前綴。 對一些業者來說，這樣的限制是不可接受的。

考慮到其他路由安全機制，ASPA 在這種情況下也無濟於事（因為它使用來自有效路由的 AS_PATH）。 由於採用率較低且有降級攻擊的可能性，BGPSec 仍然不是最佳選擇。

因此，我們對攻擊者有明顯的好處，但缺乏安全性。 很棒的組合！

我該怎麼做？

最明顯也是最徹底的步驟是檢查您目前的路由策略。 將您的位址空間分成您想要通告的最小區塊（無重疊）。 僅為他們簽署 ROA，而不使用 maxLength 參數。 在這種情況下，您目前的 POV 可以使您免受此類攻擊。 然而，同樣，對於一些運營商來說，由於專有使用更具體的路線，這種方法並不合理。 ROA 和路線物件當前狀態的所有問題將在我們未來的材料之一中進行描述。

另外，您可以嘗試監控此類攔截。 為此，我們需要有關您的前綴的可靠資訊。 因此，如果您與我們的收集器建立 BGP 會話並向我們提供有關您的互聯網可見性的信息，我們就可以找到其他事件的範圍。 對於尚未連接到我們的監控系統的人來說，首先，僅包含您的前綴的路由清單就足夠了。 如果您與我們進行了會話，請檢查您的所有路線是否已發送。 不幸的是，這一點值得記住，因為某些運算子忘記了一兩個前綴，從而乾擾了我們的搜尋方法。 如果操作正確，我們將獲得有關您的前綴的可靠數據，這將有助於我們在將來自動識別和檢測您地址空間的這種（和其他）類型的流量攔截。

如果您即時意識到此類流量已攔截，您可以嘗試自行抵消。 第一種方法是自己使用這些更具體的前綴來通告路由。 如果這些前綴受到新的攻擊，請重複。

第二種方法是透過切斷攻擊者的路由存取來懲罰攻擊者和那些以他為關鍵點（對於良好路由）的人。 這可以透過將攻擊者的 ASN 添加到舊路由的 AS_PATH 中來完成，從而迫使他們使用 BGP 中的內建環路偵測機制來避開該 AS 為了你好.

來源： www.habr.com

添加評論