使用 NTS 保护 NTP

[ad_1]

许多计算机使用网络时间协议 (NTP) 通过 Internet 同步其系统时钟。 NTP 是少数仍普遍使用的不安全互联网协议之一。 可以观察客户端和服务器之间网络流量的攻击者可以向客户端提供虚假数据,并根据客户端的实现和配置,强制其将系统时钟设置为任何时间和日期。 如果客户端的系统时钟不准确,某些程序和服务可能无法运行。 例如,如果 Web 服务器的证书根据客户端的系统时钟似乎已过期,则 Web 浏览器将无法正常工作。 使用网络时间安全 (NTS) 来保护 NTP。

Fedora 331 是第一个 Fedora 发布以支持 NTS。 NTS 是一种新的 NTP 认证机制。 它使客户端能够验证他们从服务器收到的数据包在传输过程中没有被修改。 当启用 NTS 时,攻击者唯一能做的就是丢弃或延迟数据包。 看 RFC8915 有关 NTS 的更多详细信息。

使用对称密钥可以很好地保护 NTP。 不幸的是,服务器必须为每个客户端使用不同的密钥,并且必须安全地分发密钥。 这对于本地网络上的私有服务器可能是实用的,但它不能扩展到具有数百万个客户端的公共服务器。

NTS 包括密钥建立 (NTS-KE) 协议,该协议可自动创建服务器与其客户端之间使用的加密密钥。 它在 TCP 端口 4460 上使用传输层安全性 (TLS)。它旨在扩展到非常大量的客户端,同时对准确性的影响最小。 服务器不需要保持任何客户端特定的状态。 它为客户端提供 cookie,这些 cookie 被加密并包含验证 NTP 数据包所需的密钥。 隐私是 NTS 的目标之一。 客户端在每次服务器响应时都会获得一个新的 cookie,因此它不必重复使用 cookie。 这可以防止被动观察者跟踪在网络之间迁移的客户端。

默认的 NTP 客户端 Fedora 是慢性的。 Chrony 在 4.0 版中添加了 NTS 支持。 默认配置没有改变。 Chrony 仍然使用公共服务器 池.ntp.org 默认情况下不启用项目和 NTS。

目前,支持 NTS 的公共 NTP 服务器很少。 两大供应商是 Cloudflare 和 Netnod。 这 Cloudflare 服务器 在世界各地。 他们使用应允许大多数客户端访问的任播地址 close 服务器。 这 网络节点服务器 位于瑞典。 将来我们可能会看到更多支持 NTS 的公共 NTP 服务器。

为获得最佳可靠性而配置 NTP 客户端的一般建议是至少拥有三个工作服务器。 为获得最佳精度,建议选择 close 服务器以最大限度地减少由非对称网络路由引起的网络延迟和不对称。 如果您不关心细粒度的准确性,则可以忽略此建议并使用您信任的任何 NTS 服务器,无论它们位于何处。

如果您确实想要高精度,但您没有 close NTS 服务器,您可以将距离较远的 NTS 服务器与较近的非 NTS 服务器混合使用。 但是,这种配置不如仅使用 NTS 服务器的配置安全。 攻击者仍然无法强制客户端接受任意时间,但他们确实可以更好地控制客户端的时钟及其准确性估计,这在某些环境中可能是不可接受的。

在安装程序中启用客户端 NTS

安装时 Fedora 33、您可以在网络时间配置的时间和日期对话框中启用 NTS。 Enter 服务器的名称并在单击之前检查 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 Atmp  NAK Cook CLen
=========================================================================
time.cloudflare.com          NTS     1   15  256  33m    0    0    8  100
nts.sth1.ntp.se              NTS     1   15  256  33m    0    0    8  100
nts.sth2.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 选项以恢复上次关机时保存的时间或重新启动。 时钟将落后于真实时间,但如果计算机没有关闭太长时间并且服务器的证书也没有更新 close 到它们到期时,时间检查成功应该足够了。 作为最后的手段,您可以使用 nocerttimecheck 指令禁用时间检查。 有关详细信息,请参阅 chrony.conf(5) 手册页。

运行以下命令以确认客户端正在进行 NTP 测量:

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

Reach 列应该有一个非零值; 理想情况下是 377。上面显示的值 377 是一个八进制数。 它表明最后八个请求都有一个有效的响应。 如果启用,验证检查将包括 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

确保 chrony.conf 中存在先前在客户端配置中提到的 ntsdumpdir 指令。 它允许服务器将其密钥保存到磁盘,因此服务器的客户端在服务器重新启动时不必获取新的密钥和 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

如果您看到系统时钟错误消息,则说明它工作正常。

在服务器上,您可以使用以下命令来检查它处理了多少 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 连接和 Authenticated NTP 数据包,则意味着至少某些客户端能够连接到 NTS-KE 端口并发送经过身份验证的 NTP 请求。

— 路易斯的封面照片。 Unsplash 上的 K —

1. 这 Fedora 33 Beta 安装程序包含一个较旧的 chrony 预发行版,它不适用于当前的 NTS 服务器,因为 NTS-KE 端口已更改。 因此,在安装程序的网络时间配置中,服务器将始终显示为不工作。 安装后,需要更新 chrony 包才能与当前服务器一起使用。

[ad_2]

Related Posts