El desafío era: "Escribe un filtro de tcpdump / WinDump que la captura de paquetes ICMPv6 escucha de multidifusión." Tengo una extensa escribir sobre lo que hace que la respuesta tan compleja. Si conoces a IPv6 y sólo quiere la respuesta, pase a la final.

En primer lugar, algunos antecedentes

Steinar hizo algunos comentarios a los posts anteriores y fue del 100% en el buen camino. Si les leí y pensé "Wow, eso suena muy complicado", a entender el alcance del problema también.

Protocolo vs. Campo de cabecera siguiente

Con IPv4 teníamos el campo de opciones. Esto podría hacer que la cabecera IP para crecer a partir de 20 bytes a tan grande como 60 bytes de tamaño. Con IPv6, ya no hay un campo de opciones y la cabecera es de 40 bytes de tamaño. Cuando se requieren opciones, utilizamos las cabeceras de extensión para identificarlos. Esto arroja una bola curva de interés en nosotros, porque con el campo de protocolo IPv4 (byte 9) que (casi) siempre identifican el transporte de nivel superior (TCP, UDP, etc.) Con IPv6 el campo de cabecera siguiente (byte 6) puede identificar la capa de transporte superior, o puede identificar una cabecera de extensión que incluirá un número de opciones.

Aquí está una lista de algunas cabeceras de extensión IPv6 que puede encontrar, así como el RFC que los definen:

IPv6 no limita el número de cabeceras de extensión se pueden utilizar en una sola packet.There Sin embargo, es una publicación "orden recomendado" en cuanto a cómo los encabezados debe ser expuesto. El orden es el siguiente:

• Cabecera IPv6
• Hop-by-Hop Opciones
• Routing Header
• Fragmento de cabecera
• AH
• ESP
• Opciones de destino
• Movilidad encabezado
• TCP/UDP/ICMPv6

Tenga en cuenta esta lista es "recomendable" pero no es obligatorio. Un host IPv6 debe ser capaz de procesar los encabezados de lo que sea orden en que fueron recibidos. Esto significa que usted probablemente encontrará siguientes proveedores de esta lista, pero no los atacantes. Personalmente he visto los dispositivos comienzan a actuar muy extraño cuando te metes con el fin de cabecera. De hecho me he encontrado a través de un poco de "código compatibles con IPv6", que no puede hacer frente si el orden de preferencia no se utiliza.

Persiguiendo a la cabecera del protocolo

Así que con IPv6 podemos tener varias cabeceras detrás de la cabecera IPv6. Si esto suena como un nuevo concepto, que en realidad no es. De hecho lo que has trabajado con él ya. Al implementar IPSec los dos protocolos de seguridad posibles son ESP y AH. Estos fueron tomados en realidad de IPv6 y masajes para trabajar en IPv4. AH y ESP incluye un campo de cabecera junto a identificar qué tipo de paquete que se protecting.This se conoce como encadenamiento de protocolo, ya que efectivamente tienen varios encabezados sentado detrás de la cabecera del protocolo de capa 3.

Así que para averiguar lo que el transporte de nivel superior (TCP, UDP, etc) se está utilizando, puede que tenga que buscar a través de varias cabeceras antes de encontrar la respuesta. Esto se conoce como "perseguir la cabecera", y tcpdump / Windump nos dan una opción de filtro para realizar esta tarea. Es posible que fimiliar con el filtro proto. En el mundo IPv4, si yo digo:

tcp ip proto

Que el filtro se lee "cheque de 9 bytes de la cabecera IPv4 y si el valor es igual a 6 (valor de protocolo de TCP), partido en el paquete". Este filtro no es tan eficaz en el mundo IPv6, por supuesto, porque de 6 bytes de la cabecera IPv6 podría identificar la capa de transporte superior, o que sólo puede identificar una cabecera de extensión opcional que se utiliza. Para resolver este problema, el filtro protochain se introdujo. Por escrito:

ip6 protochain tcp

Lee como "Check 6 bytes de la cabecera IPv6 para ver si el valor es igual a 6. Si en lugar de encontrar un valor que identifica una cabecera de extensión opcional, verificación de campo en el encabezado de extensión de la siguiente cabecera, por un valor de 6. Si usted encuentra las cabeceras de extensión opcionales más, repetir la última prueba hasta encontrar la cabecera de la última extensión ".

Muy simple para escribir en Inglés, pero esto es una pesadilla para implementar en el código. La mayoría de las cabeceras de extensión opcionales son de longitud variable que sólo se suma a la complejidad. He hecho algunas pruebas con Scapy y usted puede ver realmente la diferencia en el rendimiento cuando se invoca protochain. De hecho, usted probablemente podría hacer un buen trabajo de la administración un IDS / IPS por lo que obligó a procesar una gran cantidad de cabeceras de extensión inútil.

Escribir nuestro filtro

Así que nuestro primer problema en el filtro de la escritura desafío es que la cabecera ICMPv6 puede no aparecer inmediatamente después de la cabecera IPv6. Tenemos que mirar hacia fuera para las cabeceras de extensión opcionales. De hecho, RFC 2710: "Todos los mensajes MLD se describe en este documento se envían con una dirección de origen de enlace local IPv6, un límite de saltos IPv6 de 1, y una opción Router Alert IPv6 [RTR-ALERT] en un Hop-by-Hop Opciones de cabecera. "Esto significa que nuestro paquete de oyente multicast es necesario tener una extensión de la cabecera Hop-by-Hop con el conjunto de opción Router Alert. Con esto en mente, nuestro primer cheque debe ser:

ip6 protochain icmp6

Para asegurar que sólo se busca en paquetes ICMPv6. Ahora es sólo una cuestión de control para ver si el tipo de campo (byte 0) está establecido en 130 (consulta de escucha de multidifusión) o 131 (Informe de escucha de multidifusión). Esto nos lleva a nuestro segundo problema sin embargo. En el mundo IPv4 puedo hacer:

icmp [0] = <tipo valor de interest>

Si intenta esto con icmp6 me sale:

[Root @ Fubar ~] # tcpdump-nn icmp6 [0] = 130
tcpdump: IPv6 protocolo de capa superior no es compatible con proto [x]

En otras palabras, no pueden utilizar las compensaciones con icmp6 para buscar valores específicos. Windump tcpdump y se anuncian como compatibles con IPv6, pero no esperes conseguir la misma funcionalidad que tiene con IPv4. Puaj!

Entonces, ¿qué hacemos? Vamos a tener que recurrir a la referencia al valor de un ip6 offset. En otras palabras, vamos a tener que medir a través de la cabecera IPv6, a través de la necesaria Hop-by-Hop cabecera, y en la cabecera ICMPv6 para ver si el tipo de campo se encuentra a 130 o 131. Algunas cosas a tener en cuenta:

• Cabecera IPv6 es de 40 bytes de tamaño
• Hop-by-Hop cabecera es variable, pero el grupo 4 bytes con Router Alert
• El tipo de campo es de 0 bytes en la cabecera ICMPv6

Así que aquí es lo que nos encontramos con:

ip6 protochain icmp6 y (ip6 [44] = 130 o ip6 [44] = 131)

¡Menos mal! Por fin lo tengo! O que hemos hecho?

Q: ¿Qué pasa si el paquete tiene más encabezados de extensión?

R: Nuestro filtro no funcionará.

Q: ¿Qué pasa si la cabecera Hop-by-Hop tiene más opciones de conjunto de Alerta Router?

R: Nuestro filtro no funcionará.

Q: ¿Se puede arreglar estos dos problemas?

R: No hasta tcpdump / Windump añade filtrado IF / THEN apoyo bucle.

Así que si queremos capturar el tráfico de ML normal, el filtro anterior no tendrán ningún problema. Sin embargo, si queremos asegurar que la captura astucia atacante, así, el filtro no va a volar.

¿Qué pasa si se intenta algo como esto:

tcpdump-nn-s 1500-x ip6 protochain icmp6 | grep-i multicast> multicast.txt

y luego sólo tiene que utilizar la herramienta text2cap Wireshark para convertirlo a formato Libpcap? El problema aquí es que sólo obtendrá la información de la cabecera. Grep coincida con la línea de resumen que contiene la palabra "Multicast", pero luego saltar todos los hexagonal por debajo de lo que es el contenido real del paquete.

Así que la respuesta final es: "No se puede obtener theyâ de Haya de la Torre"

¿Y qué si usted realmente necesita para poder ver este tráfico? Hasta que el soporte para IPv6 madura, el único método 100% es para agarrar todo el tráfico ICMPv6 y luego manualmente ordenar a través de ella.

Al menos esa es mi opinión al respecto. Si alguien puede realmente llegar a una solución de trabajo del 100%, me encantaría escucharla.

OK, aquí va una pista para señalarle en la dirección correcta.

El desafío era: "Escribe un filtro de tcpdump / WinDump que la captura de paquetes ICMPv6 Multicast Listener".

Suena fácil, ¿verdad?

Con un poco de ayuda de Google verá que el "tipo" de escucha de multidifusión es de 130, y el tipo de campo ICMPv6 es el primer byte de la cabecera. Así que esto debería ser tan fácil como:

tcpdump-nn-p-v-s 0 icmp6 [0] = 130

Sin embargo, si ejecuta el comando que pondremos en contacto:

tcpdump: IPv6 protocolo de capa superior no es compatible con proto [x]

En otras palabras, puede utilizar "icmp6" para ver todos los paquetes ICMPv6, pero no se puede utilizar para filtrar en cualquiera de los campos de la cabecera ICMPv6.

Así que necesitamos un "Plan B". Descubrir el plan B y que ha resuelto el problema.

Sobre la base del desafío IPv6 desde la última vez, tengo un uno nuevo para usted: Escribir un filtro de tcpdump / WinDump que la captura de paquetes ICMPv6 escucha de multidifusión.

Eso es todo! Muy sencillo, ¿verdad?

Así su ahora Jueves, así que pensé es el momento de publicar las respuestas a desafiar la semana pasada.

En primer lugar, ¿por qué te importa acerca de IPv6, si usted no ha comenzado su despliegue? Me sentí de la misma manera hasta que encontré IPv6 se utiliza como un canal de comunicación encubierta dentro de la red de un cliente. Los datos fueron luego ser empujado a Internet a través de Teredo. Si usted no está familiarizado con la técnica, Scott Hogg tiene algunos puestos excelentes sobre el tema.

Así que incluso si usted no está utilizando IPv6, vale la pena empezar a cortar la cura de la tecnología, así como la observación de que en su red local.

A que revisen, el desafío era:

Escribir un filtro de tcpdump o Windump que capturar todo el tráfico con una dirección IPv6 de origen de 2001: db8:: 10 a 2001: db8:: 20.

Hay un par de advertencias por escrito con este filtro. El que los primeros tratados en el post anterior. El último, que yo sabía, pero nunca pensé que realmente era un problema hasta que comenzó a trabajar con IPv6 muy fuerte, es que tcpdump / Windump sólo le permitirá utilizar 1, 2 o 4 máscaras de bytes. Así que, aunque nos gustaría resolver esto con una declaración inicial de filtro de "ip6 [08:14] =", no podemos, porque estamos limitados a 4 bytes. De hecho, hay una manera de evitar esto, pero voy a volver a ella.

Así que aquí está el filtro que he estado trabajando con:

(Ip6 [08:04] = 0x20010db8 y ip6 [12:04] = 0 y ip6 [16:04] = 0 y (ip6 [20:04]> = 0 × 0010 y ip6 [20:04] <= 0050 ))

Poco largo, pero funciona. Isabel se le ocurrió una solución que es mucho más elegante que la mía:

src neto 2001: db8:: / 122 y ip6 [23]> = 0 × 10 & & ip6 [23] <= 0 × 20

Por lo tanto, comenzando con el formato libpcap, ella es capaz de combinar mis tres primeros estados en uno solo. De no ser una reina de tamaño, pero que hace que su solución es mucho más corta que la mía. En este caso, que es una buena cosa.

Eso es todo. Voy a publicar otro de los desafíos de tipo IPv6 mañana.

Wow, el sonido de los grillos es ensordecedor. Seguro que alguien tiene la habilidad de llevarnos a través de este dilema?

Bien, algunos consejos para ayudarte a superar el reto. Vamos a empezar por la solución de este como una dirección IPv4 y luego vamos a trabajar en nuestro camino hacia IPv6. Supongamos que el rango de direcciones que queremos capturar es 192.168.1.10 - 192.168.1.20. El gran problema es la IP que no están en un límite incluso de bytes. Podríamos hacer algo como:

src net 192.168.1.0/27

pero que nos dan las direcciones .0 a 0,31, más IPs de lo que realmente quería ver. Para resolver este problema, tendrá que utilizar algunos operadores y primitivas. Una posibilidad es la siguiente:

(Ip [12] = 192 y ip [13] = 168 y la ip [14] = 1 y (ip [15]> = 10 y la ip [15] <= 20))

A partir de los soportes más interna, la declaración anterior se lee "15 bytes debe ser mayor que o igual a 10, pero también debe ser menor o igual a 20. Si esta afirmación es cierta, asegúrese de byte 12 es igual a 192, el byte 13 es igual a 168 bytes y 14 es igual a 1. "

¿Se puede acortar esta expresión? ¡Por supuesto! En primer lugar tenemos que convertir a hexadecimal sin embargo. ¿Por qué hexagonal? Si escribo una frase como "ip [12:02] =" tcpdump se asume que el resultado será un número de 16 bits, no dos números de 8 bits. Esta es la razón por la que se puede escribir algo como "tcp [2:2] = 12345" y hacer que funcione. tcpdump convierte los dos bytes en un valor de 16-bit y lo compara con el valor especificado. Al convertir a hexadecimal se evita este problema. Por lo tanto:

192.168.1.10 = 0xC0A8010A

192.168.1.20 = 0xC0A80120

Ahora simplemente escribimos nuestra expresión:

ip [12:04]> = 0xC0A8010A y ip [12:04] <= 0xC0A80120

Eso es todo lo que hay que hacer.

Mientras que IPv4 utiliza direcciones de 4 bytes, IPv6 utiliza 16 bytes. Debido a que las direcciones son tan largas, los escribimos en hexadecimal para ahorrar algo de espacio. Por lo tanto las direcciones que te di en el desafío fueron los siguientes:

2001:0 db8: 0000:0000:0000:0000:0000:0010

2001:0 db8: 0000:0000:0000:0000:0000:0020

Fíjate que no tenía, inicialmente, a escribir de esa manera. Hay una serie de convenciones que puede utilizar para ahorrar espacio al escribir una dirección IPv6. En primer lugar, se puede truncar ceros a la izquierda. Por lo tanto:

2001:0 db8: 0000:0000:0000:0000:0000:0010

se convierte en:

2001: db8: 0000:0000:0000:0000:0000:10

Ahora, ver a todos esos ceros en el medio? Podemos cortarlas demasiado. Cuando vea "::" eso significa que para llenar ese espacio con ceros suficientes para ampliar la dirección de vuelta a 16 bytes. Por lo que añadir en este truco, así y conseguir que:

2001: db8:: 10

Mucho más fácil escribir. La única salvedad es que sólo se puede quitar un grupo de ceros con el truco de puntos dobles. Considere la siguiente dirección:

2001:: 1234:: 10

No tenemos idea de dónde colocar la secuencia de bytes "1234" en la dirección. Que empezar en cualquier lugar del byte 6 a 12 bytes.

Cuando se trabaja con IPv4, tcpdump y Windump utilizar la palabra clave del protocolo "IP", como se muestra en los ejemplos anteriores. El complemento a IPv6 que es "IP6". ¿Dónde está el campo de dirección de origen en la cabecera IPv6? Bueno, no puedo darle todo lo que hay respuestas, o ya no es un "desafío"

Aquí hay otro desafío para poner a prueba sus habilidades wienie poco:

Escribir un filtro de tcpdump o Windump que capturar todo el tráfico con una dirección IPv6 de origen de 2001: db8:: 10 a 2001: db8:: 20. Muy sencillo, ¿verdad? Si no lo he probado, la va a encontrar que tcpdump / Windump arroja unas curvas de ti.

Para comprobar su trabajo, aquí hay un archivo de captura:

ipv6-icmp

El archivo contiene una mezcla de direcciones IPv6 de origen. Es evidente que el filtro sólo debe mostrar el rango de direcciones especificado.

El ganador puede inspirar temor y admiración en menor geeks.

Si este reto parecía más difícil de lo que debería ser, usted está en el camino correcto.

Me encontré con este problema al escribir mi Decode paquete de herramientas. Tengo que decir que fue un ejercicio fresco para mí, pues nunca he pensado en la creación de filtros tcpdump y Wireshark para cada IP que sea posible, TCP, UDP y ICMP de campo y / o valor. Con mucho, el campo de opciones TCP es la más "roto" desde una perspectiva de decodificación de paquetes IP que cualquier otro campo.

En primer lugar vamos a hablar de cómo las opciones TCP que se han implementado. Si nos fijamos en el campo de opciones de IPv4, que comienza con un "tipo" de identificación. Si usted está interesado en una opción de IP específica, es sólo una cuestión de comprobación de este campo de la combinación de bits derecha. Tenía las opciones de TCP han implementado esta manera, este problema habría sido bastante sencillo.

Casi todas las opciones de TCP tienen una "clase" y "longitud" de campo, los cuales son 1 byte de tamaño. Las excepciones son "Fin de la lista de opciones" y "no-operación" que sólo tiene un campo de clase, y por lo tanto son un byte de tamaño. Aquí hay una lista de las opciones comunes de TCP:

La página 15 de RFC 793 nos dice: "La cabecera TCP (incluso un incluidas las opciones) es un número entero de 32 bits." En otras palabras, el tamaño del encabezado TCP en bytes debe ser divisible por cuatro (20 bytes, 24 bytes, etc.) Si nos fijamos en la lista de opciones TCP, sólo "el tamaño máximo de segmento" es divisible por cuatro. Por lo tanto el uso de cualquier otra opción se va a requerir de relleno.

¿Cómo el relleno se debe aplicar es un poco confuso. Si nos fijamos en la página 26 del RFC 1323, encontramos lo siguiente:

  Apéndice A: sugerencias de aplicación

    Los diseños se recomienda lo siguiente para las opciones de envío en la no-SYN
    segmentos, para lograr la máxima alineación posible de 32-bit y 64-bit
    máquinas.

        +--------+--------+--------+--------+
        | NOP ​​| NOP ​​| TSopt | 10 |
        +--------+--------+--------+--------+
        Fecha y hora TSval | |
        +--------+--------+--------+--------+
        | Timestamp TSecr |
        +--------+--------+--------+--------+ 

Tenga en cuenta el relleno NOP se presenta ante la opción de marca de tiempo, no al final como era de esperar. También tenga en cuenta el RFC específicamente dice que esto es para los "no-SYN segmentos" y que es "recomendable", no es necesario. Sin embargo, parece que la mayoría de los sistemas operativos de seguir esta recomendación y siempre con material acolchado antes de que el tipo y bytes de longitud. He comprobado Windows, Linux, Mac, de hardware, etc, y todos ponen el relleno al principio.

Así que podemos contar con este ser el "estándar", ¿verdad? No del todo. La página 17 de RFC 793 describe NOP de esta manera:

  Este código de opción puede ser utilizado entre opciones, por ejemplo, para
         alinear el comienzo de una opción posterior de un límite de palabra.
         No hay garantía de que los remitentes a utilizar esta opción, por lo que
         Los receptores deben estar preparados para procesar opciones incluso si lo hacen
         no comenzar en un límite de palabra. 

En otras palabras, no es sólo que NOP puede o no puede aparecer al principio, NOP, no puede ser utilizado en todos! Es totalmente legal a la disposición del campo de opción TCP sin relleno NOP y sólo el uso final de la lista de opciones como material de relleno al final de alcanzar el límite adecuado.

Entonces, ¿qué nos encontramos con un filtro? Si contamos con NOP antes de que la opción que terminar con un filtro que tiene este aspecto:

tcp [13] y 2 = 2 y tcp [12] y 240> 80 y ((tcp [20] = 1 y tcp [21:02] = 0 × 0303) o (tcp [24] = 1 y tcp [25:2 ] = 0 × 0303) o (tcp [28] = 1 y tcp [29:2] = 0 × 0303) o (tcp [32] = 1 y tcp [33:2] = 0 × 0303) o (tcp [ 36] = 1 y tcp [37:2] = 0 × 0303) o (tcp [40] = 1 y tcp [41:2] = 0 × 0303) o (tcp [44] = 1 y tcp 45:2 [ ] = 0 × 0303) o (tcp [48] = 1 y tcp [49:2] = 0 × 0303) o (tcp [52] = 1 y tcp [53:2] = 0 × 0303) o (tcp [ 56] = 1 y tcp [57:2] = 0 × 0303))

Para romper este filtro, lo que está haciendo:

• Sólo comprobar SYN y SYN / ACK: tcp [13] y 2 = 2
• Encabezado TCP es mayor de 20 bytes (las opciones se establecen): tcp [12] y 240> 80
• Compruebe que el primer byte de cada límite de cuatro bytes para NOP: tcp [20] = 1, tcp [24 = 1, ...
• Compruebe los dos bytes siguientes para ver si Tipo = 3 y Longitud = 3: tcp [21:02] = 0 × 0303, tcp [25:2] = 0 × 0303, ...

Sin embargo, si queremos asegurarnos de que tenemos todas las posibilidades de captura en caso de que un sistema no implementa NOP nos encontramos con:

tcp [13] y 2 = 2 y tcp [12] y 240> 80 y (tcp [20:02] = 0 × 0303 o TCP [21:02] = 0 × 0303 o TCP [22:02] = 0 × 0303 o tcp [23:02] = 0 × 0303 o tcp [24:2] = 0 × 0303 o tcp [25:2] = 0 × 0303 o tcp [26:2] = 0 × 0303 o tcp [27:2] = 0 × 0303 o tcp [28:2] = 0 × 0303 o tcp [29:2] = 0 × 0303 o tcp [30:2] = 0 × 0303 o tcp [31:2] = 0 × 0303 o TCP [32:2] = 0 × 0303 o tcp [33:2] = 0 × 0303 o tcp [34:2] = 0 × 0303 o tcp [35:2] = 0 × 0303 o tcp [36:2] = 0 × 0303 o tcp [37:2] = 0 × 0303 o tcp [38:2] = 0 × 0303 o tcp [39:2] = 0 × 0303 o tcp [40:2] = 0 × 0303 o TCP [ 41:2] = 0 × 0303 o tcp [42:2] = 0 × 0303 o tcp [43:2] = 0 × 0303 o tcp [44:2] = 0 × 0303 o tcp [45:2] = 0 × 0303 o tcp [46:2] = 0 × 0303 o tcp [47:2] = 0 × 0303 o tcp [48:2] = 0 × 0303 o tcp [49:2] = 0 × 0303 o TCP 50 [ : 2] = 0 × 0303 o tcp [51:2] = 0 × 0303 o tcp [52:2] = 0 × 0303 o tcp [53:2] = 0 × 0303 o tcp [54:2] = 0 × 0303 o tcp [55:2] = 0 × 0303 o tcp [56:2] = 0 × 0303 o tcp [57:2] = 0 × 0303 o tcp [58:2] = 0 × 0303)

La diferencia con este filtro es que estamos revisando Tipo = 3 y Longitud = 3 hasta el final a través del campo de opciones (como Elizabeth sugerido).

¿Puede alguno de estos filtros de generar falsos positivos? ¡Por supuesto! Dos posibilidades:

1. El valor de marca de tiempo coincida con el patrón que estamos buscando.
2. El filtro supone un campo de 40 bytes opción. Podría ser menos con estos valores en la carga útil.

Entonces, ¿qué filtro debe usar? El primero va a generar menos falsos positivos, pero se pierda los sistemas que son compatibles con RFC, pero diferente de la norma. El segundo, siempre se encontrará la escala de ventana si se ha establecido, pero la posibilidad de un falso positivo es mayor.

Voy a designar a Isabel como el ganador del desafío. Algunos otros estaban tan cerca, pero ella era la única que tiene las agallas para publicar su línea de pensamiento en los comentarios. Voy a conceder un segundo premio a Jeff quien se le ocurrió esta solución parcial bromeando:

tcpdump-nn | grep 'wscale'> wscale-matches.txt

Esto no va a generar una captura de paquetes reales, pero se puede hacer a:

tcpdump-nn-X-s 0 | grep 'wscale'> wscale-matches.txt

Y luego ejecutar a traves de txt2cap para volver al formato pcap. Él no siguió específicamente el reto, pero tienes que dar felicitaciones por pensar fuera de la caja, ya que soluciona todos los problemas de falsos positivos.

Elizabeth y Jeff, voy a estar en contacto con usted, tanto a través de e-mail. ¡Felicidades!

He tenido un puesto de hilo y cuatro correos electrónicos que se soooooo cerca de la respuesta correcta. Aquí hay una última pista para llegar con suerte la gente sobre el último obstáculo.

He mencionado el comando tshark útil. Aquí está la salida:

C: \ pruebas> tshark-n-r linux-syn.cap-T campos-e tcp.options
02:04:05: b4: 04:02:08:0 a: 2:47:04 a: a8: 00:00:00:00:01:03:03:05

Así que lo que tienen encima es la sección de Opciones TCP (20 bytes y superior) del paquete de prueba. La opción de escala de la ventana es la última opción en la lista.

Sé escribir este filtro no es fácil. De hecho, es por eso que se convirtió en un reto. Sin embargo es posible.