アプリケーションで阻止できない攻撃

アプリケーションでは、さまざまな HTTP ベースの攻撃を防ぐことができます (また、防ぐ必要があります)。 OWASP Top 10 は、あらゆるアプリケーション内から検出および防止可能な攻撃手法の代表的な例です。 静的および動的分析や侵入テストなどのさまざまなツールを使用することで、これらの脆弱性が本番環境に侵入しないようにすることができます。 もちろん、このようなセキュリティ テストは、ユーザーがアクセスできるようにするスイッチ (またはビット) を切り替える前の最終ステップとして残されるのではなく、CI/CD プロセスにシフトレフトされる必要があります。 

開発中に見つかった潜在的な脆弱性をすべて排除したとしても、アプリケーションは依然として危険にさらされています。 これは、一部の攻撃がアプリケーションによって検出できない（つまり、検出できない）ためです。 実際、攻撃がアプリケーションに到達する頃には、すでに手遅れになっています。

もちろん、アプリケーション層 (HTTP) DDoS 攻撃について話しています。 ご存知のとおり、これは HTTP プロトコル自体を悪用して、アプリケーションから利用可能なコンピューティングとメモリをすべて吸い上げ、正当なユーザーが使用できない状態にする吸血鬼のようなものです。

HTTP DDOS 攻撃には基本的に、高速と低速、つまりフラッドとドレインの 2 つの種類があります。

洪水攻撃

フラッディングに基づく HTTP DDoS 攻撃は、アプリが HTTP リクエストを受け入れてそれに応答することが期待されているという事実を利用します。 それが彼らのやり方みたいなものですよね？ そうなります。 そして、リクエストがどれだけ速く入ってくるかに関係なく、彼らはそうします。 たとえ数分または数秒でそのサーバーで利用可能なリソースを使い果たしてしまうような速度でリクエストが送られてきたとしても、サーバーは応答しようとします。 すべてのアプリ (実際にはすべてのデバイス、サービス、システムなど) には、それ以上開けなくなるまで開いたままにできる TCP 接続の数に上限があります。 上限に達すると、それ以降のリクエストはすべて無視されます。 ユーザーがこれを体験するのは、「接続を試行しています…」という無害なステータスで、ブラウザまたはアプリはシステムで指定された待機時間が経過するまで待機し、その後接続できないことを謝罪します。

この種の攻撃は非常に速く発生するため（「鉄砲水」の喩え）、需要を満たすためにシステムが拡張する能力を超えてしまいます。 このシナリオでは、自動スケーリングも役に立ちません。アプリの新しいインスタンスをプロビジョニングして起動するのにかかる時間は、攻撃によって既存のインスタンスからすべてのリソースが削除されるまでの時間よりも長くなるためです。

ドレイン攻撃

その逆であるドレイン攻撃では、同じタスクが実行されますが、アプリが接続を必要以上に長く開いたままにするように強制することで実行されます。 これは、ダイヤルアップ接続をしているかのように見せかけることで実現します。つまり、実際に受信できる速度ではなく、1 秒あたり数滴のデータをアプリから少しずつ送信します。 そうすることで接続が長くなるため、十分な接続数でこれを行うと、基本的にフラッディング攻撃と同じ状況、つまりリソース枯渇に陥ります。

これらの攻撃はいずれもアプリケーション内からは検出できません。 なぜそうなるのでしょうか? アプリケーションにとって、これらのリクエストはすべて正当なものであり、1 日に何千回も応答される可能性のある、整形式の HTTP ベースのデータ リクエストです。 HTTP ヘッダーまたはペイロードには、リクエストの悪質性を示すフラグはありません。 アプリケーションは、ネットワークやより広範な環境、具体的にはすべてのオープン接続のマスター リストを維持するサーバーのセッション テーブルをまったく認識できないため、これらの要求の背後にある悪意のある意図を完全に把握できません。 マルチスレッド環境でのスレッド、プロセス、データの揮発性に関する技術的な詳細や講義は省略し、「他のリクエストの処理は可視化されない」という点だけを説明します。

言うまでもなく、アプリケーション自体には、特定のリクエストがより大規模な攻撃 (フラッディング) の一部であるかどうか、またはその動作が既知の機能と一致していないかどうか (ドレイン) を判断する方法はありません。

プロキシが救助に

両方を可視化できるのは、アプリケーションの上流（前）にあるプロキシです。 これは、プロキシがおそらく負荷分散を実行しているため、現在処理中のリクエストの数と、クラスター (または必要に応じてプール) 内のアプリの 1 つに送信する必要があるため、受信するリクエストの数に注意する必要があるためです。

さらに、応答をどこに送信するかを知る必要があるため、クライアントとそのネットワーク接続について認識する必要があります (通常、クライアントの IP アドレスのみがアプリに送信され、それ以上は送信されません)。 アプリケーションとは異なり、フラッディング攻撃とドレイン攻撃の両方を検出するために必要な可視性があり、アプリのリソースに侵入する前に攻撃を阻止します。

そのため、WAF (Web アプリケーション ファイアウォール) や高度なロード バランサーなどのプロキシ ベースのサービスは、今日のアプリケーション セキュリティ戦略において重要な役割を果たします。 なぜなら、彼らには攻撃の兆候となる異常な行動を検知する可視性と手段があり、ニンニクと吸血鬼のようにそれを撃退できるからです。

そして、これらの従来の「ネットワーク」サービスは必然的にアプリケーション アーキテクチャの一部になる必要があるため、DevOps アプローチは翼を広げ、アプリのセキュリティやスケーラビリティ (負荷分散) など、そもそもアプリケーションに自然に引き寄せられるサービスをより包括的に取り込む傾向があるのは理にかなっていると思われます。

アプリケーションは、すべての攻撃、特に、アプリケーションでは実現できないレベルの可視性を必要とする攻撃を阻止することはできません。 ただし、Web アプリ セキュリティや負荷分散などのアプリケーション関連サービスと連携して動作することで、より包括的な一連の攻撃を検出して撃退し、停止や侵害を減らす手段を提供できます。