System hardening & Time attacks & TCP timestamps=0

On the topic of hardening your (host) and the danger of time leaks Whonix advises to disable TCP timestamps via kernel sysctl. I just did, my question is if this is useful and/or effective?

  1. https://security.stackexchange.com/questions/111794/ros-and-cons-of-disabling-tcp-timestamps

Under the original question Aiuti Marble makes the following comment:

In modern Linux (i.e. Ubuntu 16, 18) changing the value of net.ipv4.tcp_timestamps has no effect. The documentation at kernel org doc Documentation networking ip-sysctl.txt is incorrect for modern kernels.

Ajuti does not substantiate his claim by pointing to relevant sources, but … is he right?

  1. As I work with Ubuntu 18.04 as host, I found this in the Ubuntu manual on sysctl(d)

Many sysctl parameters only become available when certain kernel modules are loaded. Modules are usually loaded on demand, e.g. when certain hardware is plugged in or network brought up. This means that systemd-sysctl.service(8) which runs during early boot will not configure such parameters if they become available after it has run. To set such parameters, it is recommended to add an udev(7) rule to set those parameters when they become available. Alternatively, a slightly simpler and less efficient option is to add the module to modules-load.d(5), causing it to be loaded statically before sysctl settings are applied (see example below).

So we set the sysctl net.ipv4.tcp_timestamps parameter, but is it applied?? Maybe Whonix knows for sure this is the case, otherwise this feature should be tested by looking at TCP packets going out.

1 Like

Interesting line of thought. Thanks for bringing that up!

Applying sysctl setting already from inside initramfs was recently implemented.

But this might not help against what you are raising.

I don’t think we will be able to investigate this soon. “Fortunately”, this is a general security question as also your link to https://security.stackexchange.com/questions/111794/pros-and-cons-of-disabling-tcp-timestamps indicates. The scope of this issue by far transcends Whonix. Meaning, it doesn’t need to necessarily wait until anyone from the small resourceful Whonix team can investigate this.

Could you please try to resolve this as per free support principle.

Potential recipients:

Please post any references here.

1 Like

TCP timestamps are not part of a kernel module. Neither are any of the other sysctl settings we change.

Changing net.ipv4.tcp_timestamps does have effect. This is easily verified with something like nmap.

You can also verify the sysctl settings are correctly applied by running e.g. sysctl net.ipv4.tcp_timestamps and look for the correct value which in this case is 0.

I still am skeptical of the claim that disabling TCP timestamps improves anonymity though as newer kernel versions randomize the offset for each connection, making time attacks impossible unless something messes up in the randomization https://github.com/torvalds/linux/commit/95a22caee396cef0bb2ca8fafdd82966a49367bb


Wireshark logs should answer the question.


True. I can see (in Wireshark) that manually setting and applying the parameter (i.e. setting it to 0) does have the effect of suppressing TCP timestamps. Tomorrow I will see if the setting does get applied automatically when booting the system.


I am a little late to the conversation, but I can verify what has been said here.
Ubuntu 18.04 with various kernels from 4.15 to 5.3 are used daily. This sysctl parameter I have had implemented for a long time (at least as long as it became relevant in Whonix with security-misc). Systemd-sysctl is a service that runs at boot and is active before sysinit.target. Right after systemd-modules load finishes, systemd-sysctl runs and applies everything in sysctl.conf according to the service file (and verified from a syslog search).
Also, as mentioned, Wireshark can show you this information in real time capture, or as a pcap that you can view later. Conclusion is that the parameter is applied.
For the setting to be effective, remember to disable systemd-timesyncd, and also ntp if you use that. Or use sdwdate on a torified system. Ideally set machine time to UTC as well.


Booted the host after setting the TCP timestamp parameter to 0. I only saw TCP traffic without these timestamps. For Whonix traffic the setting does not matter it seems. Even when the timestamp parameter is set to 1, I did not see the timestamps.


rk1, that’s interesting; since you already tried this on Whonix, here is what happened with non-Whonix (Debian 10, full updated etc, but completely vanilla–no security mods or anything. Just how it would be if you installed a fresh system. I did this in a virtual machine using the latest Debian iso from their site. Then I tested on an Ubuntu 18.04 host with the same results. The Ubuntu is heavily modified, security hardened etc)
Here are my observations:
Okay, this is my accepted conclusion. Originally, I had forgotten to reboot the system and the sysctl setting net.ipv4.tcp_timestamps= did not apply. Interesting that sudo sysctl -p did not apply it. Maybe I could have restarted networking service also? Anyway, here is how I proceed:
Wireshark has a setting filter: tcp.options.timestamp.tsval which will show the timestamp values for the packets in the capture. With the live capture running and the sysctl setting for net.ipv4.tcp_timestamps= set to ‘0’ there was nothing to see, totally blank after the filter was applied. Then setting the sysctl value to ‘1’ and reboot and re-test of the filter value showed a full list of timestamps for the tcp packets. (Wireshark has a couple different ways to view time-related data. Go to View and then Time Display Format to toggle the different values.) So it appears that in Debian 10 and Ubuntu 18.04, the sysctl tcp timestamp setting is fully functional.
Normally, AFAIK, the tcp-timestamp is a total of 10 bytes. 4 bytes sent, 4 bytes ACK’d and then 2 bytes I do not know what they are for. One could analyze the individual packets to see if this 10 bytes was included in the payload header. I have not done this, but it probably would not be too hard to do. The presence of this 4byte + 4byte + 1byte +1byte would indicate tcp timestamp. The absence would indicate no timestamp. This could be another way to test.

1 Like

Your conclusions are not much different from mine, that is: you tested a non-Whonix system, setting and applying (via booting) the parameter net.ipv4.tcp_timestamps to 0 suppresses the timestamps, setting it to 1 inserts the timestamps in the TCP layer. That is what I found too (“Booted the host after setting the TCP timestamp parameter to 0. I only saw TCP traffic without these timestamps.”). But whereas you say that running the command ‘sysctl -p’ does not apply the setting, I saw that ‘sysctl -p’ did work.
For the Whonix system (the guest OS run in KVM) I observed that setting and applying the parameter did not seem to matter, as either way (0 or 1) TCP traffic did not include the TCP timestamps.
What you say in your last comment about inspecting the individual packets: that is how I did my testing.
And just for info, this is how the timestamps look like (RFC 7323):

1 Like

Regarding the sysctl -p; there were a couple things going on at the time with the system, as far as I was doing several things at once, so it is very possible that I simply forgot something or got distracted. In all other instances, as we know, a sysctl -p run as root/sudo privs will apply the settings right away.
That snippet you posted is exactly what I was referring to! That page and ones linked from it have been very helpful in my study of networking.
I have not tested the timestamp setting in Whonix, mainly because you already did it and shared your results and also wireshark pulls in a ton of dependencies. It’s interesting that the setting does not seem to affect anything. So it seems that in Whonix, tcp timestamps are disabled by default. Perhaps it’s due to another setting somewhere in “security-misc” or somewhere else.
Another good practice might be to disable timestamps on the host. I can speak for Virtualbox’s networking and say that everything that the virtual machine does is NAT’d to and processed by the host. I am not completely sure if disabling the setting on the host is necessary, but I do it anyway.

[Imprint] [Privacy Policy] [Cookie Policy] [Terms of Use] [E-Sign Consent] [DMCA] [Investors] [Priority Support] [Professional Support]