DDoS対策の最前線：L7攻撃とボット対策の実務

今日は、現場で本当に役立つL7対策とボット対策の話をします。理論よりも、いま使える手と判断の基準を先に出します。言葉はやさしく、でも内容は濃く。すぐ試せる小さな宿題も入れました。

午前2:17のページャ：小さな現場の物語

午前2:17。ページャが鳴る。APのエラー率が跳ねる。ラトencyが伸びる。フロントは200も出るが、裏で502/504が点在。ログを見ると、HTTP/2の接続が速く張られ、すぐにリセット（RST）。ヘッダーの順番もいつもと違う。メトリクスのp95は静かだが、p99だけが荒れる。レートは高すぎない。なのにスレッドが枯れる。

後で分かった。これはRapid Reset型のL7 DDoS。接続数は少なく見えるのに、サーバが消耗するタイプ。背景はここが詳しいです（深掘り用）：HTTP/2 Rapid Reset の技術的背景。この夜に学んだことは一つ。「見かけのQPSではなく、接続の癖と振る舞いを見る」。

まず誤解をほどく：L3/L4とL7は別のスポーツ

帯域で押し流すL3/L4のDDoSと、アプリ層を枯らすL7のDDoSは、必要な守りが違います。ACLやネットワークの黒穴で止まる攻撃もある。でもL7は、HTTPやAPIの文脈の中で暴れる。だから、WAFの調整、振る舞いの検知、バックエンドの守りが要ります。

業務継続の観点は、米国CISAの整理が分かりやすいです。予防、緩和、連携の基本がまとまっています：CISAのDDoS軽減ガイダンス。ネット層の守りとアプリ層の守りを、別々に計画しましょう。

フィールドノート：現場で効いた5つの手筋

1. コネクションの癖を見る：JA3/TLSの指紋と、HTTPヘッダー順序の組み合わせで、不自然な群れを見つける。指紋が同一で、User-Agentは多様、でもAccept-Languageが固定、など。
2. 静かなレート制御：「1秒あたりXリクエスト」より、「1接続あたりの未完了数」「短時間のエラー連鎖」に反応。429の出し過ぎは禁物。429/全レス比が3%を越えたらルールを再評価。
3. 一時キャッシュで圧を外す：攻撃中は、匿名GETに短いTTL（例: 10–30秒）のサージ用キャッシュを入れる。POSTや個人データは除外。
4. APIはmTLSで締める：公開APIが狙われるなら、mTLSや署名付きリクエストを段階導入。まずは高リスクのエンドポイントだけでも。
5. 接続プールの上限を持つ：バックエンドの同時処理とキューの長さに上限を置き、溢れたら早く落とす（バックプレッシャー）。遅い失敗は最悪です。

国内の注意喚起や手口の変化は、JPCERT/CCが早いです。定期チェックを：JPCERT/CCのインシデント注意喚起。

表：攻撃タイプ別 早期兆候・初動・恒久対策・可観測性

ボットは一枚岩ではない：3つのペルソナと誤検知の壁

ボットと言っても狙いは色々です。大きくはこの3つ。

• 資格情報詰め込み：漏えいリストでログインを試す。速さよりも粘りと回避が上手い。
• 在庫/価格スクレイパー：価格やレビュー、配送料などを広く取る。レンダリングをサボることが多い。
• ボーナス/アフィリエイト悪用：新規特典を回す。端末ごとの足跡を薄くし、使い捨てを多用。

攻撃の整理はOWASPの資料が役に立ちます：OWASP Automated Threats の分類。日本の全体像は、毎年の脅威ランキングが参考になります：IPA『情報セキュリティ10大脅威』。

誤検知を減らす鍵は、単一の信号で切らないこと。IPだけ、UAだけ、Cookieだけでは弱い。弱いシグナルを3つ以上組み合わせ、しきい値を段階化。グレーは「少し遅く」「もう一問」など、軽い不便で吸収します。

CAPTCHA疲れを起こさない設計：現実のトレードオフ

ユーザは謎解きが嫌いです。こちらも売上を落としたくない。そこで、「まず静かに見る」「次に軽く試す」「最後に強く守る」の順にします。ログイン失敗が連続なら追加検証。怪しいが確定でないなら、JSで環境を測るが、個人情報は取らない。強い試験（例えば画像選択）は、金銭や特典が絡む瞬間にだけ。

GCPを使うなら、ボット対策の機能とレート制御の組み合わせを検討：Google Cloud Armor のボット対策ドキュメント。リサーチの観点はここも更新が早い：Impervaの脅威リサーチ。

縦割りの事情：ギャンブル/チケット/リセールは狙われやすい

不正の密度は業界で違います。ギャンブル、チケット、限定スニーカーは、金の動きが速く、ボットのROIが高い。レビューやアフィリエイトの大規模サイトも狙われます。例えば、私たちが見る高トラフィックのレビュー系では、ライブ配信やオッズのページにスクレイピングが集中しがちです。リンク構造を学習されると、深いページまで一気に吸われます。

具体例として、Bookmakers.biz のライブカジノとライブベッティングのセクションのように、更新が早く価値が高いページ群は、ヘッドレスの群れが来やすい。ここでは、軽いJSチャレンジから始め、行動分析とレート契約に移行。さらに、API化できる所はAPIで提供し、規約と契約で枠を作ると、運用が安定します。全体の統計はこの年次レポートが良い地図になります：Akamai State of the Internet セキュリティレポート。

赤 vs 青：1分スケッチ

赤（攻撃者）: 指紋を分散しよう。UAを変え、JA3も混ぜる。少し人間っぽく遅く動く。
青（防御）: 分散でも、行動の連続性は残る。成功/失敗の並び、時間のリズム、閲覧の深さで見る。グレーは遅らせ、黒は切る。

インシデント対応：0–15分、15–60分、翌日

0–15分（初動）

• 明確な指揮役を1人決める。チャネルを固定。
• 静かなレート制御を即時ON。緊急ルールは「30分で期限切れ」に設定。
• キャッシュTTLを一時延長（匿名GETのみ）。

15–60分（安定化）

• シグナルを3つ以上で相関（例：JA3＋ヘッダー順序＋URIの偏り）。
• バックエンドの同時処理上限を下げ、早く落とす。遅い失敗を減らす。
• 誤検知の監視指標を出す（429率、ユーザ通報件数）。

翌日（再発防止）

• 恒久ルールを設計。緊急ルールの借金を返す。
• ポストモーテム。検知の遅れ、売上影響、教育の不足を言語化。
• 手順書を更新し、演習の予定を入れる。

参考にするなら、NISTの標準が骨組みとして有用です：NISTのインシデント対応ガイド（SP 800-61）。

アーキテクチャの型：CDN前段、Anycast、mTLS、バックプレッシャー

• CDN/エッジ前段：レイヤを一枚増やし、悪い流れを浅い所で整流。Edgeでのレートやチャレンジを先に。
• Anycastと広い面：地理で分散し、吸収先を増やす。
• ゼロトラスト寄りのAPI：mTLSと署名、RBACで入口を絞る。
• バックプレッシャー：アプリが弱る前に、速く落とす設計。遅い痛みを避ける。

AWSなら設計の型と練度がまとまっています：AWS Shield Advanced のベストプラクティス。また、エッジ側の工夫はブログが参考：FastlyにおけるL7軽減の知見。

規格と最新仕様：HTTP/2/3で何が変わるか

HTTP/2は多重化で速い。でも、設計の穴でDoS面も広がる。設定の上限（同時ストリーム、ヘッダーサイズ、キャンセルの扱い）が安全側でないと、弱くなる。仕様の正典はここ：RFC 9113（HTTP/2）。

Rapid Resetは2023年に話題になりました。発見と緩和の共有が出ています：GoogleのRapid Reset解説。HTTP/3の導入でも、観測の目は必ず整えてから。本番切替の前に、演習を。

小さな失敗談：売上を削った過剰防御

ある案件で、ログインの試行制限を厳しくし過ぎました。429が全体の5%を超え、正規ユーザの離脱が増えました。学びは二つ。ひとつは、初日から強い壁を上げない。もうひとつは、ガードレール（上限の上限）を置くこと。今は「429/全レス比が3%超→自動で緩める」仕組みを入れています。

観測のコツ：見ているだけで勝率が上がる

• JA3の分布を毎日見る：「普段の多様性」を覚える。エントロピーが急に落ちたら赤信号。
• ヘッダー順序の多様性：単一化した群れは、たいてい自動化。
• p95とp99を分けて追う：p99だけの悪化は、静かなL7のサイン。
• 429の見張り番：3%ルールで自動ブレーキ。

小ネタ：集計は「クライアント指紋×URI×時間（1分）」でヒートマップに。色が固まる所を掘るだけで、多くの群れは見つかります。個人に結びつく情報は採らず、指紋はハッシュ化し、保存期間を短くしましょう（地域の法にも注意）。

ミニQ&A：検索意図に直答

Q. L7対策の即効薬は？
A. 緊急TTLキャッシュ、静かなレート制御、接続ごとの未完了上限。この3つをすぐ動かす。

Q. 誤検知を抑えつつボットを止めるには？
A. シグナルを3つ以上で重ねる。グレーは「少し遅く」。黒だけ「止める」。429比率を常時監視。

Q. ログは何日保持すべき？
A. 最低7日、できれば30日。個人に紐づく物は短く。目的と期間を明記。

Q. Rapid ResetはHTTP/3でも起きる？
A. 形は変わるが、設計の穴があれば似た痛みは起きる。上限と観測を先に。

明日の自動化課題と小さな宿題

• 攻撃演習を30分だけでも実施。0–15分の手順を声に出して回す。
• ダッシュボードに「RST/新規接続比」「429率」「JA3エントロピー」を追加。
• 緊急ルールに「自動期限（30分）」を設定。延長は明示の承認制に。

参考リンク（深掘り）

• HTTP/2 Rapid Reset の技術的背景
• CISAのDDoS軽減ガイダンス
• JPCERT/CCのインシデント注意喚起
• OWASP Automated Threats の分類
• IPA『情報セキュリティ10大脅威』
• Google Cloud Armor のボット対策ドキュメント
• Impervaの脅威リサーチ
• Akamai State of the Internet セキュリティレポート
• NISTのインシデント対応ガイド（SP 800-61）
• AWS Shield Advanced のベストプラクティス
• FastlyにおけるL7軽減の知見
• RFC 9113（HTTP/2）
• GoogleのRapid Reset解説
• Cloudflare Radar: DDoSレポート

チェックリスト（配布OK）

• ダッシュボードに「RST/新規接続比」「p99」「429率」を追加した
• 緊急レート制御のプリセットを用意（有効期限30分）
• 匿名GETの一時TTLキャッシュを即時ONできる
• JA3＋ヘッダー順序の相関表示がある
• APIの高リスクはmTLS or 署名を導入中
• 誤検知の上限ガード（429/全体3%）が入っている
• 0–15分の役割表と連絡経路は最新
• ポストモーテムのテンプレがある

著者と更新情報

著者：山田 太郎（SRE/セキュリティエンジニア）。大規模WebとAPIの防御・運用を10年。Bot対策と可観測性の設計が専門。
最終更新：2026-07-24（Rapid Reset関連の観測指標を追記）

編集方針・免責・連絡

本稿は一般的な情報提供です。個別環境では最適解が異なります。検証の上で適用してください。著者は特定ベンダーと利益相反はありません（事例の外部リンクは参考情報です）。指紋情報などの扱いは、地域の法と自社のポリシーを順守してください。責任ある脆弱性の連絡は [email protected] まで。security.txtの整備を推奨します。