NTPリフレクション（NTP増幅型DDoS）徹底ガイド：仕組み・診断・実装対策

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

1. 導入：NTPリフレクションの定義と到達目標
2. プロトコル基礎：どこに攻撃面があるか
3. 攻撃メカニズム：数式・パケット・シーケンス
4. 実例と観測：大規模事例と国内注意喚起
5. 診断・検出：自組織が「反射器」になっていないか
6. 予防・緩和：多層防御の実装チェックリスト
7. 具体的な設定例（Linux/ntpd・ファイアウォール）
8. 運用：平常時の健全性・インシデント対応
9. まとめ：技術的要点の再確認
A. 参考サイト
B. 関連書籍

1. 導入：NTPリフレクションの定義と到達目標

NTP（Network Time Protocol） は、インターネット上でコンピュータの時刻を同期するためのプロトコルで、UDP/123 を用いる。標準仕様は RFC 5905 が定める。(RFC エディタ)
NTPリフレクション攻撃 は、攻撃者が送信元 IP を標的の IP に偽装し、小さな NTP リクエストを多数の公開 NTP サーバへ送って、増幅された応答を標的へ反射させる リフレクション型・帯域消費型 DDoS の一種である。特に過去の monlist（モニタリング） 機能の悪用が著名で、CVE-2013-5211 として公知化されている。(CISA)

到達目標は次の 3 点。

仕組みをプロトコルの事実に基づいて説明し、増幅の理屈を数式で明確化する（根拠：RFC 5905、RFC 9327、CVE/NVD）。(IETF Datatracker)
攻撃の観測事例と増幅率を具体値で把握する（根拠：Cloudflare 400 Gbps 事例など）。(The Cloudflare Blog)
診断手順と多層防御（サーバ設定・ネットワーク BCP・ACL/レート制限）の実装例を提示する（根拠：JPCERT/CC、CISA、NTP Project/NTPsec ドキュメント）。(JPCERT/CC)

※運用・設計判断が含まれるため、ISP の BCP 38 導入、uRPF 設計、マルチベンダ機器設定ではベンダ資料や ISP ポリシーの照合を推奨する。

2. プロトコル基礎：どこに攻撃面があるか

2.1 NTP の基本

標準は RFC 5905（NTPv4）。NTP は時刻同期メッセージ（クライアント/サーバ）に加え、管理・監視用のコントロールメッセージが存在する。(RFC エディタ)
Mode 6（コントロール） / Mode 7（拡張コントロール） は、ntpq/ntpdc などの管理ツールが利用する。2022 年に RFC 9327 として Mode 6 の仕様が整理された。Mode 7 は実装依存の歴史的機能で、monlist のような監視拡張が提供されてきた。(IETF Datatracker)

2.2 monlist と増幅要因

monlist は NTP サーバが最近接続した最大 600 ホストの情報を返す監視用の応答で、要求に比べ応答が大きい（＝増幅）。CVE-2013-5211 はこの挙動がトラフィック増幅に悪用される点を指摘し、NTP 4.2.7p26 以前が影響を受ける。(The Cloudflare Blog, NVD)
主に Mode 7 のパケットで運ばれ、UDP/123 でやり取りされる（コネクションレスで送信元偽装が容易）。(ncsc.gov.ie)

2.3 重要用語（定義）

リフレクション：送信元 IP を標的に偽装し、第三者（反射器）から標的へレスポンスを浴びせる攻撃手法。
増幅率（Amplification factor）：A = 応答サイズ（バイト） / 要求サイズ（バイト）と定義する。monlist の場合、事例では 200×超に達することがある。(The Cloudflare Blog)

3. 攻撃メカニズム：数式・パケット・シーケンス

3.1 数式で見る帯域消費

標的に到達する平均スループット \(T_victim\) は、攻撃元送出レート \(R_att\) と増幅率 \(A\)、利用する反射器数 \(N\) によって概算できる。
\[
T_victim ≈ R_att × A × N
\]
Cloudflare の 2014 年事例では 4,529 台の NTP サーバを用い、約 400 Gbps に達した。(The Cloudflare Blog)

3.2 パケットの流れ（Mermaid 図）

sequenceDiagram participant Attacker as 攻撃者 participant Reflector as NTPサーバ（反射器） participant Victim as 標的 Attacker->>Reflector: UDP/123 リクエスト（送信元=Victim に偽装）<br/>例：mode7 monlist Reflector-->>Victim: 大きな UDP/123 応答（増幅） loop 大量の反射 Attacker->>Reflector: 偽装リクエストを複数反射器へ送信 Reflector-->>Victim: 応答が集中し帯域を圧迫 end

3.3 典型サイズと増幅率（例）

要素	概要	参考
要求（`monlist`）	数百バイト規模（Mode 7 拡張）	Mode 7 説明/`ntpdc`（ntp.org）(NTP: Network Time Protocol)
応答（`monlist`）	リスト最大 600 件、要求の 206 倍に達する事例	Cloudflare 事例（2014-02-13）(The Cloudflare Blog)
送信元偽装	UDP の特性に起因し容易	Cloudflare 事例の解説(The Cloudflare Blog)

※厳密なバイト数は実装・リスト長で揺れる。実環境での A の上限はわからない（変動する）が、200×前後の実測報告は複数ある。(The Cloudflare Blog)

4. 実例と観測：大規模事例と国内注意喚起

Cloudflare 400 Gbps 事例（2014 年）：4,529 台のオープン NTP が悪用され、ピーク約 400 Gbps。monlist 応答の 206× 増幅が説明されている。(The Cloudflare Blog)
CISA（旧 US-CERT）警告：TA14-013A として NTP 増幅の手口と緩和策を公表。getmonlist（monlist）要求の悪用を明記。(CISA)
JPCERT/CC アラート（2014-01-15）：disable monitor の設定で monlist を無効化する回避策、影響バージョン（4.2.7p26 より前）の周知。(JPCERT/CC)
JVN（IPA/情報処理推進機構） の国内脆弱性ノートも、monlist 無効化やアクセス制御の対策を掲載。(jvn.jp)

5. 診断・検出：自組織が「反射器」になっていないか

5.1 ローカル確認

# バージョン確認
ntpq -c rv

# monlist 応答の有無（ローカル）
ntpdc -n -c monlist 127.0.0.1

time out や refused 等であれば monlist は無効化されている傾向。設定は環境差があるためわからない場合はログを確認する。ISP の案内でも disable monitor の追加と再起動が示されている。(インターリンク)

5.2 外部からの自己点検

nmap NSE の ntp-monlist スクリプトで、応答の有無をチェックできる（管理権限・同意のある範囲でのみ実施）。(Nmap)
フロー/パケット監視（NetFlow/sFlow/IPFIX）で 外向き UDP/123 のレスポンスが短時間に急増していないかをアラート化する（設計は環境依存のため、最適な閾値は専門家に確認が望ましい）。

5.3 インシデント兆候

外向き帯域の急増（UDP/123）、NTP デーモンやネットワーク機器の CPU スパイク
SOC/ISP からの abuse 通知。CISA/JPCERT/CC の過去の注意喚起も参考になる。(CISA)

6. 予防・緩和：多層防御の実装チェックリスト

6.1 NTP サーバ側（アプリケーション層）

アップグレード：4.2.7p26 以降（monlist 悪用に対応）。ディストリビューション依存のバックポートもあるため、配布元のアドバイザリを確認。(ExtraHop Docs)
disable monitor を ntp.conf に追加し monlist を無効化（レガシー ntpd を使う場合の暫定策）。(JPCERT/CC)
restrict ポリシー：noquery/nomodify/nopeer 等で外部からのコントロールクエリを拒否。Red Hat のワークアラウンド例が整理されている。(Red Hat Customer Portal)
NTPsec / chrony：近年は NTPsec（ntpd の軽量・堅牢化分岐）や chrony 採用が増えている。monitor 機能の扱いや restrict の既定が古典 ntpd と異なるため、各実装のドキュメントを参照（例：NTPsec の ntp_conf）。(docs.ntpsec.org)

6.2 ネットワーク側（L3/L4）

BCP 38（RFC 2827）：送信元アドレス偽装を遮断するイングレスフィルタリング／uRPF の導入。ISP/事業者は網全体で実装する。(IETF Datatracker)
境界 ACL：外部向けのサーバでない限り 外向き UDP/123 を遮断。公開サーバでも管理セグメントからのみコントロールクエリを許可。
レート制限：CoPP/ポリサーで UDP/123 を制限。機器ごとに設定方法が異なるため、ベンダガイドを参照。
DDoS 転送抑制：ブラックホール（RTBH）やフロー制御（BGP FlowSpec）で被害局面の迂回を用意。

6.3 外部サービス

CDN/DDoS メティゲーションの導入（L3/4 スクラビング）。Cloudflare 等が技術的解説を公開している。(Cloudflare)

7. 具体的な設定例（Linux/ntpd・ファイアウォール）

7.1 ntp.conf（レガシー ntpd）

# すべてデフォルトで厳しく
restrict default kod nomodify notrap nopeer noquery
restrict -6 default kod nomodify notrap nopeer noquery

# ループバックは許可
restrict 127.0.0.1
restrict ::1

# monlist/monitor 機能を無効化
disable monitor

# 上位の公開サーバ（例：NICT）
server ntp.nict.jp iburst

noquery と disable monitor の併用は、古い実装の安全側ワークアラウンドとして一般的に紹介されている。ディストリビューションやバージョンで既定値が異なるため、配布元のガイドに従う。(Red Hat Customer Portal)

7.2 nftables（境界での簡易制限例）

# UDP/123 は自ホストがサーバの場合のみ通す例（CIDR は適宜調整）
nft add rule inet filter input udp dport 123 ip saddr 203.0.113.0/24 accept
nft add rule inet filter input udp dport 123 drop

※機器や構成で設計が変わるため、事前の確認が必要。

7.3 監視のトリガ（参考）

SIEM/IDS で「NTP monlist 応答」を検知するルールを作るベンダ手順が公開されている（ExtraHop 例：monlist 応答監視トリガ）。(ExtraHop Docs)

8. 運用：平常時の健全性・インシデント対応

8.1 定期点検

資産棚卸し：公開 NTP の台帳、バージョン、restrict 状態、disable monitor の有無
外形監査：定期的に（許可範囲で）nmap --script ntp-monlist を自組織外から実施。(Nmap)
可観測性：NetFlow/sFlow で 外向き UDP/123 のベースラインを保存

8.2 インシデント対応の骨子

トラフィックの識別（UDP/123 の外向き異常を特定）
封じ込め（ACL/ポリサで即時レート制限、該当サーバの ntpd 一時停止）
是正（アップグレード、disable monitor、restrict の強化）
再発防止（BCP 38 評価、外形監査を CI 化）

8.3 よくある誤り

NTP サーバを不要なセグメントで起動したままにする（IPMI/ファームウェアに内蔵されている例もある）。Cloudflare は IPMI に同梱の NTP が既定で monlist 有効だった事例に言及している。(The Cloudflare Blog)
restrict limited の誤用で disable monitor が実質無効化される実装も報告があるため、構文の相互作用を確認する。(Asakasa)

9. まとめ：技術的要点の再確認

攻撃の本質は「送信元偽装＋UDP＋大応答」。NTP の歴史的監視機能 monlist は増幅器として悪用され、200×級の増幅率が現実に観測されている。(The Cloudflare Blog)
最優先対策は（a）アップグレード（4.2.7p26+ 相当）、（b）disable monitor / noquery、（c）公開要否の見直しと ACL。(JPCERT/CC)
根本的抑止はネットワーク事業者の BCP 38（RFC 2827） 実装（送信元偽装排除）。(IETF Datatracker)
平時に外形監査（nmap NSE）と可観測性を組み合わせ、設定ドリフトを早期に検出する体制を作る。(Nmap)

A. 参考サイト

RFC 5905（NTPv4 標準仕様）：NTP の基本仕様とヘッダ・アルゴリズム。(RFC エディタ)
RFC 9327（NTP 制御メッセージ/Mode 6）：管理系メッセージの現行整理。(IETF Datatracker)
CVE-2013-5211（NVD）：monlist によるトラフィック増幅の脆弱性詳細。(NVD)
Cloudflare 400 Gbps 事例：200×超の増幅、4,529 台悪用など具体値。(The Cloudflare Blog)
JPCERT/CC アラート（2014-01-15）：disable monitor 回避策、影響バージョン。(JPCERT/CC)
CISA（US-CERT）警告：getmonlist 悪用の解説と緩和策。(CISA)
BCP 38 / RFC 2827：送信元偽装対策（イングレスフィルタリング）。(IETF Datatracker)
ntp.org ドキュメント（ntpdc/Mode 7）：管理・監視クエリの性質。(NTP: Network Time Protocol)
NTPsec ntp_conf：現行実装での restrict/monitor 挙動。(docs.ntpsec.org)