すべてが非常に悪い、または新しいタイプのトラフィック傍受

13 月 XNUMX 日、RIPE 虐待防止作業部会へ オファーが届きました BGP ハイジャック (hjjack) は RIPE ポリシーの違反であると考えてください。 この提案が受け入れられた場合、トラフィック傍受によって攻撃されたインターネットプロバイダーは、攻撃者を暴露するための特別なリクエストを送信する機会を得ることになります。 検討チームが十分な裏付け証拠を収集した場合、BGP 傍受の発信元である LIR は侵入者とみなされ、LIR ステータスが剥奪される可能性があります。 いくつかの議論もありました これに反対して 変更します。

この出版物では、実際の攻撃者だけでなく、影響を受けるプレフィックスのリスト全体も対象とした攻撃の例を示したいと思います。 さらに、このような攻撃は、この種のトラフィックの将来の傍受の動機について再び疑問を引き起こします。

ここ数年、BGP 傍受としてマスコミで取り上げられるのは、MOAS (Multiple Origin Autonomous System) のような競合だけです。 MOAS は、XNUMX つの異なる自律システムが、AS_PATH 内の対応する ASN (AS_PATH 内の最初の ASN、以下、起点 ASN と呼びます) と競合するプレフィックスをアドバタイズする特殊なケースです。 ただし、少なくとも名前を挙げることができます。 追加3種類 トラフィックの傍受により、攻撃者がフィルタリングや監視に対する最新のアプローチをバイパスするなど、さまざまな目的で AS_PATH 属性を操作できるようになります。 既知の攻撃タイプ ピロソワ＝カペリ - このような傍受の最後のタイプですが、まったく重要ではありません。 これは、まさに過去数週間に見られた種類の攻撃である可能性が十分にあります。 このような出来事は理解できる性質のものであり、非常に深刻な結果をもたらします。

TL;DR バージョンをお探しの方は、「Perfect Attack」というサブタイトルまでスクロールしてください。

ネットワークの背景

(このインシデントに関係するプロセスをより深く理解するのに役立ちます)

パケットを送信する場合、宛先 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月上旬のお知らせ例

/25 プレフィックスのパスに NTT があると、特に疑わしいことがわかります。 LG NTTは事件当時、このルートを知らなかった。 そうです、一部のオペレーターはこれらのプレフィックスに対して AS_PATH 全体を作成します。 他のルーターをチェックすると、特定の ASN AS263444 が XNUMX つ判明します。 この自律システムを使用して他のルートを調べたところ、次のような状況が発生しました。

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||
ここで何が間違っているのか推測してみてください

誰かがルートからプレフィックスを取得して XNUMX つの部分に分割し、それら XNUMX つのプレフィックスに対して同じ 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||
分割プレフィックス ペアの XNUMX つのルートの例

いくつかの疑問が同時に生じます。 実際にこの種のインターセプトを実際に試した人はいますか? 誰かこれらのルートを通った人はいますか？ どのプレフィックスが影響を受けましたか?

ここから一連の失敗が始まり、インターネットの現状に対するさらなる失望が始まります。

失敗の道

まず最初に。 どのルーターがそのような傍受されたルートを受け入れ、どのルーターのトラフィックが今日再ルーティングされる可能性があるかをどのように判断できるでしょうか? /25 プレフィックスから始めようと考えたのは、「単純にグローバルに配布できない」ためです。 ご想像のとおり、私たちは非常に間違っていました。 このメトリックはノイズが多すぎることが判明し、そのようなプレフィックスを持つルートは Tier-1 オペレーターからも表示される可能性があります。 たとえば、NTT はそのようなプレフィックスを約 50 個持っており、自社のクライアントに配布しています。 一方、このメトリクスは、オペレータが 小さなプレフィックスのフィルタリング、あらゆる方向に。 したがって、この方法は、そのようなインシデントの結果としてトラフィックがリダイレクトされたすべてのオペレーターを見つけるのには適していません。

私たちが考えたもう XNUMX つの良いアイデアは、 ハメ撮り。 特に、対応する ROA の maxLength ルールに違反するルートの場合はそうです。 このようにして、特定の AS に表示される、ステータスが無効であるさまざまなオリジン ASN の数を見つけることができます。 ただし、「小さな」問題があります。 この数 (異なる発信元 ASN の数) の平均 (中央値と最頻値) は約 150 で、小さなプレフィックスを除外したとしても、依然として 70 を超えています。 この状況の説明は非常に簡単です。エントリ ポイントで「無効なルートのリセット」ポリシーを備えた ROA フィルタをすでに使用している事業者はほとんどいません。そのため、ROA 違反のあるルートが現実世界に出現すると、そのルートは全方向に伝播する可能性があります。

最後の XNUMX つのアプローチでは、インシデントを目撃したオペレーターを見つけることができますが (非常に大規模なため)、一般的には適用できません。 さて、でも侵入者を見つけられるでしょうか？ この AS_PATH 操作の一般的な特徴は何ですか? いくつかの基本的な前提があります。

• この接頭辞はこれまでどこにも見られませんでした。
• オリジン ASN (注意: AS_PATH の最初の ASN) は有効です。
• AS_PATH の最後の ASN は、攻撃者の ASN です (その隣接者がすべての受信ルートで隣接者の ASN をチェックする場合)。
• 攻撃は単一のプロバイダーから発生します。

すべての仮定が正しい場合、すべての誤ったルートは攻撃者の ASN (発信元 ASN を除く) を示すことになるため、これは「クリティカル」ポイントになります。 真のハイジャッカーの中には AS263444 が含まれていましたが、他にも存在しました。 たとえ事件ルートを考慮から外したとしても。 なぜ？ クリティカル ポイントは、ルートが正しい場合でもクリティカルなままになる場合があります。 これは、地域内の接続状態が悪いか、私たち自身の可視性が制限されていることが原因である可能性があります。

その結果、攻撃者を検出する方法はありますが、それは上記の条件がすべて満たされ、傍受が監視しきい値を通過するのに十分な大きさである場合に限られます。 これらの要素のいくつかが満たされていない場合、そのような傍受の被害を受けたプレフィックスを特定できるでしょうか? 特定の演算子の場合 - はい。

攻撃者がより具体的なルートを作成する場合、そのようなプレフィックスは真の所有者によってアドバタイズされません。 そこからすべてのプレフィックスの動的なリストがあれば、比較を行って、歪んだより具体的なルートを見つけることが可能になります。 このプレフィックスのリストは、BGP セッションを使用して収集します。これは、現在オペレーターに表示されているルートの完全なリストだけでなく、世界中にアドバタイズしたいすべてのプレフィックスのリストも提供されるためです。 残念なことに、現在、最後の部分を正しく完了していないレーダー ユーザーが数十人います。 すぐに通知し、この問題の解決に努めます。 他の誰もが今すぐ監視システムに参加できます。

元のインシデントに戻ると、重要なポイントを検索することで、攻撃者と配布エリアの両方が検出されました。 驚くべきことに、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 は、導入率が低く、ダウングレード攻撃の可能性が残っているため、依然として最適なオプションではありません。

したがって、攻撃者にとっては明らかに利益があり、セキュリティは欠如しています。 素晴らしいミックス！

私は何をすべきですか？

明白かつ最も抜本的な手順は、現在のルーティング ポリシーを確認することです。 アドレス空間を、アドバタイズする最小のチャンク (重複しない) に分割します。 maxLength パラメータを使用せずに、それらに対してのみ ROA に署名します。 この場合、現在の POV がそのような攻撃からあなたを救うことができます。 ただし、繰り返しますが、一部の通信事業者にとっては、より特定のルートを排他的に使用するため、このアプローチは合理的ではありません。 ROA とルート オブジェクトの現在の状態に関するすべての問題は、将来の資料の XNUMX つで説明される予定です。

さらに、そのような傍受を監視することもできます。 これを行うには、プレフィックスに関する信頼できる情報が必要です。 したがって、お客様が当社のコレクターとの BGP セッションを確立し、インターネットの可視性に関する情報を当社に提供していただければ、当社は他のインシデントの範囲を見つけることができます。 まだ監視システムに接続していない人は、まず、プレフィックスのみを含むルートのリストで十分です。 私たちとセッションを行っている場合は、すべてのルートが送信されていることを確認してください。 残念ながら、一部の演算子はプレフィックスを XNUMX つまたは XNUMX つ忘れてしまい、検索方法に支障をきたすため、これは覚えておく価値があります。 正しく実行されれば、お客様のプレフィックスに関する信頼できるデータが得られ、将来的には、お客様のアドレス空間におけるこのタイプ (およびその他の) トラフィック傍受を自動的に識別し、検出するのに役立ちます。

このようなトラフィックの傍受にリアルタイムで気付いた場合は、自分で対抗することができます。 最初のアプローチは、これらのより具体的なプレフィックスを使用してルートを自分でアドバタイズすることです。 これらのプレフィックスに対する新たな攻撃の場合は、これを繰り返します。

XNUMX 番目のアプローチは、攻撃者へのルートへのアクセスを遮断することで、攻撃者と、攻撃者がクリティカル ポイントとなる人々 (良いルートの場合) を罰することです。 これを行うには、攻撃者の ASN を古いルートの AS_PATH に追加し、BGP の組み込みループ検出メカニズムを使用してその AS を回避するように強制します。 あなた自身の利益のために.

出所： habr.com