web-dev-qa-db-ja.com

SSLベースのDDoS攻撃を軽減する方法

sSLベースのDDoS攻撃の問題をご存知のように、Prolexic、Akamai、RadwareなどのDDoS軽減サービスプロバイダーは、トラフィックを解読するキーがないと、トラフィックを分析およびフィルタリングできません。

私は最近、上記の企業の従業員（A社と言います）と話しました。彼らは、自社の製品の1つを使用することであり、ネットワークにあり、その目的はssl経由でコンテンツを配信し、すべてを送信することであると述べましたプレーンテキストで防御ソリューション（同じ会社、また内部ネットワーク）にトラフィックを送ります。これにより、フィルタリングされた「良好なトラフィック」が内部Webサーバーに送られます。

他の会社はあなたにあなたのSSLキーを彼らに渡すアプローチを持っているので、彼らはあなたのトラフィックを解読して分析し、あなたのサーバーにきれいなトラフィックを渡すことができます。

A社は、後者は絶対的な問題であり、考慮すらすべきではないと述べた。問題は、クラウドソリューションのキャパシティがはるかに大きい一方で、彼らのソリューションはインフラストラクチャとアプライアンスが処理できる量のトラフィックしかフィルタリングできないことです。

したがって、問題は、SSLベースのDDoS攻撃を軽減する別の方法はありますか？SSLキーを実際に配布するのはそれほど悪いことですか？それはなぜですか？

「キーをクラウドに保存する-クラウドプロバイダーを信頼するか、自分のラップトップを信頼するか」などの質問はすでにありました。これが重複している場合は申し訳ありませんが、答えは実際には私の質問に答えていません。

tlsddoscloud-computingthreat-mitigation
5
mohrphium

誤解をいくつか解消しましょう。

  • DDoS緩和パートナーは、トラフィックを復号化できない限り機能しません

はい、できます。コンテンツが表示されないため、同様にできません。トラフィックフローで機能するソリューションは引き続き機能します。

  • キーをサードパーティに渡すことは悪いこと

必ずしも。実際、これは大抵の場合、非常に一般的です。大企業では、通常、インフラストラクチャがサードパーティによって管理されています。それがすることはあなたがあなたの技術的コントロールのいくつかを契約上のコントロールで置き換えること、そしてあなたがサードパーティに対してより大きな監督/監査責任をとることを要求することです。

第三者によるキーの誤用の脅威の軽減、またはキーを保護しないことは、評価してソリューションを提供することは簡単です。

5
Rory Alsop

SSL DDoS攻撃は2つに分割する必要があります-

  • プロトコル誤用攻撃-このような攻撃は、使用されているプロトコルを悪用し、安全な接続（この場合はSSL）の作成を完了せずにサービス拒否の影響を引き起こす可能性があります。安全なチャネルの作成を完了することはありませんが、同じ接続で繰り返し「再ネゴシエーション」を作成するために使用できるTHC-SSL-DOSが良い例です。
    上記のようなプロトコル攻撃は、キーを持っている必要はありません。 IPSシグネチャ、サーバー設定の強制、または専用のDDoSアプライアンスPravail/Riorey/DefensePro/NSFocus/etcなどの比較的単純な保護手段で緩和できます。

  • SSLトラフィックフラッド-ここでは、作成された安全なチャネルを介して渡されるデータを参照します。詳細な情報がないと、これらの素晴らしい緩和デバイスは有効な接続と悪意のある接続を区別できません。ソースの正当性を試して評価するために、ウェブチャレンジを発行することさえできません。そのため、何もないか、レート制限の保護で立ち往生している-誤ったアクションを起こしやすい。

したがって、何ができるか-一部のアプライアンスには証明書を提供するか、同じファミリー（DefensPro-Alteon/Pravail-VSS）の別のアプライアンスに接続できます-ここで姉妹製品は暗号化を開き、ddosデバイスはそれを実行しますフローの続行が許可されるか、ブロックされます。ラドウェアは、最初の暗号化されたリクエストに対してチャレンジを発行できます（それのみに対して）。 Arborは暗号化されたトラフィックを継続的に検査し、疑わしいトラフィックをブロックできます（チャレンジなし）。これらのマシンを自分の場所に置いておく限り、リスクはかなり低くなります。

一部のクラウドサービスでは、キーを提供することができます。あまり推奨されない方法です。ただし、最近公開されたProlexicでは、一時的に有効期限の短いキーを使用して同じことを実現できます。これは、保護された（暗号化された）トラフィックを処理するときに他のすべての制限と制限を考慮すると、十分なソリューションになる可能性があります。

そして最後に-あなたの鍵を提供するのは悪いことですか？非常に基本的な方法で-あなたのキーはあなたのコミュニケーションを保護するために重要です。誰かがあなたの鍵を持っている場合、彼女は理論的にあなたのコミュニケーションを「読む」か、他の人とコミュニケーションしながらあなたになりすますことができます。ただし、誰かが私の前に答えたように、さまざまな場所で鍵の共有またはコピーを練習することができます。インフラストラクチャ、ネットワークの管理者などによって異なります。何よりも、それはTRUSTに関連しています。クラウドサービスでこの「昨日生まれた」DDoS保護を信頼している場合は、頭に入れて、鍵を提供してください。信頼できる企業があり、すべての規制要件への準拠に多くの努力を払っています。 100％の保険は提供していませんが、率直に言って何も提供していません。

2
Ichilov

すべてのベンダーが同じ答えを提供します。クラウドベースのセキュリティ製品、またはネットワーク内のベンダーが提供するボックスのいずれかについて、キーをベンダーに渡す必要があります。どちらの方法でも、鍵を持っているという脅威を完全に軽減することはできません。

別の方法は、個々の攻撃によってもたらされる脅威を次の方法で軽減することです。

  • システムとアプリケーションを最新の状態に保つ：OSおよびソフトウェアの更新により、以前は深刻であった多くのddos攻撃が排除されました
  • 構成の変更：多くの場合、OSとアプリケーションを調整してはるかに回復力を高めることができます
  • SSL計算のオフロード：この領域にはいくつかのソリューションがあり、多くの場合、ロードバランサーは作業を実行できる暗号化エンジンを備えています

本当に必要なことは、脅威分析を実行（または誰かに実行）させて、最大の懸念を見つけ、その解決策を探すことです。ベンダーソリューションが最善の方法である場合もありますが、戦術的なゼロコストまたは低コストのソリューションを使用して問題なく解決できる場合もあります。

1
GdD

TCPおよびSSLハンドシェイクを監視して、実際に復号化/オフロードする前に、不正な動作を特定する方法と手段があります。

非RFC準拠のクライアント/サーバーhelloを調べ、これに基づいて「hello」フラッドのレート制限を検討します。

HTH。

1
Ed Daniel

イチロフの答えはより適切です。

脆弱でない2つのSSL攻撃

  1. プレマスターシークレットの代わりにゴミデータを送信する（SSLハンドシェイクフラッド）
  2. ハンドシェイクからマスターごとのシークレットを何度も繰り返し再ネゴシエートします

イチロフの説明で十分です

緩和：

  • クライアントパズルは、DDoS攻撃を軽減するのに役立ちます。クライアントパズルメカニズムは、プロトコル用に開発できます。これは、Proof-Of-Workシステムに基づいています。 SSLの場合、IETFドラフトは http://www.ietf.org/id/draft-nygren-tls-client-puzzles-00.txt .Client-Puzzleメカニズムはインテントベースで利用できます悪意のあるクライアントを単に排除するだけでなく、攻撃者のコストを増加させるセキュリティメカニズム。また、これらのメカニズムは、大量のルールを持つIDS/IPSシステムを使用するシグネチャベースの軽減に対してより効果的です。

  • もう1つの方法は、リソース集約型の操作であるモジュラー指数の計算を外部委託することです。部分的な計算は、デーモンシステムに外部委託できます。それ以外の場合は、暗号チップを備えたシステムを使用できます。アウトソーシングはサーバーのパフォーマンスを向上させることができますが、悪意のあるクライアントを排除するものではありません。

HTTPで動作するクライアントパズルメカニズムをすでに開発しています。また、SSLの開発を計画しました。記事が面白く感じるかもしれません。 https://blog.cloudflare.com/keyless-ssl-the-nitty-gritty-technical-details/

1
Gopi