Por Carolyn Duffy Marsan
APENAS UNAS SEMANAS DESPUÉS DE UN ATAQUE A LA INFRAESTRUCTURA DE Internet, el Consejo de Arquitectura de Internet (IAB) presentó una charla técnica muy oportuna y atractiva para los participantes del IETF 97 con el objetivo de compartir las vulnerabilidades asociadas con este ciberataque masivo, así como potenciales soluciones en que podrían trabajar los organismos de estandarización.
El IAB estaba preparando otra charla técnica para el IETF 97, pero descartó estos planes luego de que un ataque dis- tribuido de denegación de servicios (DDoS) a gran escala causara daños a Dyn, el proveedor de infraestructura de DNS, el 21 de octubre de 2016. Dos aspectos del ataque a Dyn fueron poco comunes: primero, el ataque vino de una botnet que comprendía dispositivos para la Internet de las Cosas (IoT); segundo, fue el ataque de este tipo más grande de la historia.
El ataque DDoS a Dyn se realizó en tres olas durante un período de seis horas. Aunque Dyn a rma nunca haber sufrido un corte masivo de su red, la infraestructura de DNS que maneja la empresa estuvo tan lenta que muchos de sus clientes — incluidas los grandes de Internet como Twitter, CNN y Net ix— quedaron inalcan- zables.
Además de provocar una interrupción masiva de Internet para los clientes, lo que generó interés periodístico en el ataque DDoS a Dyn fue que afectó a miles de di- recciones IP discretas de la botnet Mirai, que comprende dispositivos de la IoT. Esto hace prever un futuro en el que generan ataques los dispositivos de la IoT que generalmente no tienen seguridad ni se mantienen actualizados.
“Estamos aquí para hablar sobre una nueva clase de ataques a la arquitectura de Internet o tal vez para ofrecer algunas perspectivas que esperamos sean nuevas”, dijo Suzanne Woolf, miembro del IAB, quien introdujo el plenario técnico. Comentó que el ataque DDoS a Dyn “provocó una explosión de interés por el DNS, la Internet de las Cosas, el compromiso masivo de los dispositivos conectados a Internet y los modelos operativos y de negocio que subyacen el suministro de contenido a escala de Internet”.
El primer disertante fue Nick Sullivan, jefe de cifrado en Cloud are y participante activo en el trabajo del IETF relacionado con el protocolo de seguridad en la capa de transporte (TLS). Agregó que el ataque DDoS a Dyn se destacó principalmente por su magnitud.
“Esto no es algo particularmente nuevo. Las botnets existen y han existido por mucho tiempo”, dijo Nick. “Pero este es un ejemplo de botnet a mayor escala y envía una mezcla de ataques”.
Nick comentó que la mayoría de los ataques DDoS en Internet que ocurrieron en el 2016 fueron ataques conocidos — inundaciones de consultas al DNS, inun- daciones de paquetes Syn e inundaciones HTTPS— pero que ahora estos ataques se producirán a mayor escala.
Los ataques al DNS son de dos tipos: ataques directos al servidor DNS auto- ritativo desde una botnet o ataques de botnets que atraviesan recursores válidos antes de trasladarse al servidor DNS autoritativo.
Para los ataques directos, Nick recomendó que los operadores de DNS sospechen de cada solicitud de un resolvedor des- conocido y asuman que una cantidad de solicitudes de los no resolvedores a un servidor autoritativo es un ataque. “Sim- plemente eliminen los paquetes”, aconsejó.
Nick mencionó que estas inundaciones son generalmente solicitudes de un dominio cúspide o de subdominios aleatorios. Añadió que a veces estas inundaciones vienen con direcciones de origen falsi- cadas, que son más difíciles de manejar.
“Las botnets Mirai a veces no son direc- ciones falsi cadas, lo que hace que sea un poco más fácil lidiar con ellas”.
Al experimentar una inundación de con- sultas al DNS, no se debería anunciar las direcciones IP que están siendo atacadas como “rutas nulas”, dado que esto pro- vocaría su caída de Internet. “Esto es algo bastante peligroso y tiene muchas reper- cusiones”, comentó. “Últimamente, los ataques se están dirigiendo a subredes enteras, lo que hace que este sea un mecanismo de defensa completamente irracional”.
En su lugar, Nick sugirió dividir la carga del ataque geográ camente utilizando Anycast y entre diferentes centros de datos usando el protocolo de enrutamiento de caminos múltiples de igual costo (ECMP). También recomendó ltrar los paquetes tan pronto como sea posible. ”La principal forma de manejar una gran inundación es ase- gurarse que a su aplicación solo lleguen aplicaciones legítimas”, aclaró.
Nick recomendó ltrar el trá co usando iptables con reglas de ltrado con sintaxis BPF (Berkeley Packet Filter), que son técnicas poderosas para detectar y bloquear paquetes dentro del kernel y que pueden automatizarse. Admitió que las reglas BPF de las iptables deben ser dinámicas y utilizar aprendizaje auto- mático y heurística para mantenerse al día con los per les de ataque en constante cambio. “Los ataques de una botnet no serán iguales a los de otra, por esta razón esto debe ser muy dinámico”, dijo. “Si tiene reglas estáticas, probablemente caerá. En la medida de lo posible, saque las reglas de su servidor y muévalas a la tarjeta de interfaz de red. Esto puede ayudar a reducir la carga”.
Nick dijo que las inundaciones al DNS que atraviesan servidores recursivos son diferentes tipos de ataques y que los operadores de red deberían responder a los mismos antes que intentar bloquear y eliminar el trá co. Esto se debe a que el DNS recursivo realiza solicitudes para clientes legítimos, no solo para los atacantes. “Si puede hacer una lista blanca de servidores DNS recursivos conocidos, hágala”, recomendó. “Esto resulta muy útil y además es lo que se debe hacer”.
Recomendó no aplicar limitación de la tasa de transmisión (rate limiting) a este trá co dado que esto podría ocasionar conse- cuencias negativas, entre ellas la ampli- cación del ataque. “Limitar la tasa de transmisión no es un método efectivo para esto. En realidad, hay que gestionar los paquetes”, agregó.
Una sugerencia es aprovechar el NSEC, que es una característica de las Exten- siones de Seguridad para el Sistema de Nombres de Dominio (DNSSEC) que se utiliza para probar que un nombre no existe. “Almacenar esto en caché para rangos sin rmar podría potencialmente ser de ayuda”, sugirió Nick. “Es una de muchas opciones posibles para evitar que el trá co llegue hasta el servidor autoritativo”.
Con respecto a la lucha contra los ataques de inundación Syn, observó que el uso de BGP Anycast para TCP y el estableci- miento de reglas iptables BPF dinámicas pueden resultar e caces.
Para las inundaciones HTTPS se pueden utilizar las características de limitación de tasa de transmisión del protocolo, que in- cluyen limitaciones por solicitud o volumen. Agregó que “un simple restablecimiento del TCP también ayudará mucho”.
Nick dijo que los ataques DDoS son en- viados por botnets que consisten en puntos extremos comprometidos, que cada vez más son dispositivos de la IoT. “Estamos viviendo el inicio de este nuevo conjunto de dispositivos que ejecutan software, pero en muchos de estos dispositivos el software se está poniendo viejo”, dijo, advirtiendo que es probable que los ataques de botnet basados en la IoT empeoren.
Explicó que los dispositivos de la IoT son dispositivos de bajo costo y escaso margen y que los fabricantes no tienen ningún incentivo par integrar seguridad o incluso un método para luego actualizar los dispo- sitivos en respuesta al descubrimiento de nuevas vulnerabilidades.
“Ningún aspecto de estos ataques debe ser nuevo para ustedes”, dijo Nick a los pre- sentes. “Estamos lidiando con los mismos problemas, solo que ahora a una escala mucho mayor. Esto está exponiendo ciertos aspectos de la Internet de las Cosas que ya conocíamos”.
La mejor recomendación que ofreció Nick fue que los operadores de redes detengan el trá co malo tan cerca del punto de entrada como sea posible y que utilicen Anycast. “Distribuir la carga y ltrado temprano”, aconsejó.
También destacó que para poder per- manecer en línea durante un ataque DDoS se requiere escala.
“Hay que ser grande, hay que ser inte- ligente y hay que tener las herramientas y trabajar junto con otras personas para detener los ataques tan cerca del borde como sea posible”, concluyó.
El segundo orador del plenario técnico fue Andrew Sullivan, Chair del IAB y Fellow de Dyn. Andrew comentó que el ataque contra la infraestructura de Dyn fue a gran escala y que incluso el sistema de DNS basado en Anycast y bien construido de la empresa no pudo soportarlo sin fallos de latencia y resolución.
“Hemos visto muchos ataques de ampli- cación estándares”, dijo Andrew. “Este ataque tuvo una gran proporción de TCP, algo que normalmente no vemos. Fue un spoo ng comparativamente bajo. Con- rmamos que 40.000 direcciones parti- ciparon en la botnet, aunque podrían ser hasta 100.000”.
Andrew aclaró que no cree que el ataque DDoS a Dyn haya ocurrido por única vez.
“Hubo un ataque muy grande apenas un par de semanas antes”, advirtió. “Sabemos que el software de la botnet Mirai existe y que lo están mejorando día a día”.
Andrew observó que este tipo de ataques son irónicos porque utilizan las fortalezas de Internet —su naturaleza distribuida, su facilidad para conectar puntos ex- tremos y la ausencia de inteligencia en la propia red— para atacar la arquitectura de Internet. Aseguró que se supone que los puntos extremos son más inteligentes que la propia red, pero que esta losofía de diseño no es válida para los sistemas de la IoT.
“Es obvio que la Internet de las Cosas con- tinuará creando este tipo de problemas”, opinó Andrew. “La IoT crea una conec- tividad ubicua y muchos sistemas extre- madamente ligeros… Si hay miles de estos dispositivos por todas partes, habrá mu- chísimos dispositivos comprometidos”.
Andrew teme que ataques como los re- cientes ataques DDoS a Dyn puedan llevar a los gobiernos a implementar regulaciones que apunten a evitar que los dispositivos comprometidos se conecten a Internet, lo que traería como consecuencia una reducción de la apertura de Internet.
“Nosotros somos quienes debemos abordar este problema porque entendemos la tecnología, entendemos los incentivos y entendemos la naturaleza de la arqui- tectura subyacente”, concluyó Andrew. “No tengo una solución mágica pero espero que podamos mantener una discusión interesante y útil”.
Esta charla técnica continuó con un animado espacio para preguntas y res- puestas en que se plantearon sugerencias tales como la creación de protocolos de seguridad ligeros para los dispositivos de la IoT y ofrecer recomendaciones a los fabricantes de puntos extremos para que puedan integrar seguridad a un precio más bajo. El objetivo de estas sugerencias era que el IETF encontrara formas de hacer que la construcción de dispositivos para la IoT con seguridad integrada fura más simple y menos costoso.
En la conclusión del panel, Suzanne aseguró que el IAB continuaría la discusión en línea.
En otro orden de cosas, en su sesión plenaria la Internet Society presentó el Jonathan B. Postel Service Award a Kanchana Kan- chanasut por su trabajo pionero para esta- blecer servicios de Internet en Tailandia, su país natal, y en todo el Sudeste Asiático. Kanchanasut recibió un trofeo de cristal y US$20.000. Se trata de la décimo novena ganadora del premio, que se otorga desde 1999