web-dev-qa-db-ja.com

ntp.conf:CentOSで公開されているデフォルトのサーバーリストに依存するのは合理的ですか?

新しいLinuxホスト(最近はCentOS)をセットアップするたびに、特にそのようなホストが小さなデータセンター(約100のホスト)内でいくつかの役割を担う場合は、次のことに注意します。

  1. ntpパッケージをインストールします。
  2. add、サーバーリストの上に、新しいサーバーインスタンスが指す:
    • システムにアウトバウンドntpアクセスがある場合は、多かれ少なかれ公式のイタリア語ntpサーバー(time.ien.it)に送信します。
    • システムがインターネットに接続されていない場合、一種の公式ntp「内部」サーバーのように機能する「内部ホスト」に送信されます。
  3. ntpサービスを有効にして、再起動を適切に処理する

したがって、インターネットにアクセスできるシステムの場合、ntp.confで構成されているサーバーリストは次のとおりです。

server time.ien.it iburst
server 0.centos.pool.ntp.org iburst
server 1.centos.pool.ntp.org iburst
server 2.centos.pool.ntp.org iburst
server 3.centos.pool.ntp.org iburst

まったく異なる問題を調査しているときに、上記の構成では、まったく気付いていないリモートホストへのトラフィックが生成されることがわかりました

drbd-store-02-chホストのアウトバウンドインターフェースで取得されたtcpdumpキャプチャのスニペットは次のとおりです。

enter image description here

あなたが見ることができる場所:

  • 私が正しく期待しているホストとの間のトラフィック(「黄色」のトラフィック)。
  • CentOSおよび/またはntp.orgドメインとは無関係に見えるホストとの間のトラフィック。具体的には:
    • 1.ntp.tld.sk
    • laika.paina.net
    • time.reisenbauer-it.com
    • 183.84.160.167.rdns.kaiju.cc

調査の結果、上記のリストに含まれていない他のホストも存在することが判明しました。逆ホスト名がVPSなどを参照していくつかの大きなISPを明確に指しているホストも見つけました。

だから私の質問は:

  1. デフォルトのサーバーリストを削除し、「信頼できる」time.ien.it外部ntp-serverホストのみに依存する必要がありますか?
  2. そうでない場合、これらのリモートホストが効果的に「安全」であり、適切に保護/管理されていることをどのように確認できますか...私のntp-service-requestsを危険にさらさないようにするには?

PS:補足として、私はDNS解決プロセスについて完全に認識しているので、問題はnot "なぜ「私はそれらのサーバーに連絡しています。問題は、「安全ですか?」

2

短いバージョン:おそらく安全です。

長いバージョン:表示されている動作は完全に正常であり、予期されたものです。 NTPプール は動的プールであり、DNS TTLが期限切れになるたびに変更される可能性があります。

プール内の各ホストは、NTPプールインフラストラクチャによって監視され、許容範囲から離れすぎていることが報告された場合、プールから削除されます。各ホストの監視レコードを表示できます。 at http://www.pool.ntp.org/scores/IP (ここで、IPはサーバーのIPアドレスです)。たとえば、0.centos.pool.ntp.orgを検索すると私のマシンは今、次のアドレスを取得しています。

時間同期要件が平均的であると仮定すると(実際の時間からのオフセットに関して)、通常のベストプラクティスは、プール内の4〜6台のサーバーと同期する4〜6台のサーバーを独自のネットワークに設定し、内部ホストをそれらのローカルサーバー。これについては、今年の Linux.conf.asysadmin miniconf (ページの最後の話)で詳しく説明しました。

編集:一部のプールサーバーはTORリレーまたは出口ノードでもあることに注意してください。これにより、NTPプールユーザーが熱心すぎるIDS/IPSやISPでさえ問題を抱えることがあります。 https://Twitter.com/_lennart/status/861714732709031936 を参照してください。 =最近の例。

3
Paul Gear

おそらく、DMZではそのようなリストのみを使用する必要があります。内部システムは、UDPポート123を使用してインターネット上のランダムなサービスに接続できないようにする必要があります。

  1. 自分のネットワーク内でのみ、リストを信頼できるホストに減らす必要があります。 DMZ)では、NTPソフトウェアが、内部からインターネットに奇妙な要求を転送するだけではないことを信頼する必要があります。
  2. できません。それらのホストも同様に恐ろしく構成できます。

したがって、信頼できるタイムサーバーを使用する正当な理由がある場合は、適切なタイムソースデバイスと対話するサーバーを入手し、インターネットに接続しないでください。

1
Cheatah

これは、ソフトウェアベンダー(Centos)がデフォルトのNTP構成ではなく)無料のパブリック NTP.orgプール で出荷するというかなり一般的なケースのように見えます。独自のNTPインフラストラクチャを提供するか、ユーザーにNTPインフラストラクチャを配置することを頼りにするよりも。

先に進んで、以下のドキュメントを引用します。

NTP.orgプールの 使用について

NTPプールがあなたの使用に適しているかどうかを検討してください。ビジネス、組織、または人間の生活が正しい時間を持つことに依存している場合NTPプールは一般的に非常に高品質ですが、ボランティアが運営するサービスです。空き時間。ローカルで信頼性の高いサービス設定の取得については、機器やサービスベンダーにご相談ください。利用規約もご覧ください。Meinbergのタイムサーバーをお勧めしますが、End Run、Spectracomなどのタイムサーバーもあります。 。

.。

インターネットプロバイダーにタイムサーバーがある場合、またはお近くの優れたタイムサーバーを知っている場合は、このリストではなく、それを使用する必要があります-おそらくより良い時間を取得し、より少ないネットワークリソースを使用します。お近くのタイムサーバーが1つしかない場合は、もちろんそれとpool.ntp.orgなどの2つを使用できます。


NTP.orgプールベンダーゾーン について(0.centos.pool.ntp.orgcentosなど):

ベンダーゾーンを取得します
アプリケーションでデフォルトのタイムサービスとしてプールを使用できるようにするために、0.vendor.pool.ntp.org、1.vendor.pool.ntpなどの特別なホスト名を設定します。 org、2.vendor.pool.ntp.orgおよび3.vendor.pool.ntp.org。

アプリケーションまたはアプライアンスのデフォルト構成として、デフォルトのpool.ntp.orgゾーン名を絶対に使用しないでください。

.。

ベンダーに特別なホスト名を使用する理由
特別なホスト名を使用すると、トラフィックをある程度制御できるため、負荷分散を最適化し、クライアントを最適なサーバーに一致させることができます。また、クライアント母集団のセグメントに問題が発生した場合にサポートを継続するためのより良いオプションを提供します。 (基本的なガイドラインのセクションのリンクを参照してください)。


NTP.orgプール内のサーバーの安全性については、プール内の サーバーが監視されています が、明示的に言われているように、より優れた(より信頼性が高く、信頼できる)オプションを使用する必要があります。

1

悪い時間を消費または提供することは、おそらく「インターネットの軽罪」の下で提起される可能性があります。すべてのCentOS NTP名前はIPアドレスのバッチであり、おそらくタイムソースの幅広いサンプルを提供することを目的としています(完全なNTP空白を描画するともっと悪い?)。

個人的には、CentOSが作成するリストに中程度の信頼を与えますが、懸念がある場合、またはビジネスニーズがある場合は、プロバイダーネットワークまたはNISTからNTPを見つけることができるはずです。 (time-a.nist.govなど)信頼できる場合セキュリティが最優先される状況では、プロバイダーネットワークから時間を消費し、その時間参照をコアルーターで再ホストして、ネットワーク内の消費者ができるようにしました。すべて、統一された既知のソースを使用します。

0