web-dev-qa-db-fra.com

Avantages et inconvénients de la désactivation TCP horodatages

Donc, lynis m'informe que je devrais annuler net.ipv4.tcp_timestamps. Je sais que c'est une mauvaise chose, car un attaquant pourrait déterminer les mises à jour qui nécessitent de redémarrer la machine que je n'ai pas appliquées, ou il pourrait l'utiliser pour comprendre mon calendrier de mise à jour et essayer d'attaquer dans le bref intervalle pendant lequel la machine redémarre, mais avant la mise en ligne du pare-feu, ou autre chose à laquelle je n'ai pas pensé.

Je comprends que ce n'est pas idéal.

Cependant, selon RFC 132 (et this ):

Les horodatages sont utilisés pour deux mécanismes distincts: RTTM (Round Trip Time Measurement) et PAWS (Protect Against Wrapped Sequences)

Celles-ci semblent également être de belles choses utiles à avoir. Cela étant dit, l'IIRC de mes classes de réseautage que la méthode RTTM n'est certainement pas nécessaire pour déterminer RTT, et la fenêtre coulissante de TCP rend les problèmes de bouclage de séquence improbables, mais comme ce n'est pas l'un des RFC de blague, je suppose qu'ils avaient un bonne raison de proposer ces choses et les implémenteurs avaient une bonne raison de les mettre en œuvre.

Y a-t-il des inconvénients (probables)/une utilisation négative ou des implications de sécurité à la désactivation de cette fonctionnalité?

De plus, y a-t-il un moyen pour que je puisse à la fois avoir et manger mon gâteau (en, par exemple, en disant au noyau de s'initialiser avec une valeur aléatoire et d'introduire une gigue dans la période des mises à jour de l'horodatage, ou en l'initialisant avec certains des bits de la horloge système, de sorte qu'ils ne peuvent pas utiliser un changement d'horodatage soudain et important pour indiquer qu'un redémarrage s'est récemment produit)?

networklinuxtcptimestampkernel
14
Parthian Shot

L'inconvénient serait que la séquence TCP pourrait encapsuler. C'est un risque sur les réseaux à très haut débit. Vous pouvez cependant randomiser l'horodatage initial, comme vous l'avez demandé. C'est un patch très simple, tout rejet sera donc insignifiant à corriger. Le patchset grsecurity doit déjà être appliqué.

De https://grsecurity.net/~spender/random_timestamp.diff :

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;

Notez que les noyaux plus récents ont intégré quelque chose de similaire à cela dans le temps depuis que cela a été publié.

6
forest

Un autre avantage est que, selon RedHat , il réduit les pics de performances associés à la génération d'horodatage.

1
OrangeDog

linux: plus de patchs du noyau.

Sur les noyaux plus récents, vous pouvez utiliser net.ipv4.tcp_timestamps = 1

Activez les horodatages tels que définis dans RFC1323 et utilisez un décalage aléatoire pour chaque connexion plutôt que d'utiliser uniquement l'heure actuelle

Ils choisissent de changer la sémantique: dans les vieux noyaux, tcp_timestamps = 1 active les horodatages sauvegardés par le temps.

Maintenant, pour obtenir l'ancien comportement, vous devez définir tcp_timestamps = 2

Je pense qu'ils choisissent de changer le comportement par défaut car il n'y a aucun effet négatif sur les utilisateurs normaux.

1
Massimo