「うちのNTPサーバー、インターネットからの問い合わせにも答えているみたいです」
「NTSって最近よく聞きますが、入れたほうがいいんですか？」
NTPは、標準では暗号も認証もないUDPのやり取りです。第1回で見たように、認証・証明書・ログは「時刻は正しい」という前提で動いています。つまり時刻同期は、攻撃されると、ほかの仕組みの安全性まで崩れる土台なのです。
第8回では、NTPへの攻撃と、その守り方（公開の制限、認証、NTS）を扱います。
NTPへの攻撃
- 偽の応答：送信元を偽ったNTPパケットを送り、誤った時刻を信じさせる
- 中間者（MITM）：通信路の途中で応答を書き換える
- 遅延の注入：NTPは行きと帰りの遅延が等しいと仮定して計算するので（第3回）、片方向だけを遅らせると、パケットを書き換えなくても時刻がずれる
- 少しずつずらす攻撃：stepの閾値や監視の閾値を超えない小さなずれを繰り返し、気づかれないうちに大きくずらす
ほかに、NTPサーバーを止めるDoSや、踏み台にする増幅攻撃もあります。認証で防げるのは偽の応答と書き換えで、遅延の注入は防げません（RFC 7384）。独立した複数の時刻源を比べることも、防御の一部です。
時刻をずらされると何が起きるか
| 対象 | 起きること |
|---|---|
| サーバー証明書 | 進められると有効な証明書が期限切れに見え、通信できない。戻されると期限切れの証明書や古い CRL・OCSP 応答を受け入れる（連載「証明書入門」） |
| Kerberos | 既定で5分を超えてずれると認証に失敗し、ドメインのログオンやファイル共有が止まる（連載「Kerberos入門」第4回、連載「Active Directory入門」第8回） |
| TOTP（認証アプリの6桁、RFC 6238） | 30秒単位で時刻から作るので、ずれるとコードが通らない。端末の時計を進められると、未来のコードを盗み見られるおそれ |
| ログ・監査 | 事象の順序が逆転し、改ざんの有無や発生時刻を示せない。偽の時刻で記録を残される |
| DNSSEC | 署名の有効期間の判定が狂い、検証に失敗する（または古い署名を受け入れる。連載「DNS入門」第9回） |
| ジョブ・バックアップ | 定時の処理の二重実行や未実行、世代の管理やキャッシュの期限が狂う |
どれも「時刻は正しい」という前提で作られているため、時刻がずらされると、個々の仕組みに問題がなくても安全性が崩れます。特に「時計を戻す」攻撃は、期限切れの証明書や失効済みの情報を受け入れさせる、という点で危険です。
増幅攻撃（monlist、CVE-2013-5211）
- NTPはUDPなので、送信元を偽れる。攻撃者が送信元を被害者のアドレスに偽って、小さな問い合わせを多数のNTPサーバーに送ると、大きな応答が被害者に集中する。これが増幅（リフレクション）攻撃
- 2013年から2014年にかけて大規模に悪用されたのが、ntpdの監視用の命令monlist。そのサーバーに最近アクセスした最大600件のアドレスを返すため、小さな要求に対して非常に大きな応答になり、US-CERTはNTPの増幅率を約557倍と示している（DNSは28〜54倍）
- この脆弱性がCVE-2013-5211で、ntpd 4.2.7p26より前の版が既定で応じていた
現在のntpdはmonlistを無効にしており、chronyはmonlistを持ちません。ただし、古い機器や放置されたサーバーは今も残っています。冒頭の「インターネットからの問い合わせに答えている」NTPサーバーは、まさに踏み台の候補です。
公開の制限（chrony・ntpd）
# chrony（/etc/chrony.conf）
allow 192.0.2.0/24 # 社内にだけ配る
ratelimit # 既定は8秒に1回・バースト8
cmdport 0 # chronyc の UDP ポートを閉じる（ローカルの UNIX ソケットは使える）
# ntpd（/etc/ntp.conf）
restrict default -4 nomodify notrap nopeer noquery
restrict default -6 nomodify notrap nopeer noquery
restrict source nomodify notrap noquery
restrict 192.0.2.0 mask 255.255.255.0 nomodify notrap nopeer noquery- chrony：既定ではクライアントを受け付けない（
allowがなければ純粋なクライアント）。サーバーにするときはallowで配る範囲だけを許可する。監視用のポート（UDP 323）は既定でローカルからだけ - ntpd：
restrict … noqueryで監視用の問い合わせ（モード6・7）を拒否し、時刻の応答だけを返す（RFC 8633の例） - 応答の制限：chronyの
ratelimit、ntpdのlimited kodで、問い合わせが多すぎる相手への応答を絞る。NATの後ろの多数の端末は1つのアドレスに見える点に注意
外部からのUDP 123の制限
| 通信 | 向き | 許可する範囲 | 備考 |
|---|---|---|---|
| NTP（UDP 123） | 社内の NTP サーバー → 外部の時刻源 | 送信元と宛先を限定 | 応答はステートフルに許可 |
| NTP（UDP 123） | 社内の機器 → 社内の NTP サーバー | 社内のセグメント | 機器から外部への直接の NTP は拒否 |
| NTP（UDP 123） | インターネット → 社内 | 原則拒否 | 公開するなら専用のサーバーに allow・ratelimit |
| NTS-KE（TCP 4460） | 社内の NTP サーバー → NTS サーバー | 参照先に限定 | NTS を使うとき |
| chrony の監視（UDP 323） | 監視サーバー → NTP サーバー | 監視サーバーだけ | 既定はローカルのみ |
| ntpd の制御（モード6・7） | 外部 → NTP サーバー | 拒否 | noquery |
クライアントの送信元ポートは123とは限りません（RFC 9109）。応答しないかは、管理下のアドレスに限り、nmap -sU -p 123 --script ntp-infoやw32tm /stripchart /computer:203.0.113.10 /samples:1 /dataonlyで確かめます（Test-NetConnectionはUDPを試せない）。
外とUDP 123で話せる穴は、社内のNTPサーバーの1か所だけにします（第7回の3層）。
対称鍵による認証
- サーバーとクライアントが同じ鍵（鍵番号と鍵）を持ち、NTPパケットにメッセージ認証コード（MAC）を付けて検証する。偽の応答と書き換えを防げる
- RFC 5905のMD5は弱い。RFC 8633はAES-128-CMAC（RFC 8573）への移行を勧める。chronyではAES128・AES256、SHA1・SHA256等も選べ、MD5は避けるよう明記されている
- 弱点は、鍵の配布と更新が手作業になること。台数が多いと運用が重い。ネットワーク機器はMD5しか選べないものも多いので、機種ごとに確認する
- ADドメインのWindowsは、MS-SNTPでドメインの秘密情報（Netlogonのセッションキー）を使って、DCの応答に署名する。ドメインの外の時刻源は認証されない（第5回）
- Autokey（RFC 5906）は脆弱性が見つかっており、使わない（RFC 8633）
$ chronyc keygen 10 AES128 # 鍵を生成（出力を両側の鍵ファイルに書く）
10 AES128 HEX:（32桁の16進数）
# /etc/chrony.keys は root と chrony だけが読める権限にする
# クライアント側 /etc/chrony.conf
keyfile /etc/chrony.keys
server ntp1.corp.example.jp iburst key 10NTSの仕組み
NTS（Network Time Security、RFC 8915、2020年）は、鍵の手配布なしにNTPを守る仕組みで、2段階で動きます。
- NTS-KE（鍵の確立）：クライアントはNTS-KEサーバーとTCP 4460でTLS 1.3の接続を張り、サーバー証明書を検証したうえで、使う暗号方式（AEAD。AES-SIV-CMAC-256は必須）を決め、TLSから鍵を取り出し、クッキー（通常8個）を受け取る
- NTP（UDP 123）：通常のNTPの要求に、クッキーと認証用の拡張フィールドを付けて送る。サーバーはクッキーを自分の鍵で復号して鍵を取り出し、応答に認証を付け、新しいクッキーを返す
- サーバーは状態を持たずに済み、クッキーは使い捨てなので、端末を追跡されにくい
- 時刻の中身は暗号化されないが、なりすましと書き換えを防げる
- TLSを使うのは鍵の受け渡しだけ。時刻のやり取りは、従来どおりUDP
NTSを使うときの注意
- 時刻と証明書の鶏と卵：NTS-KEは証明書の有効期間を検証するので、時計が大きくずれていると接続できない。RTCのない機器では、chronyの
nocerttimecheck 1（最初の1回だけ期間の検査を外す）など、初回の同期の方法を決めておく。Ubuntuは初回用のntp-bootstrap.ubuntu.comを用意している - TCP 4460を通す：塞がれていると同期できない。Ubuntu 25.10以降の新規インストールはchrony＋NTSが既定で、4460を塞ぐ社内では時刻が合わなくなる（NTSなしに戻す手順が公開されている）
- 名前で指定する：証明書を検証するので、IPアドレスではなくホスト名で指定する
- 認証なしの時刻源と混ぜるとき：chronyの既定（
authselectmode mix）では、認証なしの時刻源は、NTSの時刻源の多数派と一致するときだけ使われる - 社内にNTSサーバーを立てる：chronyの
ntsserverkey・ntsservercert。社内CAの証明書なら、クライアントにntstrustedcertsを書く。証明書を更新したらchronydの再起動が必要（連載「証明書入門」第8回）
NTSの対応状況（2026年9月）
| 区分 | 対象 | 状況 |
|---|---|---|
| 実装 | chrony | 4.0（2020年）以降で対応。最新は 4.9（2026年8月） |
| 実装 | Windows Time（w32time） | Microsoft Learn に NTS 対応の記載なし。ドメイン内は MS-SNTP |
| OS の既定 | Ubuntu 25.10 以降（新規インストール） | chrony＋NTS（ntp.ubuntu.com）が既定 |
| 公開サーバー | Cloudflare time.cloudflare.com | 対応 |
| 公開サーバー | Netnod nts.netnod.se、PTB ptbtime1.ptb.de 等 | 対応（stratum 1） |
| 公開サーバー | NICT ntp.nict.jp | 公式の案内なし（TCP 4460 は応答なし） |
| 公開サーバー | Google、pool.ntp.org | 未対応。プールで NTS を使う拡張は IETF で検討中 |
冒頭の「NTSは入れたほうがいいか」への答えです。日本国内の公開NTSサーバーはまだ少なく、海外のサーバーでは遅延が大きく精度が落ちます。社内のNTPサーバーだけが外部とNTSで話し、社内には従来のNTPをallowとファイアウォールで守って配る構成が現実的です。
設定例：chronyでNTSを使う
# 社内の NTP サーバーが外部を NTS で参照する例（/etc/chrony.conf）
server time.cloudflare.com iburst nts
server nts.netnod.se iburst nts
server ptbtime1.ptb.de iburst nts
server ntp.nict.jp iburst # NTS なし。NTS 側の多数派と一致するときだけ使われる
ntsdumpdir /var/lib/chrony # クッキーを保存し、再起動時の NTS-KE を省く
$ sudo chronyc -N authdata # 認証の状態（root で実行。行は chrony の文書の例）
Name/IP address Mode KeyID Type KLen Last Atmp NAK Cook CLen
=========================================================================
ntp1.example.net NTS 1 15 256 135m 0 0 8 100- ModeがNTSなら、NTSで認証できている。Atmp（鍵の確立の失敗回数）が2以上なら、ネットワークかサーバーの問題
- Typeの15はAEAD-AES-SIV-CMAC-256。
-Nは名前で表示するオプション - WindowsはNTSを使えないため、Windowsのサーバーは社内のNTPサーバー（DC経由）から受け取る構成にする
守りの全体像
認証は大事ですが、それだけでは足りません。公開を絞り、通り道を1か所にし、応答を認証し、複数の時刻源で見張る、の4つを重ねて守ります。
考えてみよう
- 自社のNTPサーバーは、インターネットからUDP 123の問い合わせに応答していませんか。どう確かめますか。
- 社内でNTSを使うとしたら、どこからどこまでをNTSにしますか。TCP 4460と証明書の更新はどう扱いますか。
- 攻撃者がサーバーの時刻を1日戻せたら、自社のどのシステムで何が起きますか。
ヒント：この記事の「時刻をずらされると何が起きるか」の表、ファイアウォールの表、NTSの注意点が手がかりです。確認は自社の管理下のアドレスに限り、Linuxはnmap -sU -p 123 --script ntp-info、Windowsはw32tm /stripchart /computer:<アドレス> /samples:1 /dataonlyで応答の有無を見ます。
まとめ
- NTPへの攻撃は偽の応答・中間者・遅延の注入・少しずつずらす。認証は遅延の注入を防げない
- 時刻をずらされると、証明書・Kerberos・TOTP・ログ・DNSSECの前提が崩れる
- monlist（CVE-2013-5211）の増幅率は約557倍。古い機器を残さない
- chronyは
allowで配る範囲を絞り、ntpdはnoquery。外とUDP 123で話すのは社内のNTPサーバーだけ - 対称鍵はAES-CMACで。ADはMS-SNTPで署名される
- NTSはTCP 4460のTLS 1.3で鍵を受け取り、UDP 123を守る。時計のずれ（鶏と卵）とTCP 4460に注意
- 現実的には外とだけNTS、社内は従来のNTPを囲って配る
次回は、NTPより高い精度が必要な場面で使うPTPを扱います。
連載「NTP入門」全11回
全回の目次と、読む順番・目的別の読み方は、NTP入門の入口のページにまとめています。
- なぜ時刻同期が必要か
- 時刻の基礎知識
- NTPの仕組み
- Linuxの時刻同期（chrony）
- Windowsの時刻同期
- ネットワーク機器・仮想基盤
- 設計と推奨構成
- NTPのセキュリティ（この記事）
- PTPと高精度同期
- 時刻同期のトラブルシュート
- 時刻同期の設計演習
コメント