Tcp timestamp cant be reliably disabled in Vista, Win2008 (R2), Win2012

ICMP timestamp requests are different from TCP timestamps
Could you please share exhibit text from your scanner? It is hard to guess which is at fault

A1: run netsh in interactive mode, you may find where tcpip options are
A2: windows firewall does not filter TCP options
A3: default windows firewall can block it 'netsh firewall set icmpsetting 13 disable'
A4: Might be true indeed then 'netsh int tcp global timestamps=disabled' may disable TCP timestamps
A5: Tcp1323Opts=1 is more adequate

Sure reboot is needed after each change, and in some forums it says TCP timestamps still are not completely disabled.

Thanks guys.

>please share exhibit text from your scanner?
I can't as this is done by external security consultants engaged by our customers : the customers
won't share the reports & honestly, they have yet to receive the reports but the customers are
highlighting this Tcp timestamp issue specifically for Windows VMs hosted in our environment.

Noted with thanks the sharing from BTan but currently we could address for Solaris & Linux
VMs in our environment;  it's only the Windows VMs that we have concern.   Our hardware
LB principal/vendor advised against disabling Tcp timestamp on the LB.

Guess, I have to resort to doing this on the firewalls which is not my preferred option : Windows
Firewall is still my preferred option so that the tenants manage this instead of us.

Looks like with Win 2003 registry setting we can securely disable Tcp timestamp & 
Win2012 has that PS command, which leaves only Win 2008 (R2), so is it worthwhile
to log a case with MS to see if they have anything for this or we are certain there's none?

Oh, I missed BTan's remark: it has to be Win2012 R2 (not even Win2012 has that PS command)

Just to clarify Gheist's remark:

>A5: Tcp1323Opts=1 is more adequate
In a few of the links I've visited, so far all say "Tcp1323Opts=0".  
Is there any MS or authoritative link that recommends the
value of 1 ?

yes - only for win2012 R2 and 8.1.
For info the TechNet registry link in my prev post stated below for those possible values.
0 (00) -Timestamps and window scaling are disabled.
1 (01) - Window scaling is enabled.
2 (10) - Timestamps are enabled.
3 (11) - Timestamps and window scaling are enabled.

https://technet.microsoft.com/en-us/library/cc938205.aspx

If you cannot tell if it is TCP or UDP timestamps hardly anybody can help you.
TCP timestamps can be added by iptables.
And those are usually randomized per connection, so they dont reflect wall time in your system.

It's Tcp timestamp.


so is it worthwhile to log a case with MS to see if they have anything (registry setting or any PS/netsh commands)
 for this in Win2008 R2 or Win2012 or we are certain there's none?

You cannot log case with MS unless you have enterprise agreement. 3 phone queue away you have pay-per-event support :P

Are you sure probe connects windows without any firewall intervention?

Check that there is no intermediary device scanned and surfacjbg this timestamp instead of the original target.
the uptime guess is accurate much of the time for most operating systems, so it is printed when available, but only in verbose mode. The uptime guess is omitted if the target gives zeros or no timestamp options in its SYN/ACK packets, or if it does not reply at all.

If you do a packet capture to check timestamp as verification of setting

The timestamp option in a TCP packet contains two values: TSval (the source’s time) and TSecr (an echo of the time the destination last sent). The best filter I found to look for positive timestamps was ip.src == <IP_of_target> && tcp.options.timestamp.tsval && !(tcp.options.timestamp.tsval == 0). The second part ensures that a TSval value is there since the third will return TRUE if the field isn’t there as well as when it’s non-zero. In this case, the filter returned no packets, as expected.

http://www.exploresecurity.com/testing-for-tcp-ip-timestamps/

>You cannot log case with MS unless you have enterprise agreement.
We do have one; requires justification though

>Are you sure probe connects windows without any firewall intervention?
Running Nmap (or Wireshark) inside the VM/server itself will tell us  Tcp
timestamp is enabled so not a firewall or other network devices issue

if those setting do not work reliably then the support had better advisebut so far I do not see any high risk for such findings per se as compared to of having to have PAWS and upkeep performance with uptiming records...

Just a thought: if Juniper, Fortigate firewalls can create rules to mitigate against this
Tcp timestamp, why can't Windows Firewall?   Or is there any 3rd party free firewall
that runs on Windows that could do this?

I can certainly log a case with MS but logging a case only to find out it can't be done
is a futile $ spent

can you post a sample pecap or screenshow where windows after reboot sends tcp timestamp flag?

iptable blocking is rather based on below
iptables -A INPUT -p icmp --icmp-type timestamp-request -j DROP
iptables -A OUTPUT -p icmp --icmp-type timestamp-reply -j DROP

good to confirm if the Windows server is really still sending the timestamps (after disabling those registry) by capturing the traffic as advised by gheist.. You can find all TCP packets with timestamp option (in Wireshark use following display filter: tcp.options.time_stamp); you should check in the second packet (after the server packet) to see if timestamp bit is set. see the capture has something like "... TSval=2308492143 TSecr=4294967295 ..." under the "Timestamps" in the info column for the packets. Note Syn need to be set since it is part of the SYN packet...

Just checked again & the D_Word(32) Tcp1323Opts   was already set to 0 (not setting to 1 as  one link
indicated value 1 is not supported) under CurrentControlSet, ControlSet001 & ControlSet002

Used nmap to scan (as I can't get hping & rsysinfo even on RHEL anymore) & it showed the "Uptime"
indicated by  <===== arrow below:

===============================

C:\nmap>nmap -v -O 172.21.x.y

Starting Nmap 4.62 ( http://nmap.org ) at 2015-10-29 18:59

Initiating Ping Scan at 18:59
Scanning 172.21.x.y [2 ports]
Completed Ping Scan at 18:59, 0.48s elapsed (1 total hosts)
Initiating Parallel DNS resolution of 1 host. at 18:59
Completed Parallel DNS resolution of 1 host. at 19:00, 0.41s elapsed
Initiating SYN Stealth Scan at 19:00
Scanning 172.21.x.y [1715 ports]
Discovered open port 3389/tcp on 172.21.128.90

. . .

Device type: general purpose
Running (JUST GUESSING) : Microsoft Windows Vista|2008 (90%), FreeBSD 6.X (88%)
Aggressive OS guesses: Microsoft Windows Vista (90%), Microsoft Windows Server 2
008 Beta 3 (89%), FreeBSD 6.2-RELEASE (88%)
No exact OS matches for host (test conditions non-ideal).
Uptime: 25.343 days (since Sun Oct 04 05:46:07 2015)      <====
TCP Sequence Prediction: Difficulty=262 (Good luck!)
IP ID Sequence Generation: Busy server or unknown class

Read data files from: C:\nmap
OS detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 14.078 seconds
           Raw packets sent: 3488 (157.688KB) | Rcvd: 39 (2310B)

For the benefit of doubt, I've just set it to 1 under CurrentControlSet, ControlSet001 & ControlSet002

Screen shot showing nmap still managed to get the Timestamp/Uptime


Do we need to restart/reboot anything after changing a registry value for it to take effect?
Does not appear it's needed because when I got back into regedit, it still show the last
value (ie 1) being set
nmapTcptimestampVal1.jpg

Hello... In last 40 days you had to restart for windows updates....
And for any driver parameter you need to restart (even those with netsh sometimes need restart)

Why such an effort if vista goes EOL in a year?

maybe good to sniff the pcap of such transaction while running the nmap

-O is very well described:
https://nmap.org/book/osdetect-methods.html

Also look at not ablr to disable reliably well for old version..https://social.technet.microsoft.com/Forums/en-US/802ae0e0-1adc-490a-b77a-27fd7f92690b/tcp1323opts-question-tcp-timestamps?forum=winserverPN

So you have 2 more options to go (rebooting after each option applied)

> if vista goes EOL
It's not Vista but Win 2008 R2 x64.

Nmap somehow reports it as Vista.

I'm sure the copy of nmap I used reported it correctly because
with an RHEL that has its Tcp timestamp disabled, the same
nmap command doesn't show the Uptime anymore.

Ok, no joy despite the reboots

Windows disable is not reliable apparently and also shared in public too..can try other Windows machine instead. And of course make there is no further intermediary to the server during the test - I assume that is checked

Doesn't matter whether there's intermediary:

the nmap test is done from exactly the same laptop to a RHEL (w tcp timestamp disabled)
& to the Win 2008 R2 (in the same subnet) : so the tests are consistent

Intermediary definitely matters. And even network card drivers interfere.

Can try running Network Monitor to capture shows the TCP timestamps option in the TCP SYN segment - see the "TCP Timestamps" section for sample capture
https://technet.microsoft.com/en-us/library/cc940037.aspx

From the very same laptop, if I run the very same nmap command to an
RHEL that has Tcp timestamp disabled, it doesn't show the Uptime anymore:
the nmap goes thru exactly the very same intermediary except for the
endpoint (either a Windows or the RHEL, both of which are on the same
subnet);  so if intermediary were to affect the result of the test, it should
have done so in the case of the RHEL endpoint

Did you reboot the system after registry change. after netsh, after powershell?

Do we need to restart/reboot anything after changing a registry value for it to take effect?

Restart also have this symptom since for registry changes it is best to restart since the memory loaded with such setting is not updated based on changes ...

The TCPIP driver will not restart on registry change, nor any other will do.

yap reboot which is what I meant as well....

> Did you reboot the system after registry change. after netsh, after powershell?
Yes, I did reboot the Windows after each change.

So For Win2008 R2, this registry change to disable Tcp timestamp did not help?

Can you dump traffic nmap generates?

suspecting this reg setting is deprecated

With Windows 2008 and Windows 2008 R2, a number of the registry parameters used in previous OS's have been deprecated and all of these configurations are now autotuned by the OS.  This includes TCP Receive Window Scaling which necessitated adding Tcp1323Opts in the registry to enable it on older OS's.

http://blogs.technet.com/b/winserverperformance/archive/2009/07/14/performance-tuning-guidelines-for-windows-server-2008-r2-released.aspx

Further check into MS tuning guide also did not shed anything close except this.

TCP Parameters
The following registry keywords in Windows Server 2003 are no longer supported and are ignored in Windows Server 2008 and Windows Server 2008 R2:
•      TcpWindowSize
HKLM\System\CurrentControlSet\Services\Tcpip\Parameters
•      NumTcbTablePartitions
HKLM\system\CurrentControlSet\Services\Tcpip\Parameters
•      MaxHashTableSize
HKLM\system\CurrentControlSet\Services\Tcpip\Parameters

https://msdn.microsoft.com/en-us/library/windows/hardware/dn529134

maybe good to check the dump as shared earlier in the posts

>Can you dump traffic nmap generates?
>maybe good to check the dump as shared earlier in the posts

How exactly can I dump the nmap traffic, mind giving exact command?

using tcpdump or wireshark.

See this using wireshark and look out for those field on timestamp in capture for filtering.
https://ask.wireshark.org/questions/1177/getting-more-info-on-tcp-packets

Can someone provide me a link to upload the Wireshark dump (about 100MB)?

Ran into NSF driver issue with that Win2008 R2 server so I've chosen another
Win2008 R2 server (17x.20.3.72): without setting  those values in the registry,
ran the nmap to it while Wireshark is capturing

Not too sure how to do filtering so I've captured the full dump :
when prompted for password, unzip using my EE id

Based on the dump, can recommend what type of Windows Firewall rules
I could create to block these Tcp timestamp & prevent uptime information
from being made known?


  https://forum.fortinet.com/tm.aspx?m=110743
Btw, Fortigate replied that Tcp Timestamp should not be disabled in their firewall
(& possibly other firewalls) as doing so will cause PAWS (PROTECT AGAINST WRAPPED
SEQUENCE NUMBERS) not to work, any truth in this?

doubt you can have the Windows FW to perform the filtering effectively. It will eventually has to drill into the packet (for those optional TCP field) to identify and drop the packet .... see http://www.securiteam.com/securityreviews/5LP0K2KF6I.html

Do also see the earlier mentioned post of the use of iptable and systctl. Review some FW rule to filter as well e.g. PAN

Create a zone protection profile that is configured to protect against packet-based attacks:

–  Remove TCP timestamps on SYN packets before the firewall forwards the packet—When you remove the TCP timestamp option in a SYN packet, the TCP stack on both ends of the TCP connection will not support TCP timestamps. Therefore, by disabling the TCP timestamp for a SYN packet, you can prevent an attack that uses different timestamps on multiple packets for the same sequence number.

https://www.paloaltonetworks.com/documentation/61/pan-os/pan-os/threat-prevention/best-practices-for-securing-your-network-from-layer-4-and-layer-7-evasions.html
... and including the FW itself

Enable the following CLI commands for checking the TCP timestamp. The TCP timestamp records when the segment was sent and allows the firewall to verify that the timestamp is valid for that session. Packets with invalid timestamps are dropped with this setting is enabled.

  set deviceconfig setting tcp check-timestamp-option yes

> use of iptable and sysctl
The above is for Linux only which I've implemented & it appears to work
effectively ie the same nmap command can't obtain the "uptime" info anymore
of the RHEL server that I implemented it

If iptables' rules alone are sufficient, perhaps we can scout around if there's
an iptables version that's been ported over to run on Win 2008 R2/Win2012?


>   set deviceconfig setting tcp check-timestamp-option yes
Is the above something I issue on the Fortigate firewall to disable
tcp timestamp?

Yup, I've just issued again the command below using administrator on the Win2008 R2 server
& it came back with an "Ok" message, indicating the command went thru fine:
  c:\> netsh int tcp set global timestamps=disabled
  Ok.

But running nmap against that server (or back to itself), still gives the uptime (guessed
rather accurately):
C:\Program Files\Nmap>nmap -v -O 17X.2X.128.90 |find/i "uptime"
Uptime guess: 10.098 days (since Thu Oct 29 21:52:53 2015)

Will check out the Fortigate with my colleagues who administer it but the link doesn't
appear to be providing firewall rules to filter out timestamp info in the outgoing traffic
but it appears to be a setting:
https://forum.fortinet.com/tm.aspx?m=103468

How does the Wireshark dump help achieve this objective of stopping the uptime
/tcp timestamp from being sent out?

Wireshark dump is to confirm no timestamp on claimed disabled setting.FG to hear iut from principal instead

I've searched  (Ctrl-F) through the entire dumps (under Packet Details section)
for the string "Timestamp value" & none of them are 0 : all are of large values:
see a few attached samples: so what does this mean?

>FG to hear iut from principal instead
Don't understand what the above meant.  Isn't FG the principal of FG firewall?
1.jpg
2.jpg
3.jpg

Yes indeed the timestamp is there hence not disabled as discussed. Not reliable for windows then..
Actual FG expert in supporting the deployment of the FG in your premise.

Is there any freeware firewall for Win2008 R2 that could help with this
if Windows Firewall can't help?

I kind of given up on the Fortigate principal's support

Is iptables ported to Windows 2008 R2 / 2012?

Which question a search with your favourite search engine did not answer?

I dont it be sensible for such porting or done really by others successfully. There is still the netsh but it did not seems working. There are tinywall and wipfw..but doubt they can do it tio..

Yap google's search result on 1st page did not return any iptables download for Windows :
perhaps some sort of filtering tool that could filter away/block the timestamp information
from being sent out.

Netsh tested not working on Win2008 R2

Windkws wise better to filter form its FW since host is not as reliable as expected and I am thinking that FW can be linux based to be the "ext iptable" instead fronting the Win2k8 system

i managed to disable windows 7 timestamps with netsh. I really dont know why it does not work for you.

Is the command you issued "netsh int tcp set global timestamps=disabled" ?

Did you run the same nmap command to test it?

Are you on 32bit or 64bit Win 7  ?

64 bit windows
I also disabled "chimney offload" in same place ( I just need traffic dump with checksums computes in software)

Yap I am thinking it may be an ordering problem on boot with the TCP offload engine of network adapters assuming it is enabled. Hence the new setting is not effective as it is not "pick" up hence those timestamps are still put into the exchanges. So disabling timestamps after the main network interface comes up may help. Some on link on this offload - http://blogs.technet.com/b/brad_rutkowski/archive/2007/08/10/how-to-know-if-tcp-offload-is-working.aspx

Ok, I've tested as follows:

At command prompt as administrator on the target Win2008 R2 server, issued
  netsh int tcp set global chimney=disabled
& verified that Chimney is now disabled (was previously 'automatic'):
  netsh int tcp show global
  netsh int tcp global timestamps=disabled

& scan again using 'nmap -o -V target_Win2008_IP'
& it still shows the uptime.    So in Gheist's case, you
don't see the 'uptime' information anymore using nmap?

Oh, btw, I just noted the command to disable tcp timestamp was
not accepted in my Win2008 R2 server (it says 'not found') :

C:\Windows\system32>netsh int tcp global timestamps=disabled
The following command was not found: int tcp global timestamps=disabled.

What's the exact command syntax that Gheist issued?

Ooops, missed the "set", got it right this time:

netsh int tcp set global timestamps=disabled
& the above was issued after chimney offload

I dont know - I dont have windows anymore, just some memories that disabling all offloads in netsh made TCP into state before RFC1323 was invented (and compatible with archaic "firewall")

Actually what is most puzzling is why windows uses real timestamp when as per protocol it could be zero or random value.

You need to restart system after each change, as this setting is used to program offload in network cards.

The given command 'netstat -nt |findstr offloaded' ... shows that it doesn't
work on both my Win2008 R2 as well as Win7 despite after reboot &
"netsh int tcp show global" shows the settings are in effect:

C:\Windows\system32>netsh int tcp show global
Querying active state...

TCP Global Parameters
----------------------------------------------
Receive-Side Scaling State          : enabled
Chimney Offload State               : disabled  <==
NetDMA State                        : enabled
Direct Cache Acess (DCA)            : disabled
Receive Window Auto-Tuning Level    : normal
Add-On Congestion Control Provider  : ctcp
ECN Capability                      : disabled
RFC 1323 Timestamps                 : disabled <==


the chimney offload & disable timestamp  commands was issued
successfully (got an 'ok' as response).  Something's amiss

Basically I can't find any "offloaded" lines in the netstat command
despite that the netsh show command shows chimney & timestamps
are disabled: this explains why nmap still detect timestamps

Since the global check using netsh shows offload disabled, then not able to find the 'offloaded' is as expected. But for the nmap to still detect it despite those setting showing disabled, I am thinking if this is the only server having this symptoms and if testing can be done on physical server instead of vm instance and possibly in staging environment ...

I'll install a Win2008 R2 on my laptop as alternate boot to test it this weekend.

https://www.hackinparis.com/sites/hackinparis.com/files/veit_hailperin_still_exploiting_tcp_timestamps.pdf
Meanwhile, allow me to deviate: governance has questioned me, referencing the above :

1. In disabling tcp timestamp on a server (ie in Linux & Solaris' cases which works), does it
    then make the system vulnerable in another way as PAWS got disabled?  Above URL
    says "Tcp timestamp is an Extension to provide PAWS and improved RTTM"

2. F5 & firewall principal advised that disabling Tcp timestamp will have performance
    impact & would disable PAWS as well (ie giving rise to another security concern):
    in what way disabling this at servers' OS level different or better than disabling
    it in F5 LB/firewalls?  

3. Between tcp timestamp & PAWS : which of the 2 is a bigger evil?  One of the slides
    in above URL appears to say that if Tcp timestamp is enabled, it will open up
    the following risks (correct me if I understand the slides wrongly):
    TCP Timestamps
I 2001 - Uptime Calculation
I 2005 - Host Identification
I 2015 - Network Layout Information Gathering
I 2015 - Reveal Active-Active Loadbalancing
I 2015 - Improve OS Fingerprints of NAT-ed Devices
Clock Skew
I 2005 - Host Identification / User Tracking
I 2005 - Network Layout Information Gathering
I 2006 - Reveal Hidden Services


Possibly the slides in above URL answers some of my questions but I am
not good enough to 'decipher' information in the slides

One more question:
so what's the best way forward?  Disable Tcp timestamp at F5 LB,
at firewall (what does terminate Tcp connection at firewall mean?)
or at the endpoint servers' OS?

1. The loss of PAWS is not totally security but support that since TCP can be unstable and can be tampered with. It comes down knowing its existence clearly.
E.g. It is to extend TCP reliability to transfer rates well beyond the foreseeable upper limit of network bandwidths. It uses timestamp to reject old duplicate segments (like if it is received with a timestamp SEG.TSval less than some timestamp recently received on this connection) that might corrupt an open TCP connection. Hence, it indirectly also protects against errors due to sequence number wrap-around on high-speed connection.
The key is it removed such "duplicate" whether it is well intended or not from earlier incarnations of the single connection. You make the choice whether to forsake this. As long as you deemed your connection is stable and guarded, I do not see the "threat" though

2. F5 posted their backing for not disabling timestamp, mainly due to a performance penalty would occur without RTTM too. They further allude the point on missing PAWS, potential attacker needs only the IP addresses and port numbers of the connection endpoints to reset the connection. Risk level of the uptime threat to F5 is deemed low as compared to the gain of having it enabled.
https://support.f5.com/kb/en-us/solutions/public/8000/000/sol8072.html

3. Make your choice performance as status quo vs disabled. I do not see great difference if no worst off but since your internal faced dilemma, I believe you are going for disabling too - the slides say likewise but note security via obscurity is not total secure. There are better means to fingerprint machine and users too...if I am the attacker, I need to be pretty savvy on the clock skew and uptime per se to gather enough to fingerprint the user and machine. I do not have such luxury of time - it can be more well spent to go other means to understand the environment. The segment can be complex with intermediary making it harder to fully and correctly map the segments. The Load balancing make it tougher.

I see the point is this - "There are other ways to gather the same intel"-excuse  ... if so serious since long time, why there is no action. Compared to heartbleed that can be exploited, which is more severe. Make a risk assessment judgment call. You cannot close everything and expect system security to work off ...

Last - disable at OS as that is the root cause, you still faced internal threat. More intermediary devices means you need to disable them too, all contributing even if they are proxy..

Would the following be logical / correct to say:
disabling tcp timestamp has the least impact on performance as server's LAN
speed is much higher & PAWS/RTTM are not relevant in servers/VMs' context,
more for WAN & possibly congested LANs.

By disabling tcp timestamp on network devices, the risk is on network which
will affect the network (something that's shared by many servers) while if
it's only a servers/VMs, the risk of performance impact is more localized to
specific servers/VMs (say during high traffic congestion/utilization)

High speed and congested network easily can cause packet loss and fragments. So timestamps help metrics via paws and rttm implementation better reliability to remove duplicates etc...

For localized smaller network, there is minimal impact to performance or reliability to traffic.
There should be security devices to monitor for anomalous activities and malformed packet if really malicious attempts exist.

I won't be testing these on physical servers as ultimately it's on Win2008 R2 VMs
that I need to fix this tcp timestamp.

>There should be security devices to monitor for anomalous activities and malformed packet
Are you referring to PAWS or Tcp timestamp in the above anomalous activities or
malformed packets?

I'm still interested in exactly how Gheist did it on Win 7.  This unreliable disabling
of Tcp timestamp was reported on both Win 7 & Win2008 so if only we could
pin-point the differences between what Gheist & I have done, may shed some light

Sure. PAWS and tcp timestamp are not malformed. For the filtering rules, it is more of timestamp.

So we don't have a way to block Tcp timestamp information from being sent out
& no way to effectively disable Tcp timestamp on Win2008 R2?

Our IPS product principals also replied they can't produce signatures to block
these while the firewall principal recommends against doing it on their firewall.