<p>We've hired a security consultant to perform a pentest on our Application's public IP (Kubernetes Loadbalancer) and write a report on our security flaws and the measurements required to avoid them. Their report warned us that we have TCP Timestamp enabled, and from what I've read about the issue, It would allow an attacker to predict boot time of the machine thus being able to grant control over it.</p>

<p>I also read that TCP Timestamp is important for TCP performance and, most importantly, for Protection Against Wrapping Sequence.</p>

<p>But since we use Kubernetes over GKE with Nginx Ingress Controller being in front of it, I wonder if that <code>TCP Timestamp</code> thing really matters for that context. Should we even care? If so, does it really make my network vulnerable for the lack of Protection Against Wrapping sequence?</p>

<p>More information about TCP Timestamp on this other question:
<a href="https://stackoverflow.com/questions/7880383/what-benefit-is-conferred-by-tcp-timestamp">What benefit is conferred by TCP timestamp?</a></p>

<p>According to RFC 1323 (TCP Extensions for High Performance) TCP Timestamp is used for two main mechanisms: </p>

<ul>
<li>PAWS (Protect Against Wrapped Sequence) </li>
<li>RTT (Round Trip Time)</li>
</ul>

<p><strong>PAWS</strong> - defense mechanism for identification and rejection of packets that arrived in other wrapping sequence (data integrity). </p>

<p><strong>Round Trip Time</strong> - time for packet to get to the destination and sent acknowledgment back to the device it originated.</p>

<p>What can happen when you disable TCP Timestamps: </p>

<ul>
<li>Turning off TCP Timestamp can result with performance issues because the RTT would stop working. </li>
<li>It will disable <a href="https://tejparkash.wordpress.com/2010/12/05/paws-tcp-sequence-number-wrapping-explained/" rel="nofollow noreferrer">PAWS</a>. </li>
<li>As <a href="https://kc.mcafee.com/corporate/index?page=content&amp;id=KB78776&amp;locale=en_US" rel="nofollow noreferrer">McAfee</a> site says disabling timestamps can allow denial attacks.  </li>
</ul>

<p>As previously mentioned McAfee's site: </p>

<blockquote>
  <p>For these reasons, McAfee strongly recommends keeping this feature enabled and considers the vulnerability as low..</p>
  
  <p>-- <a href="https://kc.mcafee.com/corporate/index?page=content&amp;id=KB78776&amp;locale=en_US" rel="nofollow noreferrer">McAfee</a></p>
</blockquote>

<p>Citation from another site:  </p>

<blockquote>
  <p>Vulnerabilities in TCP Timestamps Retrieval is a Low risk vulnerability that is one of the most frequently found on networks around the world. This issue has been around since at least 1990 but has proven either difficult to detect, difficult to resolve or prone to being overlooked entirely.</p>
  
  <p>--  <a href="https://beyondsecurity.com/scan-pentest-network-vulnerabilities-tcp-timestamps-retrieval.html" rel="nofollow noreferrer">Beyond Security </a></p>
</blockquote>

<p>I would encourage you to look on this video: <a href="https://www.youtube.com/watch?v=bXXoz5-Z9h0" rel="nofollow noreferrer">HIP15-TALK:Exploiting TCP Timestamps</a>. </p>

<h3>What about GKE</h3>

<p>Getting the information about boot time (uptime in this case) can lead to knowledge about what security patches are <strong>not</strong> applied to the cluster. It can lead to exploitation of those unpatched vulnerabilities.  </p>

<p>The best way to approach that would be <strong>regularly update</strong> existing cluster. 
GKE implements 2 ways of doing that: </p>

<ul>
<li><a href="https://cloud.google.com/kubernetes-engine/docs/how-to/upgrading-a-cluster" rel="nofollow noreferrer">Manual way </a></li>
<li><a href="https://cloud.google.com/kubernetes-engine/docs/how-to/node-auto-upgrades" rel="nofollow noreferrer">Automatic way </a></li>
</ul>

<p>Even if attacker knows the boot time of your machine it will be useless because system is up to date and all the security patches are applied. 
There is dedicated site for Kubernetes engine security bulletins: <a href="https://cloud.google.com/kubernetes-engine/docs/security-bulletins" rel="nofollow noreferrer">Security bulletins</a></p>
