¿Es práctico el spoofing de ICMP?

¿Qué tan práctico es la falsificación de ICMP?

escenario 1: en un entorno NAT, ¿cómo NAT realiza un seguimiento de las sesiones ICMP (no técnicamente sesiones ya que no está orientado a la conexión?) Para la respuesta ECHO / ECHO Windows usa el mismo identificador (0x1) y número de secuencia con 256 incrementos para cada paquete . Si dos hosts hacen ping al mismo servidor externo, ¿cómo distingue NAT los paquetes ICMP entrantes? Si la red interna no filtra la dirección de origen, ¿qué tan difícil es falsificar una respuesta ECHO? caso de uso: ping icmp utilizado para la supervisión, un equilibrador de carga puede tomar acciones incorrectas / innecesarias al recibir respuestas ICMP falsificadas (destino inalcanzable, alta latencia, etc.)

escenario 2: Algún dispositivo IPS, digamos el GFW, inspeccionando paquetes en la ruta de tránsito. Cuán práctico es falsificar mensajes de error ICMP que matan una conexión con sigilo. En lugar de enviar TCP RST, envía el puerto de destino inalcanzable / el paquete es demasiado grande (esto puede ser interesante :)) con una IP de origen falsificada (la IP legítima del otro lado o algunos saltos más adelante). Mantener el seguimiento del encabezado IP original y los primeros 64 bytes puede ser costoso, pero con la potencia informática disponible en la actualidad, ¿es factible?

Básicamente, ya sea desde dentro o desde fuera de NAT, ¿qué tan probable es que ICMP falsificado cause daños / confusiones? No estoy hablando de la inundación ICMP.

Por cierto, ¿NAT puede manejar cualquier protocolo IP que no sea TCP / UDP? En realidad, no estoy exactamente seguro de cómo maneja los diferentes tipos de ICMP.

RFC 5508 "Requisitos de comportamiento NAT para ICMP" dice (sección 3.1):

La asignación de consultas ICMP por dispositivos NAT es necesaria para que funcionen las aplicaciones actuales basadas en consultas ICMP. Esto implica un dispositivo NAT para reenviar transparentemente los paquetes de consulta ICMP iniciados desde los nodos detrás de NAT, y las respuestas a estos paquetes de consulta en la dirección opuesta. Como se especifica en [NAT-TRAD], esto requiere traducir el encabezado IP. Un dispositivo NAPT traduce aún más el Id. De consulta ICMP y la suma de verificación asociada en el encabezado ICMP antes del reenvío.

Por lo tanto, un dispositivo NAT puede poner un valor único en el campo Identificador cuando reenvía una solicitud al exterior. Dos máquinas en el interior que usan el mismo identificador no son un problema, el dispositivo NAT usará dos valores diferentes y recordará la combinación de la ID original y la dirección IP interna.

Puede encontrar información específica de Cisco (antigua) aquí: http://www.ciscopress.com/articles/article.asp?p=25273&seqNum=3 . Esta página también incluye una lista de protocolos / aplicaciones compatibles para NAT.

Si se envía un mensaje ICMP para notificar un error causado por una conexión TCP, el mensaje ICMP debe incluir el encabezado y parte de la carga útil del segmento TCP que activó el error. Esto es necesario para permitir que el host receptor identifique la conexión TCP.

Un dispositivo NAT puede hacer exactamente lo mismo para averiguar dónde enviar los errores ICMP que recibe. Si tiene una asignación correspondiente al encabezado TCP en la carga útil de ICMP, sabe a dónde enviar el mensaje ICMP.

Un atacante que quiera falsificar un error ICMP necesitaría conocer las direcciones IP y los puertos de origen y destino para crear su mensaje. Debido a que la carga útil del mensaje ICMP también contendrá un número de secuencia TCP, el punto final TCP también podría verificar si este número de secuencia es válido (es decir, enviado y aún no registrado). Esto hará que la suplantación de identidad sea mucho más difícil, pero esta validación podría no implementarse en todos los sistemas.

Probablemente debería echar un buen vistazo a RFC 5927 "Ataques ICMP contra TCP".

En cualquier implementación moderna de NAT con estado, el seguimiento de la conexión es generalmente una parte fundamental para facilitarlo. Realmente no hay ninguna limitación sobre qué protocolos IP pueden ser manejados por NAT: Linux Netfilter puede felizmente NAT cualquier protocolo IP, pero obviamente, con la limitación de que si no hay un manejo especial para ese protocolo (es decir, discriminadores adicionales), solo uno dentro del host es va a poder comunicarse con un host externo particular a la vez.

En el caso de ICMP echo request, es muy poco probable que el identificador y el campo de marca de tiempo coincidan con el de otro host que hace ping al mismo punto final remoto; por lo tanto, siempre que la implementación de seguimiento de conexión / NAT sea capaz de utilizar estos datos, puede diferenciar entre los dos. Para que destination unreachableel dispositivo NAT tuviera que rastrear los datos de la carga útil (es decir, los primeros 8 bytes) para asegurar la validez del mensaje de error ICMP, pero aun así, el punto final del host definitivamente debería validar dicho mensaje.

En términos generales, suponiendo que una pila de red compatible con RFC, los mensajes ICMP falsificados no deberían ser un problema debido al hecho de que varios campos son únicos ... A menos que el atacante sea un hombre directo en el medio, en cuyo punto pueden interferir con bastante libertad. Por supuesto, esta es la razón por la que existen cosas como IPsec, TCP-MD5 y TCP-AO.

NB: mientras que un número de RFC sí existen en relación con NAT, debería no ser considerada una norma acordada en la forma que las cosas como son los protocolos de enrutamiento.