在 20 世纪 70 年代后期,David L. Mills 开始研究网络计算机的时间同步问题,NTP(网络时间协议)版本 1 于 1980 年首次亮相。那时的网络远比现在友好——那是 ARPANET 的时代。NTP 版本 2 大约在一年后出现,与 CSNET(计算机科学网络)几乎同时。NSFNET(国家科学基金会网络)于 1986 年启动。NTP 版本 3 于 1993 年问世。
根据你划定的界限,互联网在 1991-1992 年变得有用,并在 1995 年完全到来。NTP 版本 4 于 1997 年出现。现在,17 年过去了,IETF(互联网工程任务组)几乎完成了 NTP 版本 4 标准的最终确定工作,我们中的一些人开始考虑 NTP 版本 5。
所有这一切都是由志愿者完成的——没有预算,仅仅依靠关心此事的公司和个人的善意。这种情况是不可持续的。NTF(网络时间基金会)是可以解决此问题的载体,并得到其他组织和个人的支持。例如,Linux 基金会的 Core Infrastructure Initiative 最近开始部分资助两位 NTP 开发人员:Poul-Henning Kamp 将其可用时间的 60% 用于 NTP 工作,而我将其 NTP 开发工作的 30-50% 用于 NTP 工作。(请访问 http://nwtime.org/ 查看谁在支持网络时间基金会。)
在公共互联网上,NTP 通常在三种类型的机器上可见。一种是嵌入式系统。当供应商错误配置出厂时,这些系统已成为滥用的直接原因(http://en.wikipedia.org/wiki/NTP_server_misuse_and_abuse)。这些系统通常不支持外部监控,因此在本文的上下文中通常不会被滥用。第二组机器是路由器,运行 NTP 的路由器大部分来自 Cisco 和 Juniper。第三组机器往往是运行 win32time 的 Windows 机器(不允许监控,因此既不可监控,也不会在此上下文中被滥用),以及运行 NTP 的 Unix 机器,它们充当本地时间服务器,并将时间分发给局域网上运行 NTP 的其他机器,以保持本地时钟同步。
在 NTP 历史的最初 20 年中,这些本地时间服务器通常是旧的备用机器,运行着各种令人眼花缭乱的操作系统。其中一些机器比其他机器的时间保持得更好,人们最终会将其作为主时间服务器运行。这是 NTP 代码库多年来坚持使用 K&R C(以其作者 Brian Kernighan 和 Dennis Ritchie 命名)的主要原因之一,因为那是某些旧机器上唯一容易获得的编译器。
直到 2006 年 12 月,NTP 才将其代码库从 K&R C 升级到 ANSI C。在很长一段时间内,仅需要 C89。这比 Y2K 晚了整整六年,当时许多旧操作系统已经过时,但仍在生产中。然而,到那时,NTP“容易”运行的硬件已更改为 x86 设备,而 gcc(GNU 编译器套件)是容易的编译器选择。
NTP 代码库的工作做得非常好,非常可靠,并且在安全问题方面拥有令人羡慕的记录。公司和人们经常在某些嵌入式系统上运行此软件的旧版本,这些系统实际上永远不会升级,并且运行良好很长时间。
人们只是期望时间准确,他们很少看到时间不准确的后果。如果时间错误,快速修复它通常更重要,然后——也许——看看是否可以找出原始问题。如果问题频繁发生,则找出问题的几率会增加。去年,NTP 和我们的软件估计运行了超过 1万亿小时。我们在此期间收到了一些错误报告,并且我们有一些未解决的错误报告希望解决,但尽管如此,NTP 通常运行得非常好。
说了这么多,我应该再次强调,NTP 最初是在一个友好的环境中首次亮相的,如果机器上的时间出现问题,尽快解决问题非常重要。多年来,这转化为使人们可以轻松查询 NTP 实例,以查看它一直在做什么。这有两个主要原因:一是很容易查看你要同步的远程服务器是否已配置并运行良好;二是如果出现问题,很容易从其他人那里获得帮助。
虽然多年来我们一直在采取措施使 NTP 更加安全和免受滥用,但在去年秋天,公共互联网上有超过 700 万台可滥用的 NTP 服务器。由于人们升级软件、修复配置文件,或者因为可悲的是,一些 ISP 和 IXP 决定阻止 NTP 流量,可滥用服务器的数量在短短几个月内下降了近 99%。这是一个非常巨大且快速的下降,直到你意识到仍然存在大约 85,000 台可滥用的服务器,并且可以使用 5,000 台服务器发起 50 到 400 Gbps 范围内的 DDoS(分布式拒绝服务)攻击。仍然有很多清理工作要做。
减少甚至消除 DDoS 攻击的最佳和最简单方法之一是确保你的网络上的计算机发送的数据包仅来自你的 IP 空间。为此,你应该访问 http://www.bcp38.info/ 并采取措施为你的网络实施此实践(如果你尚未这样做)。
正如我上面提到的,NTP 在公共互联网上的三个主要位置运行:嵌入式设备;Unix 和一些 Windows 计算机;以及 Cisco 和 Juniper 路由器。在我们研究如何配置后两组设备以防止它们被滥用之前,让我们先看一下 NTP 发布历史。
David L. Mills,现为特拉华大学荣誉教授和兼职教授,于 1980 年为我们带来了 NTP 版本 1。它很好,然后变得更好。“实验性”新版本 xntp2 将主二进制文件安装为 xntpd,因为,嗯,那是将先前版本和新版本同时保留在一个盒子上的简单方法。然后版本 2 变得稳定并成为推荐标准 (RFC 1119),因此开始了 xntp3 的工作。但是主程序仍然安装为 xntpd,即使该程序实际上并不是“实验性的”。请注意,RFC-1305 定义了 NTPv3,但该标准从未最终确定为推荐标准——它仍然是草案/可选标准。NTPv4 的 RFC 仍在开发中,但预计将成为完整的推荐标准。
至于软件发布编号,Mills 的三个版本是 xntp3.3wx、xntp3.3wy 和 xntp3.5f。这些版本来自我开始大量使用 NTP 之后不久,我也在发送可移植性补丁。那时,你解压缩 tarball,手动编辑 config.local 文件,并使用 makefile 做一些有趣的事情来构建代码。虽然 Perl 的 metaconfig 那时可用,并且非常适合在系统上进行探测,但它不支持子目录构建,因此无法为多个目标使用一组源代码。
GNU autoconf 在当时仍然很新,虽然它在探测方面做得不如 metaconfig 好,但它支持子目录构建。xntp3.5f 发布时,我自愿将 NTP 代码库转换为 GNU autoconf。作为转换的一部分,Mills 和我讨论了版本号,他同意我将 GNU autoconf 代码的第一个版本发布为 xntp3-5.80。这些被认为是 alpha 版本,因为 .90 及以上版本保留给 beta 版本。此代码的第一个生产版本将是 xntp3-6.0,即 NTPv3 的第六个主要版本,除了在 1993 年 11 月下旬发布 xntp3-5.93e 后不久,Mills 认为 NTPv3 代码已经足够好,是时候开始 NTPv4 了。
那时,我注意到许多人对版本编号方案有疑问,因为连字符 (-) 和点号 (.) 的使用确实让人困惑。因此,ntp-4.0.94a 是 1997 年 7 月 NTPv4 代码的第一个 beta 版本。发布编号从 ntpPROTO-Maj.Min 变为 ntp-PROTO.Maj.Min。
虽然此更改达到了消除关于如何键入版本号的困惑的预期效果,但这意味着大多数人没有意识到从 ntp-4.1.x 升级到 4.2.x 是一个重大版本升级。人们似乎也不了解在次要版本中修复或改进了多少项。有关此的更多信息,请参见表 1。
一度我尝试回到更接近先前方法的版本编号方案,但我受到了很多反对,所以我没有继续进行。事后看来,我应该坚持立场。在看到人们不欣赏发布的重要性(无论是主要版本还是次要版本)之后,我们将在 4.2.8 发布后恢复到更接近原始方案的编号方案。ntp-4.2.8 之后的下一个主要版本将是 ntp4-5.0.0 或 ntpPROTO-Maj.Min.Point。(我们的源代码档案揭示了多年来发布编号选择是如何演变的,以及其中一些编号的排序有多糟糕。)
在我们深入探讨如何保护 NTP 之前,我建议你听听 Dan Geer 在 Blackhat 2014 上的主题演讲,如果你还没有听过(https://www.youtube.com/watch?v=nT-TGvYOBpI)。这将是非常有价值的一个小时。如果你观看后不同意他所说的,那么我想知道你为什么还在阅读本文以寻找 NTP 滥用向量问题的解决方案。
现在,为了保护 NTP,首先实施 BCP38(http://www.bcp38.info)。这并不难。
如果你想确保 Cisco 或 Juniper 路由器上的 NTP 受到保护,请查阅他们的文档,了解如何操作。你会在 Web 上找到许多关于其他更新信息的良好讨论和文章,我推荐 http://www.team-cymru.org/ReadingRoom/Templates/secure-ntp-template.html,以获取有关保护 Cisco 和 Juniper 路由器上的 NTP 的信息。
NTP 支持站点提供了有关如何通过 ntp.conf 文件保护 NTP 的信息。在 http://nwtime.org/ntp-winter-2013-network-drdos-attacks/ 上找到一些讨论和该站点的链接。NTF 还在收集资源以生成在线 ntp.conf 生成器,该生成器将为此文件实施 BCP,并使其易于随着我们的代码库和知识的演进而更新该文件。
也就是说,从 ntp-4.2.7p27 开始,默认情况下禁用了最重要的 NTP 滥用向量,这些改进以及其他改进将包含在 2014 年底发布的 ntp-4.2.8 中。
对于 4.2.6 到 4.2.7p27 版本,可以通过将以下内容添加到你的 ntp.conf 文件中来防止此滥用向量
restrict default ... noquery ...
请注意,如果你有其他restrict用于 IP 或网络的行,这些行不包含noquery限制,请问问自己,这些 IP 是否有可能被欺骗...
对于 2006 年 12 月发布并在 2009 年 12 月 EOLed(达到生命周期结束)的 4.2.4 版本,请考虑以下事项
• 你没有注意 Dan Geer 所说的话。
• 你是否注意到我们从 4.2.4 到 4.2.6 修复了 630-1,000 个问题?
• 你是否仍然对运行 4.2.4 感兴趣?你真的有充分的理由这样做吗?
如果是,请添加到你的 ntp.conf 文件中
restrict default ... noquery ...
对于 2006 年 6 月发布并在 2006 年 12 月 EOLed 的 4.2.2 版本
• 你没有注意 Dan Geer 所说的话。
• 你是否注意到我们从 4.2.2 到 4.2.4 修复了大约 450 个问题,从 4.2.4 到 4.2.6 修复了 630-1,000 个问题?那是在 1,000 到 1,500 个问题之间。认真地。
• 你是否仍然对运行 4.2.2 感兴趣?你真的有充分的理由这样做吗?
如果是,请添加到你的 ntp.conf 文件中
restrict default ... noquery ...
对于 2003 年发布并在 2006 年 EOLed 的 4.2.0 版本
• 你没有注意 Dan Geer 所说的话。
• 你是否注意到我们从 4.2.0 到 4.2.2 修复了大约 560 个问题,从 4.2.2 到 4.2.4 修复了 450 个问题,从 4.2.4 到 4.2.6 修复了 630-1,000 个问题?那是在 1,500 到 2,000 个问题之间。认真地。
• 你是否仍然对运行 4.2.2 感兴趣?你真的有充分的理由这样做吗?
如果是,请添加到你的 ntp.conf 文件中
restrict default ... noquery ...
对于 4.0 到 4.1.1 版本,这些版本在 2001 年到 2003 年左右发布和 EOLed,没有关于在这些版本中修复了多少问题的数字
• 你没有注意 Dan Geer 所说的话。
• 自那时以来,可能修复了超过 2,000-2,500 个问题。
• 你是否仍然对运行 4.0 或 4.1 代码感兴趣?你真的有充分的理由这样做吗?
如果是,请添加到你的 ntp.conf 文件中
restrict default ... noquery ...
现在让我们谈谈 xntp3,它在 1997 年 9 月 EOLed。计算一下它有多旧,猜测一下自那时以来修复了多少问题,并问问你自己以及任何对此有发言权的人:为什么要运行 17 年前 EOLed 的软件,那时已经修复了数千个问题,并且从那时起实施了改进的协议?
如果你的答案是:“因为 NTPv3 是一个标准,而 NTPv4 还不是一个标准”,那么我有一个坏消息要告诉你。NTPv3 不是 推荐标准;它只是一个草案/可选标准。如果你真的只想运行官方标准软件,你可以退回到 NTPv2——而且我不认识任何想要这样做的人。
如果你的答案是:“我们不确定 NTPv4 有多稳定”,那么我会指出 NTPv4 在这一点上估计有 5-10 万亿小时的运行时间。你还想要多少?
但是如果你坚持要使用旧版本,那么保护 xntp2 和 xntp3 免受所述滥用向量攻击的方法是在你的 ntp.conf 文件中添加
restrict default ... noquery ...
喜欢它,讨厌它?请告诉我们
Harlan Stenn 在 PDP-8/S(主要是 FOCAL 和汇编程序)上学习编程,它有 4 KB 的真实磁芯内存,大约在他学会开车的同时。在帮助其他公司编写和维护可移植的 Unix 软件时,他发现了对同步时间的需求(以构建存储在 NFS 文件系统上的软件),这使他接触了“timed”和“ntp”。他开始向 David Mills 提交 NTP 补丁,这导致他将 NTP 代码库转换为使用 GNU Autoconf 作为其构建系统。然后他成为 NTP 的发布工程师和错误修复集成商。从那里,他成为 NTP 项目经理。看到志愿者团队无法跟上不断增加的工作量,他于 2011 年创立了网络时间基金会,这是一家公益公司,其使命是改善计算机网络授时的状态,致力于支持 NTP(网络时间协议)、PTP(精确时间协议)和其他与时间相关的项目。
© 2014 1542-7730/14/1200 $10.00
互联网上鲁棒时序的原理
通过网络同步时钟的关键是驯服延迟变化。
- Julien Ridoux 和 Darryl Veitch
每个人,以及大多数事物,都需要时钟,计算机也不例外。然而,如果时钟任其自行漂移,它们往往会漂移,因此有必要通过同步到某些更高精度的参考时钟来定期纠正它们。一种廉价且方便的方法是通过计算机网络进行同步。
迈向更高的精度
PTP 及其对 NTP 从业者的意义简介
- Rick Ratzel 和 Rodney Greenstreet
同步时间对现代计算机系统的重要性怎么强调都不过分。我们今天的生命依赖于金融交易、电信、发电和输电、高速制造以及“大型物理学”中的发现等等,这些都由快速、强大的计算设备相互协调时间驱动。
一秒钟战争(你什么时候死?)
随着越来越多的系统关注秒级和亚秒级时间,寻找持久解决闰秒问题的方案变得越来越紧迫。
- Poul-Henning Kamp
感谢主要在公众视线之下秘密运作的阴谋,你的死亡时间可能会比目前预期的晚一分钟。但是不要期望活得更久,除非你碰巧负责大型计算机网络中的时间同步,在这种情况下,这场政变将每隔一年左右降低你的压力水平。
最初发表于 Queue vol. 13, no. 1—
在 数字图书馆 中评论本文
David Collier-Brown - 你根本不懂带宽
当你的员工或客户说他们的互联网性能很差时,带宽可能不是问题。一旦他们拥有 50 到 100 Mbps 范围内的带宽,问题就是延迟,即 ISP 的路由器处理他们的流量需要多长时间。如果你是一家 ISP,并且所有客户都讨厌你,请振作起来。由于一群敬业的人员追查、消灭并随后在家用路由器中验证了他们的解决方案,现在这是一个可以解决的问题。
Geoffrey H. Cooper - 使用 FDO 和不受信任的安装程序模型进行设备入职
设备的自动入职是处理正在安装的越来越多的“边缘”和 IoT 设备的重要技术。设备的入职与大多数设备管理功能不同,因为设备的信任从工厂和供应链转移到目标应用程序。为了通过自动入职加快流程,必须在设备中形式化供应链中的信任关系,以允许自动化过渡。
Brian Eaton, Jeff Stewart, Jon Tedesco, N. Cihan Tas - 通过关键路径跟踪进行分布式延迟分析
低延迟是许多 Google 应用程序(如搜索)的重要功能,而延迟分析工具在维持大规模低延迟方面发挥着关键作用。对于包括功能和数据不断演变的服务在内的复杂分布式系统,将总体延迟保持在最低水平是一项具有挑战性的任务。在大型、真实的分布式系统中,诸如 RPC 遥测、CPU 分析和分布式跟踪之类的现有工具对于理解整个系统的子组件很有价值,但不足以在实践中执行端到端延迟分析。
David Crawshaw - VPN 一切焕然一新
VPN(虚拟专用网络)已经有 24 年的历史了。这个概念是为与我们今天所知的互联网截然不同的互联网而创建的。随着互联网的增长和变化,VPN 用户和应用程序也随之变化。在 2000 年代的互联网中,VPN 经历了一个尴尬的青春期,与其他广泛流行的抽象概念交互不良。在过去的十年中,互联网再次发生了变化,这个新的互联网为 VPN 提供了新的用途。一种全新的协议 WireGuard 的开发为构建这些新的 VPN 提供了技术基础。