WAFだけで守れるのか？AWS ALBのHTTPフラッド初動対応から学ぶ


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（アプリケーション層）<br>※TCPやUDPではなく、HTTP/HTTPSを使う |
| **使用プロトコル** | HTTP GET や POST（フォーム送信、API呼び出しなど） |
| **主な狙い** | サーバーの処理能力を奪う（CPU/メモリ/DB接続枯渇など） |
| **見分けにくさ** | 正規のリクエストと見分けがつきにくい<br>（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 を遮断

```json
{
  "ByteMatchStatement": {
    "FieldToMatch": {
      "SingleHeader": { "Name": "user-agent" }
    },
    "SearchString": "Edge/125.0.0.0",
    "PositionalConstraint": "CONTAINS"
  }
}
```

※AWS WAF にて「カスタムルール」を作成し即時 Block。まずは Count モードで様子見→問題なければ Block モードへ移行。

---

### ✅ 2. IP単位でリクエスト頻度を制限

```json
{
  "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ごとのリクエスト件数
```sql
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アドレス単位のアクセス件数
```sql
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 の二刀流分析で原因特定 → チューニングへ！**