Con las opciones de IP podemos especificar la ruta que queremos que tome un paquete IP mientras se conecta a un servidor. Si sabemos que un servidor en particular proporciona alguna funcionalidad adicional basada en la dirección IP, ¿no podemos utilizarla falsificando un paquete IP para que la dirección IP de origen sea la dirección IP privilegiada y uno de los hosts en el enrutamiento de origen sea el nuestro?
Entonces, si la dirección IP privilegiada es x1 y la dirección IP del servidor es x2 y mi propia dirección IP es x3. Envío un paquete de x1 a x2 que se supone que pasa por x3. x1 en realidad no envía el paquete. Es sólo que x2 cree que el paquete vino de x1 a través de x3. Ahora, en respuesta, si x2 usa la misma política de enrutamiento (como cortesía hacia x1), x3 recibirá todos los paquetes.
¿El destino normalmente utilizará las mismas secuencias de direcciones IP especificadas en el encabezado de enrutamiento para que los paquetes provenientes del servidor pasen a través de mi IP, donde puedo obtener la información requerida?
¿No podemos falsificar una conexión TCP en el caso anterior?
¿Se utiliza este ataque en la práctica? ¿Alguien lo ha usado?
Respuesta1
Ahora hay algunas buenas ideas. Pero no temas, este ya es un ataque conocido:
- http://www.citi.umich.edu/u/provos/papers/secnet-spoof.txt
- http://technet.microsoft.com/en-us/library/cc723706.aspx
Su peligro se ve mitigado por el hecho de que los paquetes enrutados en origen generalmente están bloqueados en los límites de las organizaciones, y también por el hecho de que el enrutamiento en origen está deshabilitado de forma predeterminada en sistemas operativos de servidor como FreeBSD y OpenBSD (y al menos en algunas distribuciones de Linux, por ejemplo Arch Linux). Citando ese primer enlace:
El impacto de este aviso se reduce considerablemente debido a la gran cantidad de organizaciones que bloquean paquetes enrutados de origen y paquetes con direcciones dentro de sus redes. Por lo tanto, presentamos la información más bien como un mensaje de advertencia para aquellos con inclinaciones técnicas y para reiterar que la aleatorización de los números de secuencia TCP no es una solución efectiva contra este ataque.