TCP时间戳有啥好处？

Posted 2023-04-14

【中文标题】TCP时间戳有啥好处？

【英文标题】：What benefit is conferred by TCP timestamp?TCP时间戳有什么好处？

【发布时间】：2011-12-14 09:19:21

【问题描述】：

我的安全扫描发现指示我禁用 TCP 时间戳。我理解推荐的原因：时间戳可用于计算服务器正常运行时间，这对攻击者很有帮助（在 http://www.silby.com/eurobsdcon05/eurobsdcon_silbersack.pdf 的“TCP 时间戳”标题下有很好的解释）。

但是，据我了解，TCP 时间戳旨在提高 TCP 性能。自然，在成本/收益分析中，性能下降是一个很大的成本，可能太大了。我很难理解可能会有多少（如果有的话）性能成本。 hivemind 中的任何节点都愿意提供帮助吗？

【问题讨论】：

我同意，夸大安全方面并无视网络工程师发明 tcp 时间戳的专业知识是有风险的。操作系统可以更改其 tcp 时间戳的实现，以避免提取正常运行时间。对于 linux，请参阅我的回答 security.stackexchange.com/a/224696/90485

【参考方案1】：

答案最简洁的表达在RFC 1323 - Round-Trip Measurement...对RFC的介绍也提供了一些相关的历史背景...

   Introduction

   The introduction of fiber optics is resulting in ever-higher
   transmission speeds, and the fastest paths are moving out of the
   domain for which TCP was originally engineered.  This memo defines a
   set of modest extensions to TCP to extend the domain of its
   application to match this increasing network capability.  It is based
   upon and obsoletes RFC-1072 [Jacobson88b] and RFC-1185 [Jacobson90b].


  (3)  Round-Trip Measurement

       TCP implements reliable data delivery by retransmitting
       segments that are not acknowledged within some retransmission
       timeout (RTO) interval.  Accurate dynamic determination of an
       appropriate RTO is essential to TCP performance.  RTO is
       determined by estimating the mean and variance of the
       measured round-trip time (RTT), i.e., the time interval
       between sending a segment and receiving an acknowledgment for
       it [Jacobson88a].

       Section 4 introduces a new TCP option, "Timestamps", and then
       defines a mechanism using this option that allows nearly
       every segment, including retransmissions, to be timed at
       negligible computational cost.  We use the mnemonic RTTM
       (Round Trip Time Measurement) for this mechanism, to
       distinguish it from other uses of the Timestamps option.

您因禁用时间戳而招致的具体性能损失取决于您的特定服务器操作系统以及您的操作方式（例如，请参阅PSC doc on performance tuning）。某些操作系统要求您一次启用或禁用所有 RFC1323 选项...其他操作系统允许您有选择地启用 RFC 1323 选项。

如果您的虚拟服务器以某种方式限制了您的数据传输（也许您只购买了便宜的虚拟主机计划），那么也许您无论如何都无法使用更高的性能......也许值得关闭它们尝试一下。如果这样做，请务必在多个不同位置对您的前后表现进行基准测试（如果可能）。

【讨论】：

谢谢。正是我需要更好地理解这个问题的摘要。

附加注释：启用时间戳会增加您的流量开销，因为这 9 个字节不是“有用”，因为它们不是有效负载数据。

@Astaar，TCP 时间戳选项是 10 个字节而不是 9 个字节。

【参考方案2】：

为什么安全人员希望您禁用时间戳？时间戳代表什么可能的威胁？我敢打赌 NTP 工作人员会对此不满意 ;^)

启用 TCP 时间戳后，您可以猜测目标系统的正常运行时间 (nmap v -O 。了解系统已运行多长时间将使您能够确定是否已应用需要重新启动的安全补丁。

【讨论】：

您建议nmap -v -O example.org 可以提供目标的正常运行时间，但是这个结果如何显示？我在一个实现 TCP 时间戳的测试系统上进行了尝试，但我无法得到结果。

【参考方案3】：

致丹尼尔和其他任何想要澄清的人：

http://www.forensicswiki.org/wiki/TCP_timestamps

“TCP 时间戳用于提供对包装序列号的保护。可以通过分析 TCP 时间戳来计算系统正常运行时间（和启动时间）（见下文）。 这些计算出的正常运行时间（和启动时间）有助于检测隐藏的启用网络的操作系统（请参阅 TrueCrypt）、将欺骗性 IP 和 MAC 地址链接在一起、将 IP 地址与 Ad-Hoc 无线 AP 链接等。”

这是一个在 PCI 合规性中表示的低风险漏洞。

【参考方案4】：

今天我被问到关于这个主题的类似问题。我的看法如下：

未修补的系统是漏洞，而不是攻击者是否可以轻松找到它。因此，解决方案是定期修补您的系统。禁用 TCP 时间戳不会使您的系统不那么容易受到攻击 - 它只是通过默默无闻的安全性，这根本不是安全性。

反过来，考虑编写一个解决方案脚本，该解决方案使用 TCP 时间戳来识别网络上正常运行时间最长的主机。这些通常是您最容易受到攻击的系统。使用此信息确定修补的优先级，以确保您的网络受到保护。

不要忘记，正常运行时间等信息对您的系统管理员也很有用。 :)

【参考方案5】：

我不会这样做。

如果没有时间戳，TCP 防止包装序列号 (PAWS) 机制将无法工作。它使用时间戳选项来确定突然和随机的序列号更改是一个包装（16 位序列号）而不是来自另一个流的疯狂数据包。

如果你没有这个，那么你的 TCP 会话将根据它们使用序列号空间的速度每隔一段时间打嗝。

来自 RFC 1185：

ARPANET       56kbps       7KBps    3*10**5 (~3.6 days)
DS1          1.5Mbps     190KBps    10**4 (~3 hours)
Ethernet      10Mbps    1.25MBps    1700 (~30 mins)
DS3           45Mbps     5.6MBps    380
FDDI         100Mbps    12.5MBps    170
Gigabit        1Gbps     125MBps    17

以 45Mbps（完全在 802.11n 速度范围内），然后我们每约 380 秒就会打嗝一次。不可怕，但很烦人。

为什么安全人员希望您禁用时间戳？时间戳代表什么可能的威胁？我敢打赌 NTP 工作人员会对此不满意 ;^)

嗯，我读过一些关于使用 TCP 时间戳来猜测发送方时钟频率的内容？也许这就是他们害怕的东西？我不知道;^)

时间戳对 RTT 估计的重要性没有您想象的那么重要。我碰巧喜欢它们，因为它们对于确定接收器或中间盒的 RTT 很有用。但是，根据 TCP 的大炮，只有发送方需要这种禁止知识 ;^)

发送者不需要时间戳来计算 RTT。 t1 = 我发送数据包时的时间戳，t2 = 我收到 ACK 时的时间戳。 RTT = t2 - t1。稍微平滑一下，你就可以开始了！

...丹尼尔

【讨论】：

你说的 TCP 打嗝是什么意思，TCP 连接会被断开或者只是一些性能损失？

@misteryes：我猜它需要重新建立，因为如果超出 2^16 范围，序列号对接收器没有意义。也就是说，在 32 位地址空间中回绕是可以的，但是如果它前进超过 2^16 则连接将断开。

@misteryes：其实想多了，因为TCP包的最大大小是65535字节（2^16 - 1），下一个包会落入这个范围，就是后面的将在它之外并且只需要重新传输的数据包（只是在几分钟内自相矛盾）。

"发送者不需要时间戳来计算 RTT。" - 它在重传时需要。如果没有 TCP 时间戳，则无法知道发送方收到的 ACK 来自原始传输还是重传。因此，当发生重传时，直到接收到没有重传的 ACK 才能确定 RTT。当发生多次重传时，这可能会导致异常行为，因为发送方可能会减慢到每 120 秒发送一个数据包的最低速度。