NTPセキュリティ完全ガイド｜時刻改ざん攻撃の仕組みとchronydで実現する認証・監視設定

2026年6月30日2026年7月2日

サーバー管理を担当していると、NTP（Network Time Protocol）の存在を意識するのは「時刻がずれてアラートが出たとき」だけ、という方も多いのではないでしょうか。

実は、NTPは攻撃者にとって格好の標的になり得るプロトコルです。時刻を数分ずらすだけで、多要素認証のワンタイムパスワードを無効化したり、TLS証明書のエラーを引き起こしたり、ログのタイムスタンプを乱して侵入の痕跡を隠したりできます。

この記事では、NTPを狙う攻撃の仕組みと、現代のLinux標準であるchronydを使って安全なNTP環境を構築する実践的な設定手順を解説します。NTPサーバーの設定を一度も見直したことがない方は、今日の対策として活用してください。

NTP（時刻同期プロトコル）とは？なぜセキュリティ対策が必要か

NTPは、ネットワーク上のコンピューター同士が正確な時刻を共有するためのプロトコルです。インターネット上の上位時刻配信サーバー（Stratum 1/2）から時刻情報を受け取り、サーバーやクライアントの時計を継続的に微調整します。UDP 123番ポートを使い、小さなパケットで通信が完結するシンプルな設計です。

「時刻が多少ずれても業務に支障はない」と思いがちですが、現代のITシステムでは時刻の正確さがセキュリティの根幹を支えています。

・Kerberos認証: Windows Active Directoryが採用するKerberos認証は、クライアントとサーバーの時刻差が5分を超えると認証を拒否します。時刻改ざんで正規ユーザーが締め出されると、そのすきに攻撃者が侵入するシナリオも現実的です。
・TOTP（時刻ベースワンタイムパスワード）: Google AuthenticatorなどのMFAアプリは30秒ごとにコードを生成します。端末の時刻がずれるとコードが一致せず、認証が通らなくなります。
・TLS証明書の有効期限チェック: サーバーの時計が大きくずれていると、有効な証明書でも「期限切れ」や「まだ有効ではない」とエラーになります。
・ログの相関分析: SIEMでの攻撃シナリオ再構成はサーバー間のタイムスタンプが一致していることが前提です。時刻がずれているとアラートの前後関係が崩れ、インシデント対応が困難になります。

NTPを狙う攻撃の仕組み

1. NTP増幅攻撃（Amplification Attack）

NTP増幅攻撃はDDoS攻撃の一種です。攻撃者は送信元IPアドレスを偽装して外部のNTPサーバーにリクエストを送り、応答を標的サーバーに向けます。かつてのntpdには「monlist」という診断コマンドがあり、数十バイトのリクエストに対して数キロバイト分の応答が返りました。この増幅効果（Amplification Factor）を悪用することで大量のUDPトラフィックを生成し、標的に集中させることができます。

自社のサーバーがmonlistを有効にしたまま外部公開されていると、加害者側（リフレクター）になりかねません。現在の主流であるchronydはmonlistを実装していないため、chronydへの移行だけでこのリスクを排除できます。

2. NTPスプーフィングによる時刻改ざん

ネットワーク上でMITM（中間者攻撃）の位置を取った攻撃者は、NTP応答パケットを偽造してクライアントに送り込み、時計を意図した時刻に書き換えることができます。NTP自体の認証が設定されていない環境では、クライアントは正規サーバーからの応答かどうか判断できません。

内部ネットワークに侵入した攻撃者や悪意ある内部者にとっては現実的な手段であり、特にKerberosやMFAを標的とした妨害攻撃として使われます。

3. 時刻改ざんがもたらす二次被害

時刻を数分改ざんするだけで連鎖的な被害が起きます。Kerberos認証やTOTPが機能不全を起こして正規ユーザーが締め出される一方、その混乱に乗じて攻撃者が侵入するシナリオがあります。また、ログのタイムスタンプを汚染することでフォレンジック（侵害後の証拠解析）を妨害する目的でも使われます。ログが信頼できなければ、何が起きたかを正確に追うことができなくなります。

chronydによる安全なNTP設定の実践

RHEL 8以降・Ubuntu 18.04以降・Alma Linux・Rocky Linuxなど、現代の主要なLinuxディストリビューションはchronyd（chrony）を標準NTP実装として採用しています。まだntpdを使っている環境はchronydへの移行を優先してください。

1. chrony.confの基本設定

まず現在の状況を確認します。

# chronyのバージョン確認 chronyc --version # 現在の同期状況を確認 chronyc sources -v # サービス状態の確認 systemctl status chronyd

次に `/etc/chrony.conf` を編集し、信頼できるNTPサーバーのみを指定します。

# /etc/chrony.conf # 国立研究開発法人情報通信研究機構（NICT）のNTPサーバー server ntp.nict.jp iburst # Cloudflare NTP（NTS対応。後続のセクションで認証を有効化） server time.cloudflare.com iburst # デフォルトですべてのクライアントアクセスを拒否 denyall # LAN内のみ許可（ネットワークアドレスは環境に合わせて変更） allow 192.168.1.0/24 # 3回の計測で10秒以上のずれがあれば一気に補正 makestep 10 3 # ハードウェアクロックと同期 rtcsync # ログの保存先 logdir /var/log/chrony

2. NTS（Network Time Security）認証の有効化

NTS（RFC 8915）はTLSベースでNTP通信を認証する現代的なセキュリティ拡張です。NTSをサポートするNTPサーバーと組み合わせることで、応答の偽造を検知できます。Cloudflareのtime.cloudflare.comはNTSに対応しており、無料で利用できます。

chrony 4.0以上が必要です。バージョンを確認した上で設定してください。

# /etc/chrony.conf の time.cloudflare.com の行に nts オプションを追加 server time.cloudflare.com iburst nts # NTSキャッシュの保存先（新規追加） ntsdumpdir /var/lib/chrony

設定を反映してNTS認証の状態を確認します。

# chronydを再起動して設定を反映 systemctl restart chronyd # NTS認証の状態を確認 chronyc authdata # Name列にサーバーが表示され、Mode列が NTS になっていれば認証成功

3. ファイアウォールでUDP 123の外部公開を遮断

自社のNTPサーバーをインターネットに公開する必要がない場合は、ファイアウォールでUDP 123番ポートへの外部アクセスを遮断します。


# firewalldでNTPをpublicゾーンから削除
firewall-cmd --permanent --zone=public --remove-service=ntp

# 内部ゾーンにのみNTPを許可（LAN内のクライアントが使う場合）
firewall-cmd --permanent --zone=internal --add-service=ntp

# 設定の反映
firewall-cmd --reload

# 確認
firewall-cmd --zone=public --list-services

この設定でインターネット側からのUDP 123宛てパケットを遮断し、NTP増幅攻撃の踏み台になるリスクを排除できます。

中小企業でも今日からできること

高価なツールは不要です。まず以下を順番に確認してください。

・chronyのバージョンを確認する: `chronyc –version` を実行し、chrony 4.0未満の場合はOSのアップデートを検討します。ntpdが動いている場合はchronyへの移行を計画します。
・NTPサーバーを信頼できるものに固定する: ntp.nict.jp（情報通信研究機構）は国内の信頼性の高いNTPサーバーです。「pool.ntp.org」の利用は便利ですが、接続先が不定になるため固定サーバーへの変更を推奨します。
・ファイアウォールで外部公開を確認・制限する: クラウドVPSや社内サーバーがUDP 123を外部公開していないかを確認し、不要であれば即日閉じます。
・NTSを有効化する（chrony 4.0+）: Cloudflareのtime.cloudflare.comはNTSに対応しており、設定一行で応答偽造への耐性が高まります。
・定期的にchronyの状態を確認する: `chronyc tracking` と `chronyc sources -v` を週次で確認し、時刻オフセットや参照先サーバーに異常がないかチェックします。

社内にNTPサーバーを立てている環境では、そのサーバー自体のchrony設定も同様に見直してください。内部NTPサーバーの設定が甘いと、そこが突破口になります。

よくある誤解と注意点

「ntpdが動いているから問題ない」という誤解
ntpdはRHEL 7まで標準でしたが、RHEL 8以降はchronydがデフォルトです。ntpdはmonlistなどのリスクある機能が残っており、開発の主軸もchronyに移っています。ntpdのまま放置している環境は移行を検討してください。

「クラウドはNTPが自動なので不要」という誤解
AWSやAzureはデフォルトでNTP同期を提供していますが、設定を誤って外部のNTPサーバーを直接指定していたり、chronydの設定が実は機能していなかったりするケースがあります。クラウド環境でも設定の確認は必要です。

「LAN内のNTPなら安全」という誤解
内部ネットワークに侵入した攻撃者はLAN内のNTP通信も傍受・改ざんできます。NTSによる認証はLAN内のサーバーにも有効な対策です。

「100%安全なNTPはない」という認識の重要性
NTSを使っても、大規模なネットワーク経路攻撃により時刻配信が妨害されるシナリオは理論上存在します。NTPセキュリティはあくまで多層防御の一層であり、これだけで完全な安全は主張できません。ファイアウォール・EDR・ログ監視との組み合わせが重要です。

本記事のまとめ

NTPはシステム基盤の縁の下を支える地味な存在ですが、セキュリティ的には見落とせないプロトコルです。特に時刻改ざんによる認証機能の破壊とログ汚染は、インシデント発生後の被害を深刻化させます。

脅威	対策	難易度
NTP増幅攻撃（踏み台化）	ファイアウォールでUDP 123を外部遮断	低（すぐできる）
NTPスプーフィング・偽装応答	NTS認証を有効化（chrony 4.0+）	中（バージョン確認が必要）
不正サーバーへの接続	信頼できるNTPサーバーを明示指定	低（設定変更のみ）
ログタイムスタンプの汚染	定期的な同期状態の確認と監視	低（監視ルール追加）