What benefit is conferred by TCP timestamp?

问题:

I have a security scan finding directing me to disable TCP timestamps. I understand the reasons for the recommendation: the timestamp can be used to calculate server uptime, which can be helpful to an attacker (good explanation under heading "TCP Timestamps" at http://www.silby.com/eurobsdcon05/eurobsdcon_silbersack.pdf).

However, it's my understanding that TCP timestamps are intended to enhance TCP performance. Naturally, in the cost/benefit analysis, performance degradation is a big, possibly too big, cost. I'm having a hard time understanding how much, if any, performance cost there is likely to be. Any nodes in the hivemind care to assist?

回答1:

The answer is most succinctly expressed in RFC 1323 - Round-Trip Measurement... The introduction to the RFC also provides some relevant historical context...

   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.

The specific performance penalty you incur by disabling timestamps would depend on your specific server operating system and how you do it (for examples, see this PSC doc on performance tuning). Some OS require that you either enable or disable all RFC1323 options at once... others allow you to selectively enable RFC 1323 options.

If your data transfer is somehow throttled by your virtual server (maybe you only bought the cheap vhost plan), then perhaps you couldn't possibly use higher performance anyway... perhaps it's worth turning them off to try. If you do, be sure to benchmark your before and after performance from several different locations, if possible.

回答2:

To Daniel and anyone else wanting clarification:

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

"TCP timestamps are used to provide protection against wrapped sequence numbers. It is possible to calculate system uptime (and boot time) by analyzing TCP timestamps (see below). These calculated uptimes (and boot times) can help in detecting hidden network-enabled operating systems (see TrueCrypt), linking spoofed IP and MAC addresses together, linking IP addresses with Ad-Hoc wireless APs, etc."

It's a low-risk vulnerability denoted in PCI compliancy.

回答3:

Why would the security people want you to disable timestamps? What possible threat could a timestamp represent? I bet the NTP crew would be unhappy with this ;^)

The TCP Timestamp when enabled will allow you to guess the uptime of a target system (nmap v -O . Knowing how long a system has been up will enable you to determine whether security patches that require reboot has been applied or not.

回答4:

I wouldn't do it.

Without timestamp the TCP Protection Against Wrapped Sequence numbers (PAWS) mechanism wont work. It uses the timestamp option to determine the sudden and random sequence number change is a wrap (16 bit sequence numbers) rather than an insane packet from another flow.

If you don't have this then your TCP sessions will burp every once in a while according to how fast they are using up the sequence number space.

From 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

Take 45Mbps (well within 802.11n speeds), then we would have a burp every ~380 seconds. Not horrible, but annoying.

Why would the security people want you to disable timestamps? What possible threat could a timestamp represent? I bet the NTP crew would be unhappy with this ;^)

Hmmmm, I read something about using TCP timestamps to guess the clock frequency of the sender? Maybe this is what they are scared of? I don't know ;^)

Timestamps are less important to RTT estimation than you would think. I happen to like them because they are useful in determining RTT at the receiver or a middlebox. However, according to the cannon of TCP, only the sender needs such forbidden knowledge ;^)

The sender does not need timestamps to calculate the RTT. t1 = timestamp when I sent the packet, t2 = timestamp when I received the ACK. RTT = t2 - t1. Do a little smoothing on that and you are good to go!

...Daniel

回答5:

I got asked a similar question on this topic, today. My take is as follows:

An unpatched system is the vulnerability, not whether attacker(s) can easily find it. The solution, therefore, is to patch your systems regularly. Disabling TCP timestamps won't do anything to make your systems less vulnerable - it's simply security through obscurity, which is no security at all.

Turning the question on its head, consider scripting a solution that uses TCP timestamps to identify hosts on your network that have the longest uptimes. These will typically be your most vulnerable systems. Use this information to prioritise patching, to ensure that your network remains protected.

Don't forget that information like uptime can also be useful to your system administrators. :)