Alguna vez han le\u00eddo la explicaci\u00f3n que dan la mayor\u00eda de que es un ataque DoS y el por que funciona.<\/p>\n
La explicaci\u00f3n mas sencilla y casi rid\u00edcula es<\/p>\n
Un restaurante con un \u00fanico mesero recibe demasiados comensales y estos le piden al mismo tiempo la orden, el mesero no puede atender a todos al mismo tiempo.<\/p>\n
Esa explicaci\u00f3n demuestra dos cosas<\/p>\n
La primera, el que la dice no entiende nada de c\u00f3mo funci\u00f3n un sistema operativo y que tampoco sabe hacer buenas analog\u00edas porque es mentira que el mesero no pueda atender a todos, le tomara mucho, mucho tiempo atender a todos pero finalmente y con el tiempo necesario terminara por atender hasta a el ultimo cliente, por lo que no es v\u00e1lida la analog\u00eda<\/p>\n
Muchos de los mocosos que hacen DoS a un sitio ven que funciona, pero no entienden por que funciona y explican cosas como el mesero para que los dem\u00e1s piensen que sabe de que habla y es ah\u00ed donde critico mucho a las nuevas generaciones, no tienen ni la menor idea de que pasa cuando dan un click o cuando presionan una tecla del teclado, solo dan por sentado que debe darse el click o escribirse la letra impresa en la tecla, pero desconocen como funciona el sistema operativo y las partes internas del equipo de computo. As\u00ed como desconocen el por qu\u00e9 funciona algo como el DoS <\/p>\n
El verdadero peligro de un DoS no es que el sitio deje de despachar p\u00e1ginas WEB, sino que el servidor que hostea el sitio entre en thrashing ya que una vez en ese estado, incluso un da\u00f1o f\u00edsico podr\u00eda ser inminente<\/p>\n
Primero lo b\u00e1sico<\/p>\n
Swaping es la operaci\u00f3n normal de un sistema operativo para bajar a disco duro segmentos de RAM que no est\u00e1n siendo usados y devolverlos a la RAM bajo demanda del programa que los solicita, lo que da la ilusi\u00f3n de que el sistema tiene m\u00e1s RAM de la que f\u00edsicamente tiene instalada, ya que cuando el programa es bajado al disco duro la memoria RAM que ocupaba se libera para uso de otros programas asi si solo tienes 2 MB de RAM puedes llegar a ejecutar sin problema muchos programas que en suma consuman m\u00e1s de 10 MB de RAM, lo cual sin el SWAP seria imposible<\/p>\n
Por supuesto cada que ese proceso ocurre el sistema se a lenta, el disco duro se ocupa de leer y escribir mucho por lo que la velocidad de acceso a informaci\u00f3n en el discos que no tiene nada que ver con el swap tambi\u00e9n se ralentiza, salvo tengas un disco duro de uso exclusivo para el SWAP que casi nunca es el caso <\/p>\n
Ahora el ataque<\/p>\n
El ataque DDoS funciona porque muchos clientes simult\u00e1neamente abren una sesi\u00f3n con el servidor WEB, lo que no muchos saben es que cada sesi\u00f3n no consume gran ancho de banda por lo que un ataque DoS puede ser llevado a cabo con humildes enlaces de un simple modem 33.6Kbps y si el ancho de banda no cuenta algo mas debe ser lo que logra deshabilitar el servidor en el ataque.<\/p>\n
Lo que ocurre es que y para entenderlo obviamente debes conocer del funcionamiento de TCP\/IP, la programaci\u00f3n de Sockets, asignaci\u00f3n de memoria para un proceso en (de preferencia en C) tu lenguaje favorito.<\/p>\n
Y lo que ocurre es muy simple, llega una paquete TCP por el puerto 80 que es donde esta el modo listen del servidor WEB, el servidor WEB inicia una sesi\u00f3n de TCP para despachar el flujo de datos, para hacer eso reserva una cierta cantidad de RAM para manejar un nuevo hilo del programa ya que de lo contrario el servidor WEB solo recibir\u00e1 un cliente a la vez en el puerto 80, as\u00ed que el flujo se mueve con punteros a otra secci\u00f3n e la memoria aprovechando la multitarea del sistema operativo, de modo que el proceso principal pueda quedarse escuchando nuevamente en el puerto 80 para la siguiente inicio de sesi\u00f3n TCP.<\/p>\n
Esto significa que por cada nueva sesi\u00f3n se crea un hilo, un peque\u00f1o modulo del servidor WEB que despacha los datos, cada modulo obviamente requiere un poco de RAM independiente a los dem\u00e1s m\u00f3dulos que se hayan creado, esa RAM es variable si por ejemplo tiene que ejecutar PHP o ASPX o cualquier otro cachivache porque entonces tiene que a su vez solicitar m\u00e1s RAM para ejecutar el script y n\u00f3tese que yo lo llamo SCRIPT no programa PHP y toda esa RAM se libera al cerrar la sesi\u00f3n TCP<\/p>\n
El problema viene con que la mayor\u00eda de los ataques DoS abren la sesi\u00f3n TCP pero no transmiten nada, solo se queda ah\u00ed esperando a que el cliente le diga que require y esto hace que un tercer jugador entre a la cancha, el sistema operativo.<\/p>\n
Cuando el sistema operativo entra y puede puede se cualquiera GNU\/Linux, Windows, FreeBSD, Solaris el que sea, todos traen la misma instrucci\u00f3n de cuando un programa se comporta como se esta comportando un modulo en espera. El sistema operativo lanza un equivalente a recolector de basura y por basura tenemos procesos que no est\u00e1n haciendo nada m\u00e1s que gastar memoria RAM y los manda de intercambio o swap al disco duro, remitirse a primero lo b\u00e1sico varios p\u00e1rrafos arriba para volver a leer sobre SWAP<\/p>\n
El problema en un ataque DoS es que no hay uno sino miles y siguen llegando mas y el OS sigue enviando a disco esos modulos de RAM y liberando RAM, asi que el servidor WEB puede recibir mas conexiones, lo malo es que recibe mas de esas conexiones DoS la cuales igual terminara baj\u00e1ndolas a disco duro, eventualmente hara que el sistema operativo se cuelgue y sin embargo el ataque DoS aun puede ser mas malisioso y causar un da\u00f1o aun mayor que solo un cuelgue del sistema, obvio eso no lo hacen muchos atacantes por que no son programadores solo novatos que dan click en un programa y que no entienden que pasa por debajo.<\/p>\n
\u00bfComo se vuelve devastador el ataque?<\/p>\n
si cada sesi\u00f3n TCP del lado del atacante tiene programado un tiempo de espera, es decir se espera unos 30 segundos antes de enviar unos bits de transferencia esto podr\u00eda incluso da\u00f1ar f\u00edsicamente el servidor, \u00bfPoooor que? Porque recordemos que las sesiones iniciales al estar inactivas fueron transferidas a disco duro y en este momento ya no son unas pocas sino miles de ellas y ya que estas se regresan a la RAM bajo demanda para ser ejecutadas, ya que el CPU no las puede ejecutar mientras est\u00e1n en el disco duro. Un simple byte obligar\u00eda al modulo a regresar a la RAM, significa que el OS tiene que buscar el modulo entre miles de m\u00f3dulos y regresarlo a la RAM, mientras al mismo tiempo mas m\u00f3dulos tienen que ser enviados al disco por que siguen llegando m\u00e1s conexiones de los atacantes, solo para atender un byte, despu\u00e9s el atacante le manda un byte a otro de los procesos dormidos, a varios a de ellos lo que obliga al OS a despertar todos esos m\u00f3dulos que estaban en disco mientras otros nuevos siguen llegando, aqu\u00ed la cosa es critica el sistema es superado por la cantidad de m\u00f3dulos que tiene que mandar a dormir y los que tiene que despertar para luego volverlos a mandar a dormir modificado por el byte<\/p>\n
A este estado tan ca\u00f3tico se le llama thrashing o hiperpaginacion y es aqu\u00ed cuando se vuelve peligroso el ataque DoS<\/p>\n
El CPU se sobrecaliente, sin la ventilaci\u00f3n correcta se congelara, si el procesador sobrevive el OS podr\u00eda congelarse lo que ser\u00eda el mismo efecto a que el CPU se congele y si se congela ocurren todo tipo de desgracias causadas por el mecanismo swaping.<\/p>\n
Los discos duros se sobrecalientan pudiendo causar da\u00f1o f\u00edsico en los discos pero aun si el disco duro sobrevive a la tortura de escribir y leer el espacio de swap, el servidor WEB no es el \u00fanico programa corriendo.<\/p>\n
Esta la base de datos, est\u00e1n otros m\u00f3dulos del kernel que al ser m\u00f3dulos pueden ser tratados como programas y aplicarle las mismas reglas.<\/p>\n
\u00bfQue ocurr\u00eda si el servidor se congela en el thrashing?<\/p>\n
Un ecenario devastador seria.<\/p>\n
La base de datos al ser un programa y al no ser utilizada tambi\u00e9n fue enviada al espacio swap si una tabla se quedo abierta y un dato no tuvo el tiempo del commit la tablas afectadas quedaran corruptas y cuando reinicie el servidor , si es que reinicia estar\u00e1n da\u00f1adas.<\/p>\n
\u00bfPor que si es que reinicia?.<\/p>\n
La mayor\u00eda de los servidores que usan GNU\/Linux tienen un mecanismo de compatibilidad hacia atr\u00e1s significa que soportan ext2, ext3 y ahora ext4 entre otros sistema de archivos, como el ext3 y ext4 mantienen cierta compatibilidad con ext2, los kernel dejan como c\u00f3digo fijo el ext2 pero convierte en m\u00f3dulos el ext3 y ext4.<\/p>\n
Cuando arranca un Linux las particiones son montadas primero en modo ext2 porque es el \u00fanico sistema de archivos que entiende, el \u00fanico del cual todo su c\u00f3digo esta dentro del kernel, el kernel busca la partici\u00f3n donde est\u00e1 el resto de sus m\u00f3dulos y como solo puede hacerlo con el ext2 lo hace con ese, una vez que encuentra el modulo de ext3 como un archivo en el disco, carga este modulo en RAM como un programa adicional y remonta la partici\u00f3n que hab\u00eda montado como ext2 a ext3 para aprovechar ahora los beneficios del ext3 o ext4 si fuera el caso.<\/p>\n
El problema de que sea modulo es que se carga fuera del kernel como un proceso, en el momento del thrashing es que como el sistema esta mas ocupado moviendo los hilos del servidor WEB encuentra que el sistema de archivos casi no se usa y siendo un programa ociosos en el sistema es muy probable que lo bajara al swap, si el modulo de ext3 es bajado al espacio swap todas las transacciones que estuvieran en ram se bajan en un mundo ideal cuando se demande el uso del sistema de archivos ext3 este seria despertado del swap y continuar\u00eda funcionando sin problemas, pero si en lugar de despertar el servidor se congela sea por el CPU sobrecalentado o por que el thrashing lo congelo a nivel OS, pues ni la DB, ni los archivos abiertos ni ninguna informaci\u00f3n que deber\u00eda escribirse al disco duro ser\u00e1 escrita.<\/p>\n
Al reiniciar el servidor es posible que el sistema de archivos haya quedado corrupto o da\u00f1ado al punto de la perdida de informaci\u00f3n si es un da\u00f1o irreparable.<\/p>\n
En este video se puede ver como poco a poco el thrashing termina por congelar un servidor, en el video se puede ver que aun le queda espacio de swap para hacer mas intercambios, el problema es el programa que hice para llevarlo a estado de thrashing, los m\u00f3dulos son mandados a swap y luego regresados a ram, el servido esta tan ocupado que un simple clear para limpiar la pantalla le toma mas casi 3 segundos en ser ejecutado, hasta que simplemente todo el sistema se congela, la maquina f\u00edsica sigue funcionando, es decir el CPU no se congelo en este caso, pero el led de disco duro sigue leyendo sin parar, aqui el problema es que el OS no pudo seguir haciendo el intercambio se congelo.<\/p>\n