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?
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?
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.
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 network - Pros and cons of disabling TCP timestamps - Information Security Stack Exchange 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.
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.
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.
@anontor:
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):
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.
