NTP仍在广泛采用的不安全的互联网协议之一

NTP 是为数不多仍在广泛采用的不安全的互联网协议之一。

• 由来：linux.cn • 创作者：Miroslav Lichvar • 译员：Xingyu.Wang •

（文中篇幅：5954，阅读文章时间大概：8 分鐘）

很多电子计算机应用系统时间协议书(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）。它被设计成可以扩大到特别多的客户端，而对精确性的危害最少。服务器不用保留一切客户端特殊的情况。它为客人给予 cookiecloudflare服务器，cookie 是数据加密的，包括认证 NTP 数据需要的密钥。个人隐私是 NTS 的目的之一。客户端在每一次服务器回应时都是会获得一个新的 cookie，因此它无须多次重复使用 cookie。这可以避免处于被动观测者追踪在网上中间转移的客户端。

Fedora 中默认设置的 NTP 客户端是 Chrony。Chrony 在 4.0 版本号中提高了 NTS 适用，但并没更改默认设置配备。Chrony 依然应用 pool.ntp.org 新项目中的公共性服务器，并且默认设置状况下 NTS 沒有开启。

现阶段，适用 NTS 的公共性 NTP 服务器很少。2个关键的服务提供商是 Cloudflare 和 Netnod。 Cloudflare 服务器 遍布在全球各地的差异地区。她们应用的是任播(anycast)详细地址，应当可以让大部分顾客抵达一个贴近的服务器。 Netnod 服务器 坐落于德国。在未来，大家也许会见到大量适用 NTS 的公共性 NTP 服务器。

为了更好地取得最好的稳定性，配备 NTP 客户端的一般提议是起码有三个工作中的服务器。为了更好地做到最佳的精度，提议挑选相距较近的服务器，以降低网络延时和非对称加密互联网路由器导致的不可逆性。假如不关注粗粒度的精度，你能忽视这一提议，应用一切你信赖的 NTS 服务器，无论他们坐落于哪儿。

假如你的确要想高精确度，但又沒有近距的 NTS 服务器cloudflare服务器，你能将远方的 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 nts

server nts.sth1.ntp.se iburst nts

server nts.sth2.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 authdata

Name/IP address Mode KeyID Type KLen Last AtmpNAK Cook CLen

=========================================================================

time.cloudflare.comNTS 1 1525633m008100

nts.sth1.ntp.seNTS 1 1525633m008100

nts.sth2.ntp.seNTS 1 1525633m008100

KeyID、Type 和 KLen 列应当有非零值。假如他们为零，请查验系统软件日志中能否有来源于 chronyd 的错误报告。一个有可能的问题根本原因是服务器防火墙阻拦了客户端与服务器的 TCP 端口号（端口 4460）的联接。

另一个有可能的问题根本原因是因为远程服务器的时钟不正确而造成资格证书无法验证。这也是 NTS 的先有鸡還是先有蛋的问题。你也许必须手动式调整日期或临时禁止使用 NTS，以使 NTS 正常的工作中。假如你的计算机有即时时钟，几乎任何的计算机都是有，并且有好的充电电池做备份数据，这类实际操作应当只要一次。

假如电子计算机沒有即时时钟或充电电池，如同一些常用的中小型 ARM 电子计算机（如树莓派3b）那般，你能在 /etc/sysconfig/chronyd 中加上 -s 选择项来修复之前待机或重新启动时储存的时间。时钟会滞后于真正时间，但假如电脑没有待机很久，服务器的资格证书都没有在离期满时间太近的情况下升级，应当足够让时间查验取得成功。做为最终的方式，你能用 nocerttimecheck 命令禁止使用时间查验。敬请参照chrony.conf(5) 指南页。

运作下边的指令来确定客户端是不是在开展 NTP 精确测量：

# chronyc -N sources

MS Name/IP address Stratum Poll Reach LastRx Last sample

===============================================================================

^* time.cloudflare.com 3 6 37745 355us[ 375us] /- 11ms

^ nts.sth1.ntp.se 1 6 37744 237us[ 237us] /- 23ms

^ nts.sth2.ntp.se 1 6 37744 -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.key

ntsservercert /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 clock

2020-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 serverstats

NTP packets received : 2143106240

NTP packets dropped: 117180834

Command packets received : 16819527

Command packets dropped: 0

Client log records dropped : 574257223

NTS-KE connections accepted: 104

NTS-KE connections dropped : 0

Authenticated NTP packets: 52139

如果你见到非零的 “NTS-KE connections accepted” 和 “Authenticated NTP packets”，这代表着最少有一些手机客户端可以接入到 NTS-KE 端口号，并推送一个验证的 NTP 要求。

Fedora 33 Beta 安装程序包括一个较旧的 Chrony 预公布版本，它无法与现阶段的 NTS 服务器一起工作中，由于 NTS-KE 端口号早已更改。因而，在安装程序中的系统时间配备中，服务器一直表明为不工作中。安裝后，必须升级 chrony 包，才可以与现阶段的服务器相互配合应用。 ↩︎

via: fedoramagazine.org

本文内容来源于互联网，若引用不当或侵权，请联系我们修正或删除。