¿Son las direcciones IP "triviales para falsificar"?

65

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

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?
Jeff Atwood
fuente
Las IP falsas no deberían ser un problema para las prohibiciones basadas en IP, ya que el objetivo final es obtener acceso, que necesita respuestas legítimas. Pero algunos de los mayores riesgos son: IP compartidos por muchas personas (escuelas, lugares de trabajo, cibercafés, ...) e IP que pueden cambiar a algo como después de un restablecimiento de módem en DSL no estáticos.
Halil Özgür
Obtener acceso no es el objetivo principal de muchos ataques que usan direcciones falsificadas. Sospecho que los diversos ataques de amplificación que usan DNS son más frecuentes. El DNS es encantador (con DNSSEC peor): puede enviar un paquete pequeño de <100 bytes con una dirección de origen falsificada que hará que la dirección falsificada reciba una amplificación de 7x a 40x como respuesta.
Michael Graff

Respuestas:

50

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 ...

Murali Suriar
fuente
Suena desagradable Entonces, ¿hay algo que un administrador pueda hacer si encuentra que su servidor está dirigido de esta manera? ¿Sería posible bloquear temporalmente los paquetes ICMP y los mensajes de restablecimiento TCP de todas las IP? ¿Serías capaz de operar de una forma semi-normal como esta?
UpTheCreek
45

¿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.

Zoredache
fuente
16
http (s) es la clave aquí. DNS utiliza UDP, por lo que toda la comunicación se realiza a través de paquetes individuales sin acuses de recibo en el protocolo.
noah
16
Supongo que es como el correo electrónico. Puede enviar con la dirección que desee, a menos que desee recibir respuestas
Jorge Bernal
@Jorge: Definitivamente. La analogía del correo electrónico / correo postal es excelente para explicar esto a los usuarios finales.
Evan Anderson, el
En DNS, TCP también puede usarse, pero eso actualmente asusta a las personas. Sin embargo, no hay ACK incorporado porque la respuesta es ACK.
Michael Graff el
66
@noah: en realidad, TCP es la clave, no HTTP. TCP no es imposible de falsificar, pero es 100 veces más difícil que UDP.
Alnitak
22

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.

Kyle Brandt
fuente
1
Pero los ISP generalmente no se molestan con la inspección de paquetes, ¿verdad?
Pacerier
13

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.

FryGuy
fuente
¿Quiere decir que es difícil forjar una conexión HTTP con una dirección falsificada, o que ni siquiera es posible hacerlo?
Pacerier
En internet abierto, es imposible. Hay algunos trucos si está en la misma LAN que puede engañar a la otra computadora para que le envíe tráfico ( web.eecs.umich.edu/~zhiyunq/pub/… ). Puedes pensarlo de esta manera. UDP es como enviar una postal. Puede escribir cualquier nombre en la dirección de devolución que desee. TCP es como una conversación en la que si no ingresa la dirección correcta, no podrá continuar la conversación. Algunas de las otras respuestas aquí lo explican mucho mejor.
FryGuy
10

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.

JD Long
fuente
1
Puedes ser falsificado. Solo mira secuestrar sesiones TCP. google.com/search?q=hijack+tcp+session
Dan
A menos que el atacante tenga acceso al flujo de tráfico, los ataques de secuencia TCP con sistemas operativos modernos son poco prácticos. Si de todos modos son un hombre en el medio, entonces probablemente ni siquiera necesiten hacer el secuestro de la conexión TCP de todos modos.
Evan Anderson
10

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.

Michael Graff
fuente
6

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.

Mes.
fuente
6

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.

noah
fuente
5

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.

Martin Beckett
fuente
¿Hay alguna forma de evitar el filtro ISP?
Pacerier
5

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!

Joshua
fuente
3

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.

Justin
fuente
1
Los enrutadores solo enrutan paquetes. No mantienen el estado TCP, por lo que un paquete es un paquete para ellos.
Michael Graff el
buen punto. Por lo tanto, vinculará los servidores (o cualquier dispositivo de front-end que esté haciendo una negociación SYN / ACK) esperando su ACK :-) Tenemos nuestros equilibradores de carga configurados para negociar completamente SYN / ACK antes de entregarlo a los servidores en una conexión ya abierta, por lo que ayuda a bigtime en ese caso.
Justin
2

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.


fuente
Esto no es un problema. Un verdadero "problema" aquí es el diseño del protocolo IP, que no tiene ninguna disposición para verificar si la dirección IP con la que está creando su paquete IP le pertenece o no. Por lo tanto, puede crear una tormenta de paquetes con diferentes direcciones de origen (destino) y nada le impedirá enviarlos.
monomyth
3
Algo podría detenerte. Su ISP podría configurar filtros de salida en sus enrutadores para no permitir que se reenvíen paquetes a menos que la dirección IP de origen pertenezca a esa red.
Zoredache 03 de
2

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

TonyB
fuente
2

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.

Alnitak
fuente
1

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.

Kyle Hodgson
fuente