Bombas Fork para Dummys

Debido a la reciente avalancha de comentarios dentro de los foros de Kriptopolis, presento una pequeña entrada sobre el tema:

Mucha Gente cree que los SO Tipo UNIX son inmunes al congelamiento, sin embargo, esto no es cierto. Las Bombas Fork son un claro ejemplo, estas no son en si un ataque, un error en el kernel, una vulnerabilidad (Bueno, esto a veces) o una broma puesta por algún programador del kernel. Resultan ser elementos propios del SO que permiten realizar tareas de bifurcación de procesos. Entonces (Mal usados) crean procesos bifurcados que saturan la memoria.

Mi primera experiencia con este tipo de fenómenos fue durante una explicación maliciosa sobre escaneo de puertos con NMAP, donde se me recomendó que hiciera lo siguiente:

heaven$nmap -O www.google.com &&:(){ ::& };:

¿Que ocurre?

El fork es la parte que se ejecuta despues del nmap (entiendase despues del &&) lo demas se explica de la siguiente forma:

":" Es el nombre de la funcion;

:() Creamos la funcion sin parametros por eso el parentesis esta vacio.

{

:|:& Llamamos a la propia funcion (Recursividad) rediriendo la salida estandar a la entrada estandar de si misma. el & hace que los procesos pasasn a background, es decir si muere el proceso padre, el hijo no.

};

: Llamamos la primera vez a la funcion recursiva, ella se encarga de llamarce el resto de las veces.

En aquellos tiempos usaba el extinto Mandrake Linux con su configuración estándar. Este "comando" provoco una incontable cantidad de cosas en la consola para terminar con un sistema congelado, incluso el cambio de sesión (Ctrl + Alt +F(1-6)) no funciono, la parte :(){ ::& };: es la parte del fork, este "seudo comando" es muy conocido y congelara una gran parte de las distribuciones Linux (Debian, se congela con su configuración por default). propongo dos soluciónes, una requiere privilegios de administrador y se realiza de la siguiente forma:

Con nuestro editor favorito (Vim, nano, Emacs, Jedit, etc…) editamos el archivo "/etc/security/limits.conf" (En la mayoría de las distribuciones se encuentra en ese lugar)

Le agregamos la siguiente línea:

* hard nproc 1000

Nota: recuerda que necesitas privilegios de administracion para editar este archivo, por que es un archivo del sistema.

la otra es mediante el comendo ulimit -u limite

entonces:

ulimit -u 1000 es equivalente a la modificacion del limits.conf aunque esta solo limita los procesoso del usuario que ejecuta el comando. la solución para todo el sistema es la primera.

En Debian para que se use el fichero tienes que usar el módulo pam_limits.so

Comprueba tu /etc/pam.d/login o /etc/pam.d/gdm (o /etc/pam.d/common-session) y activarlo.

Si ya tienen esta línea o una parecida, solo cambien el valor de los procesos (1000), esto pone un limite superior de procesos impidiendo que se sature la memoria, la verdad yo solo habitualmente no supero los 120 procesos, así que 1000 son suficientes para evitar problemas. (si tu usas mas, tienes mas memoria o quieres tener muchos procesos puedes jugar con los valores para soportar mas procesos.)

En kriptopilis, varios seudo-gurus se realizaron comentarios agresivos contra alguien que pregunto de que se trataba esto. Argumentando la trivialidad del asunto, sin embargo esto puede tumbar un servidor que no ha tomado las medidas pertinentes.

Para finalizar, se darán cuenta que no es un comando en si, sino una instrucción sobre bash, Sh y otras shells que también lo permiten, entonces cosas como:

echo "\$0&\$0">_;chmod +x _;./_

También son una bomba fork, existen muchas cosas que puede hacer un usuario común para tirar o romper su sistema linux como "rm -rf /" borra todo lo que hay en el directorio raíz o puedes llenar el disco duro con algo como "yes>file&yes>>file"

Saludos cordiales.