怎么用NTS保證NTP的安全

這篇文章給大家分享的是有關怎么用NTS保證NTP的安全的內容。小編覺得挺實用的，因此分享給大家做個參考，一起跟隨小編過來看看吧。

許多計算機使用網絡時間協議Network Time Protocol（NTP）通過互聯網來同步系統時鐘。NTP   是少數幾個仍在普遍使用的不安全的互聯網協議之一。攻擊者如果能夠觀察到客戶端和服務器之間的網絡流量，就可以向客戶端提供虛假的數據，并根據客戶端的實現和配置，強迫其將系統時鐘設置為任何時間和日期。如果客戶端的系統時鐘不準確，一些程序和服務就可能無法工作。例如，如果根據客戶端的系統時鐘，Web  服務器的證書似乎已經過期，Web 瀏覽器將無法正常工作。可以使用網絡時間安全Network Time Security（NTS）來保證 NTP 的安全。

Fedora 33 ^[1] 是第一個支持 NTS 的 Fedora 版本。NTS 是一種新的 NTP 驗證機制。它使客戶端能夠驗證它們從服務器接收的數據包在傳輸過程中有沒有被修改。當 NTS 啟用時，攻擊者唯一能做的就是丟棄或延遲數據包。關于 NTS 的更多細節，請參見 RFC8915。

使用對稱密鑰可以很好地保證 NTP 的安全。遺憾的是，服務器必須為每個客戶端配備不同的密鑰，而且密鑰必須安全地分發才行。這對于本地網絡上的私有服務器來說可能是實用的，但它不能擴展到有著數百萬客戶端的公共服務器上。

NTS 包括一個密鑰建立Key Establishment（NTS-KE）協議，它可以自動創建服務器與其客戶端之間使用的加密密鑰。它在 TCP 端口 4460 上使用傳輸層安全Transport Layer Security（TLS）。它被設計成可以擴展到非常多的客戶端，而對準確性的影響最小。服務器不需要保存任何客戶端特定的狀態。它為客戶提供  cookie，cookie 是加密的，包含驗證 NTP 數據包所需的密鑰。隱私是 NTS 的目標之一。客戶端在每次服務器響應時都會得到一個新的  cookie，所以它不必重復使用 cookie。這可以防止被動觀察者跟蹤在網絡之間遷移的客戶端。

Fedora 中默認的 NTP 客戶端是 Chrony。Chrony 在 4.0 版本中增加了 NTS 支持，但并沒有改變默認配置。Chrony 仍然使用 pool.ntp.org 項目中的公共服務器，而且默認情況下 NTS 沒有啟用。

目前，支持 NTS 的公共 NTP 服務器非常少。兩個主要的提供商是 Cloudflare 和 Netnod。Cloudflare 服務器分布在世界各地的不同地方。他們使用的是任播anycast地址，應該可以讓大多數客戶到達一個接近的服務器。Netnod 服務器位于瑞典。在未來，我們可能會看到更多支持 NTS 的公共 NTP 服務器。

為了獲得最佳的可靠性，配置 NTP  客戶端的一般建議是至少有三個工作的服務器。為了達到最好的精度，建議選擇距離較近的服務器，以減少網絡延遲和非對稱網絡路由造成的不對稱性。如果你不關心細粒度的精度，你可以忽略這個建議，使用任何你信任的  NTS 服務器，無論它們位于哪里。

如果你確實想要高準確度，但又沒有近距離的 NTS 服務器，你可以將遠處的 NTS 服務器和近處的非 NTS  服務器混合使用。但是，這樣的配置不如只使用 NTS  服務器的配置安全。攻擊者仍然不能強迫客戶機接受任意時間，但他們確實對客戶機的時鐘及其估計精度有更大的控制權，這在某些環境下可能是不可接受的。

在安裝程序中啟用客戶端 NTS

安裝 Fedora 33 時，你可以在“Time & Date”對話框的“Network Time”配置中啟用  NTS。在點擊“+”（添加）按鈕之前，請輸入服務器的名稱并檢查 NTS 支持情況。你可以添加一個或多個具有 NTS  的服務器或池。要刪除默認的服務器池（2.fedora.pool.ntp.org），請取消選中“Use”列中的相應標記。

Fedora 安裝程序中的網絡時間配置

在配置文件中啟用客戶端 NTS

如果你從之前的 Fedora 版本升級，或者你沒有在安裝程序中啟用 NTS，你可以直接在 /etc/chrony.conf 中啟用 NTS。除了推薦的 iburst 選項外，還可以對指定服務器使用 nts 選項。例如：

server time.cloudflare.com iburst ntsserver nts.sth2.ntp.se iburst ntsserver nts.sth3.ntp.se iburst nts

你還應該允許客戶端將 NTS 密鑰和 cookie 保存到磁盤上，這樣它就不必在每次啟動時重復 NTS-KE 會話。在 chrony.conf 中添加以下一行，如果還沒有的話：

ntsdumpdir /var/lib/chrony

如果不想讓 DHCP 提供的 NTP 服務器與你指定的服務器混在一起，請在 chrony.conf 中刪除或注釋以下一行：

sourcedir /run/chrony-dhcp

當你完成編輯 chrony.conf 后，保存你的更改并重新啟動 chronyd 服務：

systemctl restart chronyd

檢查客戶端狀態

在 root 用戶下運行以下命令，檢查 NTS 密鑰建立是否成功：

# chronyc -N authdataName/IP address             Mode KeyID Type KLen Last Atmp  NAK Cook CLen=========================================================================time.cloudflare.com          NTS     1   15  256  33m    0    0    8  100nts.sth2.ntp.se              NTS     1   15  256  33m    0    0    8  100nts.sth3.ntp.se              NTS     1   15  256  33m    0    0    8  100

KeyID、Type 和 KLen 列應該有非零值。如果它們為零，請檢查系統日志中是否有來自 chronyd 的錯誤信息。一個可能的故障原因是防火墻阻止了客戶端與服務器的 TCP 端口（端口 4460）的連接。

另一個可能的故障原因是由于客戶機的時鐘錯誤而導致證書無法驗證。這是 NTS 的先有雞還是先有蛋的問題。你可能需要手動修正日期或暫時禁用  NTS，以使 NTS 正常工作。如果你的電腦有實時時鐘，幾乎所有的電腦都有，而且有好的電池做備份，這種操作應該只需要一次。

如果計算機沒有實時時鐘或電池，就像一些常見的小型 ARM 計算機（如樹莓派）那樣，你可以在 /etc/sysconfig/chronyd 中添加 -s 選項來恢復上次關機或重啟時保存的時間。時鐘會落后于真實時間，但如果電腦沒有關機太久，服務器的證書也沒有在離到期時間太近的時候更新，應該足以讓時間檢查成功。作為最后的手段，你可以用 nocerttimecheck 指令禁用時間檢查。詳情請參見chrony.conf(5) 手冊頁。

運行下面的命令來確認客戶端是否在進行 NTP 測量：

# chronyc -N sourcesMS Name/IP address         Stratum Poll Reach LastRx Last sample===============================================================================^* time.cloudflare.com           3   6   377    45   +355us[ +375us] +/-   11ms^+ nts.sth2.ntp.se               1   6   377    44   +237us[ +237us] +/-   23ms^+ nts.sth3.ntp.se               1   6   377    44   -170us[ -170us] +/-   22ms

Reach 列應該有一個非零值，最好是 377。上圖所示的值 377  是一個八進制數，它表示最后八個請求都有有效的響應。如果啟用了 NTS 的話，驗證檢查將包括 NTS 認證。如果該值一直很少或從未達到  377，則表明 NTP 請求或響應在網絡中丟失了。眾所周知，一些主要的網絡運營商有中間設備，它可以阻止或限制大的 NTP  數據包的速率，以緩解利用 ntpd 的監控協議進行的放大攻擊。不幸的是，這影響了受 NTS 保護的 NTP 數據包，盡管它們不會引起任何放大。NTP 工作組正在考慮為 NTP 提供一個替代端口，作為解決這個問題的辦法。

在服務器上啟用 NTS

如果你有自己的 NTP 服務器，運行著 chronyd，你可以啟用服務器的 NTS 支持，讓它的客戶端安全同步。如果該服務器是其他服務器的客戶端，它應該使用 NTS 或對稱密鑰與之同步。客戶端假設同步鏈在所有服務器到主時間服務器之間是安全的。

啟用服務器 NTS 類似于在 Web 服務器上啟用 HTTPS。你只需要一個私鑰和證書。例如，證書可以由 Let's Encrypt 權威機構使用 certbot 工具簽署。當你有了密鑰和證書文件（包括中間證書），在 chrony.conf 中用以下指令指定它們：

ntsserverkey /etc/pki/tls/private/foo.example.net.keyntsservercert /etc/pki/tls/certs/foo.example.net.crt

確保之前在客戶端配置中提到的 ntsdumpdir 指令存在于 chrony.conf 中。它允許服務器將其密鑰保存到磁盤上，這樣服務器的客戶端在重啟服務器時就不必獲取新的密鑰和 cookie 了。

重新啟動 chronyd 服務：

systemctl restart chronyd

如果系統日志中沒有來自 chronyd 的錯誤信息，那么它應該是可以接受客戶端連接的，如果服務器有防火墻，則需要同時允許 UDP 123 和 TCP 4460 端口的 NTP 和 NTS-KE 服務。

你可以用下面的命令在客戶端機器上進行快速測試：

$ chronyd -Q -t 3 'server foo.example.net iburst nts maxsamples 1'2020-10-13T12:00:52Z chronyd version 4.0 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +SCFILTER +SIGND +ASYNCDNS +NTS +SECHASH +IPV6 +DEBUG)2020-10-13T12:00:52Z Disabled control of system clock2020-10-13T12:00:55Z System clock wrong by -0.001032 seconds (ignored)2020-10-13T12:00:55Z chronyd exiting

如果你看到一個“System clock wrong”消息，說明它是正確工作的。

在服務器上，你可以使用下面的命令來檢查它已經處理了多少個 NTS-KE 連接和認證的 NTP 數據包：

# chronyc serverstatsNTP packets received       : 2143106240NTP packets dropped        : 117180834Command packets received   : 16819527Command packets dropped    : 0Client log records dropped : 574257223NTS-KE connections accepted: 104NTS-KE connections dropped : 0Authenticated NTP packets  : 52139

如果你看到非零的 “NTS-KE connections accepted” 和 “Authenticated NTP packets”，這意味著至少有一些客戶端能夠連接到 NTS-KE 端口，并發送一個認證的 NTP 請求。

1. Fedora 33 Beta 安裝程序包含一個較舊的 Chrony 預發布版本，它不能與當前的 NTS 服務器一起工作，因為 NTS-KE  端口已經改變。因此，在安裝程序中的網絡時間配置中，服務器總是顯示為不工作。安裝后，需要更新 chrony 包，才能與當前的服務器配合使用。 

感謝各位的閱讀！關于“怎么用NTS保證NTP的安全”這篇文章就分享到這里了，希望以上內容可以對大家有一定的幫助，讓大家可以學到更多知識，如果覺得文章不錯，可以把它分享出去讓更多的人看到吧！