IT用語集 2024/12/21

F5アタックとは？ 10分でわかりやすく解説

コラム

ウェブサイトが突然重くなったり、つながりにくくなったりする原因はさまざまですが、代表的なもののひとつが「大量のアクセスで処理能力を使い切らせる」タイプの攻撃です。いわゆるF5アタックは、その中でもページの再読み込みを短時間に繰り返して負荷をかけるイメージで語られることが多い攻撃です。この記事では、仕組み・見分け方・実務的な対策までを整理し、読了後に「自社の構成なら何から手を付けるべきか」を判断できる状態を目指します。

F5アタックとは何か

F5アタックとは、WebサイトやWebアプリケーションに対して短時間に大量のHTTPリクエストを発生させ、サーバーやネットワーク、アプリケーションの処理資源を枯渇させてサービスの応答を遅くしたり停止させたりすることを狙う攻撃の俗称です。名称は、ブラウザで再読み込み（リロード）を行うキー操作（F5キー連打）に由来します。

F5アタックの定義と概要

実態としては、Webアプリケーション層を狙うHTTPフラッド（HTTP flood）に近い挙動です。HTTPフラッドは、正規ユーザーと同じように見えるHTTP GET/POST等のリクエストを大量に送りつけ、オリジンサーバー側のCPU・メモリ・スレッド・DB接続・外部API呼び出しなどを消費させます。いわば「大量の“普通のアクセス”で処理を詰まらせる」タイプのDDoS/DoSです。

F5アタックの仕組みと特徴

リクエストが“正規っぽい”：攻撃者は通常のブラウザ操作や自動化ツールで、一般ユーザーと似たHTTPリクエストを発生させます。
狙いは「回線」より「処理」：帯域を埋め尽くす攻撃というより、動的ページ生成・検索・ログイン・カート投入など、重い処理を踏ませてアプリ側の資源を奪います。
単純でも効く場合がある：攻撃の規模が小さくても、キャッシュが効かないエンドポイントやDB依存の処理が多いと、あっさり遅くなります。
人力からボットまで幅が広い：本当に手動でリロードを繰り返すケースもあれば、スクリプト・ツール・ボットネットで自動化されるケースもあります。

また、攻撃者はIPアドレスを分散させたり、User-Agentやヘッダを変化させたり、リファラやCookieの有無を混ぜたりして、単純な遮断をすり抜けようとします。

F5アタックによる被害のイメージ

F5アタック（HTTPフラッド）で起きがちな影響は、次のように整理できます。

被害の種類	起こりやすい現象	実務上の困りごと
可用性低下	表示が遅い、タイムアウト、500系エラー増加	問い合わせ増、運用負荷増、機会損失
アプリ資源の枯渇	CPU高騰、DB接続上限、スレッド枯渇	「原因不明の障害」に見えやすい
周辺システムへの波及	決済・検索・外部APIが連鎖的に遅延	復旧しても“後処理”が残る
信頼・収益への影響	離脱増、CVR低下、ブランド毀損	金額換算しづらい損失が大きい

F5アタックとDoS/DDoSの違い

用語は混同されやすいのですが、整理すると次の通りです。

DoS：単一（または少数）の送信元からの妨害。
DDoS：多数の送信元（分散）からの妨害。
F5アタック：俗称であり、典型的には「リロード連打のような挙動でHTTPリクエストを大量発生させる」タイプを指すことが多い（DoSにもDDoSにもなり得る）。

つまり、「F5アタック＝必ずDDoS」というより、HTTPリクエストの洪水でサービスを重くする現象を、わかりやすく呼んだ言い方だと捉えるのが安全です。

F5アタックを見分けるポイント

HTTPフラッド系は「普通のアクセスが増えただけ」に見えやすいため、“どこが増えているか”を切り分けるのが実務の要です。

典型的な兆候

特定URLだけ異常に増える（例：検索、ログイン、動的ランキング、在庫照会など）
キャッシュが効かないリクエストが増える（クエリ付き、POST、認証後ページ）
ステータスコードが偏る（200が多すぎる／429が増える／5xxが増える）
レスポンスタイムの分布が崩れる（P95/P99が急伸）
アプリ・DBの指標が先に苦しくなる（CPU、DB接続、スレッド、キュー長）

ログ/監視で見るべき観点

上位のリクエストURI（どのエンドポイントが踏まれているか）
送信元の分布（IP、ASN、国、User-Agentの偏り）
同一セッション/同一ユーザーの頻度（CookieやログインID単位で見られるなら強い）
キャッシュヒット率（CDN/リバプロがある場合）

ここが見えてくると、対策を「遮断」か「緩和（重くならない設計）」かに分岐できます。

F5アタックの対策

対策は大きく、入口（エッジ）で止める、オリジンに届いても耐える、運用で素早く収束させるの3層で考えると抜けが減ります。

エッジ（CDN/WAF）での対策

HTTPフラッドは「正規っぽい」ので、まずはオリジンに届く前にさばく設計が有効です。

CDNキャッシュの最適化：静的配信だけでなく、可能な範囲で動的ページもキャッシュ（短TTLでも効果が出ます）。
WAFルール：攻撃に使われやすいパス・パラメータ・ヘッダのパターンを制限。
レート制限（Rate limiting）：IP単位だけでなく、セッション・トークン・APIキー・ユーザー単位で制限できると強力です。
ボット対策：ヘッドレスブラウザや自動化ツールを判定できる仕組み（Bot Management等）を検討。

レート制限の応答にはHTTP 429（Too Many Requests）を返し、必要に応じてRetry-Afterで待機時間を示す、といった実装が一般的です。

サーバー/インフラ側での対策

スケールアウト前提：オートスケールだけでなく、スケール時にDBや外部APIがボトルネックにならないように設計します。
オリジン保護：CDNの背後に置き、オリジンへ直接到達できないように制限（許可IP、mTLS、トークン等）。
接続・同時実行数の上限：Webサーバー、アプリサーバー、DBそれぞれで「落ち方」を設計します（無制限に抱え込まない）。
重い処理の隔離：検索、集計、画像変換などはキュー・非同期化・別系統化で守ります。

アプリケーション側での対策

HTTPフラッドで効かれやすいのは「動的で重い処理」です。根本的には、ここを守れると強いです。

高コストURLの特定と軽量化：N+1クエリ、無駄な外部API、過剰なテンプレート処理を削減します。
キャッシュ戦略：アプリ内キャッシュ、DBキャッシュ、検索結果キャッシュ（短TTLでも“連打”には効きます）。
段階的な防御：軽い制限→強い制限へ段階的に（例：レート制限→チャレンジ→一時遮断）。
ボットを増幅させない設計：重い処理の前に早期リジェクト（認証、入力チェック、簡易判定）を置く。
失敗時の挙動：落ちるより「簡易表示」「機能縮退」「後で再試行」など、サービス継続を優先する設計も検討します。

運用（インシデント対応）での対策

攻撃はゼロにはできないため、“起きたときに短時間で収束させる”運用が重要です。

検知：アラート（RPS、P95、5xx、CPU、DB接続数）とダッシュボードを用意。
切り分け：増えているURL、送信元分布、キャッシュヒット率、アプリ/DBのどこが詰まっているか。
一次対応：WAF/レート制限の強化、怪しいパスの保護、キャッシュ有効化、重い機能の一時停止。
二次対応：恒久対策（コード軽量化、オリジン保護、アーキテクチャ改善、監視の拡充）。
周知：社内向け（状況・対応・見込み）と顧客向け（影響・回避策・復旧報告）のテンプレを用意。

F5アタック対策のポイント

「守るべきURL」を先に決める

すべてを同じ強度で守ろうとすると、UXとコストが破綻しやすいです。まずは攻撃されると致命的なURL（ログイン、検索、購入導線、APIの高コスト処理）を列挙し、そこだけ防御を厚くします。

レート制限は「IPだけ」に頼らない

IP分散（プロキシ/ボット）をされると、IP単位の制限だけでは追い付かないことがあります。可能なら、ユーザーID・APIキー・セッション・トークンなど、より実態に近い単位でも制限できる設計を検討します。

キャッシュと縮退で“落ち方”を設計する

攻撃時に全部の機能を守るのは難しい場合があります。だからこそ、重要機能を残し、非重要機能を止める縮退（Graceful Degradation）や、短TTLキャッシュで“連打”を吸収する設計が効きます。

まとめ

F5アタックは、リロード連打に由来する俗称で語られることが多いものの、実態はHTTPフラッドのように大量のHTTPリクエストでアプリやサーバーの処理資源を枯渇させるタイプの攻撃として理解するのが実務的です。対策は、CDN/WAFなどエッジでの遮断・緩和、オリジン保護とスケール設計、アプリの高コスト処理の軽量化、そしてインシデント対応手順の整備を組み合わせるのが基本です。自社の構成に合わせて「どのURLを守るか」「どこで止めるか」「落ち方をどうするか」を先に決めると、実装と運用が現実的になります。