Ataques DDoS amplificados: la más grande amenaza contra Internet

by Carlos Alvarez on April 11, 2014

Hace ya un año que The Spamhaus Project fue víctima del que, en su momento, fue considerado el más grande ataque distribuido de denegación de servicios. Los atacantes lograron enviar 300 gigabytes por segundo contra los servidores de nombres de dominio de Spamhaus, haciendo que éstos no pudieran responder las solicitudes de resolución del nombre www.spamhaus.org y haciendo que el sitio web pareciera estar caído a quien tratara de visitarlo al no conseguir la resolución del dominio.

Los atacantes explotaron una vulnerabilidad en el sistema de nombres de dominio (DNS). Ellos dirigieron el ataque contra los resolutores de DNS y contra los servidores de nombres de dominio autoritarios definidos por Spamhaus para la operación normal de su dominio. Mientras que la amenaza que esta clase de ataques representa es dada por el mal uso que los atacantes dan a los recursos de direccionamiento del DNS, su mitigación consiste en el mejoramiento de las prácticas de administración de direcciones en lo que se conoce como el ‘network edge‘ (ver 1.4, SAC 004 [PDF, 8 KB]).

Fundamentos de los ataques de DDoS a través del DNS

El DNS está compuesto por una cadena de queries enviados desde el navegador del usuario hasta un servidor que tiene la autoridad para responder. Simplificando el proceso, si usted quiere visitar ‘ejemplo.com’, su navegador enviará un query a un servidor de DNS preguntándole la dirección IP en la que ‘ejemplo.com’ está alojado. El servidor de DNS buscará la respuesta al query y la enviará de vuelta.

Los atacantes usaron tres técnicas – IP spoofing, reflexión y amplificación – para disparar este ataque masivo contra Spamhaus. Ellos coordinaron el envío de un número extraordinario de queries a alrededor de 30.000 servidores de DNS. En cada uno de estos queries la dirección IP estaba falsificada (spoofing) para aparentar que habían sido enviados por el servidor de DNS de Spamhaus. Esto hizo que los 30.000 servidores de DNS creyeran que sus respuestas debían ser enviadas a ese servidor de DNS de Spamhaus (reflexión). Y, para empeorar las cosas, los atacantes enviaron los queries de manera que las respuestas enviadas por los servidores de DNS a Spamhaus fueran paquetes muy grandes (amplificación).

¿Existe una solución?

En los 90, Paul Ferguson y Dan Senie previeron el enorme potencial de daño que representaba esta vulnerabilidad y publicaron en 1997, a través de la Internet Engineering Task Force o IETF, un borrador del documento que, luego de un largo proceso y varios años de discusiones y desarrollo, terminó convirtiéndose en el BCP 38 (¿Qué es un BCP?).

El BCP 38 describe la solución a esta vulnerabilidad (o una defensa, depende de a quién se pregunte): que todos los proveedores de servicios de Internet implementen una técnica denominada Source Address Validation. Si un ISP ha implementado el BCP 38, al recibir un paquete IP que diga venir de una dirección IP por fuera de los rangos de IPs que le hayan sido asignados, su servidor lo bloqueará y no lo dejará pasar.

Implementación del BCP 38

El BCP 38 reduce en gran medida las posibilidades de crear ataques de la misma escala del que fue dirigido contra Spamhaus. Lo paradójico es que, a pesar de que el primer borrador del documento fue publicado en 1997, la técnica aún no ha sido implementada por la gran mayoría de ISPs en el mundo.

Por el bajo nivel de implementación quise hacerle algunas preguntas a Paul Ferguson, uno de sus coautores, quien muy amablemente compartió su opinión para este artículo:

Carlos Álvarez (CA): Tu eres uno de los dos coautores del BCP 38. ¿Qué tan frustrante es ver que aún no ha sido ampliamente implementado, a pesar de que fue publicado hace tantos años?

Paul Ferguson (PF): Nosotros (Dan Senie y yo) publicamos el documento como un borrador de la IETF en 1997, luego se convirtió en el RFC2267 en 1998 (¿Qué es un RFC?), que fue a su vez derogado por el RFC2827 en el año 2000 y que en ese mismo año terminó convirtiéndose en el BCP 38.

¿Qué tan frustrante es para mí? Sólo un poco. Internet es algo *muy* grande y no es necesariamente razonable esperar que todos los que participan en él cumplan con su deber, especialmente en un tema de arquitectura que es voluntario.

Sin embargo, no hay una sola razón *legítima* para permitir tráfico en Internet que falsifique la dirección IP desde la que éste proviene. Punto final. Las redes que permiten esta clase de tráfico están permitiendo que haya actividad criminal en su propio terreno. Deberíamos invitar a todo el Internet a implementar SAVE o Source Address Validation Everywhere.

CA:¿Deberíamos, como algunos sugieren, buscar nuevas regulaciones y hacer de esto una obligación en todas partes? (El excelente artículo de Dave Piscitello sobre regulación y DDoS se puede encontrar acá).

PF: Preferiría mucho más que sea la comunidad misma de ISPs la que se vigile a sí misma e implemente voluntariamente estas medidas, a que sean los gobiernos y los congresos los que se involucren porque pueden terminar imponiendo leyes redactadas por personas no técnicas. Necesitamos hacer esto antes de que alguien intente forzarnos y terminemos con una regulación draconiana o técnicamente imposible.

Por otro lado, conseguir que los ISPs hagan esto voluntariamente no parece estar funcionando, así que tal vez una pequeña cantidad de legislación o regulación se puede necesitar. Estoy indeciso en este asunto.

Deberíamos también apoyar la idea de un modelo similar al del CDC (Center for Disease Control) para la infraestructura de Internet. Si todos no nos ponemos de acuerdo respecto de unas líneas básicas para apoyar la salud de Internet, alguien puede venir y simplemente incendiarlo como le plazca, que es lo que estos ataques de DDoS representan.

Recomendaciones relativas a la Source Address Validation

Hace pocos días Paul Vixie sostuvo una conversación con un reportero en la que expresó algunas recomendaciones relacionadas con la importancia de que el BCP 38 sea ampliamente implementado. Bien vale leerlas acá.

También es necesario hacer referencia al documento SAC065 [PDF, 423 KB], publicado por el Comité Asesor en Seguridad, Estabilidad y Resiliencia de la Internet Corporation for Assigned Names and Numbers (ICANN). El documento contiene una serie de recomendaciones que deberían ser seguidas por los ISPs y los operadores de infraestructura de Internet en todo el mundo.

Finalmente, pedí a Vixie que enviara unas líneas sobre este tema a los ISPs y operadores de infraestructura de Internet en América Latina. Estas son sus palabras:

“Un agradecimiento especial y un saludo a mis colegas que manejan la operación y la seguridad de Internet en América Latina… Ustedes tienen la oportunidad de construir un mejor sistema que el que nosotros tenemos.

“…El Viejo Internet fue construido sobre lo que yo llamo <<un modelo de negocio contaminante>> en el que desechos industriales peligrosos, resultado de nuestras ganancias económicas, son con frecuencia arrojados a la Red y se convierten en un problema para todos los demás.

“Los reto a hacerlo mejor que nosotros. De hecho, los reto a demostrarle al mundo cómo el Internet debió ser construido y cómo puede ser reconstruido.

“Source Address Validation es un poco más de trabajo para los operadores de redes, pero el beneficio para toda la economía y para la sociedad humana bien vale la pena ese poco más de trabajo”.

Conclusiones

Ojalá la industria de ISPs y los demás operadores de infraestructura de Internet implementen –voluntariamente– Source Address Validation cuanto antes. Si no lo hacen, la frecuencia y la magnitud de los ataques de denegación de servicios continuarán creciendo, incrementando la probabilidad de que se presenten apagones regionales de Internet y la probabilidad de que gobiernos nacionales dicten regulaciones que no sean deseables desde el punto de vista operacional o técnico.

Un agradecimiento especial a Vixie y a Fergie por sus amables contribuciones para este artículo.

Saludos desde California,

Carlos S. Alvarez
SSR Technical Engagement Sr. Manager
Security Stability Resiliency Team
ICANN

Nota: la versión en español de este artículo fue inicialmente publicada acá.

{ 0 comments… add one now }

Leave a Comment

You can use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

*
To prove you're a person (not a spam script), type the security word shown in the picture. Click on the picture to hear an audio file of the word.
Anti-spam image