Cerrar Menú Blogs
Las opiniones de los blogueros son de su estricta responsabilidad y no representan la opinión de este portal.
Profile image

Ingresa o regístrate acá para seguir este blog.

Seguir este blog
@isitreallysafe

@isitreallysafe

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

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.

Paul FergusonPor 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

Paul VixieHace 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, 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. Álvarez
blogladooscuro @ gmail.com
@isitreallysafe

Nota: este artículo fue inicialmente publicado por techtarget.com acá.

(Visited 265 times, 1 visits today)
PERFIL
Profile image

    Sigue a este bloguero en sus redes sociales:

  • twitter

Más posts de este Blog

  • Mundo

    LATAM CISO: Regional Cybersecurity Network

    [caption id="attachment_147" align="alignright" width="82"] @isitreallysafe[/caption] Under the auspices of Venable, LLP, a law and lobbying firm in Washington, D.C.,(...)

  • Mundo

    Rusia, ¿robando tráfico de Apple?

    [caption id="attachment_147" align="alignright" width="82"] @isitreallysafe[/caption] Según información publicada por BGPmon, Rostelecom, el más grande proveedor de conectividad ruso, estuvo(...)

  • Mundo

    LATAM CISO: Red de ciberseguridad a nivel regional

    [caption id="attachment_147" align="alignright" width="82"] @isitreallysafe[/caption] Bajo el auspicio de Venable, LLP, una firma de abogados y lobbying con sede(...)

  • Colombia

    Mi empresa fue hackeada: ¿reporto a la policía?

    [caption id="attachment_147" align="alignright" width="82"] @isitreallysafe[/caption] En el blog que publiqué hace unas semanas, titulado “De la cíberseguridad pasiva a(...)

Ver más

Lo más leído en Blogs

1

¿Casa-logía?    Uno es lo que es. A los 15 años(...)

2

Hambre

El hambre es más atroz que la muerte misma y ahora(...)

3

“Las personas más felices son las que están ocupadas, porque sus(...)

0 Comentarios
Ingresa aquí para que puedas comentar este post
Reglamento de comentarios

ETCE no se responsabiliza por el uso y tratamiento que los usuarios le den a la información publicada en este espacio de recomendaciones, pero aclara que busca ser la sombrilla de un espacio donde el equilibrio y la tolerancia sean el eje. En ese camino, disponemos de total libertad para eliminar los contenidos que:

  1. Promuevan mensajes tipo spam.
  2. El odio ante una persona o comunidad por su condición social, racial, sexual, religiosa o de situación de discapacidad.
  3. Muestren o impulsen comportamientos o lenguajes sexualmente explícitos, violentos o dañinos.
  4. Vulneren o atenten contra los derechos de los menores de edad.

Además, tenga en cuenta que:

  • - El usuario registrado solo podrá hacer un voto y veto por comentario.
Aceptar
¿Encontraste un error?

Para EL TIEMPO las observaciones sobre su contenido son importantes. Permítenos conocerlas para, si es el caso, tomar los correctivos necesarios, o darle trámite ante las instancias pertinentes dentro de EL TIEMPO Casa Editorial.


Debes escribir el comentario
¡Gracias! Tu comentario ha sido guardado
Tu calificación ha sido registrada
Tu participación ya fue registrada
Haz tu reporte
Cerrar
Debes escribir tu reporte
Tu reporte ha sido enviado con éxito
Debes ser usuario registrado para poder reportar este comentario. Cerrar