こんにちは、私の名前はEvgeny Uskovです。QratorLabsを代表しています。 本日は、サービス拒否につながる可能性のある別の脆弱性に触れます。 この問題は自明のように思えるかもしれませんが、100万を超える脆弱なデバイスが見つかりました。
まず、典型的なルーターを想像してみましょう。 たとえば、ルーティングテーブルを作成し、さまざまなプロトコルを使用して他のデバイスと通信し、最後にネットワークパケットを直接転送します。 よく知られた抽象化があり、これらすべてのタスクは、異なるプロパティを持つ2つのレベル（送信レベルと制御レベル）に分割できます。
管理レベルでは、トラフィックの転送先を決定します。 これには、スパニングツリープロトコル（STP）、OSPF、BGPなどのさまざまなプロトコルが使用されます。 ルータがパケットの宛先または送信元である場合、パケットは送信層に到達します。 それにもかかわらず、制御レベルは中央処理装置ですべてを処理し、さらに、これらの操作は一般にパッケージの比較的小さな部分に対して実行されるため、処理に厳しい時間制限がないことに注意することが重要です。
送信層は転送層とも呼ばれ、その名前が示すように、主に転送を提供します。
これらの層の重要な違いは、送信層のパケットはハードウェアで処理され、制御レベルではパケットがCPUで処理されることです。 制御レベルをインターネット全体に公開したままにすることは、伝統的に悪い考えです-攻撃者がCPUを攻撃するために使用することができます。
制御層へのアクセスを取得するための典型的なシナリオは、開いているTCPポートの使用率に基づいています。 通常、ネットワークデバイスで開いているTCPポートは何ですか？ これは、もちろん、いくつかのネットワークサービスまたはプロトコルのポートです。 そこで、BGPポート（179）を使用して、この問題の危険性を確認することにしました。
最初に、このようなオープンポートが実際の脆弱性であるかどうか、およびサービス拒否を攻撃するために使用できるかどうかを確認する簡単な実験を行いました。 被害者は通常のCiscoルーターであり、意図的に非常に単純なSYNフラッド攻撃を行いました。
32 hping syn-floodプロセスを開始しました。これにより、約0.5 Gb / sで毎秒約720,000パケットの平均トラフィック負荷を生成できました。
この量でさえ、深刻な結果を引き起こすのに十分でした。 以下は、デバイスのCPU負荷のグラフです。 X軸に沿って時間があり、Y軸にCPU負荷がかかります。 攻撃が発生するまでの最初の45分間は、プロセッサは実質的に非アクティブでしたが、最後の15分間では、攻撃を受けてほぼ100％の負荷がかかっていました。 しかし、このチャートを見て、あなたはまだ尋ねることができます-だから何？ CPU負荷はどれくらいですか？
実際、プロセッサの負荷レベル自体が攻撃の唯一の結果ではなく、最も危険なものからはほど遠いものでした。
まず、BGPセッションのいくつかの再起動を観察しました。 画面上のログのスクリーンショット。 さらに、OSPFダイナミックルーティングプロトコルにいくつかの誤動作が見られ、デバイスへのトレースが不安定になりました。 これらすべてに加えて、過負荷のデバイスに到達するのは単純に困難です。
この実験は、オープンネットワークポートの脆弱性がサービス拒否攻撃に悪用される可能性があることを示しています。 これは複数の個々のホストに対するサービス拒否を意味するという事実を強調したいと思います-これはネットワークデバイスであるため、その不安定な動作は、ネットワーク全体へのアクセス不能など、より多くの付随的な損害につながる可能性があります。
この問題の解決策は、いつものように簡単です。 管理レベルのポートをインターネット全体に対して開いたままにしないでください。 アクセス制御リスト（ACL）または少なくともプライベートアドレスを使用します。 複雑なことは何もないようです。
ただし、ほとんどの場合、ルーターの制御レベルは次のようになります。 誰にでも抱擁を提供します。
脆弱なホストに関するいくつかの統計を見てみましょう。 次の方法でこのデータを収集しました：開いているBGPポートの利用可能なIPv4スペースをスキャンすることにより、開いているすべてのポートで応答したポートをフィルターで除外し、それらの動作がBGPに似ているかどうかを確認します-たとえば、インスタントセッションリセット。
ここに数字があります。 100万を超える脆弱なホストが存在します。 すべてのプレフィックスの約10分の1およびすべての自律システムの約3分の1が危険にさらされています。 さらに、これらの自律システムの約5,000はIPトランジットのプロバイダーであるため、それらの問題は顧客に引き継がれます。 また、これらのポートの動作を確認したところ、ほとんどのポートが接続を閉じていることがわかりました。 しかし、特別なケースがあります-たとえば、約60,000人のホストが通知を送信しました。 また、接続が完了する前に、約70,000人のホストがオープンメッセージを送信します。これは、出会ったすべての人に対する抱擁の申し出です。
radar.qrator.net
結論は単純です-全世界に開かれた港の問題は少なくとも数年間は知られているという事実にもかかわらず、それは依然として関連性があり、悪い結果につながる可能性があります。 ネットワークデバイスにアクセスできない可能性について話していることを繰り返します。
このような脆弱性について自律システムをチェックするツールがあります。 このツールは無料で、誰でもアクセスできます。 攻撃者によるこの情報の使用を除外するには、独自の自律システムを登録して所有権を確認するだけです。 フィードバック、意見、提案がある場合は、それを書いてください。
ありがとうございました。質問があれば、喜んでお答えします。
PS同僚、注目！ 2週間目は、BGPプロトコルでの「ルートリーク」の発生に対する自動保護のメカニズムを導入するというイニシアチブで、受け入れコールが進行中です。
これは、2017年5月21日からIETFメーリングリストで2週間（ ここで購読できます ）、ワーキンググループの著者による提案案を受け入れることのすべての長所と短所について議論することを意味します。 投票の結果に応じて、このドキュメントの作業は、標準ステータス（RFC）が受信または凍結されるまで継続されます。
BGP問題の状態に関心があるすべての人に、「draft-ymbk-idr-bgp-open-policy-03」という見出しの下のメッセージスレッドで英語で自分の主張を表現するようにお願いします。 意見を表明するときは、雇用主の意見ではなく、エンジニアとして意見を表明する必要があります。 あなたの意見が推論されることは非常に望ましいです-このため、あなたは私たちの提案にもう一度慣れることをお勧めします（ドラフトへのリンク： one 、 two ）。
IETFメーリングリストで誰でも意見を述べることができることを思い出してください。資格はありません。
すべての技術専門家、システム管理者、開発者、および最新のネットワークの効率的な運用を保証する重要なプロトコルの1つを近代化するイニシアチブを声援する準備ができている関心のある人のみに感謝します。
ありがとう