暗号化キーを開示しない暗号化トラフィックフィルタリングスキーム。
多くの場合、ディスカッションでは、トラフィックの継続的なフィルタリングに基づく分散型サービス拒否攻撃を無効にするサービスは、オンデマンドフィルタリングよりも効率が悪く、費用がかかると聞きます。
このようなダイアログで使用される引数は、議論が始まるとき、実際には時間とともに変化しません。オンデマンド攻撃を中和するプロセスに専門家または機器を含めるために必要な時間遅延に対する一定のフィルタリングの高コスト。
Qrator Labsは、コンスタントフィルタリングがオンデマンドフィルタリングとどのように異なり、最初のオプションが実際に唯一のオプションである理由について議論するために、いくつかの議論を提唱することにより、自分の立場を明確にしたいと考えています。
主な理由の1つは、最新の攻撃が非常に迅速に発生することです-リアルタイムで進化し、より複雑になります。 サービス自体は進化しています-サイトとアプリケーションは開発中であるため、前回の攻撃中の「通常の」ユーザーの行動はもはや関係ないことが判明する可能性があります。
手動フィルタリングの場合、サービス拒否攻撃を無効にするサービスプロバイダーの技術専門家は、ほとんどの場合、正しい行動戦略と特定のアクションのシーケンスを開発するために何が起こっているかを理解するための時間を必要とします。 さらに、このようなスペシャリストは、クライアントの要求に応じて攻撃ベクトルを効果的に無効にするために、攻撃ベクトルがいつどのように変化するかを正確に知る必要もあります。
主にサービスにアクセスしようとするすべてのユーザーのアクセシビリティが低下するため、攻撃を受けて接続することは別の困難です。 攻撃が成功し、ユーザーがリクエストされたリソースを受け取らなかった場合、ユーザーは単にページを更新するか、アプリケーションをリロードするだけで、再度取得しようとします。 これにより、ジャンクトラフィックと正当なトラフィックを区別することが難しくなるため、攻撃シナリオが悪化します。
クラウドまたは物理的にクライアントのサイト、パートナーのデータセンターで攻撃を無効にするためのサービスの実際の展開は、多くの場合、実装の重要な要件です。 配置オプションのいずれでも継続的な自動または手動フィルタリングが可能であるため、それに応じて-攻撃の検出と中和。 ただし、自動フィルタリングが重要な要件です。
ほとんどの場合、攻撃を中和するクラウドサービスは、すべての着信トラフィックをフィルタリングし、分析に完全に利用できるようになります。 ネットワークエッジに設置された、または複製されたトラフィックを受信する物理機器は、リアルタイムで攻撃を監視および中和するためのほぼ同じ機能を提供します。
一部のベンダーは、トラフィック分析にNetFlowメトリックまたはその他のメトリックを使用することを推奨しています。これは、サードパーティまたは派生メトリックがデータに関する情報の一部のみを提供し、検出の可能性を絞り込むため、それ自体が結果的に悪い点で妥協です攻撃を中和します。 またその逆-クラウドサービスは着信トラフィックの100％を分析する必要はありませんが、ほとんどの場合、クラウドサービスは分析を実行します。なぜなら、このアプローチによりモデルを構築し、アルゴリズムを最適な方法でトレーニングできるからです。
NetFlowプロトコルを主な分析ツールとして使用することのもう1つの欠点は、データストリームの一部の特性のみを提供することです-ストリーム自体ではなく、その説明です。 したがって、もちろん、NetFlowが反映するパラメーターに基づいた攻撃に気付くでしょうが、ストリームのコンテンツを分析することで検出されるべきより複雑なタイプの攻撃は表示されません。 したがって、トランスポート内での攻撃の100％の証拠の場合を除き、アプリケーションレイヤー（L7）への攻撃はNetFlowメトリックのみを使用して撃退することは困難です（L4 NetFlowを超えると、まったく役に立たないため）。
ろ過ネットワークへの接続の一般的なスキーム。
1.クラウドベースのDDoS中和サービスプロバイダーは、現在攻撃が行われていない場合でも「永続的なフィルタリング」を提供するのはなぜですか？
答えは簡単です。常時フィルタリングは、攻撃を無効にする最も効果的な方法です。 また、ここで追加する必要があるのは、クライアントがホストする物理機器がクラウドフィルターとそれほど変わらないことです。ただし、データセンター内のどこかでボックスが物理的にオンとオフになる点が異なります。 ただし、どのような場合でも（動作するように、つまりデバイスの電源を常にオンにするか、必要な場合にのみオンにする）選択肢があり、ユーザーはそれを作成する必要があります。
理論的には、フィルタリングによるネットワーク遅延の低下は実際に起こり得ます-特に最も近いノードが地理的に遠く、クライアントがローカルリソースとトラフィックを必要とする場合。 しかし、ほとんどの場合に見られるのは、論理ホスト割り当てを備えた適切に構築されたフィルタリングネットワークに基づくHTTPS / TCPハンドシェイクの加速による全体的な遅延の減少です。 正しい中和ネットワークは、保護が必要なネットワークよりも優れたトポロジ（高速で信頼性の高い）を持っていると主張する人はいないでしょう。
リバースプロキシがフィルタリングオプションをHTTPおよびHTTPS（SSL）プロトコルのみに制限していると言うと、あなたは真実の半分に過ぎません。 HTTPトラフィックは不可欠であり、複雑なフィルタリングシステムの重要な部分の1つです。逆プロキシは、HTTPトラフィックを収集して分析する最も効果的な方法の1つです。
2.ご存じのように、分散型サービス拒否攻撃は、HTTPプロトコルから離れて、多くの形態を取り、変更することができます。 この場合のクラウドは、クライアント側の自立型機器よりも優れているのはなぜですか？
ろ過ネットワークの個々のノードの過負荷は、ラック内にある機器で実現するのが現実的である限り可能です。 どんな攻撃にも対処できるほど強力な鉄の箱はありません-複雑でマルチコンポーネントのシステムが必要です。
ただし、最大規模の機器メーカーでも、最も深刻な攻撃に備えてクラウドフィルタリングに切り替えることを推奨しています。 クラウドはクラスターで編成された同じ機器で構成されているため、デフォルトではそれぞれがデータセンターにある個別のソリューションよりも強力です。 さらに、ボックスはあなただけのために機能しますが、大規模なフィルタリングネットワークは数十および数百の顧客にサービスを提供します-このようなネットワークの設計は、もともと攻撃を無力化するために大量の大量のデータを処理するように設計されました。
攻撃の前に、スタンドアロン機器（CPE）またはフィルタリングネットワークノードを無効にすることの方が簡単かどうかを明確に言うことは不可能です。 しかし、これについて考えてください-ポイント障害は常にベンダーにとっての問題ですが、購入後に述べられているように動作を拒否する機器はあなたの問題です。
3.プロキシサーバーとして機能するネットワークノードは、リソースからコンテンツとデータを受信できる必要があります。 これは、だれでもクラウドソリューションを回避して攻撃を無効化できるということですか？
あなたとセキュリティサービスプロバイダーの間に専用の物理回線がない場合は、はい。
サービス拒否攻撃を無効にするためのクライアントからサービスプロバイダーへの専用チャネルがなければ、攻撃者はサービスのネイティブIPアドレスを攻撃できます。 このようなサービスのすべてのプロバイダーが、原則として、自分自身からクライアントに専用線のサービスを提供するわけではありません。
一般に、クラウドフィルタリングへの切り替えとは、BGPを使用して適切なアナウンスを発表することを意味します。 この場合、攻撃を受けているサービスの個々のIPアドレスは隠されており、攻撃にはアクセスできません。
4.クラウドフィルタリングに対する議論として、サービスのコストとプロバイダーからのコストの比率が使用される場合があります。 この状況は、クライアント側にある機器と比較するとどのように見えますか？
そのようなネットワークを構築する際の内部費用は常にそれぞれの主張に基づいているにもかかわらず、サービス拒否攻撃がどれほど小さくても、それらを中和するクラウドサービスプロバイダーはすべてを処理する必要があると言っても安全です攻撃は激しく、大きく、長く、スマートです。 一方、これは、そのようなサービスのプロバイダーがすべてに対する顧客保護を販売してお金を失うことを意味するものではありませんが、実際には主に中小規模の攻撃に対処することを余儀なくされています。 はい、フィルタリングネットワークは「完全な状態」よりも少し多くのリソースを消費する可能性がありますが、無力化された攻撃が成功した場合、誰も質問しません。 クライアントとプロバイダーの両方がこのパートナーシップに満足し、高い確率で継続します。
設備が設置されている同じ状況を想像してください-一度だけ桁違いに費用がかかり、サービスに資格のある手が必要です...それでも、小規模でまれな攻撃の解決を余儀なくされます。 どこでも安くないような機器を買うつもりだったとき、これについて考えましたか？
クラウドで適切な関税を購入する場合と比較して、高度な資格を持つエンジニアの作業のためのインストール、技術サポート、および支払いの契約と一緒に別のボックスが最終的に安くなるという理論は、単に間違っています。 機器の最終コストとその稼働時間は非常に高く、これが分散型サービス拒否攻撃の保護と無効化が独立したビジネスになり、業界を形成した主な理由です-さもなければ、すべてのIT企業に攻撃保護ユニットが表示されます。
攻撃はまれな現象であるという前提に基づいて、攻撃を無効化するソリューションを適切に構築し、これらのまれな攻撃を無力化できるようにする必要があります。 しかし、これに加えて、ほとんどの場合、悪いことは何も起こらないことを誰もが理解しているため、適切な資金もかかります。
クラウドプロバイダーは、機器とソフトウェアの両方であるフィルタリングポイント間でトラフィックを分散することにより、独自のリスクを統合し、攻撃に対処するために、効率的な方法で独自のネットワークを設計および構築します。
ここでは、確率論からおなじみの「大数の法則」について話しています。 これが、インターネットサービスプロバイダーが実際に所有しているチャンネルよりも高い容量のチャンネルを販売している理由です。 保険会社のすべてのクライアントは、仮説上、同時に不快な状況に陥ることがありますが、実際にはこれは起こりませんでした。 そして、個々の保険の補償は莫大である可能性がありますが、これは誰かが事故に遭うたびに保険事業の破産につながるわけではありません。
サービス拒否攻撃を専門的に無効にする人々は、それがアンプに関連する最も安価な、したがって最も一般的な攻撃であり、「小規模」とは言えないことを知っています。
同時に、物理的なサイトに設置された機器の1回限りの支払いが永遠に残ることに同意することで、攻撃方法が進化します。 昨日の機器が明日の攻撃に対処する保証はありません-これは単なる仮定です。 したがって、そのような機器への大量投資は、その継続的なメンテナンスと更新の必要は言うまでもなく、設置の瞬間からその価値を失い始めます。
DDoSの無効化に関しては、接続性の高い高度にスケーラブルなソリューションを用意することが重要です。これは、機器のボックスを個別に購入することでは実現が非常に困難です。
深刻な攻撃が発生すると、自立型機器はクラウドにその開始の事実について信号を送り、フィルタリングポイントによりトラフィックを分散しようとします。 ただし、チャネルがガベージで詰まった場合、このメッセージを独自のクラウドに配信できるという保証はありません。 また、データストリームの切り替えには時間がかかります。
したがって、クライアントがサービス拒否攻撃から自分のインフラストラクチャを保護するためにお金に加えて支払うことができる唯一の実際の価格は、遅延だけであり、それ以外は何もありません。 しかし、すでに述べたように、適切に構築されたクラウドは遅延を減らし、リクエストされたリソースのグローバルな可用性を改善します。
鉄の箱とろ過の雲の間で選択するとき、これを覚えておいてください。