まず 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 の二刀流分析で原因特定 → チューニングへ！