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

Refer to the above.  Not sure if there's surefire answer ultimately but putting a firewall
in front of the server is not an option currently.

I tried the PowerShell command given in the url above using administrator but got syntax
error below, so what's the exact syntax:

PS C:\Windows\system32> Set-netTCPsetting -SettingName InternetCustom -Timestamps disabled
 term 'Set-netTCPsetting' is not recognized as the name of a cmdlet, function, script file, or operable program. Che
the spelling of the name, or if a path was included, verify that the path is correct and try again.
line:1 char:18
et-netTCPsetting <<<<  -SettingName InternetCustom -Timestamps disabled
 + CategoryInfo          : ObjectNotFound: (Set-netTCPsetting:String) [], CommandNotFoundException
 + FullyQualifiedErrorId : CommandNotFoundException

Can we set Windows Firewall rules instead & what's the exact Windows Firewall rules?

Saw somewhere the following so is it sufficient or there's more rules
needed?   What's the equivalent rules in Windows Firewall, Juniper &
 Fortigate & Cisco ACLs if any & if they help to get the scanner report
the Tcp timestamp is fixed?
"Create RHEL iptables firewall rules as additional enhancement:
   iptables -A INPUT -p icmp --icmp-type timestamp-request -j DROP
   iptables -A OUTPUT -p icmp --icmp-type timestamp-reply -j DROP

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?
Is above true?

Anyone know of any other ways to fix this in Win 2008 (R2) & Win2012?
Anyone tried the following & it helps:
  set the Tcp1323Opts=0 in CurrentControlSet001, 002, etc as well
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

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.
btanExec ConsultantCommented:
A1/A4/A5 - Powershell for "Set-NetTCPSetting" is only in Win2012 R2 and Win8.1 only and not on other Windows Server verison including Win2008R2/2012. The PS 3.0 update will not include them even if you try to upgrade your PS as these cmdlet module is specifically bind onto the supported OS version only. I also see that the syntax for disabling is as what stated and in specific "-Timestamps Disabled" . See

To list all the cmdlets that are available, use the Get-Command –Module NetTCPIP cmdlet. For more detailed information, you can run any of the following cmdlets:
● Get-Help <cmdlet name> -Detailed
● Get-Help <cmdlet name> -Examples
● Get-Help <cmdlet name> -Full

A2 - For FW rule, supposed to be able to be disabled RFC 1323 Timestamps via "netsh int tcp set global timestamps=disabled", but so far it has not be an reliable actions though. It is to set the values (e.g. Tcp1323Opts) in the registry (e.g. HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters) as per stated in technet

A3 - for Linux - Disable TCP timestamps on Linux via "Sysctl" (e.g. echo 0 > /proc/sys/net/ipv4/tcp_timestamps, and change permanent though, you need to add the following line to /etc/sysctl.conf: net.ipv4.tcp_timestamps = 0) and "IPTables"
To be on the safe side, add the following basic IPTables configuration to your system:

iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p tcp --dport ssh -j ACCEPT
iptables -A INPUT -p udp --dport 514 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT
iptables -A INPUT -p tcp --dport 1984 -j ACCEPT
iptables -A INPUT -p icmp –icmp-type 13 -j DROP
iptables -A INPUT -p icmp --icmp-type timestamp-request -j DROP
iptables -A OUTPUT -p icmp --icmp-type timestamp-reply -j DROP
iptables -I INPUT 1 -i lo -j ACCEPT
iptables -L
apt-get install iptables-persistent

answer “yes” to used current configuration, “yes” you want to use IPv6 as well.

NOTE: You need to add all services on your system, this is just a basic template.
Orig source: (ref

For IPv6, should be able to accomplish by using ip6tables and additionally  enforcing echo 0 > /proc/sys/net/ipv6/tcp_timestamps

For FG - (via the config system global)

For Cisco - (mainly on "tcp-options timestamp clear")

For SonicWALL - (can be from mgmt admin GUI)

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
sunhuxAuthor Commented:
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.
Become a Leader in Data Analytics

Gain the power to turn raw data into better business decisions and outcomes in your industry. Transform your career future by earning your MS in Data Analytics. WGU’s MSDA program curriculum features IT certifications from Oracle and SAS.  

sunhuxAuthor Commented:
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?
sunhuxAuthor Commented:
Oh, I missed BTan's remark: it has to be Win2012 R2 (not even Win2012 has that PS command)
sunhuxAuthor Commented:
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 ?
btanExec ConsultantCommented:
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.
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.
sunhuxAuthor Commented:
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?
btanExec ConsultantCommented:
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.
sunhuxAuthor Commented:
>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
btanExec ConsultantCommented:
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...
sunhuxAuthor Commented:
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?
btanExec ConsultantCommented:
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...
sunhuxAuthor Commented:
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 ( ) 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

. . .

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 .
Nmap done: 1 IP address (1 host up) scanned in 14.078 seconds
           Raw packets sent: 3488 (157.688KB) | Rcvd: 39 (2310B)
sunhuxAuthor Commented:
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
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?
btanExec ConsultantCommented:
maybe good to sniff the pcap of such transaction while running the nmap
-O is very well described:
btanExec ConsultantCommented:
So you have 2 more options to go (rebooting after each option applied)
sunhuxAuthor Commented:
> 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
btanExec ConsultantCommented:
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
sunhuxAuthor Commented:
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.
btanExec ConsultantCommented:
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
sunhuxAuthor Commented:
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?
btanExec ConsultantCommented:
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.
btanExec ConsultantCommented:
yap reboot which is what I meant as well....
sunhuxAuthor Commented:
> 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?
btanExec ConsultantCommented:
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.

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
•      NumTcbTablePartitions
•      MaxHashTableSize

maybe good to check the dump as shared earlier in the posts
sunhuxAuthor Commented:
>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.
btanExec ConsultantCommented:
See this using wireshark and look out for those field on timestamp in capture for filtering.
sunhuxAuthor Commented:
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?
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?
TCP sequence number is 32bit, which means you need to have 2^32 packets in flight to get rollover case.
That means that send/receive buffers (and packets in transfer) must be close to 2^32*64 bytes or 256GB in normal language to get counter rolling over.
10GbE must have 240s latency to make use of such buffer

As of now for all practical cases PAWS is of no use at all.
btanExec ConsultantCommented:
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

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.
... 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
sunhuxAuthor Commented:
> 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?
btanExec ConsultantCommented:
Suppose netsh is the eqv of iptable - the use "netsh int tcp set global timestamps=disabled" should be eqv but does not seems to be reliable ... probably to add those rules ..

" set deviceconfig setting tcp check-timestamp-option yes " is for PAN, maybe FG has eqv

For wireshark capture showing no timestamp - see an image
nil timestamp
sunhuxAuthor Commented:
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

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:

How does the Wireshark dump help achieve this objective of stopping the uptime
/tcp timestamp from being sent out?
btanExec ConsultantCommented:
Wireshark dump is to confirm no timestamp on claimed disabled setting.FG to hear iut from principal instead
sunhuxAuthor Commented:
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?
btanExec ConsultantCommented:
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.
sunhuxAuthor Commented:
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
sunhuxAuthor Commented:
Is iptables ported to Windows 2008 R2 / 2012?
Which question a search with your favourite search engine did not answer?
btanExec ConsultantCommented:
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..
sunhuxAuthor Commented:
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
btanExec ConsultantCommented:
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.
sunhuxAuthor Commented:
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)
btanExec ConsultantCommented:
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 -
sunhuxAuthor Commented:
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?
sunhuxAuthor Commented:
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?
sunhuxAuthor Commented:
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.
btanExec ConsultantCommented:
Pls see the below as another mean to check if offloaded is make not available after disabling
So how do we see if traffic is offloaded?  You run netstat -nt, the 't' dumps their current offload state.   I used findstr just to grab the offloaded connections.

C:\>netstat -nt | findstr /i offloaded
  TCP     ESTABLISHED     Offloaded
  TCP    ESTABLISHED     Offloaded
  TCP     ESTABLISHED     Offloaded
  TCP   ESTABLISHED     Offloaded
  TCP    ESTABLISHED     Offloaded
  TCP   ESTABLISHED     Offloaded
  TCP    ESTABLISHED     Offloaded
  TCP    ESTABLISHED     Offloaded
  TCP      ESTABLISHED     Offloaded
sunhuxAuthor Commented:
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
sunhuxAuthor Commented:
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
btanExec ConsultantCommented:
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 ...
sunhuxAuthor Commented:
I'll install a Win2008 R2 on my laptop as alternate boot to test it this weekend.
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
sunhuxAuthor Commented:
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?
btanExec ConsultantCommented:
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.

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..
sunhuxAuthor Commented:
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)
btanExec ConsultantCommented:
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.
sunhuxAuthor Commented:
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
btanExec ConsultantCommented:
Sure. PAWS and tcp timestamp are not malformed. For the filtering rules, it is more of timestamp.
sunhuxAuthor Commented:
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.
btanExec ConsultantCommented:
Doubt so for windows as it should be working with those registry already set but the test still yearn finding of the timestamp value return. Even the setting of the NIC card did not show significant difference in your case.

The block will then have to rely on the ext FW or proxy to filter off but if anyone has concerns - system owner on risk or security vendor or contractor fearing deteriorated services, then it comes down to an informed risk based decision by owner. Security is driver to support business running and not the main business derivatives though avoiding damages is indirectly saving cost to handle any lapses. Strike a balance. As a whole, I see the risk is not high since a cyber kill chain requires more than just knowing the uptime and knowing it for a prolonged period to further any malicious long term penetration or damages. Otherwise consider other non windows system to helm critical service while the performance play a backstage which may even include refurnished the server and segregate the traffic reachable via authorised internal-only segments. Pardon me if I digress

But we do want to close uptime cases if it does exist and due to application installed like this recent one regarding Up.time agent for Windows contains multiple vulnerabilities due to unsecured and anonymous connection that can cause DDoS and/or information gathering attempts
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Network Security

From novice to tech pro — start learning today.