PR

memcached リフレクション（UDP増幅）攻撃の実践解説

本記事は学習用です。作成には ChatGPT と GitHub Copilot を使用しています。

1. 概要：何が起きる・なぜ重要か

memcachedリフレクション攻撃は、キャッシュサーバ「memcached」が提供するUDP（User Datagram Protocol）応答特性を悪用し、送信元IPアドレスを詐称した極めて小さな要求に対し、被害者側へ極端に大きな応答を返させるリフレクション／増幅型DDoSの一種。2018年2月末、GitHubに対するピーク 1.35 Tbps の事例（当時最大級）が観測され広く認知された。攻撃は UDP/11211（memcachedのデフォルトポート）から反射される巨大パケット群によりトランジット回線や機器を飽和させ、可用性を低下させる。(The GitHub Blog)

memcachedのUDPは認証がなく、要求に比べ極端に大きな（最大1MB級）応答が返り得る。Cloudflareは、非常に小さい要求（例：15バイト程度）に対し 100KB超〜数百KB規模の応答が返り、最大約51,200倍の増幅率が観測されるケースを報告している。(The Cloudflare Blog)

ポイント

  • 反射元：誤ってインターネットへ外部公開（露出）された memcached（UDP有効）。
  • ターゲット：送信元IPとして詐称された被害者。
  • 影響規模：Tbps級トラフィックが短時間到達する事例が確認済み。(The GitHub Blog)

2. 仕組み：リフレクションと増幅の数式・データパス

定義：

  • リフレクション：要求の送信元IPをターゲットに詐称し、応答がターゲットへ返るようにする手口。
  • 増幅率 (A)：
    \[
    A=\frac{\text{応答バイト数}}{\text{要求バイト数}}
    \]
    Memcached/UDPでは、プロトコル仕様と実装特性により \(A\gg 1\) となる。Cloudflareは 10,000倍〜51,200倍 を観測している。(The Cloudflare Blog)

データパス（Mermaidシーケンス図）:

sequenceDiagram autonumber participant Attacker as 攻撃者(送信元詐称) participant Memc as 反射元memcached(UDP/11211) participant Victim as 被害者(ターゲット) Note over Attacker: 送信元IPをVictimに詐称したUDP要求を生成 Attacker->>Memc: 小さなUDP要求 (src=Victim, dst=Memc:11211) Memc-->>Victim: 大きなUDP応答 (dst=Victim) loop 多数反射 Memc-->>Victim: 大量の巨大UDP応答 end

増幅要因

  • UDPはコネクションレスかつ未認証で送信元詐称を検出しづらい。
  • memcachedはUDP経由で大容量応答（最大1MB、分割送信）を返し得る。(The Cloudflare Blog)

3. 実例データ：過去の大規模事案

  • GitHub（2018-02-28）：1.35 Tbps / 約1.27億 pps。Akamai ProlexicへのBGP切替で数分以内に収束。(The GitHub Blog)
  • 米国事業者（2018-03-05頃）：1.7 Tbps（NETSCOUT Arborが確認）。(NETSCOUT)

国内状況（当時）

  • JPCERT/CC は 2018年2月下旬から UDP/11211 へのスキャン増加を観測し注意喚起。(JP-CERT)

4. 攻撃前提条件と検知の基本

4.1 反射元にされるサーバの条件

  • インターネットから memcached の UDP/11211 に到達可能。
  • memcached が UDP有効で起動（古いバージョンのデフォルト）。
    ※ 1.5.6以降はUDPがデフォルト無効。(GitHub)

4.2 増幅に利用される典型挙動（高レベル）

攻撃者は公開された memcached に大きな値を格納（または既存エントリ利用）し、送信元IPを被害者に詐称したUDP要求を投げる。memcachedは巨大応答を被害者へ返送。(The Cloudflare Blog)

4.3 自組織での露出チェック（安全手順）

以下は自組織資産の公開有無確認例（外部アドレスへの無断スキャンを行わない）。

sudo nmap -sU -sS -p 11211 --script memcached-info 127.0.0.1
sudo nmap -sU -sS -p 11211 --script memcached-info <管理アドレス範囲>

memcached-info NSEはUDP/TCP開放と認証有無を確認可能。(The Cloudflare Blog)

5. 対策：memcached側・ネットワーク側・事業継続

5.1 memcachedサーバ直接対策（最優先）

  1. UDP無効化（恒久策）
  • 1.5.6以降：UDPは既定無効。旧版は -U 0 を付与。
  • 例 /etc/memcached.conf:
   -U 0
   -l 127.0.0.1
   # もしくは内部プライベートアドレス
   # -l 10.0.0.10

systemd起動パラメータにも -U 0 を追加。(Memcached)

  1. アップグレード
  • 1.5.6（UDPデフォルト無効化）へ早期更新。(GitHub)
  1. 露出抑止
  • ループバック/内部アドレスのみバインド、ファイアウォールで到達源制御。(The Cloudflare Blog)

5.2 ネットワーク／OSレイヤ硬化

  • ファイアウォール/ACL：不要な UDP/11211 を遮断。
nft add rule inet filter input udp dport 11211 ip saddr { 192.0.2.0/24 } accept
nft add rule inet filter input udp dport 11211 drop
  • アンチスプーフィング（BCP 38）。(CISA)
  • レート制御・シグネチャドロップ（DDoS緩和装置）。(NETSCOUT)

5.3 事業継続（BCP）

  • Anycast + スクラビング：地理的分散洗浄。GitHubはBGPで緩和事業者へ切替。(The GitHub Blog)

6. 監視・検知・演習

6.1 露出監視

  • アタックサーフェス管理と定期ポート監査（UDP含む）。
  • 外形監視で UDP/11211 外部到達ゼロをログ化。

6.2 兆候検知

  • フローログ：src port=11211/udp が急増・多宛先化。
  • パケットキャプチャ：1,000B超〜1,400B前後のUDP応答が大量到来。(The Cloudflare Blog)

6.3 手順化・訓練

  • Runbook:
  1. BGPコミュニティ操作 / RTBH / FlowSpec
  2. DDoS緩和業者自動フェイルオーバー
  3. WAF/Anycastによるオリジン秘匿

7. 誤解と落とし穴

  • 「TCPだけ塞げば良い」→ 誤り。主眼は UDP/11211。TCPも不要なら閉鎖。(JP-CERT)
  • 「内向き構成だから旧版で安全」→ 構成変更・踏み台化で外部露出リスク。定期監査と更新必須。(JP-CERT)
  • 「装置自動防御で十分」→ 増幅はボリューム依存。回線容量と上流連携が要。(CISA)

8. 最小コスト対策手順

  1. 資産把握と UDP/11211 露出監査。
  2. memcached UDP無効化・アップグレード（-U 0 / 1.5.6+）。(Memcached)
  3. 境界フィルタ・アンチスプーフィング。(CISA)
  4. DDoS緩和切替手順（BGP・Anycast）文書化と演習。(The GitHub Blog)

A. 参考サイト

  • Cloudflare Blog: “Memcrashed – Major amplification attacks from UDP port 11211” (The Cloudflare Blog)
  • GitHub Blog: “February 28th DDoS Incident Report” (The GitHub Blog)
  • NETSCOUT Arbor: “1.7 Tbps DDoS Attack Makes History” (NETSCOUT)
  • JPCERT/CC: 「memcached のアクセス制御に関する注意喚起」 (JP-CERT)
  • CISA/US-CERT: “UDP-Based Amplification Attacks” (CISA)
  • memcached公式: 1.5.6 Release Notes / UDP DDoS (GitHub, Memcached)

B. 関連書籍

コメント