HTTPベースのさまざまな攻撃は、アプリケーション内で防止できます（また、防止すべきです）。OWASP Top 10は、あらゆるアプリケーション内で検出と防止が可能な攻撃手法の代表例です。静的解析や動的解析、ペネトレーションテストなど、多様なツールを活用することで、こうした脆弱性が本番環境に入り込むのを防げます。もちろん、そのためには、このようなセキュリティテストをCI/CDプロセスの早い段階にシフトレフトし、ユーザーがアクセスできるようにするスイッチ（厳密にはビット）を切り替える直前の最終工程まで先送りしないことが前提です。
開発段階で見つかった潜在的な脆弱性をすべて排除したとしても、アプリケーションには依然としてリスクが残ります。なぜなら、一部の攻撃はアプリケーションでは検知できないからです。ここで言う「できない」とは、本当に検知できないという意味です。実際、攻撃がアプリケーションに到達した時点では、すでに手遅れです。
もちろん、ここで取り上げているのはアプリケーション層（HTTP）DDoS攻撃です。HTTPプロトコル自体を悪用し、アプリケーションで利用可能なコンピューティングリソースとメモリを最後の一滴まで吸い尽くして、正規ユーザーが利用できない状態にする、いわば吸血鬼のような攻撃です。
HTTP DDoS攻撃は、基本的に2種類に分けられます。高速型と低速型、つまりフラッド型とリソース枯渇型です。
フラッド攻撃
フラッド型のHTTP DDoS攻撃は、アプリがHTTPリクエストを受け付け、それに応答することを前提としている点を悪用します。それがアプリの役割ともいえるでしょう。そのため、リクエストがどれほどの速さで届いても、アプリは応答しようとします。数分、あるいは数秒でサーバーの利用可能なリソースを枯渇させるほどの速度でリクエストが届いても同様です。どのアプリにも（実際には、あらゆるデバイス、サービス、システムなどにも）、同時に開いておけるTCP接続数に上限があり、それを超えると新たな接続を開けなくなります。この上限に達すると、それ以降のリクエストは無視されます。ユーザーのブラウザやアプリには「接続を試みています…」という一見何でもないステータスが表示され、システムで指定された待機時間が経過した後、接続できなかったことを知らせるメッセージが表示されます。
この種の攻撃は非常に急速に押し寄せるため（「鉄砲水」に例えられるのはこのためです）、需要に応じてシステムをスケールする能力を上回ることがあります。この状況では、自動スケーリングさえ役に立ちません。アプリの新しいインスタンスをプロビジョニングして起動するまでにかかる時間よりも、攻撃によって既存のインスタンスのリソースがすべて枯渇するまでの時間の方が短いためです。
ドレイン攻撃
これとは逆のドレイン攻撃も同じ目的を達成しますが、その手法は、アプリに必要以上に長く接続を維持させるというものです。ダイヤルアップ接続を装い、実際に受信可能な速度ではなく、アプリから毎秒わずかなデータしか受信しないことで実行されます。その結果、接続が長時間維持されます。十分な数の接続でこれを行うと、最終的にはフラッド攻撃とほぼ同じ状況、つまりリソースの枯渇に至ります。
これら2種類の攻撃は、いずれもアプリケーション内部からは検出できません。それも当然です。アプリケーションから見れば、これらのリクエストはすべて正当なものです。いずれも適切な形式のHTTPベースのデータリクエストであり、アプリケーションが1日に何千回も応答している可能性があります。HTTPヘッダーにもペイロードにも、リクエストの悪意を示すフラグはありません。アプリケーションからは、ネットワークやより広範な環境、特に開いているすべての接続のマスターリストを保持するサーバーのセッションテーブルを把握できないため、これらのリクエストの背後にある悪意をまったく認識できません。スレッドやプロセス、マルチスレッド環境におけるデータの揮発性についての技術的な詳細や解説は省き、ここでは「他のリクエストの処理状況を把握できない」という点にとどめます。
要するに、アプリケーション自体には、個々のリクエストがより大規模な攻撃（フラッディング）の一部であるかどうか、また、その動作が既知の処理能力と整合しているかどうか（ドレイニング）を判断する手段がありません。
プロキシが窮地を救う
この両方を実際に把握できるのは、アプリケーションの上流（前段）に配置されたプロキシです。これは、プロキシがロードバランシングを行っている可能性が高く、受信したリクエストをクラスター（プールと呼んでも構いません）内のいずれかのアプリケーションに送信する必要があるためです。そのため、現在処理中のリクエスト数と受信中のリクエスト数の両方を把握する必要があります。
さらに、レスポンスの送信先を把握する必要があるため、クライアントとそのネットワーク接続に関する情報も認識しています（通常、アプリに送信されるのはクライアントのIPアドレスのみで、それ以外の情報は送信されません）。アプリケーションとは異なり、フラッディング攻撃とドレイニング攻撃の両方を検知するために必要な可視性を備えており、こうした攻撃がアプリのリソースを吸い尽くす前に阻止できます。
そのため、WAF（Web Application Firewall）などのプロキシベースのサービスや高度なロードバランサーは、今日のアプリケーションセキュリティ戦略において重要な役割を担います。攻撃の兆候となる異常な挙動を把握して検知し、ニンニクで吸血鬼を追い払うように攻撃を退ける手段を備えているからです。
また、従来は「ネットワーク」サービスとされてきたこれらのサービスも、必然的にアプリケーションアーキテクチャの一部となるべきです。そのため、DevOpsのアプローチが対象範囲を広げ、もともとアプリケーションと密接に関わるサービスも包含するようになるのは自然な流れです。たとえば、アプリケーションセキュリティやスケーラビリティ（負荷分散）などが挙げられます。
アプリケーションだけですべての攻撃を阻止することはできません。特に、アプリケーションからは得られないレベルの可視性を必要とする攻撃には対応できません。しかし、Webアプリケーションセキュリティや負荷分散など、アプリケーションと親和性の高いサービスと連携することで、より広範な攻撃を検知して撃退し、停止や侵害を減らすことができます。
著者について
Lori MacVittieは、F5のOffice of the CTOに所属するDistinguished Engineer兼Chief Evangelistであり、アプリケーションデリバリ、自動化戦略、インフラストラクチャに関する深い専門知識を有しています。AIエージェントのガードレール策定、脆弱なマルチクラウドアーキテクチャの分析、スケーラブルなシステムの限界の検証など、複雑な事柄を明快にすることで知られています。アプリケーション開発、ITアーキテクチャ、ネットワークおよびシステム運用の分野で、30年以上にわたる業界経験を有しています。F5入社前は、受賞歴のあるテクノロジー編集者として活躍していました。 MacVittieはコンピューターサイエンスの修士号を取得しており、セキュリティ、クラウド、エンタープライズアーキテクチャにわたる分野で多数の著作を発表しています。また、テーブルトークゲームとビデオゲームをこよなく愛し、チーズについては遠慮なく強いこだわりを語ります。
Lori Mac Vittieのその他のブログ記事関連するブログ記事
F5 Application Study Tool：OpenTelemetryによるF5 BIG-IP環境の監視
F5の新しいオープンソースツールは、BIG-IP環境を詳細に可視化し、データを追跡するとともに、強力でカスタマイズ可能なインサイトを得るための基盤を提供します。
F5 BIG-IPでAI防御を実現
F5 BIG-IP Advanced WAF、BIG-IP APM、BIG-IP SSL Orchestratorが、生成AIアプリ向けに包括的なセキュリティソリューションを提供する仕組みをご覧ください。
F5 Advanced WAFによるGraphQL APIの保護
ここ数年、多くの組織がデジタルトランスフォーメーションを進めており、COVID-19のパンデミックによってその動きは加速しています。
アプリケーションサービスの現状 通信業界版：リーダーとしての台頭
通信ネットワークが進化し、さまざまな業界の幅広いユースケースに対応するなか、通信業界の回答者がテクノロジーリーダーとしての存在感を高めていることがわかります。
デジタルトランスフォーメーションは、単なるペーパーレス化ではない
デジタルトランスフォーメーションは、単なるペーパーレス化ではありません。真のモダナイゼーションにアプリケーションアーキテクチャとセキュリティの再構築が必要な理由を、F5ブログでご覧ください。
やめましょう。もう本当にやめましょう。HTTPSはHTTPより高速ではありません。
もうやめましょう。HTTPSはHTTPより高速ではありません。プロトコルのパフォーマンスに関する微妙な違いと、暗号化トラフィックを適切に最適化する方法については、F5ブログをご覧ください。