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:
- El valor de marca de tiempo coincida con el patrón que estamos buscando.
- 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!
