networking - tracer - ¿Qué beneficio le otorga la marca de tiempo TCP?
para qué sirve nat (5)
Tengo un análisis de seguridad que me indica que desactive las marcas de tiempo TCP. Entiendo los motivos de la recomendación: la marca de tiempo se puede usar para calcular el tiempo de actividad del servidor, lo que puede ser útil para un atacante (buena explicación en el encabezado "Marcas de tiempo TCP" en http://www.silby.com/eurobsdcon05/eurobsdcon_silbersack.pdf )
Sin embargo, entiendo que las marcas de tiempo TCP están destinadas a mejorar el rendimiento de TCP. Naturalmente, en el análisis de costo / beneficio, la degradación del rendimiento es un costo grande, posiblemente demasiado grande. Estoy teniendo dificultades para entender cuánto, si es que hay, el costo de rendimiento es probable que exista. ¿A los nodos de la mente de la mente les importa ayudar?
¿Por qué las personas de seguridad querrían que desactivas las marcas de tiempo? ¿Qué posible amenaza podría representar una marca de tiempo? Apuesto a que el equipo del NTP no estaría contento con esto; ^)
La marca de tiempo TCP cuando esté habilitada le permitirá adivinar el tiempo de actividad de un sistema de destino (nmap v-O. Conocer cuánto tiempo ha estado funcionando un sistema le permitirá determinar si se han aplicado o no parches de seguridad que requieren reinicio.
La respuesta se expresa más sucintamente en RFC 1323 - Medición de ida y vuelta ... La introducción a la RFC también proporciona un contexto histórico relevante ...
Introduction
The introduction of fiber optics is resulting in ever-higher
transmission speeds, and the fastest paths are moving out of the
domain for which TCP was originally engineered. This memo defines a
set of modest extensions to TCP to extend the domain of its
application to match this increasing network capability. It is based
upon and obsoletes RFC-1072 [Jacobson88b] and RFC-1185 [Jacobson90b].
(3) Round-Trip Measurement
TCP implements reliable data delivery by retransmitting
segments that are not acknowledged within some retransmission
timeout (RTO) interval. Accurate dynamic determination of an
appropriate RTO is essential to TCP performance. RTO is
determined by estimating the mean and variance of the
measured round-trip time (RTT), i.e., the time interval
between sending a segment and receiving an acknowledgment for
it [Jacobson88a].
Section 4 introduces a new TCP option, "Timestamps", and then
defines a mechanism using this option that allows nearly
every segment, including retransmissions, to be timed at
negligible computational cost. We use the mnemonic RTTM
(Round Trip Time Measurement) for this mechanism, to
distinguish it from other uses of the Timestamps option.
La penalización de rendimiento específica en la que incurre al inhabilitar las marcas de tiempo dependerá del sistema operativo del servidor específico y de cómo lo haga (para ver ejemplos, consulte este documento del PSC sobre ajuste del rendimiento ). Algunos sistemas operativos requieren que habilite o deshabilite todas las opciones de RFC1323 a la vez ... otros le permiten activar selectivamente las opciones de RFC 1323.
Si su servidor virtual acelera de algún modo la transferencia de datos (tal vez usted solo compró el plan vhost barato), quizás no pueda usar un rendimiento superior de todos modos ... quizás valga la pena apagarlos para intentarlo. Si lo hace, asegúrese de comparar su desempeño antes y después de varias ubicaciones diferentes, si es posible.
Me hicieron una pregunta similar sobre este tema, hoy. Mi opinión es la siguiente:
Un sistema sin parche es la vulnerabilidad, no si los atacantes pueden encontrarla fácilmente. La solución, por lo tanto, es parchear sus sistemas regularmente. Deshabilitar las marcas de tiempo de TCP no hará nada para que sus sistemas sean menos vulnerables, es simplemente la seguridad a través de la oscuridad, que no es seguridad en absoluto.
Convirtiendo la pregunta en su punto crítico, considere crear una solución de comandos que use las marcas de tiempo de TCP para identificar los hosts en su red que tienen los tiempos de actividad más largos. Estos generalmente serán sus sistemas más vulnerables. Utilice esta información para priorizar el parcheo, para garantizar que su red permanezca protegida.
No olvide que la información como el tiempo de actividad también puede ser útil para los administradores de su sistema. :)
Para Daniel y cualquier otra persona que desee una aclaración:
http://www.forensicswiki.org/wiki/TCP_timestamps
"Las marcas de tiempo de TCP se utilizan para proporcionar protección contra números de secuencia ajustados. Es posible calcular el tiempo de actividad del sistema (y el tiempo de arranque) analizando las marcas de tiempo de TCP (ver a continuación) Estas temporizaciones calculadas (y tiempos de arranque) pueden ayudar a detectar redes ocultas habilitadas sistemas operativos (vea TrueCrypt), conectando direcciones falsas IP y MAC juntas, vinculando direcciones IP con AP inalámbricos Ad-Hoc, etc. "
Es una vulnerabilidad de bajo riesgo denotada en el cumplimiento PCI.
Yo no lo haría
Sin marca de tiempo, el mecanismo de Protección TCP contra números de secuencia envueltos (PAWS) no funcionará. Utiliza la opción de marca de tiempo para determinar el cambio de número de secuencia repentino y aleatorio es un ajuste (números de secuencia de 16 bits) en lugar de un paquete loco de otro flujo.
Si no tiene esto, sus sesiones TCP eructarán de vez en cuando de acuerdo con la rapidez con que estén usando el espacio de números de secuencia.
De RFC 1185:
ARPANET 56kbps 7KBps 3*10**5 (~3.6 days)
DS1 1.5Mbps 190KBps 10**4 (~3 hours)
Ethernet 10Mbps 1.25MBps 1700 (~30 mins)
DS3 45Mbps 5.6MBps 380
FDDI 100Mbps 12.5MBps 170
Gigabit 1Gbps 125MBps 17
Tome 45Mbps (bien dentro de las velocidades 802.11n), entonces tendríamos un eructo cada ~ 380 segundos. No es horrible, pero es molesto.
¿Por qué las personas de seguridad querrían que desactivas las marcas de tiempo? ¿Qué posible amenaza podría representar una marca de tiempo? Apuesto a que el equipo del NTP no estaría contento con esto; ^)
Hmmmm, ¿leí algo sobre el uso de marcas de tiempo TCP para adivinar la frecuencia de reloj del emisor? Quizás esto es de lo que tienen miedo? No lo sé; ^)
Las marcas de tiempo son menos importantes para la estimación de RTT de lo que se podría pensar. Me gustan, porque son útiles para determinar RTT en el receptor o en un middlebox. Sin embargo, de acuerdo con el cañón de TCP, solo el emisor necesita tal conocimiento prohibido; ^)
El remitente no necesita marcas de tiempo para calcular el RTT. t1 = timestamp cuando envié el paquete, t2 = timestamp cuando recibí el ACK. RTT = t2 - t1. ¡Haz un poco de suavización y estarás listo!
... Daniel