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"