Unsplashのui-martinが撮影した写真

F5アタックとは？意味・HTTPフラッドとの関係・見分け方・対策を解説

F5アタックは、ページの再読み込みを短時間に繰り返してWebサイトへ負荷をかける場面を指す俗称です。実際には、通常の閲覧に見えるHTTPリクエストを数多く送り、アプリやDBを重くするHTTPフラッドに近いケースがよく見られます。この記事では、意味、DoS/DDoSとの違い、見分けるときに見る点、対策の考え方を順に確認します。

• 意味：リロード連打に由来する俗称で、実際の挙動はHTTPフラッドに近いことが多い
• 見分ける点：どのURLが増えているか、重い処理に偏っていないか
• 対策の軸：エッジで止める、オリジンを守る、重い処理を軽くする

F5アタックとは何か

F5アタックは、WebサイトやWebアプリケーションへ短時間に多くのHTTPリクエストを送り、サーバーやアプリを重くしたり止めたりする行為を指す俗称です。名前は、ブラウザの再読み込みを繰り返すイメージに由来します。

定義と概要

実際の挙動は、Webアプリケーション層を狙うHTTPフラッドに近いことが多くあります。HTTPフラッドでは、正規の利用者に見えるHTTP GETやPOSTのリクエストを数多く送り、オリジンサーバー側のCPU、メモリ、スレッド、DB接続、外部API呼び出しなどを消費させます。

仕組みと特徴

1. 正規のアクセスに見えやすい：攻撃者は通常のブラウザ操作や自動化ツールを使い、一般の利用者に似たHTTPリクエストを送ります。
2. 回線よりアプリが先に苦しくなる：帯域を埋めるというより、動的に作るページ、検索、ログイン、カート投入など、重い処理を踏ませてアプリ側の資源を奪います。
3. 少ない数でも影響が出ることがある：キャッシュが効かないURLやDB依存の処理が多いと、規模が大きくなくても遅くなることがあります。
4. 手作業から自動化まで幅がある：手でリロードを続けるだけの例もあれば、スクリプト、ツール、ボットネットで自動化される例もあります。

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

どのような影響が出るか

HTTPフラッドに近い攻撃で出やすい影響は、次の通りです。

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

用語は混同されやすいため、まずは次のように分けておくと分かりやすくなります。

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

つまり、F5アタックは必ずDDoSになるとは限りません。HTTPリクエストを大量に送り、サービスを重くする現象を分かりやすく呼んだ言い方だと考えると安全です。

見分けるときに見る点

HTTPフラッド系は、普通のアクセスが増えただけに見えやすい攻撃です。まずは、どこにリクエストが集まっているかを切り分けます。

典型的な兆候

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

ログや監視で確認する点

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

ここが見えてくると、手前で止めるべきか、オリジンまで届いても重くならないようにするべきかを分けて考えやすくなります。

F5アタックの対策

対策は、エッジで止める、オリジンまで届いても耐えられるようにする、起きた後の対応を早くする、の三つに分けると考えやすくなります。

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

HTTPフラッドは正規のアクセスに見えやすいため、まずはオリジンへ届く前にさばく構成が有効です。

• CDNキャッシュを見直す：静的な配信だけでなく、可能な範囲で動的ページもキャッシュします。短いTTLでも効果が出ることがあります。
• WAFルールを使う：攻撃に使われやすいパス、パラメータ、ヘッダのパターンを制限します。
• レート制限をかける：IP単位だけでなく、セッション、トークン、APIキー、利用者ごとでも制限できると強くなります。
• ボット対策を入れる：ヘッドレスブラウザや自動化ツールを見分ける仕組みを検討します。

アプリやAPIが独自にレート制限を実装する場合は、HTTP 429（Too Many Requests）を返し、必要に応じてRetry-Afterで待つ時間を示す形がよく使われます。一方、WAFやマネージドサービスでは、403や製品側のブロック応答になることもあります。

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

1. スケールしやすい構成にする：オートスケールだけでなく、増やしたときにDBや外部APIが先に詰まらないように設計します。
2. オリジンを守る：CDNの背後に置き、オリジンへそのまま届かないように、許可IPやmTLS、トークンなどで制限します。
3. 接続数と同時に動く数の上限を決める：Webサーバー、アプリサーバー、DBごとに、抱え込み過ぎないよう上限を設けます。
4. 重い処理を分ける：検索、集計、画像の変換などは、キュー化したり非同期で動かしたりして別の経路で守ります。

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

HTTPフラッドで特に狙われやすいのは、動的で重い処理です。アプリ側を軽くできると、少ない攻撃でも落ちにくくなります。

• 高コストURLの特定と軽量化：N+1クエリ、無駄な外部API、過剰なテンプレート処理を削減します。
• アプリ内のキャッシュ、DBキャッシュ、検索の結果のキャッシュを使う：短いTTLでも連打への対策として役立つことがあります。
• 防御を段階的に強める：軽い制限から始め、必要に応じてチャレンジや一時的な遮断へ進めます。
• ボットを増やさない設計にする：重い処理の前に、認証、入力チェック、簡単な判定を置きます。
• 失敗したときの動きを決める：全部を止めるのではなく、簡単な表示だけにする、使う機能を絞る、後で再試行してもらう、といった形も検討します。

運用での対応

攻撃をゼロにはできないため、起きたときに早く収束させる運用も欠かせません。

1. 検知：アラート（RPS、P95、5xx、CPU、DB接続数）とダッシュボードを用意。
2. 切り分け：増えているURL、送信元のばらつき、キャッシュヒット率、アプリやDBのどこが詰まっているかを確認します。
3. まず行う対応：WAFやレート制限を強め、怪しいパスを守り、キャッシュを有効にし、重い機能をいったん止めます。
4. 次に行う対応：長く使う対策として、コードを軽くし、オリジンを守り、構成と監視を見直します。
5. 周知：社内向けには状況、対応、見込みを伝え、顧客向けには影響、回避策、復旧したことの連絡を出せるようにしておきます。

対策で先に決めること

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

すべてを同じ強さで守ろうとすると、UXとコストの両方が苦しくなります。まずは、攻撃されると止まりやすいURLを洗い出し、そこから優先して守ります。

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

IPを分散されると、IP単位の制限だけでは追い付きにくいことがあります。可能なら、利用者ID、APIキー、セッション、トークンなど、より実態に近い単位でも制限できるようにします。

キャッシュと機能を絞る設計を考える

攻撃時にすべての機能を守るのは難しい場合があります。重要な機能を残し、それ以外は止める、短いTTLのキャッシュで連打を吸収する、といった設計を先に決めておくと対応しやすくなります。

まとめ

F5アタックは、リロード連打に由来する俗称ですが、実際にはHTTPフラッドに近い場面が多くあります。対策では、CDNやWAFなどで手前を守ること、オリジンとアプリを重くしにくい構成にすること、起きた後の切り分けと周知を早く行えるようにすることが基本です。自社の構成では、どのURLを優先して守るか、どこで止めるか、どの機能を残すかを先に決めておくと、実装と運用の両方を進めやすくなります。