役立つDDoS：ストレスおよびストレステストの実施方法

Varitiは、ボットおよびDDoS攻撃に対する保護を開発し、ストレスおよび負荷テストも実施します。 HighLoad ++ 2018カンファレンスで、さまざまな種類の攻撃からリソースを保護する方法について話しました。 つまり、システムの一部を分離し、クラウドサービスとCDNを使用して定期的に更新します。 しかし、専門企業がなければ、あなたはまだできない保護:)



テキストを読む前に、会議のウェブサイトで短い要約に慣れることができます。

また、動画を読みたくない場合や動画を視聴したい場合は、レポートの記録はネタバレの下にあります。





多くの企業はすでにストレステストを行う方法を知っていますが、誰もがストレステストを行うわけではありません。 一部のお客様は、高負荷システムを備えており、攻撃からシステムを保護しているため、サイトに脆弱性がないと考えています。 これは完全に真実ではないことを示しています。



もちろん、テストを実施する前に、お客様から許可を取得し、署名とスタンプを押しますが、私たちの助けを借りてだれにもDDoS攻撃を仕掛けることはできません。 テストは、お客様が選択した時間に実行されます。この場合、リソースへの出席は最小限であり、アクセスの問題はお客様に影響しません。 さらに、テストプロセス中に何かが常に失敗する可能性があるため、お客様と常に連絡を取り合っています。 これにより、達成された結果をレポートできるだけでなく、テスト中に何かを変更することもできます。 テストの最後に、発見された欠陥を指摘し、サイトの弱点を排除するための推奨事項を示すレポートを常に作成します。

どうやって働くの

テスト中に、ボットネットをエミュレートします。 ネットワークに配置されていないクライアントと連携し、制限または保護のトリガーによりテストが最初の1分間で終了しないように、1つのIPではなく、独自のサブネットから負荷を読み込みます。 さらに、大きな負荷をかけるために、独自の強力なテストサーバーがあります。

仮定

多くは良くない



リソースに障害が発生する可能性があるほど、負荷が少ないほど効果的です。 1秒間に1つのリクエストから、または1分に1つのリクエストからでもサイトが機能しなくなるようにできれば、それで問題ありません。 卑劣な法則によると、ユーザーまたは攻撃者が誤ってこの脆弱性に陥るからです。

部分的な障害は完全な障害よりも優れています



システムを異種にすることを常にお勧めします。 さらに、コンテナ化だけでなく、物理レベルでそれらを分離する価値があります。 物理的な分離の場合、サイトで何かが失敗しても、完全に機能しなくなることはほとんどなく、ユーザーは機能の少なくとも一部にアクセスできます。

適切なアーキテクチャは持続可能性の基盤です



リソースのフォールトトレランスと攻撃や負荷に耐える能力は、設計段階、実際にはノートブックに最初のブロック図を描く段階で設定する必要があります。 致命的なエラーが忍び込んだ場合、将来修正することができますが、それは非常に難しいからです。

コードが良いだけでなく、設定も必要です



多くの人々は、優れた開発チームがサービスの耐障害性を保証すると考えています。 優れた開発チームが本当に必要ですが、優れた運用、優れたDevOpsも必要です。 つまり、Linuxとネットワークを正しく構成し、nginxで構成を正しく記述し、制限を構成するなどの専門家が必要です。 そうしないと、リソースはテストでのみ正常に機能し、本番環境ではある時点ですべてが機能しなくなります。

ストレステストとストレステストの違い



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

L7攻撃の特徴的な機能

通常、L7とL3＆4のレベルの負荷に分割する負荷の種類。 L7はアプリケーションレベルの負荷であり、ほとんどの場合、HTTPとしてのみ理解されますが、TCPプロトコルレベルの負荷を意味します。



L7攻撃には特定の特徴があります。 まず、アプリケーションに直接アクセスします。つまり、ネットワーク手段によって反映される可能性は低いです。 このような攻撃はロジックを使用するため、CPU、メモリ、ディスク、データベース、その他のリソースを非常に効率的に消費し、トラフィックはほとんどありません。

HTTPフラッド

攻撃の場合、負荷は処理するよりも作成が容易であり、L7の場合も同様です。 攻撃トラフィックを正当なものと区別することは必ずしも容易ではなく、ほとんどの場合、頻度によって行うことができますが、すべてが正しく計画されている場合、攻撃がどこにあり、正当な要求がログによってどこにあるかを理解することは不可能です。



最初の例として、HTTP Flood攻撃を検討します。 グラフは、通常、このような攻撃は非常に強力であり、以下の例では、要求のピーク数が1分あたり60万を超えていることを示しています。







HTTP Floodは、負荷を作成する最も簡単な方法です。 通常、ApacheBenchなど、何らかの種類の負荷テストツールが使用され、リクエストと目的が設定されます。 このような単純なアプローチでは、サーバーキャッシングが発生する可能性がありますが、簡単に回避できます。 たとえば、リクエストにランダムな行を追加すると、サーバーは常に新しいページを常に表示します。

また、負荷を作成するプロセスでuser-agentを忘れないでください。 一般的なテストツールの多くのユーザーエージェントは、システム管理者によってフィルター処理されます。この場合、負荷が単にバックエンドに到達しない可能性があります。 多かれ少なかれ有効なヘッダーをブラウザーからリクエストに挿入することで、結果を大幅に改善できます。

HTTP Flood攻撃には、そのすべての単純さに対して欠点があります。 まず、負荷を作成するには大きな容量が必要です。 第二に、このような攻撃は、特に同じアドレスからの攻撃の場合、非常に簡単に検出できます。 その結果、システム管理者またはプロバイダーレベルのいずれかで、リクエストのフィルタリングがすぐに開始されます。

何を探す

1秒あたりのリクエスト数を減らしても効率が損なわれないようにするには、少し想像力を発揮してサイトを探索する必要があります。 そのため、チャネルまたはサーバーだけでなく、アプリケーションの個々の部分（データベースやファイルシステムなど）も読み込むことができます。 計算機、製品選択ページなど、すばらしい計算を行うサイト上の場所を検索することもできます。 最後に、サイトには、数十万行のページを生成する特定の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構造を分析します。 たとえば、JSON配列内のCookie内に値を入力し、大きなネストを作成して、リソースを不当に長く動作させることができます。

検索負荷

ほとんどすべての人が検索を行っており、残念ながらほとんどの人が検索を行っているため、サイトを調査するときに最初に頭に浮かぶのはデータベースをロードすることです。 何らかの理由で、開発者は検索に十分な注意を払っていません。 ただし、推奨事項が1つあります。HTTPフラッドの場合のように、キャッシュが発生する可能性があるため、同じタイプの要求を行わないでください。



データベースにランダムなクエリを作成することも、常に効率的ではありません。 検索に関連するキーワードのリストを作成することをお勧めします。 オンラインストアの例に戻ると、サイトで車のタイヤを販売しており、タイヤの半径、車のタイプ、その他のパラメーターを設定できるとします。 したがって、関連する単語の組み合わせにより、データベースはより複雑な条件で動作します。



さらに、ページネーションを使用する価値があります。SERPの最後から2番目のページを検索するのは、最初のページよりもはるかに困難です。 つまり、ページネーションの助けを借りて、負荷を少し分散させることができます。



以下の例では、検索の負荷を示しています。 1秒あたり10リクエストの速度でのテストの最初の1秒から、サイトがダウンし、応答しなかったことがわかります。

検索がない場合

検索がない場合、これはサイトに他の脆弱な入力フィールドが含まれていないことを意味しません。 このフィールドは承認の場合があります。 現在、開発者は、レインボーテーブルの攻撃からログインデータベースを保護するために、複雑なハッシュを作成することを好みます。 これは良いことですが、そのようなハッシュは大きなCPUリソースを消費します。 誤った承認の大規模なストリームは、プロセッサの障害につながり、その結果、サイトは出力の処理を停止します。



コメントやフィードバックのためのあらゆる種類のフォームがサイトに存在することは、そこに非常に大きなテキストを送信したり、単に大規模な洪水を引き起こしたりする機会です。 サイトは、gzip形式などの添付ファイルを受け入れる場合があります。 この場合、1TBのファイルを取得し、gzipを使用して数バイトまたはキロバイトに圧縮してサイトに送信します。 その後、解凍され、非常に興味深い効果が得られます。

REST API

Rest APIなどの人気のあるサービスに少し注意を払いたいと思います。 Rest APIの保護は、通常のサイトよりもはるかに困難です。 Rest APIの場合、パスワードのクラッキングやその他の違法なアクティビティに対するささいな保護方法でさえ機能しません。



Rest APIは、データベースに直接アクセスするため、非常に簡単に壊れます。 同時に、このようなサービスの失敗は、ビジネスにとって非常に深刻な結果をもたらします。 実際、REST APIには通常、メインサイトだけでなく、モバイルアプリケーション、内部ビジネスリソースも含まれます。 そして、これらすべてが該当する場合、その効果は単純なサイトの障害の場合よりもはるかに強力です。

重いコンテンツの負荷

複雑な機能を持たない通常の1ページのアプリケーション、ランディングページ、名刺Webサイトをテストするように提案された場合、重いコンテンツを探しています。 たとえば、サーバーから提供される大きな画像、バイナリファイル、pdfドキュメントなど、すべてを出力しようとしています。 このようなテストは、ファイルシステムを適切にロードし、チャネルを詰まらせるため、効果的です。 つまり、サーバーを停止せずに、低速で大きなファイルをダウンロードした場合でも、ターゲットサーバーのチャネルが詰まるだけで、サービス拒否が発生します。

このようなテストの例は、30 RPSの速度でサイトが応答を停止したか、500サーバーエラーを生成したことを示しています。







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







ここで、負荷はルートに行き、わずか10 RPSになりました。 5分待ってからサーバーがクラッシュしました。 しかし、結局のところ、彼がなぜ落ちたのかはわかりませんが、彼は単に記憶がいっぱいで、したがって応答しなくなったという仮定があります。

ウェーブベース

過去1年か2年で、ウェーブ攻撃は非常に一般的になりました。 これは、多くの組織がDDoSからの保護のために特定のハードウェアを購入しているため、フィルタリング攻撃を開始するために一定量の統計が必要です。 つまり、データを蓄積して学習するため、最初の30〜40秒間は攻撃をフィルタリングしません。 したがって、これらの30〜40秒で、すべての要求がレイクされるまでリソースが長時間存在するように起動できます。



攻撃の場合、10分以下の間隔があり、その後、攻撃の新しい修正された部分が到着しました。







つまり、防御は訓練され、フィルタリングを開始しましたが、攻撃のまったく異なる部分が新たに到着し、防御は再び訓練を開始しました。 実際、フィルタリングは機能しなくなり、保護は無効になり、サイトにアクセスできなくなります。



ウェーブ攻撃は、ピーク時に非常に高い値を特徴とし、L7の場合、1秒あたり10万または100万のリクエストに達する可能性があります。 L3および4について話すと、パケットで数えた場合、数百ギガビットのトラフィック、またはそれに応じて数百mppsになる可能性があります。



このような攻撃の問題は同期です。 ボットネットからの攻撃であり、非常に大きな1回限りのピークを作成するには、高度な同期が必要です。 そして、この調整は常にうまくいくとは限りません。出力に放物線のピークが現れることがありますが、これはかなり哀れに見えます。

HTTPユニファイドではない

L7レベルのHTTPに加えて、他のプロトコルを悪用することが大好きです。 原則として、通常のWebサイト、特に通常のホスティングでは、メールプロトコルとMySQLが使用されています。 メールプロトコルはデータベースよりも影響が少ないですが、非常に効率的にロードでき、出力でサーバーのCPUが過負荷になる可能性があります。



2016 SSH脆弱性の助けを借りて、私たちは非常に成功しました。 現在、この脆弱性はほぼ全員に対して修正されていますが、これはSSHをロードできないという意味ではありません。 できます。 膨大な量の認証が提供されるだけで、SSHはサーバー上のCPUのほぼ全体を使い果たし、Webサイトはすでに1秒あたり1つまたは2つのリクエストで構成されています。



したがって、これらの1つまたは2つのログクエリを正当な負荷と区別することはできません。

サーバーで開く多くの接続は引き続き関連します。 以前は、Apacheが罪を犯しましたが、nginxは実際に罪を犯しました。多くの場合、デフォルトで構成されています。 nginxが開いたままにできる接続の数は限られているため、この数の接続を開くと、新しいnginx接続は受け入れられなくなり、サイトは出力で機能しなくなります。



テストクラスタには、SSLハンドシェイクを攻撃するのに十分なCPUがあります。 原則として、実践が示すように、ボットネットもこれを好むことがあります。 一方では、Googleの発行、ランキング、およびセキュリティのため、SSLなしでは実行できないことは明らかです。 一方、SSLには残念ながらCPUの問題があります。

L3および4

L3および4レベルでの攻撃について話すとき、通常はチャネルレベルでの攻撃について話します。 このような負荷は、SYNフラッド攻撃ではない場合、ほとんど常に正当な負荷と区別できます。 セキュリティツールのSYNフラッド攻撃の問題は大量に発生します。 L3＆4の最大値は1.5-2 Tb / sでした。 このようなトラフィックは、OracleやGoogleなどの大企業でも処理が非常に困難です。



SYNおよびSYN-ACKは、接続の確立に使用されるパッケージです。 したがって、SYNフラッドと正当な負荷を区別することは困難です。これがSYNであるか、接続を確立するようになったのか、フラッドの一部であるのかは明確ではありません。

UDPフラッド

通常、攻撃者は私たちが持っている能力を持っていないため、増幅を使用して攻撃を整理することができます。 つまり、攻撃者はインターネットをスキャンし、脆弱なサーバーまたは不適切に構成されたサーバーを見つけます。サーバーは、たとえば、1つのSYNパケットに応答して、3つのSYN-ACKで応答します。 ターゲットサーバーのアドレスからソースアドレスを偽造することにより、1つのパッケージを使用して容量をたとえば3倍に増やし、トラフィックを被害者にリダイレクトできます。







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

難しいSYNフラッド

SYNフラッドは、おそらく開発者の観点から見ると、すべての攻撃の中で最も興味深いビューです。 問題は、多くの場合、システム管理者が保護のためにIPブロッキングを使用することです。 さらに、IPブロッキングは、スクリプトに従って動作するシステム管理者だけでなく、残念ながら、多くのお金で購入されるセキュリティシステムにも影響を及ぼします。



攻撃者がIPアドレスを置き換えると、会社は独自のサブネットをブロックするため、このような方法は大惨事になります。 ファイアウォールが独自のクラスターをブロックすると、外部の相互作用が出力でクラッシュし、リソースが破損します。



また、独自のネットワークをブロックすることは簡単です。 クライアントのオフィスにWi-Fiネットワークがある場合、またはさまざまな監視を使用してリソースの状態を測定する場合、この監視システムまたはオフィスのWi-FiクライアントのIPアドレスを取得し、それをソースとして使用します。 出力では、リソースは利用可能であるようですが、ターゲットIPアドレスはブロックされています。 そのため、会社の新製品が発表されるHighLoad会議のWi-Fiネットワークはブロックされる可能性があり、これには特定のビジネスおよび経済的コストが伴います。



テスト中、許可されたIPアドレスにのみトラフィックを提供する契約があるため、一部の外部リソースによるmemcachedを介した増幅は使用できません。 したがって、システムが2つまたは3つのSYN-ACKで応答して1つのSYNを送信し、出力が2〜3倍になる場合、SYNおよびSYN-ACKを介した増幅を使用します。

ツール

L7レベルでの読み込みに使用する主なツールの1つは、Yandex-tankです。 特に、ファントムは銃として使用され、さらにカートリッジを生成し、結果を分析するためのいくつかのスクリプトがあります。



Tcpdumpはネットワークトラフィックの分析に使用され、Nmapはサーバーの分析に使用されます。 L3＆4レベルで負荷を作成するには、OpenSSLを使用し、DPDKライブラリで独自の魔法を少し使用します。 DPDKは、Linuxスタックをバイパスしてネットワークインターフェイスを操作できるようにするIntelのライブラリであり、これにより効率が向上します。 当然、DPDKはL3および4レベルだけでなく、L7レベルでも使用します。1台のマシンから毎秒数百万のリクエスト内で非常に高い負荷フローを作成できるためです。

また、特定のテスト用に作成した特定のトラフィックジェネレーターと特別なツールも使用します。 SSHでこの脆弱性を思い出すと、上記の設定では回避できません。 メールプロトコルを攻撃する場合、メールユーティリティを使用するか、スクリプトを作成します。

結論

その結果、私は言いたいです：

• 従来のストレステストに加えて、ストレステストも実行する必要があります。 パートナーの下請け業者が負荷テストのみを実施した実際の例があります。 リソースが標準負荷に耐えることが示されました。 しかし、その後、異常な負荷が発生し、サイト訪問者はリソースの使用方法を少し変え始め、出力時に下請け業者が決めました。 したがって、すでにDDoS攻撃から保護されている場合でも、脆弱性を探す価値があります。
• システムの一部を他の部分から分離する必要があります。 検索がある場合は、別のマシン上で、つまりドッカー内でなくても検索する必要があります。 検索または承認が失敗した場合、少なくとも何かが機能し続けるためです。 オンラインストアの場合、ユーザーは引き続きカタログで製品を検索し、アグリゲーターから切り替え、既に承認されている場合は購入するか、OAuth2を介してログインします。
• あらゆる種類のクラウドサービスを無視しないでください。
• CDNは、ネットワークの遅延を最適化するためだけでなく、チャネルの枯渇に対する攻撃の保護手段としても使用し、静的にあふれます。
• 特別なセキュリティサービスを使用する必要があります。 ほとんどの場合、十分なチャネルがないため、チャネルレベルでL3＆4攻撃から身を守ることはできません。 また、L7攻撃は非常に大きいため、L7攻撃に打ち勝つことはできません。 さらに、小さな攻撃の検索は、依然として特別なサービス、特別なアルゴリズムの特権です。
• 定期的に更新してください。 これは、カーネルだけでなく、SSHデーモンにも適用されます。特に、外部に対して開かれている場合はそうです。 原則として、すべての脆弱性を自分で追跡できる可能性は低いため、すべてを更新する必要があります。