时钟不准，记录就不能当证据

一句话总结

隔离网络中没有外部时间源。在网络内部建立的时间源，只能让各主机之间的相对顺序保持一致，并不能保证绝对时间，而不了解这个差别、就写下“记录是准确的”的陈述书，在监理中会一击即溃。

为什么需要它

故障调查也好，审计应对也好，最终问的都是“什么先发生”。但记录中的时间，是留下该记录的机器的时钟所显示的值，而每台机器的时钟都不同。相差几秒，人还会察觉；相差 2 秒左右，则没有人会注意到，却把因和果颠倒了。实际上，调查中最常出现偏差的就是这个位置。如果看上去部署发生在故障之后，调查就会走向错误的方向。

在能连通互联网的地方，这个问题通常会悄无声息地被解决。只要看着几台公共 NTP 服务器，时钟就会自行收敛。在隔离网络中，这个前提消失了。网络内建立一个时间源，所有人都向它对齐，而这个时间源自己却没有可以对齐的外部对象。在 RFC 5905 所定义的层级（stratum）中，这样的时间源处在以自身为基准的位置上。结果，网络内所有的记录彼此一致，但整体比外部世界快了或慢了多少，没有人能说清。这个事实如果不写进陈述书，日后就会出问题。

工作原理

判定分四层叠加。

第一，统一表示方式。即使在同一个系统内，日志的时间表示也各不相同。带偏移量的 ISO 8601、不带偏移量的本地时间、epoch 秒数，以及末尾带 Z 的 UTC。其中最危险的是不带偏移量的时间。把它当作 UTC 来读，在韩国时区会整整偏移九个小时。仅看日志文件无法知道是哪一种，所以这个事实必须从系统文档中获取，陈述书中也要写明依据。RFC 3339 规定偏移量为必需，原因就在于此。

第二，沿着层级追踪。一步一步追踪每台主机从哪里获取时间，大多数都能到达所声明的时间源。到不了的主机才是问题。配置被删除、仍在使用自己时钟的主机，会不断打出看上去毫无问题的时间，所以仅看日志无法区分。沿着层级一直追到底，是唯一的办法。

第三，找出记录互相冲突的位置。在两台主机互相收发的请求和响应中，如果有响应早于请求的案例，就意味着两个时钟至少相差这么多。这不是推测，而是下限。这个值是因为发送方和接收方用不同的时钟给同一个事件打了时间而产生的，与同步报告中的偏移量比较，也可以确认报告是否属实。

第四，查看校正之后剩下的东西。用偏移量校正之后，大部分矛盾都会消失。如果还剩下不消失的，那就不是时钟问题，而是记录本身的缺陷。区分这两者，是这项工作的核心。能用校正解释的区间，可以有条件地使用；不能解释的区间，不能作为证据使用。

还有一点。时钟同步并不能证明那条记录在那个时间点就已经存在。那是另一个层面的事，需要像 RFC 3161 的时间戳那样由第三方签名的结构。把同步与时间戳说成同一回事的陈述书，会失去信任。关于日志管理的一般问题，NIST SP 800-92 把时间同步作为日志可信性的前提来论述。

在现场相遇的样子

在一个隔离网络的交付项目中，调查白白空转了两天。因为看上去批处理作业比它被放入队列的时间更早被处理。原因是处理节点的时钟快了 2.4 秒，而同步报告中原样写着这个值。只是没有人把这份报告和日志放在一起看。校正之后剩下的矛盾只有一处，而那一处才是真正的缺陷。

另一个常见的是把自己写成时间源的主机。这是安装过程中把配置删了一次，之后没有恢复，而该主机的日志一直打出貌似合理的时间。在把层级画成图之前，它不会暴露。

第三个是陈述书的措辞。移交调查结果时，很容易想写“时间是准确的”，但这句话没有数据支撑。数据能够支撑的是：“这个区间的记录彼此不矛盾，并且可以用所报告的偏移量来解释。”这个区别不是文字游戏。日后哪怕有一处对不上，写了前一句的陈述书会整个失去信任，写了后一句的陈述书只需要重新查看那一处。监理方喜欢的文档，不是下断言的文档，而是把确认了什么、未能确认什么分开写明的文档。

下一项实验要做什么

你将把表示方式分为四种的五台主机的日志汇集到同一条轴上，统计把不带偏移量的日志误当作 UTC 来读时，会有多少条记录偏移多少。接着沿着时间层级追踪，找出到不了所声明时间源的主机，通过请求与响应的矛盾求出时钟误差的下限，再进行校正。最后给每台主机的记录评定可信程度的等级，并撰写同时写明哪些可以相信、哪些不能相信的陈述书。