Pro e contro di disabilitare i timestamp TCP

Question

Pro e contro di disabilitare i timestamp TCP

#1 da (3 voti)

8

Quindi, il lynis mi informa che dovrei annullare net.ipv4.tcp_timestamps . So che è una cosa negativa perché un utente malintenzionato potrebbe capire quali aggiornamenti richiedono il riavvio della macchina che non ho applicato, o potrebbero usarlo per capire la mia pianificazione degli aggiornamenti e provare ad attaccare nel breve intervallo durante il quale il riavvio della macchina ma prima che il firewall arrivi online, o qualcos'altro che non ho pensato.

Capisco che non è l'ideale.

Tuttavia, secondo RFC 1323 (e questo ):

The timestamps are used for two distinct mechanisms: RTTM (Round Trip Time Measurement) and PAWS (Protect Against Wrapped Sequences)

Anche quelli sembrano cose carine e utili da avere. Detto questo, IIRC dalle mie classi di networking che il metodo RTTM non è assolutamente necessario per determinare RTT, e la finestra scorrevole di TCP rende improbabili i problemi di sequenza, ma poiché non si tratta di uno scherzo RFC, presumo che abbiano avuto un Una buona ragione per proporre queste cose e implementatori aveva una buona ragione per implementarle.

Esistono (probabilmente) svantaggi / implicazioni di usabilità o sicurezza negative per disabilitare questa funzione?

Inoltre, c'è un modo in cui posso avere e mangiare la mia torta (ad esempio, dicendo al kernel di inizializzarlo con un valore casuale e introdurre jitter nel periodo degli aggiornamenti di timestamp, o inizializzarlo con alcuni dei bit dell'orologio di sistema, quindi non possono usare un improvviso, grande cambiamento di timestamp per dire che si è verificato di recente un riavvio)?

linux kernel tcp network timestamp

posta Parthian Shot 26.01.2016 - 17:46

fonte

1 risposta

Leggi altre domande sui tag linux kernel tcp network timestamp

Risposta a una scansione non autorizzata da una società legittima? [chiuso] Quanto è sicuro Sandboxie?

score 3 · Answer 1

Lo svantaggio sarebbe che la sequenza TCP potesse avvolgere. Questo è un rischio su reti ad altissima velocità. Puoi randomizzare il timestamp iniziale, tuttavia, proprio come richiesto. È una patch molto semplice, quindi qualsiasi rifiuto sarà banale da risolvere. Richiede che il patchset di grsecurity sia già applicato.

Da link :

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;

Nota che i nuovi kernel hanno integrato qualcosa di simile nel tempo da quando è stato pubblicato. Impostando il timestamp sysctl su "2", verrà randomizzato lo scostamento di base del timestamp iniziale.