Friday, October 22, 2010 7:44 AM
We have to be PCI-DSS compliant and have several Windows servers running ISA and TMG.
Win 2K with ISA 2000 (on it's way out)
Win 2K3 with ISA 2006
Win 2K8 R2 with TMG 2010
All of these servers, in the registry have TCP1323Opts set to '0' as per http://technet.microsoft.com/en-us/library/cc938205.aspx to disable TCP Timestamps.
This is confirmed using Netsh where RFC 1323 Timestamps : disabled
However, for PCI-DSS compliance we have to run vulnerability scans.
Although only informational, all these servers come back as giving Timestamp replies.
Although vulnerabilities due to this are minimal, from the timestamp is can be calculated how long a server has been running and therefore you can work out if it is missing the latest patches due to a lack of a reboot.
I'm mainly puzzled as to why this is showing up when it is meant to be disabled.
I've searched high and low across the Internet and can't find anything apart from the instructions as to how to change that reg entry.
Do I need to do anything extra for the driver or something?
Any help appreciated,
Monday, October 25, 2010 7:52 AMModerator
Thanks for the post.
Please check if you add the Tcp1323Opts registry key as follows:
Value Type: REG_DWORD—number (flags)
Valid Range: 0 or 2
0 (disable the use of the TCP timestamps option)
2 (enable the use of the TCP timestamps option)
Default: No value.
Description: This value controls the use of the RFC 1323 TCP Timestamp option. The default behavior of the TCP/IP stack is to not use the Timestamp options when initiating TCP connections, but use them if the TCP peer that is initiating communication includes them in their synchronize (SYN) segment.
For more information about TCP/IP Registry Values, you could access this link:
Hope this helps.
Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
- Marked As Answer by Miles ZhangModerator Monday, November 01, 2010 2:01 AM
Tuesday, November 02, 2010 1:24 PM
Sorry about the late reply, I've been on holiday.
Unfortunately I've got the Tcp1323Opts option set to 0 but the PCI-DSS vulnerability tests we have done still show timestamps.
Wednesday, March 23, 2011 8:35 PMAny progress on this issue? I am seeing the same results with the registry entry set to 0 and netsh results show it as disabled but the PCI scan is showing it enabled. Any insight would be appreciated.
Thursday, March 24, 2011 2:35 AMSounds stupid, but verify/set the Tcp1323Opts=0 in CurrentControlSet001, 002, etc as well. I've seen weird stuff like that before
Friday, April 08, 2011 9:16 AM
Sorry to jump on someone else's thread but i'm also having this issue. I've verified Tcp1323Opts=0 is set in all CurrentControlSets correctly, and using netsh it's showing as disabled but our PCI scans are still reporting it's enabled (as are our Nessus scans).
Any information anyone can give would be very helpful
Friday, April 15, 2011 4:12 PMThis answer does not seem adequate when several of us have the same issue and still have a flag reported by the PCI compliance scan. Someone suggested setting the parameters in the other control sets (beyond current control set). No one has mentioned also setting the parameters for IPv6, does it matter? I have added it to all these places and will let you know the result of my next scan.
Thursday, April 21, 2011 3:26 PM
Failed again... any other registry settings we need to change related to this?
Friday, July 08, 2011 5:10 PMI'm having this same issue. Any updates on this thread?
Friday, July 08, 2011 5:58 PMWe never succeeded with an automated PCI compliance scan even after making all the suggested changes by the vendor and Microsoft. We finally got resolution by contacting the vendor running the scan for us and making a manual exception to override the results and we passed. So I can only suggest you do the same and hopefully your compliance vendor will give you approval.
- Proposed As Answer by Boys Ranch Tech Friday, July 08, 2011 5:58 PM
Monday, July 18, 2011 7:12 PMCould it be the scanner is getting the timestamp response from an intermediary device (firewall, router, load balancer, etc..) that it is scanning through? The scanner should give the timestamp that it is receiving back (system uptime usually). Seems odd that netsh is showing that it is already disabled on the device. Is it getting flagged on all your devices, or just that one?
Thursday, March 22, 2012 8:29 PM
Just chiming in to let you know we are seeing the same issues. Our XP boxes will take the netsh command to disable icmp timestamp response and it will correct the issue. However, any OS newer than XP/2003, we see the same issue as all of you with the scans showing a "fail" on the 1323 TimeStamp Response, when every setting possible is already modified with disable or 0.
Like, Boys Ranch Tech, since the CVSS score is 0, we are going to make the same manual exception.
Monday, July 16, 2012 1:22 PM
While not official Microsoft documentation, this Symantec page seems to indicate that Tcp1323Opts is deprecated in Windows Server 2008 and Windows Server 2008 R2. So I guess the question is - what has it been replaced by?
Tuesday, October 23, 2012 11:53 PM
While researching similar things, I came across this thread, and this possible reference:
netsh int tcp set global timestamps=enabled
Looks like it might be worth a try.
(Post provided as-is and without warranty. Your mileage may vary. Some geese may like chalk.)