Pregunta de la No cON Name

Durante la charla que dimos en la No cON Name sobre "IP Fragmentation Overlapping", en la ronda de preguntas, uno de los asistentes preguntó si era posible encontrar overlapping en un tráfico normal de la red, es decir, sin que existan malas intenciones.

Yo respondí que, desde mi punto de vista, NO, ya que el overlapping es una situación completamente anómala, y ninguna pila TCP/IP debería fragmentar con overlapping, así que si nos encontramos una fragmentación con overlapping, casi 100% seguro tenemos detrás alguna persona con no muy buenas intenciones.

Tras mi respuesta, una persona levantó la mano y me planteo una situación, que era... ¿qué pasa si los fragmentos van por un camino muy lento, tanto que salta el timeout del origen y vuelve a reenviar los datos, y esta vez van por otro camino más rápido, de tal forma que llegan al destino ambos fragmentos a la vez? Entonces se produciría overlapping sin que sea un ataque, ¿no?

Mi respuesta estuvo basada completamente en la suposición y en el conocimiento que tengo de como funciona la fragmentación ip y las redes en general, pero tal y como dije en las conferencias, es algo que no podía garantizarles sin probarlo.

Ahora, después de probarlo, vamos a darle una respuesta algo más que teórica a esta pregunta:

1. En caso de que se produjeran, los dos fragmentos con el mismo offset deberían tener EXACTAMENTE los mismos datos, así que el método de defragmentación sería indiferente. Si algo similar a esto ocurriera, la clave para determinar si es un ataque o alguna anomalía en la red, es comprobar el contenido de los fragmentos. Si los fragmentos que hacen overlapping tienen exactamente el mismo contenido, no hay problema, no se trata de un ataque. Si tienen contenido diferente... alerta! alguien ahí fuera está intentando algo.
2. Mi respuesta, basada en la lógica, es que dado que no se recibe un ACK de cada fragmento, sino que se recibe el ACK del paquete una vez defragmentado, en caso de no recibirse el ACK (por congestión, porque se pierde un fragmento y no se puede reconstruir, porque el checksum del paquete defragmentado ha fallado, por lo que sea), el origen vuelve a enviar el paquete (al no recibir ACK), y este paquete (que no fragmento) viajará por la red, y si llega a un router en el que debe ser fragmentado, se fragmentará, pero es posible que ni siquiera sea el mismo router que realizó la anterior defragmentación, así que el IPID sería diferente.

No dispongo de una infraestructura de red como para probar todo esto, pero haciendo una pequeña prueba con fragroute con una configuración como la de la segunda demo de las conferencias, ya que en ocasiones (como se puede ver en la demo) no se fragmentaba correctamente y la conexión no funcionaba. En estos casos, he realizado una captura de red para observar los IPID de los fragmentos al ser reenviados, y este ha sido el resultado:

Como podéis ver, el Linux asigna IPIDs consecutivos para cada fragmentación, y aunque evidentemente esto es algo que puede cambiar con el tipo de pila TCP/IP del sistema que realiza la fragmentación, entendemos que es más que improbable que dos paquetes con mismo origen, destino, número de secuencia, etc, resultaran ser fragmentados con el mismo IPID (sería una sucesión de colisiones muy complicada).

Aún así, la posibilidad teórica existe, y en ese caso, como decíamos anteriormente, el contenido es el que nos dirá si se trata de un ataque o no.