2025年某日
突如ALBのメトリクスが異常値を記録。
- CPU使用率：96%
- ALBの有効接続数：数十万超え
- User-Agent に怪しい
Edge/125.0.0.0 - ネットワークパケット送信/受信数も爆増
「これは…HTTPフラッド（L7型DDoS）か？」
こんな状況（仮定）で即座に対応しなくてはならない内容と、再発防止のための中長期的な対策、分析手法をQiita向けにまとめました。
まず Edge/125.0.0.0 について明確にしておきます。
Edge/125.0.0.0 とは何か？
これは本来、HTTPリクエストの User-Agent ヘッダーに含まれる情報の一部です。多くの場合、ブラウザ（例: Microsoft Edge）やBotクライアントが自分を識別するために付けるものです。
ただし、Edge/125.0.0.0 は以下の特徴があります：
-
実際のブラウザでは存在しない バージョン番号（125.0.0.0）
-
正規の Microsoft Edge であれば、Edg/125.0.XXXX.XX のような形式が一般的
⇒ したがって 偽装されたUser-Agent（Botの可能性が高い）
🌊 HTTPフラッドとは？特徴と被害の実例まとめ
HTTPフラッド（HTTP Flood）は、アプリケーション層（L7）を狙ったDDoS攻撃の一種で、正規リクエストを装ってサーバーに過剰な負荷をかける手法です。
🔍 HTTPフラッドの特徴
| 項目 | 内容 |
|---|---|
| 攻撃層 | L7（アプリケーション層） ※TCPやUDPではなく、HTTP/HTTPSを使う |
| 使用プロトコル | HTTP GET や POST（フォーム送信、API呼び出しなど） |
| 主な狙い | サーバーの処理能力を奪う（CPU/メモリ/DB接続枯渇など） |
| 見分けにくさ | 正規のリクエストと見分けがつきにくい （User-Agent や Referer を偽装） |
| リクエスト例 |
/login, /api/search, /cart/checkout など負荷の高いパス |
🧨 具体的な攻撃例
- 攻撃者が 1秒間に何万件もの
GET /index.htmlを送信 - あるいは、リクエストボディ付きで大量の
POST /loginを連投
→ 結果としてアプリケーションのDB接続プールを枯渇させ、処理不能に
😨 被害例
- CPU使用率やALB接続数が急上昇（例：CloudWatchで確認）
-
ログに異常なUser-AgentやRefererが大量記録
- 例：
Edge/125.0.0.0のような実在しないバージョン名
- 例：
- 正常ユーザーのログイン失敗やタイムアウト多発
HTTPフラッドはトラフィック量ではなく「処理させる量」で攻めてくるため、検知や対策にはLayer 7（アプリ層）の理解が不可欠です。
対応には AWS WAF、レート制限、CAPTCHA、CloudFront などの多層的な防御が重要です。
🔥 目の前の応急対応（即日）
✅ 1. User-Agent で怪しい Bot を遮断
{
"ByteMatchStatement": {
"FieldToMatch": {
"SingleHeader": { "Name": "user-agent" }
},
"SearchString": "Edge/125.0.0.0",
"PositionalConstraint": "CONTAINS"
}
}
※AWS WAF にて「カスタムルール」を作成し即時 Block。まずは Count モードで様子見→問題なければ Block モードへ移行。
✅ 2. IP単位でリクエスト頻度を制限
{
"RateBasedStatement": {
"Limit": 2000,
"AggregateKeyType": "IP"
}
}
「5分間で2000回以上アクセスしたIPは即遮断」という Rate-based ルールを併用。
✅ 3. AWS マネージドルールで広範な対策もオン
| ルール名 | 効果 |
|---|---|
AWSManagedRulesCommonRuleSet |
SQLi・XSSなどOWASP系の脅威対策 |
AWSManagedRulesAmazonIpReputationList |
AWSが検知済みの悪質IPをブロック |
AWSManagedRulesBotControlRuleSet（有償） |
Bot制御（User-Agent偽装対策） |
🔍 分析と見える化（攻撃の中身を探る）
🔹 CloudWatch Logs + Athena
ALBアクセスログを S3 に出力し、Athena で調査。
例）User-Agentごとのリクエスト件数
SELECT user_agent, count(*) AS req_count
FROM alb_logs
WHERE time BETWEEN timestamp '2025-05-15 18:00:00' AND timestamp '2025-05-15 20:00:00'
GROUP BY user_agent
ORDER BY req_count DESC
LIMIT 10;
例）IPアドレス単位のアクセス件数
SELECT client_ip, count(*) AS req_count
FROM alb_logs
WHERE user_agent LIKE '%Edge/125.0.0.0%'
GROUP BY client_ip
ORDER BY req_count DESC
LIMIT 10;
🔹 CloudWatch ダッシュボードで可視化
- 有効接続数、新規接続数、ネットワーク転送量などをパネルで監視
- スパイク検出 → SNS通知も併用可能
🛡 中長期的な防御策
✅ WAF のルール整理と順序最適化
| 優先度 | 内容 |
|---|---|
| 0 | User-Agent ベースの即時遮断 |
| 1 | Rate-based ルール |
| 10〜 | AWSマネージドルール |
✅ CloudFront 前段化 + CAPTCHA
ALBに直アクセスさせず、CloudFrontを前段に設置。
→ CloudFront Functions や AWS WAF CAPTCHA を活用することで Bot 対策を強化。
✅ Shield Advanced の検討（本番環境で予算に余裕があれば）
- DDoS対策チーム（DRT）との連携
- コスト保護
- 攻撃検出と自動応答
📘 まとめ：WAFとAthenaで「守り」と「見える化」を両立しよう
ALB配下のインフラは意外と攻撃されやすく、突然のスパイクに耐えるには**「即応できる構成」と「継続的な可視化」**の両方が必要です。
以下を満たしておくと安心です：
- WAF で L7の入口をしっかり制御
- ALBログをAthenaで即時分析可能にしておく
- Rate-based制御 × マネージドルールの併用
- 様子見ルールは Count モードから導入
🛠 参考Tips
- TerraformでWAFルールを一元管理
- Slack通知連携（Lambda）
- QuickSightでダッシュボード化
📎 もし同様の事象に遭遇したら…
とりあえず CloudWatch で 「有効接続数」や「User-Agent」ログの急増が見えたら、
WAF + Athena の二刀流分析で原因特定 → チューニングへ！