Ventajas y desventajas de deshabilitar las marcas de tiempo de TCP

Question

Ventajas y desventajas de deshabilitar las marcas de tiempo de TCP

#1 de forest (3 votos)

8

Entonces, Lynis me informa que debo cancelar net.ipv4.tcp_timestamps . Sé que eso es algo malo porque un atacante podría averiguar qué actualizaciones requieren reiniciar la máquina que no he aplicado, o podrían usarla para averiguar mi programa de actualización e intentar atacar en el breve intervalo durante el cual la máquina se reinicia, pero antes de que el firewall esté en línea, o algo más que no haya pensado.

Entiendo que no es lo ideal.

Sin embargo, de acuerdo con RFC 1323 (y this ):

Las marcas de tiempo se utilizan para dos mecanismos distintos: RTTM (Medición del tiempo de ida y vuelta) y PAWS (Protección contra envuelto) Secuencias)

También parecen cosas agradables y útiles para tener. Dicho esto, el IIRC de mis clases de redes de que el método RTTM definitivamente no es necesario para determinar el RTT, y la ventana deslizante del TCP hace que los problemas de la secuencia de la envolvente sean poco probables, pero dado que este no es uno de los RFC de broma, asumo que tienen un una buena razón para proponer estas cosas y los implementadores tenían una buena razón para implementarlas.

¿Existe alguna (probable) desventaja / usabilidad negativa o implicaciones de seguridad para deshabilitar esta función?

Además, ¿hay alguna forma de que pueda tener y comer mi pastel (por ejemplo, indicando al kernel que se inicie con un valor aleatorio e introduzca fluctuaciones en el período de las actualizaciones de la marca de tiempo, o inicializándolo con algunas de las ¿Bits del reloj del sistema, por lo que no pueden usar un gran cambio repentino en la marca de tiempo para indicar que se produjo un reinicio recientemente?

network linux kernel timestamp tcp

pregunta Parthian Shot 26.01.2016 - 17:46

fuente

1 respuesta

Lea otras preguntas en las etiquetas network linux kernel timestamp tcp

¿Qué tan seguro es Sandboxie? Detección del proceso de vaciado

score 3 · Answer 1

La desventaja sería que la secuencia TCP podría ajustarse. Este es un riesgo en redes de muy alta velocidad. Sin embargo, puedes aleatorizar la marca de tiempo inicial, tal como lo pediste. Es un parche muy simple, por lo que cualquier rechazo será trivial de arreglar. Requiere que el parche de grsecurity ya esté aplicado.

De enlace :

diff --git a/grsecurity/Kconfig b/grsecurity/Kconfig
index 3abaf02..700e56c 100644
--- a/grsecurity/Kconfig
+++ b/grsecurity/Kconfig
@@ -925,6 +925,16 @@ config GRKERNSEC_RANDNET
      here.  Saying Y here has a similar effect as modifying
      /proc/sys/kernel/random/poolsize.

+config GRKERNSEC_RANDOM_TIMESTAMPS
+   bool "Add random offset to TCP timestamps"
+   default y if GRKERNSEC_CONFIG_AUTO
+   help
+     If you say Y here, a simple change will be made to TCP timestamp
+     behavior that will prevent the system from leaking the jiffies
+     value remotely to an attacker who has not been persistently
+     monitoring the system since boot.  The jiffies value can be used
+     to remotely determine system uptime.
+
 config GRKERNSEC_BLACKHOLE
    bool "TCP/UDP blackhole and LAST_ACK DoS prevention"
    default y if GRKERNSEC_CONFIG_AUTO
diff --git a/grsecurity/grsec_init.c b/grsecurity/grsec_init.c
index ae6c028..c7dbe97d 100644
--- a/grsecurity/grsec_init.c
+++ b/grsecurity/grsec_init.c
@@ -7,6 +7,11 @@
 #include <linux/percpu.h>
 #include <linux/module.h>

+#ifdef CONFIG_GRKERNSEC_RANDOM_TIMESTAMPS
+__u32 random_timestamp_base __latent_entropy;
+EXPORT_SYMBOL_GPL(random_timestamp_base);
+#endif
+
 int grsec_enable_ptrace_readexec;
 int grsec_enable_setxid;
 int grsec_enable_symlinkown;
diff --git a/include/net/sock.h b/include/net/sock.h
index b2948c0..ccbeda9 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -2296,4 +2296,8 @@ extern int sysctl_optmem_max;
 extern __u32 sysctl_wmem_default;
 extern __u32 sysctl_rmem_default;

+#ifdef CONFIG_GRKERNSEC_RANDOM_TIMESTAMPS
+extern __u32 random_timestamp_base;
+#endif
+
 #endif /* _SOCK_H */
diff --git a/include/net/tcp.h b/include/net/tcp.h
index 44a58b0..fcdca06 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -684,7 +684,11 @@ void tcp_send_window_probe(struct sock *sk);
  * to use only the low 32-bits of jiffies and hide the ugly
  * casts with the following macro.
  */
+#ifdef CONFIG_GRKERNSEC_RANDOM_TIMESTAMPS
+#define tcp_time_stamp     ((__u32)(jiffies) + random_timestamp_base)
+#else
 #define tcp_time_stamp     ((__u32)(jiffies))
+#endif

 #define tcp_flag_byte(th) (((u_int8_t *)th)[13])

diff --git a/net/core/dev.c b/net/core/dev.c
index f3e28ec..8b1cf12 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -6986,6 +6986,10 @@ static int __init net_dev_init(void)

    BUG_ON(!dev_boot_phase);

+#ifdef CONFIG_GRKERNSEC_RANDOM_TIMESTAMPS
+   random_timestamp_base += prandom_u32();
+#endif
+
    if (dev_proc_init())
        goto out;

Tenga en cuenta que los kernels más nuevos han integrado algo similar a esto desde que se publicó. Al establecer la marca de tiempo sysctl en '2', se aleatorizará el desplazamiento base de la marca de tiempo inicial.