¿Son las direcciones IP "triviales para falsificar"?

Estaba leyendo algunas de las notas sobre el nuevo servicio de DNS público de Google :

• Beneficios de rendimiento
• Beneficios de seguridad

Noté en la sección de seguridad este párrafo:

Hasta que una solución estándar de todo el sistema para las vulnerabilidades de DNS se implemente universalmente, como el protocolo DNSSEC2, los solucionadores de DNS abiertos deben tomar independientemente algunas medidas para mitigar las amenazas conocidas. Se han propuesto muchas técnicas; vea IETF RFC 4542: medidas para hacer que el DNS sea más resistente frente a las respuestas falsificadas para obtener una descripción general de la mayoría de ellas. En Google Public DNS, hemos implementado y recomendamos los siguientes enfoques:

• Sobreaprovisionamiento de recursos de la máquina para proteger contra ataques DoS directos en los mismos resolvers. Dado que las direcciones IP son triviales para los atacantes, es imposible bloquear consultas basadas en la dirección IP o subred; La única forma efectiva de manejar tales ataques es simplemente absorber la carga.

Esa es una realización deprimente; incluso en Stack Overflow / Server Fault / Super User, con frecuencia usamos direcciones IP como base para prohibiciones y bloques de todo tipo.

¡Pensar que un atacante "talentoso" podría usar trivialmente cualquier dirección IP que desee y sintetizar tantas direcciones IP falsas únicas como quiera, es realmente aterrador!

Entonces mi pregunta (s):

• ¿Es realmente tan fácil para un atacante falsificar una dirección IP en la naturaleza?
• Si es así, ¿qué mitigaciones son posibles?

Como han dicho muchos otros, los encabezados IP son triviales para falsificar, siempre y cuando a uno no le importe recibir una respuesta. Es por eso que se ve principalmente con UDP, ya que TCP requiere un protocolo de enlace de 3 vías. Una excepción notable es la inundación SYN , que usa TCP e intenta atar recursos en un host receptor; nuevamente, a medida que se descartan las respuestas, la dirección de origen no importa.

Un efecto secundario particularmente desagradable de la capacidad de los atacantes de falsificar direcciones de origen es un ataque de retrodispersión . Hay una excelente descripción aquí , pero brevemente, es la inversa de un ataque DDoS tradicionales:

1. Obtenga el control de una botnet.
2. Configure todos sus nodos para usar la misma dirección IP de origen para paquetes maliciosos. Esta dirección IP será su eventual víctima.
3. Envíe paquetes desde todos sus nodos controlados a varias direcciones en Internet, apuntando a puertos que generalmente no están abiertos o conectándose a puertos válidos (TCP / 80) que afirman ser parte de una transacción ya existente.

En cualquiera de los casos mencionados en (3), muchos hosts responderán con un ICMP inalcanzable o un restablecimiento de TCP, dirigido a la dirección de origen del paquete malicioso . El atacante ahora tiene potencialmente miles de máquinas sin compromisos en la red que realizan un ataque DDoS a su víctima elegida, todo mediante el uso de una dirección IP de origen falsificada.

En términos de mitigación, este riesgo es realmente uno que solo los ISP (y particularmente los ISP que brindan acceso al cliente, en lugar de tránsito) pueden abordar. Hay dos métodos principales para hacer esto:

1. Filtrado de entrada : garantiza que los paquetes que ingresan a su red provienen de rangos de direcciones que viven en el extremo de la interfaz entrante. Muchos proveedores de enrutadores implementan características como el reenvío de ruta inversa de unidifusión , que utiliza las tablas de enrutamiento y reenvío del enrutador para verificar que el siguiente salto de la dirección de origen de un paquete entrante sea la interfaz entrante. Esto se realiza mejor en el primer salto de capa 3 en la red (es decir, su puerta de enlace predeterminada).

2. Filtrado de egresos : garantiza que los paquetes que salen de su red solo se originen en rangos de direcciones de su propiedad. Este es el complemento natural para el filtrado de ingreso, y es esencialmente parte de ser un "buen vecino"; asegurando que incluso si su red se ve comprometida por el tráfico malicioso, ese tráfico no se reenvía a las redes con las que se conecta.

Ambas técnicas son más efectivas y fáciles de implementar cuando se realizan en redes de 'borde' o 'acceso', donde los clientes interactúan con el proveedor. La implementación del filtrado de entrada / salida por encima de la capa de acceso se vuelve más difícil, debido a las complejidades de múltiples rutas y enrutamiento asimétrico.

He visto estas técnicas (particularmente el filtrado de ingreso) utilizadas con gran efecto dentro de una red empresarial. Quizás alguien con más experiencia en proveedores de servicios pueda dar más información sobre los desafíos de implementar filtros de entrada / salida en Internet en general. Me imagino que el soporte de hardware / firmware es un gran desafío, además de no poder obligar a los proveedores de otros países a implementar políticas similares ...

¿Es realmente tan fácil para un atacante falsificar una dirección IP en la naturaleza?

Claro, si no me importa recibir realmente ninguna respuesta, puedo enviar fácilmente paquetes usando cualquier dirección de origen que me guste. Dado que muchos ISP realmente no tienen buenas reglas de salida, generalmente se entregará todo lo que falsifique.

Si el atacante realmente necesita comunicación bidireccional, se vuelve muy difícil. Si necesitan comunicación bidireccional, es más fácil usar un proxy de algún tipo. Lo cual es muy fácil de configurar si sabes lo que estás haciendo.

Prohibir a las personas por dirección IP es moderadamente efectivo en SF / SO / SU ya que el sitio usa http / https que requiere comunicación bidireccional.

Pequeña prueba de concepto para la respuesta de Zordeche (con ubuntu):

$ sudo apt-get install hping3
$ sudo hping3 -1 --spoof 11.10.10.20 www.google.com
HPING www.google.com (eth0 64.233.169.105): icmp mode set, 28 headers + 0 data bytes

Luego en otra consola:

$ sudo tcpdump -i eth0 'icmp'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
13:30:19.439737 IP 11.10.10.20 > yo-in-f105.1e100.net: ICMP echo request, id 31297, seq 0, length 8

Entonces sí, trivial, pero luego no obtienes las respuestas como se mencionó anteriormente a menos que tengas acceso a 11.10.10.20 o tengas un sniffer en algún lugar entre www.google.com y 11.10.10.20 (Y tendría que estar justo en frente de cualquier extremo, ya que no puede predecir la ruta de los paquetes). Además, es posible que la puerta de enlace del spoofer (ISP) no permita que ese paquete salga por la puerta si tienen algún tipo de inspección ip y ven que la fuente huele mal.

Las direcciones IP son fáciles de falsificar para el tráfico UDP unidireccional . Para los paquetes TCP, solo puede falsificar para obtener conexiones TCP medio abiertas con paquetes SYN. Esta es la base de un tipo de ataque DOS también. Pero no puede falsificar una conexión HTTP con una dirección falsificada (por ejemplo, si está filtrando sesiones para usar la misma dirección IP). Si bien sí, puede falsificar una dirección IP en los paquetes, solo es útil para ciertos tipos de ataques de denegación de servicio.

El artículo de GOOG estaba discutiendo explícitamente sobre DNS. DNS utiliza paquetes UDP y TCP. Los UDP pueden ser falsificados, pero no el TCP. TCP requiere un protocolo de enlace de 3 vías . Si se falsifica la dirección IP de un paquete TCP, la computadora falsificadora no recibirá la respuesta y la conexión fallará. UDP, como se menciona en otras respuestas, es 'dispara y olvida' y no requiere comunicación de respuesta. Los ataques DoS vienen casi exclusivamente en forma de paquetes UDP por este motivo.

En el contexto de Stack Overflow y los sitios familiares, el problema planteado por Takaun Daikon es muy válido. Hay muchas formas de obtener una nueva dirección IP del ISP de uno. Cambiar una dirección MAC es claramente la más fácil y funciona para muchos ISP. Además, muchas personas que están dispuestas a tonterías pueden estar usando un proxy público o TOR. Claramente, bloquear la IP de origen para esos paquetes simplemente bloquearía el proxy o el nodo de terminación TOR.

Entonces, ¿es válido el bloqueo de direcciones IP? Demonios, sí lo es. Pero terminarás con errores. Bloqueará algunas IP que realmente no son la fuente del problema (es decir, proxies) y también hará que las personas eviten sus bloqueos cambiando las IP. La persona que tiene la mala suerte de obtener la IP prohibida más tarde no podrá acceder a la familia de sitios SO. Pero la tasa de error debe ser pequeña. A menos que esté bloqueando grandes conjuntos de IP. Pero si está bloqueando uno o dos al día, debería estar bien.

Es posible que desee introducir un esquema un poco más sofisticado donde bloquea, pero solo por un período, como un año. Si su red es capaz de limitar el ancho de banda o limitar la conexión, también puede considerar un esquema en el que los imbéciles que ejecutan los puntos de referencia de Apache en su sitio simplemente se pongan en una jaula con un ancho de banda muy limitado.

La suplantación de IP continuará porque los ISP son flojos.

Mi ISP sabe muy bien que estoy en una dirección específica, o al menos en la subred en la que estoy. Sin embargo, puedo usar cualquier dirección de origen. ¿Porqué es eso? Simplemente, costo.

Si falsifico algunas direcciones aquí y allá, no le cuesta nada a mi ISP. Si cada usuario de mi ISP falsificara un paquete entre la 1:00 y las 2:00, todavía sería apenas un error en el radar. Sin embargo, cuando una botnet envía muchos paquetes falsificados de muchos hosts en muchos ISP, la máquina o red objetivo se cae.

La realidad financiera es que, a menos que seas el atacado, la suplantación de identidad no cuesta nada. Implementar filtros cerca del cliente cuesta dinero, y el que gasta el dinero obtiene muy pocos beneficios, aparte de saber que son buenos ciudadanos de la red.

UDP e ICMP son más fáciles de falsificar, pero TCP también es posible. Requiere un sistema operativo remoto inseguro, que utiliza números de secuencia predecibles para explotar. A veces son las máquinas de equilibrio de carga las que alteran los números de secuencia y las hacen predecibles. Entonces, TCP es posible, pero más difícil.

La suplantación de identidad de DNS se centra principalmente en el lado de la seguridad para evitar que alguien envíe una respuesta falsa a un solucionador recursivo. Los aspectos de inundación de UDP no son específicos de DNS, aparte de una sola consulta pequeña (por ejemplo, '.') Causará una respuesta bastante grande. Por lo tanto, hace un buen vector de amplificación. Existen muchos otros protocolos UDP que funcionan, pero DNS está en uso en todas partes, y es fácil encontrar máquinas para amplificar los ataques.

DNSSEC lo empeora aún más, con paquetes UDP que pueden alcanzar un tamaño de 4k.

Las direcciones IP son triviales para falsificar en lo que respecta a los ataques DOS basados ​​en DNS (D), ya que generalmente son un caso de paquetes UDP disparar y olvidar. Para el tráfico HTTP, ese no es el caso, por lo que necesitaría estar en la misma red local que el servidor web (completamente posible, por supuesto, dependiendo de dónde esté alojado su sitio), o controlar los enrutadores intermedios.

Puede enviar una carta a cualquier persona, y si no pone una dirección de devolución en el sobre (o la incorrecta), pueden contratar a todos los filtradores de correo basura del mundo y no filtrar su mensaje sin abrirlo (procesamiento ) eso.

Sin embargo, si el remitente desea una respuesta, es mejor que la dirección de retorno sea correcta, o tendría que haber un mecanismo de capa de aplicación para obtener la dirección correcta. Así que puedo hacerte pensar que estás abriendo una carta de Nana, pero incluso si te engaño con el contenido de la carta, no le enviarás un cheque a EFECTIVO a alguna dirección en Nigeria (a menos que Nana sea nigeriana ) Por lo tanto, el desafío / respuesta es una defensa efectiva siempre que no seas un Hombre en el Medio.

Puedo configurar cualquier dirección IP de origen que quiera en un datagrama.
Si mi ISP permitiría que dicho paquete salga a la naturaleza es otra cuestión.

Si bien esta es una realidad que debe abordarse, el problema subyacente es realmente no técnico: personas con intenciones maliciosas que intentan hacer cosas maliciosas. Por lo tanto, la solución real debe ser no técnica también.

Creo que lo que ha hecho Stackoverflow es EXACTAMENTE la solución correcta para manejar la segunda línea de defensa: las técnicas para restringir a los posibles usuarios de spam a través de las diferentes formas de limitar sus habilidades para interactuar con la plataforma antes de alcanzar cierto nivel de 'credibilidad'.

Estas técnicas no solo ayudan a mejorar la calidad general del sitio, sino que también incentivan a los usuarios a involucrarse más y proporcionar respuestas más creíbles / confiables.

Desde el punto de vista técnico, lo mejor sería hacer lo que Google sugiere: simplemente ser eficiente en la absorción / manejo de la carga adicional.

¡Buen trabajo y sigue mejorando!

UDP es la parte principal de por qué esto es fácil: de hecho, Skype y Slingbox aprovechan la capacidad de falsificar direcciones IP fácilmente en UDP para ' perforar ' a través de NAT y permitir una fácil conexión entre pares.

TCP es más difícil ya que requiere un ciclo SYN / ACK completo, pero aún puede inundar el servidor con paquetes SYN colgantes que van a direcciones IP a muchos saltos y esencialmente atan una gran cantidad de enrutadores en el proceso.

Como se mencionó anteriormente, el uso de servidores proxy es trivial, y hay una gran cantidad de servidores proxy anónimos abiertos disponibles.

Incluso sin usar un proxy, puedo configurar la dirección MAC en mi firewall a cualquier nuevo valor arbitrario, restablecer mi cable módem y mi ISP me asignará una nueva dirección IP brillante.

Y eso es solo para empezar. Hay muchas otras formas de evitar las prohibiciones de IP.

Si es así, ¿qué mitigaciones son posibles?

No hay mucho que puedas hacer en el lado receptor.

El ISP del falsificador debería estar filtrando su tráfico saliente para que sus clientes no puedan falsificar IP de diferentes redes.

Solo hay unas pocas líneas en la configuración del enrutador, por lo que no hay una buena excusa para no hacerlo.

Hay una manera de rastrear al atacante, pero requiere la cooperación de sus proveedores ascendentes: http://www.cymru.com/Documents/dos-and-vip.html

Como otros han señalado, UDP es bastante trivial de falsificar, TCP no tanto.

La defensa preferida, pero desafortunadamente no universalmente implementada, son los filtros de salida.

Para los ISP que ejecutan servicios DSL, etc., cada línea virtual debe configurarse con ip verify unicast reverse-path(o lo que sea que no sea el equivalente de Cisco) que bloquea cualquier paquete cuya dirección IP de origen no se encuentre en los rangos que se sabe que se enrutan por esa línea.

Recuerdo que hice programación de sockets a finales de los 90 con lo que probablemente era Visual Basic, y pudimos establecer la IP de origen en nuestra conexión. Recuerdo vagamente que cuando lo probamos, netstat -an mostró la IP de origen real, pero los registros de Apache mostraron la IP falsificada; y creo que Apache estaba entregando la IP falsificada a los módulos perl y así también.