NGINX App Protect Denial of ServiceでアプリケーションレベルのDoS攻撃をブロック

NGINX | 2021年7月06日

デジタルトランスフォーメーションによってビジネスの可能性が広がる一方、残念ながら脅威領域も拡大しています。セキュリティチームが対象範囲と責任の拡大への対応に追われるなか、攻撃者はその隙を突き、金銭的利益を得るためにアプリケーションを悪用する手口をかつてないほど巧妙化させています。従来のネットワークレベルのサービス拒否（DoS）攻撃と比べ、アプリケーションレベル（Layer 7）のDoS攻撃が急増しています。その主な理由は、最新のアプリケーションアーキテクチャを想定して設計されていない従来型の防御を回避できるためです。

攻撃者にとって、Layer 7 DoS攻撃には2つの有利な特徴があります。ごくわずかなリソースで大きな混乱を引き起こせることと、検知が難しいことです。高度なツールと精密に標的を絞ったリクエストを用いることで、アプリケーションサーバーやAPIが正規のリクエストを処理できない状態に陥ります。サーバーが処理能力を超える大量のリクエストを受けると、正規のリクエストが破棄され、応答しなくなり、場合によってはクラッシュすることもあります。

従来のDoS緩和ソリューションは、モダンアプリには効果的ではありません。静的なルールベースのセキュリティを提供するため、モダンアプリを取り巻く環境の変化やアップデートの速さに対応するには、継続的なメンテナンスが必要です。

NGINX App Protect DoSのご紹介

NGINX App Protect Denial of Service (DoS)は、極めて高度なアプリケーションDoS攻撃から最新のアプリケーションを保護するために設計された、NGINX Plus向けの新しい軽量ダイナミックモジュールです。NGINX App Protect DoSは、アプリケーションの中断や損害を意図した攻撃を緩和し、継続的なパフォーマンスと収益確保を支えるとともに、競争の激しいデジタル環境における顧客ロイヤルティとブランドの維持に貢献します。

NGINX App Protect DoSは、Kubernetesクラスターを含むあらゆるプラットフォーム、アーキテクチャ、環境で、アプリケーションやマイクロサービスの近くに導入できます。アプリケーションとともにスケールアウトし、常に高いセキュリティ効果を維持します。

NGINX App Protect DoSの実際の動作

導入ユースケース

アプリケーションサービスを保護するため、NGINX App Protect DoSはさまざまな場所に導入できます。

エッジ – 外部ロードバランサーおよびプロキシ
Ingress Controller – Kubernetesへのエントリーポイント
サービス単位のプロキシ – 内部サービスプロキシ層
Pod単位のプロキシ – Podに組み込まれたプロキシ
APIゲートウェイ – マイクロサービスへのエントリーポイント

緩和対象の攻撃タイプ

NGINX App Protect DoSは、複数の高度な攻撃タイプに対する保護を提供します：

GETおよびPOSTフラッド攻撃 –（HTTPとHTTPSの両方）攻撃者は大量のリクエストを送信してサーバーまたはAPIを過負荷状態にし、正規ユーザーに応答できなくなるよう試みます。
「低速」攻撃 –（HTTPとHTTPSの両方）「Slow-and-low」攻撃はサーバーリソースを占有し、実際のユーザーからのリクエストを処理できない状態にします。低速攻撃には、主に次の3つのタイプがあります。
- ネットワークDDoS攻撃とは異なり、広帯域を使用しないため、通常のトラフィックとの区別が困難です。
- 攻撃の開始に多くのリソースを必要としないため、高度な自動化ツールを使用すれば、1台のコンピューターから数千件のリクエストを送信できます。
- Slowloris – 攻撃者はサーバーに接続し、不完全なリクエストヘッダーを低速で送信します。サーバーは残りのヘッダーを待つ間、接続を開いたままにするため、実際のユーザーが利用できる接続プールが枯渇します。
- Slow read – 攻撃者は正しい形式のHTTPリクエストを送信した後、レスポンスを極端に低速で読み取るか、まったく読み取りません。これによりサーバーリソースが徐々に消費され、正当なリクエストが処理されなくなります。
- 低速POST – 攻撃者は、後続するメッセージ本文のサイズを正しく指定した正規のHTTP POSTヘッダーをサーバーに送信します。その後、メッセージ本文を非常に低速で送信します。メッセージが有効に見えるため、サーバーは本文全体の到着を待って接続を開いたままにします。低速POST攻撃が大量に行われると、実際のユーザーが利用できる接続プールが枯渇します。
前述の攻撃の分散型 – 複数のコンピューターを動員すれば、より多くの攻撃を同時に仕掛けることが容易になります。さらに、各コンピューターからのトラフィック量を比較的少なく抑え、通常のユーザーによる通信に見せかけることもできます。また、コンピューターが攻撃元のプールから離脱した後に再参加することで、送信元IPアドレスの集合が絶えず変動します。こうしたトラフィック特性により、レート制限やジオブロッキングなどの従来の緩和手法は効果が低下します。
Challenge Collapsar攻撃／ランダムURI – Challenge Collapsar（CC）攻撃では、攻撃者は、複雑で時間のかかるアルゴリズムやデータベース処理の実行を必要とするURIへのリクエストを高頻度で送信し、標的サーバーのリソースを枯渇させる可能性があります。それ以外の点では、これらは通常のリクエストです。また、攻撃者はURIやその他のHTTPパラメーターをランダム化し、静的ルールなどの従来型の緩和ツールを回避することもできます。一方、NGINX App Protect DoSは高度な機械学習アルゴリズムを活用し、有効性を大幅に高めるとともに、誤検知を低減します。

NATの背後に隠れる – 攻撃者は、暗号化またはネットワークアドレス変換（NAT）を利用して検知を回避します。送信元IPアドレスだけを追跡して攻撃を検知しようとしても、攻撃しているユーザーが1人だけであっても、NATを利用するすべてのユーザーを攻撃者として扱うため、効果的ではありません。NGINX App Protect DoSは、IPv4のフィンガープリントを使用して、NATの背後にいる悪意のある攻撃者を正確に検知します。ほとんどのトラフィックはSSL/TLSで暗号化されているため、攻撃者を識別するキーをIPアドレスだけでなく、IPアドレスとTLSフィンガープリントの組み合わせに拡張できます（フィンガープリントはTLS Helloメッセージに基づきます）。
標的型SSL/TLS攻撃 – 攻撃者はSSL/TLSハンドシェイクプロトコルを悪用します。一般的な手法の1つは、標的のSSL/TLSサーバーに無意味なデータを送信することです。無効なメッセージの処理には、正当なメッセージと同程度の計算リソースが必要ですが、有用な結果は得られません。ほとんどのファイアウォールは、有効なSSL/TLSハンドシェイクパケットと無効なパケットを区別できず、ファイアウォールに復号機能を実装するには多大なコストがかかるため、このような攻撃への対策には役立ちません。NGINX App Protect DoSは、暗号化されずSSL/TLSハンドシェイクプロセスの初期段階で送信されるCLIENT HELLOメッセージに基づき、SSL/TLSシグネチャメカニズムを使用して異常ベースの検知と緩和を行うため、復号に伴う高いコストを回避できます。さらに、SSL/TLSシグネチャとサーバーの健全性監視メカニズムを併用することで、SSL/TLS終端を行わずにDoS攻撃を防御、緩和できます。

まとめ

DoS攻撃では、ネットワークではなくアプリケーションを標的とするケースが増えています。こうしたレイヤー7 DoS攻撃の多くは正規のトラフィックに見えるため、従来のWAF防御では効果的に検知できません。

さらに、攻撃者は機械学習やAIなどの新しいテクノロジーを利用してLayer 7 DoS攻撃を仕掛け続けており、単純なルールや静的シグネチャの有効性は低下しています。Layer 7 DoSの緩和策も進化する必要があります。NGINX App Protect DoSは、適応型かつ動的な防御により、これに適したテクノロジーを提供します。

DoS対策を確実に実施する方法について詳しくは、ソリューション概要をご覧ください。以下の関連記事も併せてご覧ください。

NGINX App Protect DoSをぜひお試しください。今すぐ30日間の無料トライアルを開始するか、ユースケースについてご相談ください。