Server 2012 R2 TCP Timestamps

Question

We will be having some penetration testing performed shortly and looking to clean up a few things. One of these is TCP timstamps in Windows. A simiple NMAP scan shows me a guess of the TCP timestamp that is actually quite accurate. We run Sonicwall firewalls and tech support tells me that it is unable to remove timestamps at the firewall level. Looking at the windows environment, it seems the following commands should work:

To set using netsh:

netsh int tcp set global timestamps=disabled

To set using PowerShell cmdlets:

Set-NetTCPSetting -SettingName InternetCustom -Timestamps Disabled

After applying and a server reboot, NMAP still seems to show timestamps.

Has anyone had any luck with this? Or am i the only person attempting this :) It does not seem to be recommended, so how do you handle this?

Thanks.

Solution

TCP timestamps are used to improve performance as well as protect against late packets messing up your data flow. If you disable TCP timestamps you should expect worse performance and less reliable connections. This is the case regardless of the method used to disable TCP timestamps.

Any modifications made to packets by a middlebox can cause additional problems, because TCP endpoints are not required to take such modifications into account.

TCP timestamps are required to grow monotonically over time. Thus they are necessarily predictable. I have seen no documentation of this predictability being a problem.

It is technically possible to vary an initial offset and growth rate such that the timestamps you send to one IP address cannot be used to predict timestamps you would send to another IP address.

So my recommendation is clear.

• Do not mess with timestamps on the firewall.
• Request additional information from the pentester documenting why predictable timestamps would be a problem as well as recommended configuration of the endpoint.
• Apply configuration settings to the endpoint as needed.

Comments

[Brian]

Does the test pass before the reboot? It may be an ordering problem on boot with the TCP offload engine of network adapters not picking up the setting and putting timestamps in. If so running the command to disable timestamps after the main network interface comes up may help.

[TheITGuy]

Thanks for the response. The concern is that it is able to return a 'guess' of the server up-time - and therefore, indicate restart times and related patching levels. Whilst i agree with your post, it is something that has been highlighted in the past. I guess i might have to see their response this time around.