Bombas y bombos

Ayer sábado, un usuario de Kriptópolis decidió hacer uso de su legítimo derecho a enviar una nota a los foros, tratando de informar sobre un hecho que le había parecido curioso e intentando recabar más información sobre el mismo.

Aunque su planteamiento no era técnicamente correcto, eso es siempre de esperar en una nota remitida por un usuario a un foro, donde su autor se expresa como su leal saber y entender le permite. Por tanto di curso a la nota, sin imaginar -eso sí- que iba a resultar lo más leído y comentado en Kriptópolis (y con bastante éxito también fuera de aquí) durante todo el fin de semana.

Hasta ahí todo bien. Lo que no resulta de recibo es que algunos comentarios hayan resultado tan prepotentes y chulescos (tranquilos, los más insultantes ni siquiera han visto la luz), primero contra el autor y luego contra el propio sitio, por el intolerable delito de dar cabida y pábulo al post de este usuario...

Entonces, ¿qué se supone que hay que hacer? ¿Cerrar el paso a la nota original, hurtando así la información y el debate al 84% de los lectores que aseguran no conocer el tema? ¿O tal vez editar la nota original para convertirla en un artículo, cambiando las expresiones originales por las del propio editor?

Estoy harto de repetirlo, pero no me importa hacerlo una vez más. Kriptópolis no es un sitio para expertos en seguridad (aunque éstos también sean bienvenidos, sobre todo cuando pretenden ayudar). Su fundador y editor no es un "hacker", ni siquiera un experto en seguridad; es un usuario común, un aficionado a la criptografía y la seguridad que se propuso crear un sitio donde los usuarios comunes como él no fueran despreciados ni vilipendiados por los autoproclamados "gurús" de la seguridad. Donde preguntar no fuera delito. Donde querer saber fuera lo único importante.

A lo largo de estos once años de pequeña historia del sitio he visto nacer (y también morir, y no precisamente de éxito) decenas de sitios sobre seguridad creados por "hackers" y presuntos "gurús" con el único objeto aparente de satisfacer sus egos a base de despreciar a quien no sabe. Si Kriptópolis les ha sobrevivido a casi todos por algo será. No me corresponde a mí explicar el éxito de un sitio creado por un experto en nada y perpetuo aprendiz de todo, pero desde luego pienso seguir dedicando mis fuerzas y escasas habilidades a que los usuarios comunes y corrientes no se sientan vilipendiados ni insultados por el único hecho de querer saber. Lo siento, pero es que tampoco sé hacer mucho más.

Y para predicar con el ejemplo, aparco aquí mi proverbial e incontenible verborrea y en lo que sigue trataré de ayudar a entender y abordar las "bombas fork" a otros usuarios comunes como yo (algo que -por cierto- muchos "expertos" aún no se han molestado en intentar).

Las bombas fork para torpes (como yo)

En primer lugar, y como algunos acertadamente han señalado, una bomba fork no es una bomba lógica, ni tampoco un fallo del kernel, ni mucho menos se trata de algo "liberado por uno de los programadores del kernel". Tampoco es en sí mismo una vulnerabilidad (aunque sí pueda convertirse en alguna rara ocasión en un problema). De hecho en la inmensa mayoría de los casos no tiene ninguna importancia, y no pasa de ser una curiosidad. Ni siquiera cabe -en mi opinión- echar la culpa de su existencia a los responsables de tal o cual sistema operativo o distribución.

Supongamos que utilizas Linux. Cierra todo lo que estés haciendo (es muy probable que tengas que reiniciar el equipo), arranca un terminal y teclea el siguiente "comando":

:(){ :|:& };:

En bastantes distribuciones Linux se desencadenará tal avalancha de procesos que el sistema acabará colgándose. ¿Decepcionado, no? Tu Linux tumbado por un solo "comando", sin necesidad siquiera de ser root.

Afortunadamente, si lo piensas bien el asunto no hará ganar a Linux un concurso de popularidad, pero tampoco es grave. En primer lugar, cualquier usuario de una máquina de escritorio puede encontrar una forma de tumbarla (sí, también en Windows ;) pero hay que ser un poco estúpido (o estar experimentando, como nosotros ahora) para "suicidarse" así. No obstante, si los resultados de la prueba no te han resultado agradables, puedes hacer algo para que no te vuelva a ocurrir.

Busca y abre el fichero /etc/security/limits.conf de tu distribución. Al menos en Arch viene perfectamente documentado, conteniendo explicaciones detalladas (en inglés, sorry) sobre cómo adaptarlo a tus necesidades. Como puedes ver, las posibilidades de configurar tu máquina en este sentido son bastante amplias. Pero al grano: ¿qué hay que cambiar y cómo? Yo tenía en marcha un monitor del sistema (Gkrellm) cuando efectué el test, y pude ver que los procesos superaban ya los 4.000 cuando el sistema se colgó. Por tanto, cabe deducir que cualquier cifra que impida que los procesos en marcha alcancen los cuatro mil resultará segura. Sin embargo he ido mucho más lejos: si en mi trabajo normal tengo unos cien procesos en marcha, con un tope como 1.000 (y también con mucho menos) creo que estoy más que seguro frente a una avalancha que acabe con el sistema. Por tanto, añado al fichero en cuestión la siguiente línea:

*    hard    nproc    1000

Cierro el fichero y vuelvo a probar el test (yo antes reinicié, pero no creo que sea necesario). Perfecto: la cuenta de procesos sube hasta 1000 y para. Tecleo un Ctrl-D y compruebo que tengo el control total. En definitiva; ya soy inmune a una bomba fork... lo cual no es una gran cosa, porque lo único que he hecho ha sido protegerme... ¡contra mí mismo!

El asunto puede pintar peor si en vez de un ordenador de escritorio que sólo utilizo yo, se trata de un servidor o un sistema multiusuario. En ese caso un usuario local (no root) también podría echarlo abajo... a no ser que el administrador hubiera tomado antes las medidas oportunas, que es lo que debe hacer. No cometeré el atrevimiento de decirle a todo un señor administrador cómo debe configurar su sistema, por más que me conste que muchos de los que desempeñan esa función no tiene la menor idea al respecto. Para estos últimos sólo una pista: ningún usuario local debería ser capaz de ejecutar una bomba fork desde su terminal, y usted dispone de medios para crear un perfil seguro por defecto para sus usuarios.

Si disponemos de abundante tiempo que no sabemos a qué dedicar, podemos comenzar ahora una interminble discusión sobre qué distribuciones (o sistemas) vienen mejor o peor configuradas por defecto frente a bombas fork. Pero como el tiempo no nos sobra a ninguno baste decir que al usuario normal de un desktop todo esto le resulta indiferente, si bien arriba le hemos explicado cómo prevenirse "contra sí mismo" ;).

Ahora sí es el momento para complementar, mejorar o rebatir las palabras del ignorante que esto suscribe.