DDoS 攻撃を手動でトラブルシューティングする際の問題

by マーク・ハリス 2017 年 6 月 23 日

次の記事は、DDoS 攻撃のトラブルシューティングに関する 2 部構成のシリーズの第 3 部であり、Matt Conran によるゲスト投稿です。 ネットワークインサイト. この記事では、Matt が DDoS トラブルシューティングの手動アプローチの課題について説明します。

概要

DDoS (分散型サービス拒否) 攻撃は、多数のソースからの膨大なトラフィックによってオンライン サービスを遠ざける待ち伏せ攻撃です。 このサイバー攻撃では、実行者は複数の一意の IP アドレスを使用します。 それで、 DDoS について考えるとき、頭に浮かぶ最も重要な要素は、検出と緩和のコンポーネントです。 結局のところ、これはお金が押し寄せられる場所であり、新しい派手な機能が導入される場所です. ただし、DDoS を時間通りに阻止するのは、エンド ツー エンドのソリューション全体の有効性です。

パズルの欠けているピースは、トラブルシューティングです。 多くの人がそれを認識しています ネットワークのマッピング トラブルシューティングは、エンジニアの手だけが必要な技術的なタスクです。 しかし、一緒に統合する必要がある会社全体のプロセスがあり、最終的な実践的な構成作業につながり、それによって DDoS を阻止します。

この手順には、さまざまなチームや技術的背景を持つ人々の調整が含まれ、ソリューションを効率的にブレンドして形成します。 これは自動的に、または偶然に起こることではありません。 リハーサルを行い、正確に制御する必要があります。 DDoS 攻撃の最大の問題の XNUMX つは、準備不足です。 準備不足はパニックにつながり、それが始まると何も修正されません.

チーム間の文化が効率的に機能しない限り、世界中のすべての技術的経験は役に立ちません。 また、DDoS イベントでは、複数のチームが一緒に活動する必要があります。

ネットワーキングの芸術

ネットワーキングの技術は、独自のスノーフレークと呼ばれることが多い何千もの異なるネットワーク設計につながっています。 SP ネットワークでは、多くの場合、L2VPN や L3PVPN など、同じ最終目標の接続要件を提供します。 ただし、ネットワーク設計のタイプはプロバイダーによって大きく異なります。

多くのデザインは、変更を追跡する中央リポジトリにあるはずなのに、デザイナーの頭に残されています。 ボリュームがテラバイト規模に達する DDoS 攻撃を受けると、さまざまなネットワーク設計と構成のトラブルシューティングが難しくなります。

リモートトリガーブラックホール (RTBH)

リモート トリガー ブラック ホール (RTBH) は、最も一般的なブラック ホールの XNUMX つです。 攻撃を軽減する方法。 ネットワーク内で Border Gateway Protocol (BGP) を使用し、転送先にルールをインストールして宛先をブロックし、DDoS 攻撃を緩和します。 基本的に、攻撃者に代わって DDoS 攻撃を完了します。 RTHB はこれまで便利でしたが、その欠点の XNUMX つは、ミッション モード ルーティングとセキュリティ機能の両方を同じデバイスで組み合わせていることです。

攻撃をブロックするために使用されるファイアウォール ルールは、ポイント A からポイント B にトラフィックをルーティングするというコアの役割を実行するネットワーク デバイスに配置されます。したがって、技術的な観点からは、すでに課題があります。 これをさらに複雑にするために、多くの場合、セキュリティとネットワークの両方で同じデバイスで作業するために XNUMX つのチームを組み合わせる必要があります。 運用上の観点から見ると、DDoS 緩和への最も一般的なアプローチは、同じデバイスに XNUMX つの技術的なハットを混在させることです。

DDoS 攻撃のピーク時には、チームのコラボレーションが重要であり、RTBH などの既存の DDoS 軽減策では、チームの調整が困難になる可能性があります。 DDoS から効率的に防御するには、技術的な観点だけからソリューションを単一のものと見なすことはできません。 レースに勝つのは、トラブルシューティング プロセス全体とチームのコラボレーションです。

すべてを見る能力

効率的な DDoS 保護のために、Open Systems Interconnection モデル (OSI) スタックのすべてのレイヤーを調べる必要があります。 もはや XNUMX つのレイヤーだけではありません。 サイバー犯罪者は、複数のレイヤーを使用してネットワークに侵入しています。 並列攻撃は、ボリューメトリックなレイヤー 4 とレイヤー 7 アプリケーション攻撃の両方を組み合わせて使用​​されることがよくあります。 したがって、本質的に、トラブルシューティングが必要なスタックの 4 つのレイヤー (レイヤー 7 とレイヤー XNUMX) があります。

これには、レイヤ 4 のネットワーキング チームとレイヤ 7 のアプリケーション チームという XNUMX つの別個のチームが関与する可能性もあります。いくつかのファイアウォールとロード バランサを組み合わせることで、分散したチームの相互作用がうまく組み合わされています。 このタイプのコラボレーションは、合理化され、効率的に調整される必要があります。

手動アプローチの例

DDoS に対する手動のアプローチには、問題の原因を実際に突き止める前に、いくつかの手順が含まれます。 これらはすべて、さまざまな人、チーム、場所、時間で実行する必要がある場合があります。 ほとんどの場合、関係者が隣同士に座っているわけではありません。 攻撃とそれがどのように通知されたかに応じて、何が重要かが決まります。 アプリケーション レベルの攻撃の場合、管理者は、手動でログインするか、中央のログ アナライザーを介して、個々のサーバーのログを表示する必要がある場合があります。

別の管理者がマシンのグループを追跡し、次のようなコマンドを発行する必要がある場合があります。 「ネットスタット」 そのサーバーまたはアプライアンスで開いている接続を特定します。 別の管理者が、マシンの負荷が高いかどうかを確認するか、または数を決定する必要があります。 HTTP プロセス ランニング。 Linux またはファイアウォールの管理者は、カスタム スクリプトを作成し、それを IP テーブルに対して実行して、他の種類のセキュリティ情報を判断する必要があります。

カスタム スクリプトに関する注意事項

個々のエンジニアによって作成されたカスタム スクリプトは、ジョブの XNUMX つには最適ですが、チーム間で自動化する場合は、さらに複雑になります。 スクリプトを作成する人は、通常、スクリプトを管理する人です。 この人が去った場合、または必要なバグや変更がある場合はどうなりますか?

そのエンジニアの領域を超えた追加の作業は、彼の通常の日常業務にプールされ、最終的に脇に置かれます。 誰も担当していない集中管理データベースにすべてのスクリプトを備蓄しておく方がはるかに優れています。 DDoS 攻撃は急速に進化しています。 必要なランダム変更のタイプ (TCP -> UDP) は、C2 サーバーでの単純なコマンドです。 これらすべてをカスタム スクリプトで追跡しようとすると、あなたとあなたの会社にとって不利益になります。

高度な攻撃

HTTP ホスト ヘッダーまたはセッション テーブルを確認するために、より高度なエンジニアを呼び出す必要がある場合があります。 ロードバランサーで、より高度な攻撃かどうかを判断します。 レイヤー 7 攻撃は 5 秒あたりのパケット数を超えないため、標準の XNUMX タプルよりも深く掘り下げて断続的な問題を特定する必要があります。

場合によっては、輻輳カウント、輻輳ウィンドウ、TCP RTT、またはその他の高度な機能を調べるために、さらに長い時間を費やす必要がある場合があります。 Web サーバーでは、Null0 に書き込む特定のヘッダーを探す必要がある場合があります。

BGP コミュニティ

多くの場合、BGP コミュニティは DDoS 緩和に適しています。 BGP コミュニティがルートに設定され、そのルートが WAN エッジでブロックされます。 設定が間違っていると、問題の原因を突き止めるために多くの手作業が必要になります。

閉会のコメント

トラブルシューティングへの手動のアプローチは最終的に実行する必要があり、その後、何をすべきかを決定するために、すべての診断情報を何らかの形で XNUMX つの場所にプールする必要があります。 自動化せずに同じ人でこれらの手順を繰り返そうとすると、スムーズな運用にはなりません。 多くの異なるチームを必要とする多くの異なるステップがあり、多くの異なるテクノロジの帽子を組み合わせています。

トラブルシューティングに必要なこれらのデバイスの一部は、ログインが異なる別のネットワーク上にある場合もあります。 デバイスに乗ってトラブルシューティングを開始する場合でも、トラブルシューティング チケットを提出する必要がある場合があります。 私たちはすでに手を結んでおり、DDoS はすでに大きな勝利を収めています。 この種のトラブルシューティングは、特にいたちごっこをしているときには、あなたに不利益をもたらします。 チーム、技術的な帽子、スキルセットを組み合わせることは困難な作業であり、優れたチームとプロジェクト管理が必要です. 神々に信仰を任せる代わりに、物事をうまく機能させるための解決策を用意しておく方がよいでしょう。 したがって、DDoS が発生し、それが確実に発生する場合、ボタンをクリックするだけでそれを緩和する準備が整います。

NetBrain 提供しています ネットワーク自動化への独自のアプローチ これにより、DDoS の検出と緩和の間のギャップを埋めます。 の能力 NetBrain 検出システムと軽減システムの両方と統合することで、サービス拒否 (DDoS) パズルの欠けているピースが完成します。 活用するのはマッピング会社ではなく、自動化会社です。 動的ネットワーク マッピング、実行可能ファイル Runbook砂 API の豊富な統合フレームワーク とワークフロー あらゆる種類の DDoS のトラブルシューティングを行います。