Alguna vez han leído la explicación que dan la mayoría de que es un ataque DoS y el por que funciona.

La explicación mas sencilla y casi ridícula es

Un restaurante con un único mesero recibe demasiados comensales y estos le piden al mismo tiempo la orden, el mesero no puede atender a todos al mismo tiempo.

Esa explicación demuestra dos cosas

La primera, el que la dice no entiende nada de cómo función un sistema operativo y que tampoco sabe hacer buenas analogías 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álida la analogía

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ás piensen que sabe de que habla y es ahí 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í como desconocen el por qué funciona algo como el DoS

El verdadero peligro de un DoS no es que el sitio deje de despachar páginas WEB, sino que el servidor que hostea el sitio entre en thrashing ya que una vez en ese estado, incluso un daño físico podría ser inminente

Primero lo básico

Swaping es la operación normal de un sistema operativo para bajar a disco duro segmentos de RAM que no están siendo usados y devolverlos a la RAM bajo demanda del programa que los solicita, lo que da la ilusión de que el sistema tiene más RAM de la que físicamente 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ás de 10 MB de RAM, lo cual sin el SWAP seria imposible

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ón en el discos que no tiene nada que ver con el swap también se ralentiza, salvo tengas un disco duro de uso exclusivo para el SWAP que casi nunca es el caso

Ahora el ataque

El ataque DDoS funciona porque muchos clientes simultáneamente abren una sesión con el servidor WEB, lo que no muchos saben es que cada sesión 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.

Lo que ocurre es que y para entenderlo obviamente debes conocer del funcionamiento de TCP/IP, la programación de Sockets, asignación de memoria para un proceso en (de preferencia en C) tu lenguaje favorito.

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ón 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á un cliente a la vez en el puerto 80, así que el flujo se mueve con punteros a otra sección 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ón TCP.

Esto significa que por cada nueva sesión se crea un hilo, un pequeño modulo del servidor WEB que despacha los datos, cada modulo obviamente requiere un poco de RAM independiente a los demás módulos 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ás RAM para ejecutar el script y nótese que yo lo llamo SCRIPT no programa PHP y toda esa RAM se libera al cerrar la sesión TCP

El problema viene con que la mayoría de los ataques DoS abren la sesión TCP pero no transmiten nada, solo se queda ahí esperando a que el cliente le diga que require y esto hace que un tercer jugador entre a la cancha, el sistema operativo.

Cuando el sistema operativo entra y puede puede se cualquiera GNU/Linux, Windows, FreeBSD, Solaris el que sea, todos traen la misma instrucción 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án haciendo nada más que gastar memoria RAM y los manda de intercambio o swap al disco duro, remitirse a primero lo básico varios párrafos arriba para volver a leer sobre SWAP

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ándolas 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ño 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.

¿Como se vuelve devastador el ataque?

si cada sesión 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ía incluso dañar físicamente el servidor, ¿Poooor 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án en el disco duro. Un simple byte obligaría al modulo a regresar a la RAM, significa que el OS tiene que buscar el modulo entre miles de módulos y regresarlo a la RAM, mientras al mismo tiempo mas módulos tienen que ser enviados al disco por que siguen llegando más conexiones de los atacantes, solo para atender un byte, después 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ódulos que estaban en disco mientras otros nuevos siguen llegando, aquí la cosa es critica el sistema es superado por la cantidad de módulos que tiene que mandar a dormir y los que tiene que despertar para luego volverlos a mandar a dormir modificado por el byte

A este estado tan caótico se le llama thrashing o hiperpaginacion y es aquí cuando se vuelve peligroso el ataque DoS

El CPU se sobrecaliente, sin la ventilación correcta se congelara, si el procesador sobrevive el OS podría congelarse lo que sería el mismo efecto a que el CPU se congele y si se congela ocurren todo tipo de desgracias causadas por el mecanismo swaping.

Los discos duros se sobrecalientan pudiendo causar daño físico 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 único programa corriendo.

Esta la base de datos, están otros módulos del kernel que al ser módulos pueden ser tratados como programas y aplicarle las mismas reglas.

¿Que ocurría si el servidor se congela en el thrashing?

Un ecenario devastador seria.

La base de datos al ser un programa y al no ser utilizada también 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án dañadas.

¿Por que si es que reinicia?.

La mayoría de los servidores que usan GNU/Linux tienen un mecanismo de compatibilidad hacia atrás 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ódigo fijo el ext2 pero convierte en módulos el ext3 y ext4.

Cuando arranca un Linux las particiones son montadas primero en modo ext2 porque es el único sistema de archivos que entiende, el único del cual todo su código esta dentro del kernel, el kernel busca la partición donde está el resto de sus módulos 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ón que había montado como ext2 a ext3 para aprovechar ahora los beneficios del ext3 o ext4 si fuera el caso.

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ía 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ón que debería escribirse al disco duro será escrita.

Al reiniciar el servidor es posible que el sistema de archivos haya quedado corrupto o dañado al punto de la perdida de información si es un daño irreparable.

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ódulos 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ísica 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.

Para evitar este efecto de un DoS

Lo primero es desactivar el swap, los servidores web no deben llevar SWAP por que en lugar de ayudarlos en un ataque DoS el SWAP se vuelve en contra del mismo servidor llevandolo al modo thrashing.

Recompila el kernel, desactiva todos módulos que tu sistema no requiere y los que requiere ponlos fijos en el kernel, simplemente no uses módulos de kernel.

Si tienes ext3, no requieres compilar ext2 ni ext4, solo necesitas ext3

Necesitas un servidor dedicado para la base de datos, por lo general meten la DB en el mismo servidor WEB, eso es un error, la DB debe estar en un tercer servidor para que los fallos y cuelgues del servidor WEB no le causen problemas a la DB

La mayoría de los ataques DoS no son tan dañinos, los atacantes no son programadores solo saben dar click y esperan ver que el servidor deja de responder, solo atacantes como Xianuro pueden hacer este tipo de ataques tan letales ya que no usan soluciones de tercero sino que programan sus propias herramientas de ataques y conozco muy pocos como Xianuro.