El día en que Internet fue atacada

Marzo 19th, 2009

Quizás nunca os lo hayáis planteado, quizás nunca creistéis que fuera posible, quizás ni sentistéis los ecos de tamaña batalla… pero lo cierto es que hubo un día en el que toda Internet casi deja de funcionar, fue uno de los ataques más increíbles que jamás se han realizado.

A lo largo de los años de vida de la red de redes no han sido pocos los que han señalado la debilidad de nuestra arquitectura actual de resolución de nombres. Ya sabéis que cuando escribimos en el navegador “www.google.com”, esto debe traducirse a una dirección IP que luego es usada para establecer la conexión. Para realizar este proceso es necesario que nuestro equipo contacte con algún servidor en donde se mapee el nombre “www.google.com” con su IP correspondiente. Obviamente, no existe ningún servidor central en donde todos los nombres estén mapeados con todas las IP, dado el tamaño de Internet y su naturaleza cambiante, eso es simplemente imposible.

Para visualizar la arquitectura de resolución de nombres debemos imaginar una pirámide, en la cima están los servidores raíz, los directores de la orquesta. A ellos siempre podremos preguntarles por el nombre que queramos resolver, pero en vez de darnos la respuesta, nos contestará con la dirección de un servidor de nivel inferior que puede que si la conozca. Ese servidor, si no la sabe, nos contestará a su vez con una dirección de nivel inferior al suyo, y así vamos bajando hasta dar con el servidor de nombres que tiene la información que buscamos. No quiero entretenerme mucho en el protocolo de resolución de nombres (DNS), pero la idea básica es que la información está repartida entre muchos servidores y existen caminos para llegar a ella a partir de los servidores raíz. Como toda arquitectura jerárquica cuenta con el problema clásico de la decapitación, ¿Qué pasa si por alguna razón caen los servidores raíz?  Existen un total de 13 servidores de raíz y muchos expertos coinciden en que las posibilidades de realizar un ataque éxitoso sobre los 13 de manera simultánea y con la duración suficiente para que sea notable son rídiculas. Por otro lado, estos servidores cuentan con medidas extraordinarias de seguridad, además atacarlos no produce ningún beneficio a nadie.

A pesar de todo, a las 20.45 UTC del  21 de Octubre del 2002 comenzó un ataque de denegación de servicio distribuido sobre los 13 servidores de nombres raíz. Cientos de miles de equipos comenzaron a establecer conexiones con estos servidores, cargándolos de trabajo adicional con la intención de impedirles realizar la tarea para la que fueron diseñados. El grueso del ataque se prolongó hasta  las 22.00 UTC, aunque aún siguieron llegando rafagas de paquetes maliciosos hasta la mañana del 22 de Octubre.

Se estima que cada servidor recibió una carga adicional de entre 50 y 100 Mbits/seg. El tráfico involucrado en el ataque iba desde paquetes ICMP hasta paquetes TCP mal fragmentados, pasando por los clásicos TCP SYN o intentos de conexiones UDP. Todas las direcciones de origen eran falsas, por lo que nunca se pudo ubicar a los bots que lanzaron el ataque.

Lo más singular es que fue la primera vez en que se ponía en marcha un ataque simultáneo de tal magnitud, el simple hecho de llevarlo a cabo ya era un reto importante. Otro de los detalles más desconcertantes fueron las motivaciones del atacante… la gloria en los sitios más oscuros del underground es lo único que parece aceptable.

El objetivo del ataque era evitar que los servidores de nombres raíz pudieran responder a las peticiones de resolución de nombres, lo que impediría la comunicación con cualquier máquina de la que no supieramos la IP. Por buscar un símil, si Internet es un gran continente, el ataque lo hubiera fragmentado en pequeñas islas incomunicadas entre sí… o con una comunicación muy limitada. Un desastre… sin negocios globales, sin e-mail… SIN GOOGLE!!! :P (bueno, posiblemente sí que seguiríamos teniendo acceso a Google, al menos durante varias horas después del comienzo del ataque, pero eso es otra historia). El caso es que de haber funcionado, hubiera sido un cataclismo sin precedentes… pero a que no os habéis enterado de que algo parecido haya sucedido, ¿verdad?

A pesar de que el ataque llegó a afectar a 9 de los 13 servidores, sólo fue perceptible por el usuario final como pequeños retrasos al intentar usar ciertos servicios. Esto se debió principalmente a las buenas medidas con las que contaban los servidores raíz para hacer frente a eventualidades como éstas y al buen hacer de los técnicos que intervinieron en esta incidencia: se amplió el caudal de datos, se activaron balanceadores de carga, se pusieron en marcha redes espejos para evitar congestiones en puntos concretos y muchas más medidas adicionales.

Todo quedó en un susto, horas de sueño perdidas y bastante dinero gastado (las contramedidas que se tomaron para mantener el servicio no fueron precisamente baratas). Además sirvió para reforzar aún más la seguridad de estos servidores.

Pero ésta no fue la última vez que se intetó decapitar Internet, el 6 de Febrero del 2007 un nuevo ataque masivo intentaba dejar fuera de servicio a los servidores raíz. A pesar de que este ataque fue mucho más agresivo y gracias a las mejoras introducidas en la arquitectura DNS tras el ataque del 2002, el impacto fue muy limitado, aunque se informó que dos de los servidores raíz habían sido gravemente afectados. Sin embargo, una vez más, el usuario final apenas notó retrasos en las comunicaciones.

Creedme si os digo que todos los días se libran batallas escalofriantes en ésta, nuestra red, sin embargo los hombres de negro velan por nosotros… o eso dicen ellos.

Fuentes principales:

http://d.root-servers.org/october21.txt

http://www.icann.org/announcements/factsheet-dns-attack-08mar07.pdf

Categorías: Cibercriminales, curiosidades | 17 comentarios

El misterioso caso del Linux que iba lento

Febrero 27th, 2009

Desde hace tiempo estoy buscando alguna excusa para instalar mi querido Debian en el ordenador del trabajo. Por fin la excusa llegó de mano de un proyecto muy interesante sobre clusters Red Hat y sistemas de ficheros compartidos. El caso es que tras instalarlo fui tan contento a bajar algunas herramientas que necesitaba vía apt-get. No podéis imaginar mi sorpresa cuando la velocidad de descargar no superaba los 6KB, más o menos la velocidad a la que iba mi antiguo modem, allá por el principio de los tiempos.

Me digo, ¡No puede ser! Windows va estupendamente y nadie se queja, así que tiene que ser cosa del repositorio APT, voy a probar otro mirror.  Pues no, todos iguales.

¿Me afectará también a la hora de navegar? Pues sí y no. En algunas páginas va genial y en otras se arrastra. Que cosa más rara.

Quizás es algún bug que hay en este kernel tan nuevo, mañana traigo el portátil de casa y comparo. Y lo traje y vi asombrado como mi portátil no superaba los 6KB.  También llevé el equipo del trabajo a casa y vi como la velocidad de descarga no bajaba de los 200KB.

Ajá, hay algo en la red del trabajo que le está haciendo la puñeta a mi pobre Linux y que dejá a los Windows tan tranquilos. Esto en sí mismo es bastante raro, pero ya puestos me puse a trastear con switches y routers. Mmmmm… todo parece correcto.

¿Y que dice Google? Seguro que ya ha habido muchos casos como éste antes. Y sí, efectivamente ha habido muchos casos como éste. Búsquedas tan originales como linux internet lento o simpelmente internet lento arrojan miles de resultados. Algunos coinciden exactamente con mi problema, sin embargo las soluciones que ofrece la comunidad son del estilo: revisa el cable, formatea el equipo o desfragmenta el disco. Es más, este problema no se limita sólo a los Linux, hay otros S.O. como Windows Vista que también lo sufren.

Pero…

¿Por qué en casa va bien?

¿Por qué con algunos servidores no hay problemas?

¿Por qué me pasa a mi esto (y a los demás no)? Es inevitable pensar que somos las personas más desgraciadas del universo…

Vale, habrá que tomarse las cosas con calma, ¿Qué sabemos?

* Es un problema que ocurre en la red del trabajo, por lo tanto hay algún elemento de la misma que está haciendo algo que no debe.

* Por los resultados de la búsqueda podemos deducir que es un problema que afecta a S.O. relativamente recientes.

* No todas las comunicaciones están afectadas (esto sí que es condenadamente raro)

Armado con mi wireshark sigo haciendo pruebas y descubro que el problema sólo parece darse con conexiones TCP. Ya la cosa tiene más sentido. Quizás alguna optimización de la pila TCP que se ha incluido en los nuevos núcleos y no es bien vista por equipos de comunicaciones antiguos. Ahora que ya sé lo que estoy buscando vuelvo a Google y no tardo en encontrar el RFC1323 y los problemas que tienen alguno routers con él. Voy a resumir un poco para no aburriros demasiado…

El RFC1323 es una extensión al protocolo TCP para resolver un problema conocido como TCP Window Scaling. Uno de los campos del protocolo TCP, llamado window, especifica la cantidad de datos que esta preparado a recibir el sistema que envía el paquete. De esta manera comunicamos al otro extremo como estamos de carga y lo que estamos dispuesto a procesar, es el mencanismo de control de flujo básico de TCP.

El campo window tiene una longitud de 16bits, lo que implica que podemos especifar una ventana máxima de 64Kb, en aquellos tiempos en los que se diseñó el protocolo era un tamaño ridículamente exagerado, hoy en día es un tamaño ridículamente limitado. Así que en el 92 salió a la luz el RFC1323 en el que se especificaba una manera de acabar con esta limitación.

Lo solución que se dió es la siguiente, se incluye un campo de opciones TCP llamado scale.  El valor de este campo multiplicado por el valor del campo window especifica el tamaño real de la ventana TCP (para los puristas: no se realiza una multiplicación, sino un desplazamiento hacia la izquierda de bits). Así pues, de esta manera tan sencilla se había acabado con el problema de ventanas TCP demasiado pequeñas.

Ahora bien, había otro problema que solucionar. No todos los sistemas tenían que implementar esta optimización y aún así todos deberían poder seguir comunicándose entre sí. Se decidió que la mejor manera de solucionar esto era negociarlo durante el 3-way-handshake (SYN/SYN+ACK/ACK). Si un sistema desea usar las optimizaciones del tamaño de ventana, manda en el paquete SYN la opción TCP adecuada con la escala que considere oportuna, si el sistema destino soporta la optimización, devolverá en el paquete SYN-ACK esta opción, si no siemplemente elminará la opción del paquete de vuelta, que es la forma estándar de proceder en el caso de ignorar el significado de una opción TCP. La limitación de esta negociación es que el tamaño de la ventana permanece constante durante toda la sesión TCP, un mal menor.

Y ahora el problema, algunos routers y firewalls, como medida de “seguridad”, cuando ven alguna opción TCP que no reconocen la ponen a 0, lo que claramente viola el estándar: o bien se quita el campo de opción completo o bien se ignora su contenido, pero alterarlo de esa manera sólo puede producir problemas. Veamos lo que pasa, nuestro Linux que soporta la optimización del RFC1323 pone el campo scale como opción TCP. Nuestro router no ve con buenos ojos esa opción que no reconoce y la pone a 0. El sistema final, que también soporta el RFC1323 hace los calculos para una escala de 0 y devuelve el SYN+ACK con esta opción activa. El resultado es una confusión en el tamaño de ventana que hay que utilizar. Los problemas que esto genera van desde una comunicación extremadamente lenta o la pérdida total de comunicación. Por otro lado, si el sistema final no soporta las optimización, el campo scale es ignorado y eliminado del paquete de vuelta, y se usa el antiguo método de control de flujo, por lo que todo va estupendamente bien. De ahí que con algunos sistemas dé problemas y con otros no.

SOLUCIÓN

El workaround es desactivar esta optimización, en Linux esto lo puedes hacer así:

echo 0 > /proc/sys/net/ipv4/tcp_window_scaling

Lo que cambiará esta opción hasta el próximo reinicio de la máquina, para dejarlo fijo añade la siguiente línea al /etc/sysctl.conf:

net.ipv4.tcp_window_scaling = 0

Para Windows Vista tienes una guía paso a pasa en el siguiente enlace:

http://www.tech-recipes.com/rx/1744/vista_tcp_cannot_communicate_primary_dns_server/

Si alguno se ha quedado con ganas de más, podéis ampliar información en: http://lwn.net/Articles/92727/

Categorías: curiosidades, interesante | 19 comentarios

Diría que eso lo he escrito yo

Noviembre 27th, 2008

Tendriaís que haber visto la cara que se me quedó cuando me encontré con uno de mis posts en otro blog y además firmado por otra persona!!. Al contrario de la indignación que suele acompañar a estos casos, a mí me entró la risa. Exagerando un poquito, hasta me hizo ilusión :mrgreen: Al fin y al cabo si te copian es que lo estás haciendo bien.

Aquí está la espectacular web de AngelInformático y su galería de artículos copiados. Pero es que además este curioso personaje tiene otro blog llamado Soporte Computacional en el que se dedica a resolver las dudas que le envían… eso sí, a base de ir copiando artículos a diestro y siniestro. Al mío sólo le cambio el título, todo lo demás es idéntico (ver artículo original).

Y ahora unas palabras para el plagiador: te paso que me hayas copiado el texto, te paso que no me cites como fuente… pero lo que es intolerable es que encima firmes con tu nombre! Un poco de decencia, hombre.

Categorías: curiosidades, offtopic | 4 comentarios

SubDownloader - Subtítulos a un click de ratón

Noviembre 13th, 2008

Aunque no suelo publicar este tipo de cosas, creo que en esta ocasión vale la pena. Sé que muchos de vosotros estáis tan engachados como yo a las series en versión original, esto nos viene generando la necesidad constante e irritante de estar buscando continuamente los subtutítulos adecuados. A veces es una tarea sencilla, en otros casos la búsqueda resulta agotadora y frustrante. Pues bien, gracias a SubDownloader ya podemos olvidarnos de ir de página en página como almas en pena intentando encontrar los subtítulos que necesitamos.

Esta inteligente utilidad permite buscar subtitulos en webs dedicadas a almacenarlos (aunque de momento sólo los busca en OpenSubtitles.org), además tiene una interesante opción en la que seleccionamos el archivo de video que queremos subtitular y ya el programa se encarga de buscar entre los disponibles (usa el hash del archivo para esta tarea). Además y como no podía ser de otra manera, nos permite filtrar por el idioma deseado. También cuenta con otras opciones interesantes como mostrar la información IMDb de la peli o reproducirla en el mismo SubDownloader.

Resumiendo, una utilidad que nos facilitará la vida.

Categorías: curiosidades, utilidades | 2 comentarios

GOOSH

Junio 6th, 2008

Hoy os traigo una curiosidad, la verdad es que me hizo mucha gracia cuando me la enseñaron… y es que si sois de esos que prefieren usar los ‘ls’ y ‘cd’ antes que navegar gráficamente entre los archivos, si podéis concatenar comandos con la misma facilidad con la que respiráis, si cuando alguien os enseña un menú gráfico para que lo ayudéis a configurar su Linux os quedáis mirándole con cara extrañada… entonces querido amgio amante de la consola, goosh es para ti. Lo que siempre habías soñado!!! Ahora también podrás hacer búsquedas a través de Google cómo si estuvieras en tu shell de toda la vida!! Increíble, ¿no?

Goosh

Aprovecho para dar las gracias a David por mostrarme goosh

Categorías: curiosidades | 1 comentario

Kameraflage

Mayo 2nd, 2008

No he podido resistir la tentación de comentar esta tecnología (aunque luego alguno que otro luego me deje algún comentario criticándome)

Bueno, a lo que iba, Kameraflage es una tecnología que permite imprimir textos e imágenes que no son visibles al ojo humano (se usan colores que se encuentran fuera del espectro visible), pero que son capturados fácilmente por las cámaras digitales. Así pues, podemos llevar una camiseta que aparentemente esté vacía, pero que contenga todo tipo de mensajes subversivos que sólo aparecerán cuando nos fotografien. En la web oficial se explican otras aplicaciones, como la protección de películas de estreno u obras de arte mediante la sobreimpresión de texto.

Foto realizada con Kameraflage
Esperemos que saquen una línea de camisetas con frases variadas, seguro que se convierten en un buen regalo-putada.

Categorías: curiosidades | 4 comentarios