Hi, We have to be PCI-DSS compliant and have several Windows servers running ISA and TMG. We have: 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, Adrian

Hi, 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. I'm stumped...

Any 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.

Sounds stupid, but verify/set the Tcp1323Opts=0 in CurrentControlSet001, 002, etc as well. I've seen weird stuff like that before

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 Thanks

This 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.

Failed again... any other registry settings we need to change related to this?

Could 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?

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.

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? http://www.symantec.com/business/support/index?page=content&pmv=print&impressions=&viewlocale=&id=HOWTO56222NightOwl888

While researching similar things, I came across this thread, and this possible reference: http://technet.microsoft.com/en-us/library/cc731258(WS.10).aspx#BKMK_6 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.)