Pros and cons of disabling TCP timestamps

Question

So, lynis informs me that I should unset net.ipv4.tcp_timestamps. I know that's a bad thing because an attacker could figure out which updates that require restarting the machine I haven't applied, or they could use it to figure out my update schedule and try to attack in the brief interval during which the machine's restarting but before the firewall comes online, or something else I haven't thought of.

I understand it's not ideal.

However, according to RFC 1323 (and this):

The timestamps are used for two distinct mechanisms: RTTM (Round Trip Time Measurement) and PAWS (Protect Against Wrapped Sequences)

Those also seem like nice, useful things to have. That having been said, IIRC from my networking classes that RTTM method definitely isn't necessary for determining RTT, and TCP's sliding window makes sequence wraparound issues unlikely, but since this isn't one of the joke RFCs I'm assuming they had a good reason for proposing these things and implementors had a good reason for implementing them.

Are there any (likely) disadvantages / negative usability or security implications to disabling this feature?

Additionally, is there any way I can both have and eat my cake (by, for example, telling the kernel to initialize with a random value and introduce jitter into the period of the timestamp updates, or initializing it with some of the bits of the system clock, so they can't use a sudden, large change in timestamp to tell a reboot recently occurred)?

Answer 1

The disadvantage would be that the TCP sequence could wrap. This is a risk on very high speed networks. You can randomize the initial timestamp, however, just as you asked. It's a very simple patch, so any rejects will be trivial to fix. It requires the grsecurity patchset to already be applied.

From https://grsecurity.net/~spender/random_timestamp.diff:

diff --git a/grsecurity/Kconfig b/grsecurity/Kconfig
index 3abaf02..700e56c 100644
--- a/grsecurity/Kconfig
+++ b/grsecurity/Kconfig
@@ -925,6 +925,16 @@ config GRKERNSEC_RANDNET
      here.  Saying Y here has a similar effect as modifying
      /proc/sys/kernel/random/poolsize.

+config GRKERNSEC_RANDOM_TIMESTAMPS
+   bool "Add random offset to TCP timestamps"
+   default y if GRKERNSEC_CONFIG_AUTO
+   help
+     If you say Y here, a simple change will be made to TCP timestamp
+     behavior that will prevent the system from leaking the jiffies
+     value remotely to an attacker who has not been persistently
+     monitoring the system since boot.  The jiffies value can be used
+     to remotely determine system uptime.
+
 config GRKERNSEC_BLACKHOLE
    bool "TCP/UDP blackhole and LAST_ACK DoS prevention"
    default y if GRKERNSEC_CONFIG_AUTO
diff --git a/grsecurity/grsec_init.c b/grsecurity/grsec_init.c
index ae6c028..c7dbe97d 100644
--- a/grsecurity/grsec_init.c
+++ b/grsecurity/grsec_init.c
@@ -7,6 +7,11 @@
 #include <linux/percpu.h>
 #include <linux/module.h>

+#ifdef CONFIG_GRKERNSEC_RANDOM_TIMESTAMPS
+__u32 random_timestamp_base __latent_entropy;
+EXPORT_SYMBOL_GPL(random_timestamp_base);
+#endif
+
 int grsec_enable_ptrace_readexec;
 int grsec_enable_setxid;
 int grsec_enable_symlinkown;
diff --git a/include/net/sock.h b/include/net/sock.h
index b2948c0..ccbeda9 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -2296,4 +2296,8 @@ extern int sysctl_optmem_max;
 extern __u32 sysctl_wmem_default;
 extern __u32 sysctl_rmem_default;

+#ifdef CONFIG_GRKERNSEC_RANDOM_TIMESTAMPS
+extern __u32 random_timestamp_base;
+#endif
+
 #endif /* _SOCK_H */
diff --git a/include/net/tcp.h b/include/net/tcp.h
index 44a58b0..fcdca06 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -684,7 +684,11 @@ void tcp_send_window_probe(struct sock *sk);
  * to use only the low 32-bits of jiffies and hide the ugly
  * casts with the following macro.
  */
+#ifdef CONFIG_GRKERNSEC_RANDOM_TIMESTAMPS
+#define tcp_time_stamp     ((__u32)(jiffies) + random_timestamp_base)
+#else
 #define tcp_time_stamp     ((__u32)(jiffies))
+#endif

 #define tcp_flag_byte(th) (((u_int8_t *)th)[13])

diff --git a/net/core/dev.c b/net/core/dev.c
index f3e28ec..8b1cf12 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -6986,6 +6986,10 @@ static int __init net_dev_init(void)

    BUG_ON(!dev_boot_phase);

+#ifdef CONFIG_GRKERNSEC_RANDOM_TIMESTAMPS
+   random_timestamp_base += prandom_u32();
+#endif
+
    if (dev_proc_init())
        goto out;

Note that newer kernels have integrated something similar to this in the time since this was posted.

Answer 2

linux: no more kernel patches.

On newer kernels, you can use net.ipv4.tcp_timestamps = 1

Enable timestamps as defined in RFC1323 and use random offset for each connection rather than only using the current time

They choose to change the semantic: in old kernels, tcp_timestamps = 1 enables timestamps backed by time.

Now to get the old behaviour, you have to set tcp_timestamps = 2

I think they choose to change the default behaviour because there isn't any adverse effect on normal users.

Answer 3

Another advantage is that, according to RedHat, it reduces performance spikes associated with the timestamp generation.