¿Los enrutadores actuales evitan los encabezados IP falsos?

Sé que las personas pueden modificar los encabezados IP y cambiar la dirección IP de origen, pero debería ser simple para los dispositivos de red detectar esos mensajes. Si no lo hacen, ¿por qué es tan difícil? ¿Agrega demasiada sobrecarga?

Sé que las personas pueden modificar los encabezados IP y cambiar la dirección IP de origen, pero debería ser simple para los dispositivos de red detectar esos mensajes.

Las direcciones de origen IP falsas en los encabezados se pueden detectar y bloquear en el equipo de red comercial; otros encabezados falsos de IPv4 pueden ser un poco más difíciles de identificar. La mayoría de las personas se refieren a la función para detectar direcciones IP de origen falsas como "Reenvío de ruta inversa de unidifusión", que se abrevia como uRPF ; uRPF se define en RFC 3704 y se considera una mejor práctica actual de Internet . El uRPF debe aplicarse en el primer enrutador del equipo de las instalaciones del cliente, o en el enrutador perimetral de una red corporativa.

Si no lo hacen, ¿por qué es tan difícil? ¿Agrega demasiada sobrecarga?

Mientras el enrutador no sea un enrutador basado en CPU, no hay una penalización de rendimiento. Muchos de los enrutadores / conmutadores utilizados por los ISP tienen esta característica integrada en un ASIC en hardware; normalmente no hay una gran penalización de rendimiento por encenderlo. A veces hay conflictos de características, pero nuevamente esto no es un gran problema en la mayoría de los casos.

Las políticas y la competencia del personal operativo / de ingeniería del ISP varían, y muchos ISP (particularmente en países más pequeños) están tan ocupados haciendo que las cosas "funcionen" que no tienen ciclos para hacer que las cosas "funcionen bien".

La prevención del cambio de la dirección IP de origen requiere listas de acceso (ACL) o filtrado de ruta inversa de unidifusión (uRPF).

Tampoco vienen gratis. El uRPF generalmente requiere una búsqueda adicional o una búsqueda única más compleja, por lo que incluso podría reducir a la mitad el rendimiento de su búsqueda en algunas plataformas. ACL ralentizará la búsqueda y usará la memoria.

uRPF no requiere mantenimiento, solo configúrelo una vez y olvídelo. ACL necesita un sistema que sepa qué direcciones hay detrás de la interfaz y se asegura de que la ACL se mantenga actualizada.

ACL es más ampliamente compatible que uRPF, uRPF es una característica relativamente rara en dispositivos de nivel de conmutador L3. En los enrutadores "reales", generalmente ambas funciones están disponibles.

Incluso si ambas funciones están disponibles, la configuración de uRPF en un lugar incorrecto de la red puede romper la red, no entender las limitaciones específicas de la plataforma ACL puede causar interrupciones.

Por lo general, usted mismo no se beneficia al evitar la suplantación de direcciones de origen, es principalmente Internet en general quien se beneficia. Usted corre un riesgo distinto de cero al intentar hacerlo, ya que puede terminar rompiendo cosas. Y sus clientes no obtendrán ningún beneficio, nadie le pagará más por implementarlos. Entonces la recompensa es baja haciéndolo.

El proveedor de servicios responsable lo hace, porque es lo correcto, pero no es realista esperar que tengamos antideofing en una porción relevante de los dispositivos de acceso implementados. El objetivo mucho más realista es, si hacemos ACL en conexiones de tránsito IP, ya que solo hay alrededor de 6000 o más números AS rechonchos.

La razón por la que esto es un problema es debido a los ataques de reflexión UDP, que pueden solucionarse mediante protocolos como QUIC y MinimaLT que aseguran que la reflexión no tenga ganancias, ya que la consulta entrante garantiza que sea mayor que la respuesta saliente, por lo que la suplantación de identidad pierde su beneficio.

De nuevo, recientemente se ha vuelto bastante popular usar la reflexión UDP como ataque DDoS. Hay muchos servidores DNS abiertos en los dispositivos CPE del consumidor que los consumidores no conocen, por lo que esos consumidores sufren porque su conexión doméstica está congestionada y se usa para reflejar el ataque. Y también es una manera fácil de obtener una amplificación significativa. Una pequeña consulta de decenas de bytes puede producir una gran respuesta de más de mil bytes. Se han producido ataques DDoS de reflexión que son varios cientos de gigabits por segundo, y cada día son más pequeños, solo el domingo por la noche transportamos un ataque de 43 Gbps a uno de nuestros clientes.

El filtrado de direcciones de origen no es trivial en el mundo real, porque el enrutamiento de Internet es asimétrico, por lo que, en principio, necesitamos una suposición informada sobre si es probable que aparezca un paquete de esta fuente en esta interfaz entrante.

No hay una fórmula fácil para eso, porque para cada regla que funciona en casi todos los casos, también hay un caso de uso que tiene sentido comercial que se rompería en ese momento.

El filtrado de ruta inversa funciona muy bien en los enrutadores de borde, donde hay una definición clara de "dentro" y "fuera": no permite que los extraños usen direcciones "dentro" y viceversa. Se vuelve más complicado tan pronto como empiezo a usar múltiples enrutadores de borde para la redundancia.

Para los enrutadores de red troncal, la única forma de implementar el filtrado de ruta inversa es permitir los paquetes entrantes cuando el par anuncia una ruta de trabajo (independientemente de si sería nuestra preferencia). Esa sería una búsqueda prohibitivamente larga, fácilmente eludida y rompe el caso de uso donde deliberadamente compro tránsito pero no anuncio mi prefijo en ese enlace.