NTP ポート ガイド: UDP 123 での時刻同期

NTP クライアントは、定期的に UDP 123 経由で 1 つ以上のタイム サーバーにリクエストを送信します。サーバーは、クライアントがオフセット、遅延、ジッターを推定できるようにするタイムスタンプを返します。その後、クライアントは、ドリフトが大きすぎない限り、中断を伴うジャンプを行わずにローカル クロックを調整します。

NTP の導入は多くの場合、階層的に配置されます。 Stratum 0 は、GPS や原子源などの基準クロックです。ストラタム 1 サーバーはそれらの参照に直接接続し、下位ストラタム サーバーは時間をさらにネットワークに分散します。ほとんどの組織は、信頼できるアップストリーム ソースを使用し、内部 NTP を自社のシステムに提供する必要があります。

NTP クライアントは、設定されたタイム ソースに向けて UDP 123 へのアウトバウンド アクセスを必要とします。 NTP サーバーは、サービスを提供するクライアントからの受信 UDP 123 を必要とします。これらはファイアウォールに関するさまざまな質問であり、これらを混同すると時刻同期が失われる一般的な原因になります。

ワークステーションとアプリケーション サーバーは通常、クライアントとしてのみ機能します。ドメイン コントローラー、ネットワーク タイム アプライアンス、監視インフラストラクチャ、および内部タイム ハブは、フリートの残りの部分のサーバーとして機能する場合があります。

信頼できる外部または内部のタイム ソースと同期する必要があるシステムからのアウトバウンド UDP 123 を許可します。既知のクライアントに意図的に NTP を提供するサーバー上でのみ受信 UDP 123 を許可します。

容量、レート制限、監視、および悪用制御を備えた公共タイム サービスとして意図的に運用されている場合を除き、NTP サーバーをインターネットに広く公開しないでください。パブリック NTP が正しく構成されていないと、リフレクション攻撃や増幅攻撃に悪用される可能性があります。

UDP 123 を許可する前に、どのシステムがクライアントで、どのシステムがサーバーで、どのアップストリーム タイム ソースが信頼できるかを決定してください。環境で chrony、systemd-timesyncd、ntpd、Windows タイム サービス、ドメイン階層、または専用アプライアンスを使用しているかどうかを確認します。

ポート チェッカーは到達可能性の向上に役立ちますが、時刻同期はプロトコル レベルとクロック レベルでも検証する必要があります。 chronyc、ntpq、w32tm、timedatectl、またはモニタリング データを使用して、オフセット、ストラタム、ソース選択、およびドリフトを確認します。

Windows ドメインでは、Windows タイム サービスは通常、信頼できるアップストリーム ソースに対して構成された PDC エミュレータを使用して、ドメイン階層を通じてドメイン メンバーを同期します。スタンドアロン Windows サーバーは、稼働時に w32tm と UDP 123 のファイアウォール ルールを構成できます。

Linux では、最新のディストリビューションでは chrony が一般的ですが、ntpd および systemd-timesyncd も表示されます。信頼できるプールまたは内部サーバーを構成し、ホストが時間を提供する場合にのみ UDP 123 を許可し、オフセットとソースの状態を監視します。

可能な場合、内部 NTP ソースにあるネットワーク デバイス、ポイント スイッチ、ルーター、ファイアウォール、およびアプライアンス上。正確なデバイス時刻により、ログ、証明書、VPN、およびインシデント調査の信頼性が大幅に高まります。

まず、クライアントと目的のタイム サーバーの間で UDP 123 が到達可能かどうかを確認します。次に、プラットフォームに応じて、chronyc tracking、chronycsources、ntpq -p、timedatectl timesync-status、または w32tm /query /status を使用して実際の同期を確認します。

NTP サーバーを運用している場合は、既知のクライアント ネットワークからテストし、未承認のネットワークからクエリできないことを確認します。インターネットに接続されたサービスの場合は、到達可能性だけでは構成が安全であるとは証明できないため、リクエストの量と応答パターンを監視してください。

NTP が同期していない場合、クライアントは UDP 123 からブロックされているか、間違ったサーバーを使用しているか、オフセットが高いためにソースを拒否しているか、タイム サーバーのホスト名を解決できない可能性があります。ホスト時間、ゲスト ツール、および NTP が相互に競合している場合にも、仮想マシンがドリフトする可能性があります。

サーバーに到達できるがクライアントがまだドリフトしている場合は、ストラタム、リープ ステータス、ソースの選択、ファイアウォールの状態、NAT の動作、および複数のタイム システムが同時に構成されているかどうかを検査します。 Windows ドメインの場合は、すべてのホストを個別に変更する前に、ドメイン時間階層を確認してください。

NTP サーバーにクエリできるユーザーを制限し、廃止された高増幅コマンドを無効にし、NTP ソフトウェアにパッチを当て続け、異常なトラフィックの急増を監視します。すべてのホストがランダムなパブリック サーバーにクエリを実行するよりも、内部時間の分散を優先します。

重要な環境の場合は、複数の信頼できる時刻ソースを使用し、過度のオフセットについて警告し、信頼できる時間パスを文書化し、インシデント対応チェックに時刻同期を含めます。時間が合わないと、証明書、認証、ログの関連付け、およびスケジュールされたジョブが破損する可能性があります。