時刻同期がどのようにして安全になったか

TCP/IP 経由で通信する大小さまざまなデバイスが XNUMX 万台ある場合、時間自体が嘘をつかないようにするにはどうすればよいでしょうか? 結局のところ、彼らはそれぞれ時計を持っており、全員の時間が正確でなければなりません。 この問題は、ntp を使用しないと回避できません。

産業用 IT インフラストラクチャのあるセグメントで、時間の経過とともにサービスを同期することが困難になっていると少し想像してみましょう。 すぐにエンタープライズ ソフトウェアのクラスタ スタックに障害が発生し始め、ドメインは崩壊し、マスター ノードとスタンバイ ノードは現状を復元しようとしますが失敗します。

攻撃者が MiTM または DDOS 攻撃を通じて意図的に時間を妨害しようとする可能性もあります。 このような状況では、あらゆることが起こる可能性があります。

• ユーザー アカウントのパスワードは期限切れになります。
• X.509 証明書は期限切れになります。
• TOTP の XNUMX 要素認証は機能しなくなります。
• バックアップは古くなり、システムによって削除されます。
• DNSSec が壊れてしまいます。

すべての IT 部門が時刻同期サービスの信頼性の高い運用に関心を持っていることは明らかであり、産業運用において信頼性が高く安全であれば、それは望ましいことです。

25 分で NTP を破る

ネットワーク プロトコル - ミレニアル世代には XNUMX つの特徴があります。 時代遅れの それらはもはや何の役にも立ちませんが、必要な数の愛好家と資金が蓄積されたとしても、それらを置き換えるのはそれほど簡単ではありません。

従来の NTP に関する主な不満は、侵入者による攻撃から保護するための信頼できるメカニズムが欠如していることです。 この問題を解決するためにさまざまな試みがなされてきた。 これを実現するために、まず対称キーを交換するための事前共有キー (PSK) メカニズムを実装しました。

残念ながら、この方法は単純な理由で効果がありませんでした。拡張性が低いという単純な理由です。 サーバーによっては、クライアント側で手動構成が必要です。 つまり、このように別のクライアントを追加することはできません。 NTP サーバーで何かが変更された場合は、すべてのクライアントを再構成する必要があります。

その後、彼らは AutoKey を思いつきましたが、すぐにアルゴリズム自体の設計に多くの深刻な脆弱性が発見され、放棄せざるを得なくなりました。 問題は、シードには 32 ビットしか含まれておらず、小さすぎて正面攻撃に十分な計算量が含まれていないということです。

• キー ID - 対称 32 ビット キー。
• MAC (メッセージ認証コード) - NTP パケットのチェックサム。

オートキーは次のように計算されます。

Autokey=H(Sender-IP||Receiver-IP||KeyID||Cookie)

ここで、H() は暗号化ハッシュ関数です。

同じ関数を使用してパケットのチェックサムを計算します。

MAC=H(Autokey||NTP packet)

パッケージ チェックの整合性全体は、Cookie の信頼性に基づいていることがわかりました。 これらを取得したら、オートキーを復元して MAC を偽装できます。 ただし、NTP サーバーはシードを生成するときにシードを使用します。 ここに落とし穴があります。

Cookie=MSB_32(H(Client IP||Server IP||0||Server Seed))

MSB_32 関数は、md5 ハッシュ計算結果から最上位 32 ビットを切り取ります。 サーバーパラメータが変更されない限り、クライアント Cookie は変更されません。 この場合、攻撃者は初期番号を復元することしかできず、独自に Cookie を生成できます。

まず、クライアントとして NTP サーバーに接続し、Cookie を受信する必要があります。 その後、攻撃者は総当たり法を使用して、単純なアルゴリズムに従って初期番号を復元します。

総当たり法を使用して初期値の計算を攻撃するためのアルゴリズム。

   for i=0:2^32 − 1 do
        Ci=H(Server-IP||Client-IP||0||i)
        if Ci=Cookie then
            return i
        end if 
    end for

IP アドレスはわかっているので、あとは作成された Cookie が NTP サーバーから受信した Cookie と一致するまで 2^32 ハッシュを作成するだけです。 Intel Core i5 を搭載した通常のホーム ステーションでは、これには 25 分かかります。

NTS - 新しいオートキー

Autokey のこのようなセキュリティ ホールに耐えることは不可能であり、2012 年にそれが登場しました。 новаяверсия プロトコル。 名前を妥協するために、彼らはブランド名を変更することを決定し、Autokey v.2 は Network Time Security と名付けられました。

NTS プロトコルは NTP セキュリティの拡張であり、現在はユニキャスト モードのみをサポートしています。 パケット操作に対する強力な暗号化保護を提供し、スヌーピングを防止し、拡張性に優れ、ネットワーク パケット損失に対する回復力があり、接続セキュリティ中に発生する精度の損失を最小限に抑えます。

NTS 接続は、下位層プロトコルを使用する XNUMX つのステージで構成されます。 の上 最初の この段階で、クライアントとサーバーはさまざまな接続パラメータに同意し、キーを含む Cookie と付随するすべてのデータセットを交換します。 の上 2番目の この段階で、実際の保護された NTS セッションがクライアントと NTP サーバーの間で行われます。

NTS は、TLS 経由で安全な接続を開始する Network Time Security Key Exchange (NTS-KE) と、NTP プロトコルの最新版である NTPv4 という XNUMX つの下位層プロトコルで構成されます。 これについては以下でもう少し詳しく説明します。

最初のステージ - NTS KE

この段階で、NTP クライアントは、NTS KE サーバーとの別の TCP 接続を介して TLS 1.2/1.3 セッションを開始します。 このセッション中に次のことが起こります。

• 当事者がパラメータを決定する AEAD 第 XNUMX 段階のアルゴリズム。
• 当事者は 4 番目の下位層プロトコルを定義しますが、現時点では NTPvXNUMX のみがサポートされています。
• 当事者は、NTP サーバーの IP アドレスとポートを決定します。
• NTS KE サーバーは NTPv4 で Cookie を発行します。
• 当事者は、Cookie マテリアルから対称キーのペア (C2S および S2C) を抽出します。

このアプローチには、接続パラメータに関する秘密情報を送信する負担全体が、実績のある信頼性の高い TLS プロトコルにかかるという大きな利点があります。 これにより、安全な NTP ハンドシェイクのために独自の車輪を再発明する必要がなくなります。

第 XNUMX 段階 - NTS 保護下の NTP

4 番目のステップでは、クライアントは NTP サーバーと時刻を安全に同期します。 この目的のために、NTPvXNUMX パケット構造で XNUMX つの特別な拡張 (拡張フィールド) を送信します。

• Unique Identifier Extension には、リプレイ攻撃を防ぐためのランダムな nonce が含まれています。
• NTS Cookie Extension には、クライアントが使用できる NTP Cookie の 2 つが含まれています。 クライアントのみが対称 AAED C2S キーと SXNUMXC キーを持っているため、NTP サーバーはそれらを Cookie マテリアルから抽出する必要があります。
• NTS Cookie Placeholder Extension は、クライアントがサーバーに追加の Cookie を要求する方法です。 この拡張は、NTP サーバーの応答が要求よりも長くならないようにするために必要です。 これは増幅攻撃の防止に役立ちます。
• NTS オーセンティケーターと暗号化された拡張フィールド 拡張には、C2S キー、NTP ヘッダー、タイムスタンプ、および付随データとして上記の EF を含む AAED 暗号が含まれています。 この拡張機能がないと、タイムスタンプを偽装することが可能になります。

クライアントからリクエストを受信すると、サーバーは NTP パケットの信頼性を検証します。 これを行うには、Cookie を復号化し、AAED アルゴリズムとキーを抽出する必要があります。 NTP パケットの有効性チェックに成功すると、サーバーは次の形式でクライアントに応答します。

• Unique Identifier Extension はクライアント要求のミラーコピーであり、リプレイ攻撃に対する対策です。
• NTS Cookie Extension セッションを継続するには、さらに Cookie を追加します。
• NTS Authenticator と暗号化された拡張フィールド 拡張には、S2C キーを使用した AEAD 暗号が含まれています。

各要求と応答がクライアントに追加の Cookie を与えるため、XNUMX 番目のハンドシェイクは最初のステップをバイパスして何度も繰り返すことができます。 これには、PKI データの計算と送信という比較的リソースを大量に消費する TLS 操作が、繰り返されるリクエストの数で分割されるという利点があります。 これは、すべての主要な機能を対称暗号化の分野からのいくつかの機能にパッケージ化し、TLS スタック全体を別のデバイスに転送できる場合、特殊な FPGA タイムキーパーにとって特に便利です。

NTPSec

NTP の特別な点は何ですか? プロジェクトの作者である Dave Mills は、自分のコードを可能な限り文書化しようとしたにもかかわらず、35 年前の時刻同期アルゴリズムの複雑さを理解できる稀なプログラマーです。 コードの一部は POSIX 時代より前に書かれており、当時の Unix API は現在使用されているものとは大きく異なりました。 さらに、ノイズの多い回線上の干渉から信号を除去するには、統計の知識が必要です。

NTS は、NTP を修正する最初の試みではありませんでした。 攻撃者が NTP の脆弱性を悪用して DDoS 攻撃を増幅する方法を学習すると、根本的な変更が必要であることが明らかになりました。 そして、NTS 草案が準備され最終決定される一方で、2014 年末に米国国立科学財団は NTP の近代化のための助成金を緊急に割り当てました。

このワーキンググループは誰が率いていたわけではありませんが、 エリック・スティーブン・レイモンド - オープンソース コミュニティの創設者および柱の XNUMX 人であり、本の著者 大聖堂とバザール。 Eric と彼の友人が最初にやろうとしたのは、NTP コードを BitKeeper プラットフォームから git に移動することでしたが、うまくいきませんでした。 プロジェクトリーダーのハーラン・ステンはこの決定に反対し、交渉は停滞した。 その後、プロジェクト コードをフォークすることが決定され、NTPSec が誕生しました。

GPSD の研究を含む確かな経験、数学的背景、古代のコードを読み取る魔法のスキルを持つエリック レイモンドは、まさにこのようなプロジェクトを成し遂げることができるハッカーでした。 チームはコード移行のスペシャリストを見つけ、わずか 10 週間で NTP を完成させました。 落ち着いたGitLab 上で。 仕事は本格化していました。

エリック・レイモンドのチームは、オーギュスト・ロダンが石の塊を使ってやったのと同じ方法でこの課題に取り組みました。 古いコードの 175 KLOC を削除することで、多くのセキュリティ ホールを塞ぎ、攻撃対象領域を大幅に減らすことができました。

以下は、ディストリビューションに含まれるものの不完全なリストです。

• 文書化されていない、古い、時代遅れ、または壊れた参照クロック。
• 未使用の ICS ライブラリ。
• libopts/autogen。
• Windows 用の古いコード。
• ntpdc。
• オートキー。
• ntpq C コードは Python で書き直されました。
• sntp/ntpdig C コードは Python で書き直されました。

コードのクリーンアップに加えて、プロジェクトには他のタスクもありました。 成果のリストの一部を次に示します。

• バッファ オーバーフローに対するコード保護が大幅に改善されました。 バッファ オーバーフローを防ぐために、安全でない文字列関数 (strcpy/strcat/strtok/sprintf/vsprintf/gets) はすべて、バッファ サイズ制限を実装した安全なバージョンに置き換えられました。
• NTS サポートを追加しました。
• 物理ハードウェアをリンクすることにより、タイム ステップ精度が XNUMX 倍向上しました。 これは、現代のコンピューターの時計が NTP が誕生した当時よりもはるかに正確になっているためです。 この恩恵を最も受けたのは、GPSDO と専用の時報です。
• プログラミング言語の数は XNUMX つに減りました。 Perl、awk、さらには S スクリプトの代わりに、すべて Python になりました。 このため、コードを再利用する機会が増えます。
• autotools スクリプトの代わりに、プロジェクトはソフトウェア ビルド システムを使用し始めました。 WAF.
• プロジェクトドキュメントを更新および再編成しました。 矛盾し、時には古風な文書のコレクションから、彼らは非常に無難な文書を作成しました。 すべてのコマンド ライン スイッチとすべての構成エンティティには、単一のバージョンの真実が含まれるようになりました。 さらに、マニュアル ページと Web ドキュメントが同じコア ファイルから作成されるようになりました。

NTPSec は、多くの Linux ディストリビューションで使用できます。 現時点で、最新の安定バージョンは 1.1.8 で、Gentoo Linux の場合は最後から XNUMX 番目のバージョンです。

(1:696)$ sudo emerge -av ntpsec
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild   R    ] net-misc/ntpsec-1.1.7-r1::gentoo  USE="samba seccomp -debug -doc -early -gdb -heat -libbsd -nist -ntpviz -rclock_arbiter -rclock_generic -rclock_gpsd -rclock_hpgps -rclock_jjy -rclock_local -rclock_modem -rclock_neoclock -rclock_nmea -rclock_oncore -rclock_pps -rclock_shm -rclock_spectracom -rclock_trimble -rclock_truetime -rclock_zyfer -smear -tests" PYTHON_TARGETS="python3_6" 0 KiB
Total: 1 package (1 reinstall), Size of downloads: 0 KiB
Would you like to merge these packages? [Yes/No]

クロニー

古い NTP をより安全な代替手段に置き換える別の試みがありました。 Chrony は、NTPSec とは異なり、ゼロから作成されており、不安定なネットワーク接続、部分的なネットワークの可用性や輻輳、温度変化などの幅広い条件下で確実に動作するように設計されています。 さらに、chrony には次のような利点もあります。

• chrony はシステム クロックをより速く、より正確に同期できます。
• chrony はサイズが小さく、メモリ消費量が少なく、必要な場合にのみ CPU にアクセスします。 これは、資源とエネルギーの節約にとって大きな利点です。
• chrony は Linux 上のハードウェア タイムスタンプをサポートし、ローカル ネットワーク上で非常に正確な同期を可能にします。

ただし、chrony には、ブロードキャストやマルチキャストのクライアント/サーバーなど、古い NTP の機能の一部がありません。 さらに、クラシック NTP は、より多くのオペレーティング システムとプラットフォームをサポートしています。

サーバーの機能と chronyd プロセスへの NTP リクエストを無効にするには、chrony.conf ファイルにポート 0 を書き込むだけです。 これは、NTP クライアントまたはピアの時間を維持する必要がない場合に行われます。 バージョン 2.0 以降、NTP サーバー ポートは、allow ディレクティブまたは適切なコマンドによってアクセスが許可されている場合、NTP ピアが設定されている場合、またはブロードキャスト ディレクティブが使用されている場合にのみオープンされます。

プログラムは XNUMX つのモジュールで構成されます。

• chronyd はバックグラウンドで実行されるサービスです。 システムクロックと外部タイムサーバーの差に関する情報を受信し、現地時間を調整します。 また、NTP プロトコルも実装しており、クライアントまたはサーバーとして機能します。
• chronyc は、プログラムの監視と制御のためのコマンド ライン ユーティリティです。 さまざまなサービス パラメーターを微調整するために使用されます。たとえば、chronyd の実行を継続しながら NTP サーバーを追加または削除できるようになります。

RedHat Linux バージョン 7 以降 使用する 時刻同期サービスとしての chrony。 このパッケージは他の Linux ディストリビューションでも利用できます。 最新の安定バージョンは 3.5 で、v4.0 のリリースの準備が整っています。

(1:712)$ sudo emerge -av chrony
These are the packages that would be merged, in order:
Calculating dependencies... done!
[binary  N     ] net-misc/chrony-3.5-r2::gentoo  USE="adns caps cmdmon ipv6 ntp phc readline refclock rtc seccomp (-html) -libedit -pps (-selinux)" 246 KiB
Total: 1 package (1 new, 1 binary), Size of downloads: 246 KiB
Would you like to merge these packages? [Yes/No]

インターネット上に独自のリモート chrony サーバーをセットアップして、オフィス ネットワーク上の時刻を同期する方法。 以下は VPS のセットアップ例です。

VPS上のRHEL/CentOSにChronyを設定する例

ここで少し練習して、VPS 上に独自の NTP サーバーを設定してみましょう。 非常に簡単です。RuVDS Web サイトで適切な料金表を選択し、既製のサーバーを入手して、XNUMX 個の簡単なコマンドを入力するだけです。 私たちの目的には、このオプションが非常に適しています。

サービスの設定に進み、まず chrony パッケージをインストールします。

[root@server ~]$ yum install chrony

RHEL 8 / CentOS 8 は異なるパッケージ マネージャーを使用します。

[root@server ~]$ dnf install chrony

chrony をインストールした後、サービスを開始してアクティブ化する必要があります。

[root@server ~]$ systemctl enable chrony --now

必要に応じて、/etc/chrony.conf を変更して、NPT サーバーを最も近いローカルサーバーに置き換えて、応答時間を短縮できます。

# Use public servers from the pool.ntp.org project.
# Please consider joining the pool (http://www.pool.ntp.org/join.html).
server 0.ru.pool.ntp.org iburst
server 1.ru.pool.ntp.org iburst
server 2.ru.pool.ntp.org iburst
server 3.ru.pool.ntp.org iburst

次に、指定したプールのノードと NTP サーバーの同期を設定します。

[root@server ~]$ timedatectl set-ntp true
[root@server ~]$ systemctl restart chronyd.service

NTP ポートを外部に開くことも必要です。そうしないと、ファイアウォールがクライアント ノードからの受信接続をブロックします。

[root@server ~]$ firewall-cmd --add-service=ntp --permanent 
[root@server ~]$ firewall-cmd --reload

クライアント側では、タイムゾーンを正しく設定するだけで十分です。

[root@client ~]$ timedatectl set-timezone Europe/Moscow

/etc/chrony.conf ファイルは、NTP サーバー chrony を実行している VPS サーバーの IP またはホスト名を指定します。

server my.vps.server

最後に、クライアント上で時刻同期を開始します。

[root@client ~]$ systemctl enable --now chronyd
[root@client ~]$ timedatectl set-ntp true

次回は、インターネットを使用せずに時刻を同期するためのオプションについて説明します。

出所： habr.com