DDoS を救う: ストレス テストと負荷テストの実施方法

Variti はボットや DDoS 攻撃に対する保護を開発し、ストレスと負荷のテストも実施しています。 HighLoad++ 2018 カンファレンスでは、さまざまなタイプの攻撃からリソースを保護する方法について話し合いました。 つまり、システムの一部を分離し、クラウド サービスと CDN を使用し、定期的に更新します。 しかし、それでも専門会社なしでは保護​​を扱うことはできません:)

本文を読む前に、短い要約を読むことができます カンファレンスのウェブサイトで.
読みたくない場合、またはビデオだけを見たい場合は、レポートの記録をネタバレの下に記載します。

レポートのビデオ録画

多くの企業はすでに負荷テストの方法を知っていますが、すべての企業がストレス テストを実行しているわけではありません。 当社の顧客の中には、自社のサイトは高負荷のシステムを使用しており、攻撃から十分に保護されているため、無敵であると考えている人もいます。 これが完全に真実ではないことを示します。
もちろん、テストを実施する前に、お客様から署名と捺印のある許可を得ており、私たちの協力があれば、誰に対しても DDoS 攻撃を実行することはできません。 テストは、リソースへのトラフィックが最小限で、アクセスの問題がクライアントに影響を与えない、顧客が選択した時間に実行されます。 さらに、テストプロセス中に常に問題が発生する可能性があるため、私たちは常にお客様と連絡を取り合っています。 これにより、達成された結果を報告するだけでなく、テスト中に何かを変更することもできます。 テストが完了すると、検出された欠点を指摘し、サイトの弱点を解消するための推奨事項を記載したレポートを必ず作成します。

私たちの働き方

テスト時にはボットネットをエミュレートします。 当社のネットワーク上にないクライアントと連携しているため、制限や保護の発動によってテストが最初の XNUMX 分で終了しないようにするために、XNUMX つの IP からではなく独自のサブネットから負荷を供給しています。 さらに、かなりの負荷を発生させるために、独自のかなり強力なテスト サーバーを用意しています。

仮定

多すぎるのは良い意味ではありません
リソースに障害をもたらす負荷が少なければ少ないほど良いのです。 XNUMX 秒あたり XNUMX つのリクエスト、または XNUMX 分あたり XNUMX つのリクエストでもサイトの機能を停止できれば、それは素晴らしいことです。 なぜなら、意地悪の法則によれば、ユーザーまたは攻撃者は誤ってこの特定の脆弱性に陥る可能性があるからです。

部分的な失敗は完全な失敗よりも良い
私たちは常に、システムを異種混合にすることをお勧めします。 さらに、コンテナ化だけではなく、物理レベルでそれらを分離する価値があります。 物理的に分離した場合、サイト上で何か障害が発生しても、サイトの動作が完全に停止することはなく、ユーザーは引き続き機能の少なくとも一部にアクセスできます。

優れたアーキテクチャは持続可能性の基礎です
リソースのフォールト トレランスと攻撃や負荷に耐える能力は、設計段階、実際にはメモ帳で最初のフローチャートを描く段階で定められる必要があります。 致命的なエラーが忍び込んだ場合、将来的に修正することは可能ですが、それは非常に困難だからです。

コードが優れているだけでなく、構成も優れている必要があります
多くの人は、優れた開発チームがフォールト トレラントなサービスを保証すると考えています。 優れた開発チームは本当に必要ですが、優れた運用、優れた DevOps も必要です。 つまり、Linux とネットワークを正しく構成し、nginx で構成を正しく書き込み、制限を設定するなどの専門家が必要です。 そうしないと、リソースはテストでのみ正常に機能し、ある時点で実稼働環境ですべてが機能しなくなります。

負荷テストとストレステストの違い
負荷テストにより、システム機能の限界を特定できます。 ストレス テストは、システムの弱点を見つけることを目的としており、このシステムを破壊し、特定の部品が故障する過程でシステムがどのように動作するかを確認するために使用されます。 この場合、負荷の性質は通常、ストレス テストが開始されるまで顧客には不明のままです。

L7攻撃の特徴

通常、負荷のタイプを L7 レベルと L3&4 レベルの負荷に分類します。 L7 はアプリケーション レベルの負荷であり、ほとんどの場合 HTTP のみを意味しますが、ここでは TCP プロトコル レベルのあらゆる負荷を意味します。
L7 攻撃には特定の独特の特徴があります。 まず、それらはアプリケーションに直接送信されます。つまり、ネットワーク手段を介して反映される可能性はほとんどありません。 このような攻撃はロジックを使用するため、CPU、メモリ、ディスク、データベース、その他のリソースを非常に効率的に、少ないトラフィックで消費します。

HTTPフラッド

どのような攻撃の場合でも、負荷は処理するよりも作成する方が簡単ですが、L7 の場合も同様です。 攻撃トラフィックと正規のトラフィックを区別するのは必ずしも簡単ではありません。多くの場合、これは頻度によって判断できますが、すべてが正しく計画されている場合、どこに攻撃があり、どこに正規のリクエストがあるかをログから理解することは不可能です。
最初の例として、HTTP フラッド攻撃を考えてみましょう。 グラフは、このような攻撃が通常非常に強力であることを示しています。以下の例では、リクエストのピーク数は 600 分あたり XNUMX 万件を超えています。

HTTP フラッドは、負荷を作成する最も簡単な方法です。 通常、ApacheBench などの何らかの負荷テスト ツールを使用し、リクエストとターゲットを設定します。 このような単純なアプローチでは、サーバー キャッシュに遭遇する可能性が高くなりますが、それを回避するのは簡単です。 たとえば、リクエストにランダムな文字列を追加すると、サーバーは常に新しいページを提供するようになります。
また、ロードを作成するプロセスではユーザー エージェントについても忘れないでください。 一般的なテスト ツールのユーザー エージェントの多くはシステム管理者によってフィルタリングされており、この場合、負荷がバックエンドに到達しない可能性があります。 ブラウザからの多かれ少なかれ有効なヘッダーをリクエストに挿入することで、結果を大幅に改善できます。
HTTP フラッド攻撃は単純ですが、欠点もあります。 まず、負荷を生成するには大量の電力が必要です。 第 XNUMX に、このような攻撃は、特に XNUMX つのアドレスからのものである場合、非常に簡単に検出できます。 その結果、リクエストはシステム管理者またはプロバイダー レベルでのフィルタリングをすぐに開始します。

何を探す

効率を落とさずに XNUMX 秒あたりのリクエスト数を減らすには、少し想像力を発揮してサイトを探索する必要があります。 したがって、チャネルやサーバーだけでなく、データベースやファイル システムなどのアプリケーションの個々の部分もロードできます。 また、電卓、製品選択ページなど、サイト上で大規模な計算を行う場所を探すこともできます。 最後に、サイトには数十万行のページを生成するある種の PHP スクリプトが存在することがよくあります。 このようなスクリプトはサーバーに大きな負荷を与え、攻撃の標的になる可能性があります。

どこを見れば

テスト前にリソースをスキャンするときは、もちろん、まずサイト自体を調べます。 私たちは、あらゆる種類の入力フィールド、重いファイル、つまりリソー​​スに問題を引き起こし、その動作を遅くする可能性のあるすべてのものを探しています。 ここでは、Google Chrome と Firefox の平凡な開発ツールが役に立ち、ページの応答時間を表示します。
サブドメインもスキャンします。 たとえば、あるオンライン ストア abc.com があり、サブドメイン admin.abc.com があります。 おそらく、これは権限のある管理パネルですが、負荷をかけるとメイン リソースに問題が発生する可能性があります。
サイトにはサブドメイン api.abc.com がある場合があります。 おそらく、これはモバイル アプリケーション用のリソースです。 アプリケーションは App Store または Google Play で見つけることができ、特別なアクセス ポイントをインストールし、API を分析してテスト アカウントを登録します。 問題は、承認によって保護されているものはサービス拒否攻撃の影響を受けないと人々がよく考えていることです。 おそらく認証が最良の CAPTCHA であると思われますが、そうではありません。 10 ～ 20 個のテスト アカウントを作成するのは簡単ですが、作成することで、複雑で隠された機能にアクセスできるようになります。
当然のことながら、robots.txt や WebArchive、ViewDNS で履歴を調べ、リソースの古いバージョンを探します。 場合によっては、開発者が mail2.yandex.net などを展開したにもかかわらず、古いバージョンの mail.yandex.net が残っていることが起こります。 この mail.yandex.net はサポートされなくなり、開発リソースは割り当てられませんが、データベースを消費し続けます。 したがって、古いバージョンを使用すると、バックエンドのリソースとレイアウトの背後にあるすべてのものを効果的に使用できます。 もちろん、これは常に起こるわけではありませんが、それでもかなりの頻度でこれに遭遇します。
当然のことながら、すべてのリクエストパラメータと Cookie 構造を分析します。 たとえば、Cookie 内の JSON 配列に値をダンプし、多数のネストを作成して、リソースを不当に長時間動作させることができます。

検索負荷

サイトを調査するときに最初に思い浮かぶのは、データベースをロードすることです。これは、ほぼすべての人が検索を行うためであり、残念なことに、ほぼすべての人にとって、データベースは十分に保護されていません。 何らかの理由で、開発者は検索に十分な注意を払っていません。 ただし、ここでの推奨事項が XNUMX つあります。HTTP フラッドの場合と同様に、キャッシュが発生する可能性があるため、同じタイプのリクエストを作成しないでください。
データベースに対してランダムなクエリを実行することも、常に効果的であるとは限りません。 検索に関連するキーワードのリストを作成することをお勧めします。 オンライン ストアの例に戻ると、そのサイトでは車のタイヤが販売されており、タイヤの半径、車の種類、その他のパラメータを設定できるとします。 したがって、関連する単語を組み合わせると、データベースはさらに複雑な条件で動作するようになります。
さらに、ページネーションを使用する価値があります。検索で検索結果の最後から XNUMX 番目のページを返すことは、最初のページよりもはるかに困難です。 つまり、ページネーションを使用すると、負荷をわずかに分散できます。
以下の例は検索負荷を示しています。 XNUMX 秒あたり XNUMX リクエストの速度でテストを行った最初の XNUMX 秒から、サイトがダウンして応答しなくなったことがわかります。

検索がなかったら？

検索が行われない場合でも、サイトに他の脆弱な入力フィールドが含まれていないという意味ではありません。 このフィールドは認証である場合があります。 現在、開発者はログイン データベースをレインボー テーブル攻撃から保護するために複雑なハッシュを作成することを好みます。 これは良いことですが、このようなハッシュは大量の CPU リソースを消費します。 不正な承認が大量に発生するとプロセッサ障害が発生し、その結果、サイトが機能しなくなります。
コメントやフィードバック用のあらゆる種類のフォームがサイトに存在することは、そこに非常に大きなテキストを送信したり、単に大規模な洪水を引き起こしたりする理由になります。 サイトによっては、gzip 形式などの添付ファイルを受け入れることがあります。 この場合、1 TB のファイルを取得し、gzip を使用して数バイトまたはキロバイトに圧縮し、サイトに送信します。 その後、解凍すると、非常に興味深い効果が得られます。

残りのAPI

Rest APIなどの人気サービスに少し注目してみたいと思います。 Rest API を保護することは、通常の Web サイトよりもはるかに困難です。 パスワードのブルート フォースやその他の不正行為から保護する簡単な方法であっても、Rest API では機能しません。
Rest API はデータベースに直接アクセスするため、非常に簡単に破られてしまいます。 同時に、このようなサービスの失敗はビジネスに非常に深刻な影響をもたらします。 実際、Rest API は通常、メイン Web サイトだけでなく、モバイル アプリケーションや一部の内部ビジネス リソースにも使用されます。 そして、これがすべて失敗した場合、その影響は単純な Web サイトの障害の場合よりもはるかに大きくなります。

重いコンテンツの読み込み

複雑な機能を持たない通常の単一ページのアプリケーション、ランディング ページ、名刺 Web サイトのテストを依頼された場合、私たちは重いコンテンツを探します。 たとえば、サーバーが送信する大きな画像、バイナリ ファイル、PDF ドキュメントなど、これらすべてをダウンロードしようとします。 このようなテストはファイル システムに十分な負荷をかけ、チャネルを詰まらせるため、効果的です。 つまり、サーバーを停止させなくても、大きなファイルを低速でダウンロードすると、ターゲット サーバーのチャネルが詰まるだけで、サービス妨害が発生します。
このようなテストの例では、30 RPS の速度でサイトが応答を停止したか、500 番目のサーバー エラーが発生したことが示されています。

サーバーのセットアップを忘れないでください。 多くの場合、ある人が仮想マシンを購入し、そこに Apache をインストールし、デフォルトですべてを構成し、PHP アプリケーションをインストールした結果が以下に表示されます。

ここでは負荷がルートにかかり、わずか 10 RPS に達しました。 5分ほど待ったところ、サーバーがクラッシュしました。 確かに彼がなぜ落ちたのかは完全にはわかっていないが、単純に記憶力が強すぎて反応しなくなってしまったのではないかという推測がある。

ウェーブベース

ここ 30 ～ 40 年で、波状攻撃が非常に人気になりました。 これは、多くの組織が DDoS 保護のために特定のハードウェアを購入しており、攻撃のフィルタリングを開始するために統計を蓄積するのに一定の時間が必要であるという事実によるものです。 つまり、データを蓄積して学習するため、最初の 30 ～ 40 秒間の攻撃はフィルタリングされません。 したがって、この XNUMX ～ XNUMX 秒の間に、サイト上で非常に多くのリクエストを起動できるため、すべてのリクエストがクリアされるまでリソースが長時間横たわることになります。
以下の攻撃の場合、10 分の間隔があり、その後、攻撃の新たな変更された部分が到着しました。

つまり、防御側は学習してフィルタリングを開始しましたが、攻撃のまったく異なる新しい部分が到着し、防御側が再び学習し始めました。 実際、フィルタリングが機能しなくなり、保護が無効になり、サイトが利用できなくなります。
ウェーブ攻撃はピーク時の値が非常に高いのが特徴で、L7 の場合、3 秒あたり 4 万または XNUMX 万のリクエストに達することがあります。 LXNUMX と LXNUMX について話す場合、パケット単位でカウントすると、数百ギガビット、つまり数百 mpps のトラフィックが存在する可能性があります。
このような攻撃の問題は同期です。 この攻撃はボットネットから行われ、非常に大規模な XNUMX 回限りのスパイクを作成するには高度な同期が必要です。 そして、この調整は常にうまくいくわけではありません。出力が放物線状のピークになる場合があり、それはかなり情けないものに見えます。

HTTP だけではない

L7 での HTTP に加えて、私たちは他のプロトコルも活用したいと考えています。 一般に、通常の Web サイト、特に通常のホスティングでは、メール プロトコルと MySQL が突出しています。 メール プロトコルはデータベースよりも負荷が低いですが、非常に効率的に負荷がかかり、サーバー上の CPU が過負荷になる可能性もあります。
私たちは 2016 年の SSH 脆弱性を利用してかなり成功しました。 現在、この脆弱性はほぼすべての人に対して修正されていますが、SSH に負荷を送信できないという意味ではありません。 できる。 単純に膨大な承認の負荷があり、SSH がサーバー上の CPU をほぼすべて消費し、XNUMX 秒あたり XNUMX つまたは XNUMX つのリクエストで Web サイトが崩壊します。 したがって、ログに基づくこれら XNUMX つまたは XNUMX つのリクエストは、正当な負荷と区別できません。
サーバー内で開いた多くの接続も関連性を維持します。 以前は、Apache がこの問題を抱えていましたが、現在は nginx がデフォルトで設定されていることが多いため、実際にはこの問題を抱えています。 nginx が開いたままにできる接続の数は制限されているため、この数の接続を開くと、nginx は新しい接続を受け入れなくなり、その結果サイトが機能しなくなります。
私たちのテスト クラスターには、SSL ハンドシェイクを攻撃するのに十分な CPU があります。 原則として、実践が示すように、ボットネットもこれを行うことを好むことがあります。 一方で、Google の検索結果、ランキング、セキュリティのために SSL なしではやっていけないことは明らかです。 一方、SSL には残念ながら CPU の問題があります。

L3&4

L3 および 4 レベルでの攻撃について話すときは、通常、リンク レベルでの攻撃について話します。 このような負荷は、SYN フラッド攻撃でない限り、ほとんどの場合、正規の負荷と区別できます。 セキュリティ ツールに対する SYN フラッド攻撃の問題は、攻撃量が大きいことです。 L3&4 の最大値は 1,5 ～ 2 Tbit/s でした。 この種のトラフィックは、Oracle や Google などの大企業でも処理が非常に困難です。
SYN および SYN-ACK は、接続を確立するときに使用されるパケットです。 したがって、SYN フラッドを正当なロードと区別するのは困難です。これが接続を確立するために来た SYN なのか、それともフラッドの一部なのかは明らかではありません。

UDP フラッド

通常、攻撃者は私たちのような能力を持っていないため、攻撃を組織化するために増幅が使用される可能性があります。 つまり、攻撃者はインターネットをスキャンし、脆弱なサーバーまたは不適切に構成されたサーバー (たとえば、XNUMX つの SYN パケットに応答して XNUMX つの SYN-ACK で応答するサーバー) を見つけます。 ターゲット サーバーのアドレスから送信元アドレスをスプーフィングすることで、XNUMX つのパケットで電力をたとえば XNUMX 倍に増加させ、トラフィックを被害者にリダイレクトすることができます。

増幅の問題は、検出が難しいことです。 最近の例には、脆弱な memcached のセンセーショナルなケースが含まれます。 さらに、現在では多くの IoT デバイスや IP カメラが存在しますが、これらもほとんどがデフォルトで設定されており、デフォルトでは正しく設定されていないため、攻撃者はそのようなデバイスを介して攻撃を行うことがほとんどです。

困難な SYN フラッド

開発者の観点から見ると、SYN フラッドはおそらく最も興味深いタイプの攻撃です。 問題は、システム管理者が保護のために IP ブロックを使用することが多いことです。 さらに、IP ブロックは、スクリプトを使用して行動するシステム管理者だけでなく、残念ながら、高額な費用をかけて購入した一部のセキュリティ システムにも影響を及ぼします。
攻撃者が IP アドレスを置き換えると、企業は自社のサブネットをブロックしてしまうため、この方法は大惨事になる可能性があります。 ファイアウォールが独自のクラスターをブロックすると、出力は外部との対話に失敗し、リソースに障害が発生します。
さらに、自分のネットワークをブロックすることは難しくありません。 クライアントのオフィスに Wi-Fi ネットワークがある場合、またはさまざまな監視システムを使用してリソースのパフォーマンスを測定する場合、この監視システムまたはクライアントのオフィスの Wi-Fi の IP アドレスを取得し、それをソースとして使用します。 最終的に、リソースは利用可能であるように見えますが、ターゲット IP アドレスはブロックされます。 したがって、会社の新製品が発表される HighLoad カンファレンスの Wi-Fi ネットワークがブロックされる可能性があり、これには一定のビジネス上および経済的コストがかかります。
テスト中は、許可された IP アドレスにのみトラフィックを送信するという取り決めがあるため、外部リソースで memcached を介した増幅を使用することはできません。 したがって、システムが XNUMX つの SYN の送信に XNUMX つまたは XNUMX つの SYN-ACK で応答する場合、SYN と SYN-ACK による増幅を使用し、出力では攻撃が XNUMX または XNUMX 倍になります。

ツール

L7 ワークロードに使用する主なツールの XNUMX つは Yandex-tank です。 特に、ファントムは銃として使用され、さらにカートリッジを生成し、結果を分析するためのスクリプトがいくつかあります。
Tcpdump はネットワーク トラフィックの分析に使用され、Nmap はサーバーの分析に使用されます。 L3&4 レベルで負荷を作成するには、OpenSSL と DPDK ライブラリを使用した独自の魔法が少し使用されます。 DPDK は、Linux スタックをバイパスしてネットワーク インターフェイスを操作できるようにする Intel のライブラリで、これにより効率が向上します。 当然のことながら、DPDK は L3 および 4 レベルだけでなく、L7 レベルでも使用されます。これは、XNUMX 台のマシンから XNUMX 秒あたり数百万リクエストの範囲内で非常に高い負荷フローを作成できるためです。
また、特定のトラフィック ジェネレーターや、特定のテスト用に作成した特別なツールも使用します。 SSH での脆弱性を思い出すと、上記のセットを悪用することはできません。 メール プロトコルを攻撃する場合は、メール ユーティリティを使用するか、単にその上にスクリプトを作成します。

所見

結論として私は次のように言いたいと思います。

• 従来の負荷テストに加えて、ストレス テストを実施する必要があります。 パートナーの下請け業者が負荷テストのみを実行した実際の例があります。 これは、リソースが通常の負荷に耐えられることを示しています。 しかしその後、異常な負荷が発生し、サイト訪問者がリソースを少し異なる方法で使用し始め、その結果、下請け業者が倒産しました。 したがって、すでに DDoS 攻撃から保護されている場合でも、脆弱性を探す価値があります。
• システムの一部を他の部分から分離する必要があります。 検索がある場合は、それを別のマシン (Docker にさえ移動する必要はありません) に移動する必要があります。 なぜなら、検索や承認が失敗しても、少なくとも何かは引き続き機能するからです。 オンライン ストアの場合、ユーザーは引き続きカタログで製品を検索し、アグリゲーターからアクセスし、すでに承認されている場合は購入するか、OAuth2 経由で承認します。
• あらゆる種類のクラウド サービスを無視しないでください。
• CDN は、ネットワーク遅延を最適化するためだけでなく、チャネルの枯渇や静的トラフィ​​ックへの単純なフラッディングに対する攻撃から保護する手段としても使用します。
• 専門の保護サービスを利用する必要があります。 十分なチャネルがない可能性が高いため、チャネル レベルで L3&4 攻撃から身を守ることはできません。 また、L7 攻撃は非常に大規模になる可能性があるため、撃退する可能性はほとんどありません。 さらに、小規模な攻撃の探索は依然として特別なサービス、特別なアルゴリズムの特権です。
• 定期的に更新してください。 これはカーネルだけでなく、SSH デーモンにも当てはまります (特に、SSH デーモンを外部に開いている場合)。 特定の脆弱性を自分で追跡できる可能性は低いため、原則としてすべてを更新する必要があります。

出所： habr.com