¿Qué sucede cuando un paquete de IP de origen falsificado se envía fuera de una red privada con NAT?

Hay tres comportamientos probables a medida que el paquete se envía desde la LAN al enrutador:

1. El enrutador aplica el filtro de ruta inversa y elimina el paquete.
2. El enrutador no filtra. En su lugar, el enrutador lo trata como cualquier otro paquete de la LAN, lo que significa que la IP de origen se reemplaza con la IP del enrutador, y el enrutador crea una entrada de seguimiento de conexión.
3. El enrutador no aplica filtrado o NAT. En su lugar, el enrutador reenvía el paquete con la dirección de origen falsificada.

En el primer caso, no pasa nada más. En el tercer caso, el paquete puede ser retirado o reenviado por el ISP. En uno de estos casos, el paquete falsificado llega hasta el objetivo. Pero ninguna respuesta volverá a este enrutador, ya que iría a la IP falsificada.

El caso más interesante es aquel en el que se aplica NAT al paquete. El ISP ya no podrá soltar el paquete en función de la IP de origen, porque en este caso la IP de origen es de hecho válida en lo que respecta al ISP. Pero esto no es muy perjudicial porque los paquetes se pueden filtrar fácilmente según la IP de origen una vez que llegan al destino (suponiendo que la inundación sea lo suficientemente grande como para que se note en el destino). Tampoco se puede abusar fácilmente en un ataque de reflexión, porque las respuestas se remontan al enrutador NAT.

Lo que sucede con las respuestas al enrutador NAT es más interesante. Coincidirán con una entrada de seguimiento de conexión. Pero después de que se haya aplicado el NAT, la dirección de destino no estará dentro de la LAN, sino externamente. En este punto hay algunos resultados posibles:

• El enrutador puede rehusarse a reenviar el paquete porque se enviaría de vuelta a la interfaz desde donde vino.
• El enrutador puede reenviar el paquete a la red externa tan pronto como haya aplicado NAT de acuerdo con la entrada de seguimiento de la conexión.
• El enrutador puede intentar realizar NAT en el paquete nuevamente, ya que se estaría dejando en la interfaz externa.

El primer caso en el que se descarta el paquete, no es particularmente interesante o perjudicial.

El segundo caso en el que el paquete se reenvía a la red externa es más interesante. Este es el caso en el que el NAT evitó que se produjese la falsificación en primer lugar, pero un efecto secundario de esto es que al procesar la respuesta, en realidad produce un paquete con una IP de origen falsificada (de hecho, la IP de origen y destino del original). paquete ha sido revertido).

Si el ISP no filtra el paquete debido a una IP de origen no válida, el tráfico de retorno se reenviará a la IP que se falsificó en primer lugar. Y a la llegada se verá más o menos igual que si no hubiera ocurrido ningún NAT.

Pero como esto implica tres viajes a través de la conexión externa de la red atacante, la velocidad del tráfico de ataques es limitada en comparación con lo que podría haber sido.

Si el enrutador intenta volver a NAT, las cosas se ponen un poco interesantes. El problema aquí es que no es el primer paquete de un flujo, por lo que la capa NAT puede no saber cómo manejarlo. Por lo tanto, el paquete puede eliminarse debido a la aplicación de NAT sin haber visto el primer paquete del flujo.

También es posible que se cree una entrada de seguimiento de conexión. Como la entrada de seguimiento de conexión recién creada obviamente no se aplicó al primer paquete del flujo, no hay forma de que esto funcione para una conexión TCP. Pero otros protocolos podrían funcionar incluso en tal escenario. Sin embargo, dado que este paquete en particular se debe a la suplantación de identidad, nada bueno saldrá de la NAT.

Si asumimos que se trataba de un paquete TCP SYN-ACK, y el enrutador lo vuelve a utilizar en NAT, a pesar de que no tiene ningún sentido, entonces el ISP reenviará el SYN-ACK. El SYN-ACK activará una respuesta RST (asumiendo que el destino es funcional), el RST luego regresará a través de ambas entradas de seguimiento de la conexión y se reenviará al host desde donde vino el SYN-ACK y limpiará la conexión.

Como puede ver, hay muchos ifs en este flujo. Y es probable que haya un posible resultado, que no he considerado.

Depende de la configuración de tu enrutador.

• Si su enrutador tiene filtrado en su lugar, eliminará el paquete, ya que su dirección de origen no proviene de ninguna red conocida por el enrutador. Normalmente configuro mis puertas de enlace / firewalls / routers para hacer esto.

• Si su enrutador no tiene ningún filtro (el escenario más común) cambiará la dirección de origen en el paquete a su propia dirección, y colocará una entrada en una tabla interna para "recordar" a qué conexión paquete pertenece. Tan pronto como reciba una respuesta, el enrutador mirará esa tabla interna para ver dónde enviar el paquete. Como la dirección no es de ninguna red interna, el enrutador enviará el paquete a la puerta de enlace predeterminada.

Editar: las botnets DDoS generalmente no se basan en este método. Generalmente consisten en docenas (o cientos) de miles de computadoras infectadas, esperando un comando para atacar algún sitio. Cuando llega el comando, todas las computadoras infectadas se conectan al mismo sitio a la vez. Si un botmaster tiene 100.000 bots en su red, cada uno con un promedio de enlace descendente de 4 Mbps, teóricamente puede generar 400 Gbps de tráfico.

Hay otro método DDoS, llamado amplificación . Funciona falsificando la fuente y enviando un paquete a un servicio que devuelve más datos de los que fue enviado. DNS y NTP son los protocolos abusados más comunes. Amplificación de DNS utiliza unos 60 bytes salientes y, a menudo, genera un retorno de más de 4k bytes. Es una proporción de 70: 1.

En este caso, una botnet muy pequeña (10.000 bots con una conexión promedio de 4 Mbps) puede generar suficiente tráfico para derribar muchos sitios.