Rutas envenenadas (Route Poisoning) a YouTube

Esto va a dar mucho que hablar en la comunidad de ruteo. No es algo nuevo, nada que no supiéramos, o nada que no hubiera pasado antes. Las tablas de BGP (Border Gateway Protocol) son uno de los puntos más vulnerables de la infraestructura de Internet junto con los servidores de nombres (DNS). Mientras para los servidores de nombres ya se han puesto algunas medidas de seguridad para evitar los ataques de negación de servicio, para las tablas de BGP aún no hay nada definido. Los grupos de seguridad de enrutamiento del IETF han definido varios RFCs donde se enlistan precisamente los problemas que pueden existir por la falta de seguridad en los protocolos de ruteo y los requerimientos que un protocolo de ruteo seguro debe tener. Lo nuevo en este caso es el perfil del atacado (YouTube de Google) y la razón por lo que pasó (censura)

El problema de la inseguridad de BGP es real y ahora tenemos un caso que va a resonar en los medios (seguramente). Hace unos días Pakistan anunció que bloquearía el acceso a Youtube por considerarlo un sitio con contenido inapropiado (dejaremos por un momento nuestra ideología en contra de la censura por un lado). Un ISP pakistaní (PCCW que realmente está en Hong Kong y según ellos son los más grandes de la región) tuvo la grandiosa idea de bloquear los sitios por Youtube usando infraestructura de ruteo, lo cual es un práctica común cuando apuntamos rutas estáticas a null y anunciamos INTERNAMENTE la ruta de “hoyo negro” a NUESTROS enrutadores. El problema es cuando esto se hace mal y anunciamos EXTERNAMENTE la ruta y esta tiene mejor métrica que la ruta del propietario (en esta caso Google).

El resultado es que PCCW terminó haciendo haraquiri a sus enlaces al recibir todo (o una buena parte de) el tráfico de Youtube. Esto fue un doble ataque de negación de servicio (uno a Youtube por el error de los ingenieros de ruteo de PCCW) y otra al mismo PCCW al saturar sus enlaces con el tráfico de YouTube. Afortunadamente los cuerpos de rescate filtraron las rutas y después de varias horas (aproximadamente 4) YouTube comenzó a volver a la normalidad.
A pesar del final feliz (bueno, esto aun no acaba. No sé si vaya a haber algunas demandas de Google a PCCW por daños), esto nos deja una buena lección de que la infraestructura de ruteo es muy frágil. Aunque BGP es un protocolo muy estable no fue diseñado con la seguridad en mente (sino con estabilidad) y es fácilmente engañado con anuncios falsos. Ahora que hay un precedente, uno de los blancos favoritos de los hackers va a ser posiblemente los enrutadores de ISPs donde la seguridad es baja. En estos casos un enrutador secuestrado podría empezar a inyectar las rutas de la víctima con mejores métricas ocasionando una doble negación de servicio (a la víctima y al ISP al saturar los enlaces –ésto depende del perfil de la víctima-).

Más información: BBC y Znet

Update: Encontré algo más de información en la lista de correo de NANOG donde incluso pueden ver los bloques de IP que fueron erróneamente anunciados.

Reinforcement Learning en Sistemas Multiagentes: Caso aplicado a Detección de Intrusos

Esta presentación es parte de los seminarios del Grupo de Inteligencia Artificial de Ciencias Computacionales de la Universidad de York.

Abstract:
En este seminario presentaré una arquitectura distribuida de agentes sensores y agentes de decisión que aprenden como identificar estados normales y anormales en la red mediante el uso de Reinforcement Learning (RL). Los agentes sensores extraen información sobre el estado de la red usando tile-coding como técnica de aproximación de función y envían señales de comunicación en la forma de acciones a los agentes de decisión. Estos a su vez generan acciones en la forma de alarmas al operador de la red. Mediante un proceso en línea, agentes sensores y de decisión aprenden las semántica de las señales de comunicación sin ningún conocimiento previo. En esta presentación describiré el proceso de aprendizaje, la operación de la arquitectura de los agentes y los resultados en la evaluación de este trabajo de investigación.




Y un video de la simulación:
Advertencia, el contenido de este video puede ser molesto para la audiencia (contiene música muy cursi de ABBA)

Wordpress bajo DoS

Que puedo decir, que bueno que tengo mi blog en Blogger y no en Wordpress. Desde el sábado Wordpress, uno de los hostings más populares de blogs ha estado en un ataque de negación de servicio (DoS). De acuerdo al reporte muchos de los blogs han estado inaccesibles tanto para los blogueros como para hacer comentarios.

De acuerdo a Wordpress el servicio se está restableciendo poco a poco pero aún no hay un estimado (como en cualquier DoS) de cuando el servicio se re-establecerá por completo. El aununcio oficial de cuales son las características y fuentes del ataque de servicio aún no ha sido dado a conocer. Me preguntó si será algo intencional o un ataque inintencionado (similar al ocurrido a Amazon S3)

¿Amazon S3 bajo un ataque de negación de servicio?

   El día 15 de febrero (2008), Amazon S3 uno de los servicios de almacenamiento más confiables dejó de funcionar para sorpresa de muchos. Amazon ha liberado el reporte de lo sucedido. Traduciendo el comunicado:

"Esta mañana muy temprano, alrededor de las 3:30 p.m. PST,  en una de nuestros centros comenzamos a recibir elevados niveles de requisiciones de autentificación de múltiples clientes. Mientras que revisamos que los niveles de requisiciones se mantuvieran bajo los niveles normales, no habiamos estado monitoreando la proporción de requisiciones de autentificación. Estas requisciones al hacer uso de encripción consumen más recursos que otros tipos de requisición.

Poco después de las 4:00 PST, comenzamos a observar otros usuarios con incrementos significativos de servicios de autentificación. El último de éstos llevó al servicio de autentificación a su límite antes de que pudieramos alocar más capacidad. Además de la autentificación, este servicio también maneja validación de cuentas en cada requisición de Amazon S3. Esto causó que el servicio de Amazon S3 estuviera inoperable para cualquier requisición en ese centro. Para las 6:48 PST mya habiamos movido la suficiente capacidad para resolver el problema." 

Una pregunta que no ha sido contestada y que posiblemente se conteste en los próximos días es si ésto fue un ataque de negación de servicio sin intención o intencionado. Es una gran coincidencia que varios clientes iniciaran requisiciones de autentificación de forma simultánea y en el mismo centro de datos de Amazon. En el caso de un ataque sin intención, Amazon deberá buscar la razón de este y el evento que desencadenó las múltiples autentificaciones, no solo para entender el fenómeno sino para que ellos puedan tomar las medidas operativas para resolver estos eventos. 

En lo personal creo que Amazon S3 sigue siendo un excelente servicio (y muy económico) y estoy seguro que Amazon tomará las medidas necesarias para evitar problemas en su servicio.

Fuentes:

Why S3 failed

Amazon Web Services Developer Connection

Mashable