レイヤー7 DoS:Webアプリケーションのサービス拒否攻撃



人気のあるサイトに対する分散型サービス拒否攻撃は、通常、何千ものハッキングされたデバイスから発生します。 これらの攻撃の主な目的は、大規模なトラフィックでターゲットシステムを抑制し、通信チャネルを詰まらせることです。 これらの攻撃は、レイヤー3(ISO / OSIモデルのネットワークレイヤー)DoS / DDoSに関連しており、リソースを攻撃する多数のパケットが特徴です。 レイヤー7(ISO / OSIモデルのアプリケーションレイヤー)DoS / DDoSは通常、Webアプリケーションの「弱点」を対象としています。







最初に、Incapsulaの調査からいくつかの統計を紹介します。2016年以来、アプリケーションレベルでのDoS / DDoS攻撃は、ネットワークレベルでの従来のサービス拒否攻撃よりも優先されています。







画像

このような攻撃を識別することの難しさは、Webアプリケーションが攻撃と通常のトラフィックを簡単に区別できないことです。 この困難に関与する多くの要因がありますが、最も重要なことの1つは、いくつかの理由により、IPアドレスが資格情報として有用ではない可能性があることです。 ネットワーク攻撃中に、不正なトラフィックを区別し、攻撃IPアドレスをブロックすることができます。アプリケーションレベルでの攻撃の場合、これを行うことは困難です。正当なユーザーをブロックせずに攻撃の兆候を判断する必要があります。 また、リソースの単純な使用(攻撃なし)は、リソースの枯渇につながる可能性があります-これは、多くの人に知られているHabraeffectかもしれません。







DoS / DDoS攻撃の主な種類:



ボリュメトリックボリューメトリック攻撃は、ホスティングインフラストラクチャのWebアプリケーションの帯域幅をオーバーフローさせ、大量のネットワークトラフィックを誘導することを目的としています。 通常、このようなトラフィックはUDP / ICMPフラッドで表されます。







レイヤー3:これらの攻撃は、TCPプロトコルスタックアーキテクチャの欠陥を標的としています。 攻撃者は、接続ステータス情報をオーバーフロー、歪曲、または破棄するように設計されたパケットを送信し、ターゲットデバイスのネットワーク処理機能に追加の作業を引き起こし、応答を遅くします。 このような攻撃の最も一般的なベクトルは、TCP SYNフラッド、TCPフラグメンテーション、ティアドロップなどです。







レイヤー7:これらの攻撃はWebアプリケーションのロジックに向けられており、「重い」リクエスト、集中的な処理機能、またはメモリを処理する際のWebサーバーリソースの枯渇を目的としています。







アプリケーションリソース



ほとんどのWebサーバーは、通常のリソース使用で数百の同時ユーザーを処理できます。 問題は、1人の攻撃者が1つのホストからWebアプリケーションを拒否するのに十分なトラフィックを生成できることです。 この場合のロードバランシングは、「完全に」という言葉では役に立ちません。







主な問題は次のとおりです。CPU使用率-CPUの99%を使用すると、他の重要なプロセスが停止します。 RAM-許容できないメモリ割り当て、リーク、メモリの枯渇-他の重要なプロセスの欠点。 プロセスとスレッド-デッドロック(プロセスのフリーズ)、フォーク、競合状態(競合状態); ディスク-ディスクがいっぱいです。







Webサーバーの重要なリソースの1つはRAMです。 このリソースの枯渇に対する攻撃は次の可能性があります。



再帰。 再帰的なコードの良い例を次に示します-include( 'current_file.php')。 PHPは、インクルードごとに新しいメモリを割り当て、メモリがなくなるまでプロセスを繰り返します。 この脆弱性は、従来のLFI(ローカルファイルインクルージョン)の形式で検出できます。







ジップボム。 圧縮ファイルをダウンロードしてコンテンツを抽出できるWebアプリケーションは、特にアプリケーション(または圧縮解除を処理するライブラリ)が適切なファイルチェックを実行しない場合、このような攻撃を受けやすくなります。







XML爆弾。 名前付きエンティティは、文字列だけでなく、他のエンティティのシーケンスにも展開できます。 再帰は標準では禁止されていますが、入れ子の許容される深さに制限はありません。 これにより、非常に長いテキスト文字列のコンパクトな表現が可能になり(アーカイバと同様)、10億笑い攻撃の基礎を形成します。







非現実化。 OWASP TOP 10 2017 A8-Insecure Deserializationに含まれる比較的新しいタイプの攻撃ですが、十分に深刻です。 これは、ビットシーケンスからデータ構造の初期状態を復元するプロセスです。 ユーザー入力の不適切な制御は、リソースの枯渇につながる可能性があります。







ファイルヘッダー。 ファイルヘッダーの値を操作すると、リソースが枯渇する可能性があります。 入力ファイルで計算が実行される場合、ファイルサイズはヘッダーにあります。 画像、ビデオファイル、ドキュメントなどです。 例はピクセルフラッド攻撃です。







無限のデータストリームの読み取り。 1 TBスピードテストなどを使用して、LFI経由で/ dev / zeroまたは/ dev / urandomを読み取る







Webサーバーの重要なパラメーターはCPUです。プロセッサパワーの枯渇に対する攻撃は、Webアプリケーションの動作不能につながる可能性があります。



reDOS-正規表現のサービス拒否。 Stackoverflowで比較的新しいタイプの攻撃が最初に特定されました。 これは攻撃者による攻撃ではなく、コードに20,000個の空白文字が含まれているユーザーのアクションです。 正規表現は、200.010.000ステップ(20,000 + 19,000、+ ... + 2 + 1)で20,000文字の文字列をシステムがチェックするように作成されました。 Webアプリケーションで正規表現を使用できる場合は、着信データを慎重に確認する必要があります。







SQLインジェクション。 SQLインジェクションを活用すると、特にスリープ、ベンチマークなどの機能を使用する場合、Webアプリケーションのパフォーマンスが大幅に低下する可能性があります。







フォーク爆弾。 システムのすべてのリソースを使用して、何度も繰り返されるプロセス。 最もよく知られているのは:(){:|:&};:。







リソース/機能の乱用。 攻撃者は、Webアプリケーションでリソースを集中的に使用する操作を検出し、複数のリソース枯渇要求を送信する可能性があります。 例としては、パスワードハッシュ機能の不正使用があります。







SSRF サーバー側のリクエスト偽造の脆弱性を悪用すると、攻撃者は攻撃されたWebサーバーのリソースを使い果たす可能性があります。







ディスク容量もWebサーバーの重要なパラメーターです。



大きなファイルをダウンロードします。 システムにデータを入力する最も明白な方法は、大きなファイルをサーバーにアップロードすることです。 アプリケーションが適切な制限を適用しない場合、攻撃者はWebサーバーのリソースがなくなるまでデータをシステムにロードできます。







システムログのオーバーフロー。 ログローテーション機能がない場合、攻撃者はシステムログを「詰まらせる」か、これらのログを大量に作成する触媒として機能し、ディスクスペースリソースの枯渇を招く可能性があります。







Webアプリケーションをテストするためのユーティリティ:



通常、特定のWebアプリケーションの動作を不安定にすることを目的としたLOIC / HOICなどの高度に特殊化されたユーティリティについては、意図的に検討しません。







これらのツールの悪意のある使用は禁止されており、あなたが居住している国の立法措置によって訴追される可能性があります。 これらのツールを使用して、独自のサーバー、またはテストが所有者と法的に同意されたサーバーのみをテストします。







Slowlorisは、かなり有名なテストツールです。 nmap用のnseスクリプトがあります。







HULK (HTTP Unbearable Load King)-ほとんどのWebサーバーリソースを消費する一意のリクエストの大きなストリームを生成します。 ストリームをフィルタリングするタスクを複雑にするために、各リクエストのHULKは異なるユーザーエージェントを置き換え、リファラーを難読化し、リクエストのno-cache属性とkeep-alive属性、および一意のURLを使用します。







OWASP DoS HTTP POST-「遅い」httpリクエストを生成するためのOWASPコンソーシアムのユーティリティ。







GoldenEye HTTPサービス拒否ツール-HTTPキープアライブ+ NoCacheベクターを活用します。







予防保護対策



Webアプリケーションのプロアクティブな保護のための良い方法は、Webリソースの負荷テストです。 高負荷またはピーク負荷でのシステムの応答時間を調査するために、「ストレステスト」が実行されます。このテストでは、システムで発生する負荷が通常の使用シナリオを超えます。







負荷テストの主な目標は、システムのパフォーマンスを監視するために、システムに特定の予想負荷を作成することです(たとえば、仮想ユーザーまたはそのアクションを通じて)。 これにより、Webアプリケーションのボトルネック/弱点が特定および強化され、将来アプリケーションにアクセスできなくなる可能性のあるリスクが回避されます。








All Articles