Wolff’s Blog


Tuesday 8 May, 2007

Ataques de DOS para noobs

Hace no mucho tiempo en Kriptopolis aparecía la siguiente noticia en la que alguien supuestamente desvelaba una grave vulnerabilidad que afectaba a todos los sistemas Linux, derivados de Unix, supuestamente desvelada por un “programador del kernel”.
En realidad lo único que desveló fué una Bomba Fork un tipo en concreto de las denominadas Bombas Lógicas que así a lo cotidiano son programas, o trozos de código, que explotan algún tipo de fallo o peculiaridad del sistema a fín de hacerlo inestable o causar algún tipo de fallo en él.

El trozo en cuestión, y de la discordia, es el siguiente:
:(){ : | :& };:

Básicamente, y sin entrar a desgranarlo, se trata de la declaración de una función recursiva que se declara a sí misma. El resultado es fácil de imaginar, si se comprende el concepto de recursividad.
Lanzas la supuesta función, que no hace nada salvo llamarse a si misma y esta se llama a si misma, por lo que tenemos 2 procesos en el sistema, el original y el nuevo. Al finalizar la primera, siguiendo el principio de recursividad vuelve a ejecutarse, creando una nueva función. La segunda, generada por la primera, lanza una tercera, y vuelve a ejecutarse…. así hasta el infinito. Reproduciéndose cada vez a una velocidad más rápida y siguiendo una progresión exponencial. Resultado final, la máquina se satura, ya que tiene un montón de procesos que “no hacen nada” pero que crean nuevos procesos y ocupan tiempo de CPU y memoria, lo que proboca un enlatecimiento de la máquina y finalmente un ataque de DOS en toda regla.

No tardaron en aparecer flames por todo el hilo, con los que quieren atacar a Linux riéndose del “sistema perfecto” y los usuarios medio-avanzados de Linux comentando el motivo de “la vulnerabilidad”. No se trata de una vulnerabilidad, si no de un uso incorrecto de una herramienta necesaria que es la recursividad. Es fácilmente solventable aquí se explica como, y requiere solo un mínimo de atención por parte del responsable de la máquina. Bien es cierto que se trata de un fallo que es extraño que se siga produciendo, es un ataque de DOS conocido desde la noche de los tiempos en cualquier sistema, pero tampoco es nada por lo que haya que criticar a unos ni ponerle la etiqueta de “gran hacker” a cualquiera que lo use, como mucho un script kiddie con suerte.

Equiparar esto a “exploit grave en la seguridad” sería como definir de “virus” un ejecutable de linux que realice un “format C:” o un “rm -rfi /” en un sistema GNU/Linux.

Una de las cosas importantes, y mejores, de Linux es que, con una puesta a punto conveniente, se trata de un entorno muy seguro y estable evidentemente, si el responsable de mantener ese sistema seguro y estable, se dedica a ejecutar cosas así siendo root … apaga y vamonos, se merece lo que le pasará.

Es importante tener un sistema seguro, pero es más importante que el que lo usa sepa usarlo, una cosa es la seguridad informática, y otra, que es cada vez más grande y dificil de controlar, es la estupidez humana.

Si queréis ejecutarlo en un sistema Windows, su equivalente es:
:s
start %0
goto s

Clasificado en: Tecnología, Linux/Unix, Seguridad Informática — Lupin @ 17:19

Thursday 26 April, 2007

Matar Procesos a lo DOOM

Una tarea que se debe realizar muchas veces en Linux/Unix es la de matar procesos. Cuando algún proceso no hace lo que debería, o hace más de lo que debería hay que matarlo, sin piedad. Normalmente se utiliza “kill -9″ o si se trata de algo gráfico xkill, que lo hace mucho más cómodo. No obstante hay gente con mucho tiempo libre y una mente oscura y misteriosa que genera cosas como esta.

DoomKill

Básicamente te ofrece una “interfaz” basada en el juego DOOM para matar procesos. Apareceran todos en una sala, cada uno con su numerito, y tras dispararlos y matarlos como si estubieras en un videojuego estos pasaran a mejor vida en tu sistema, realmente surrealista.

Ya me imagino las conversaciones:

El Apache estaba tocándome las narices así que fuí a matarlo, pero el servidor de MySQL me vió y me atacó por lo que tube que matarlo a él también para salvar la vida. Lo más duro es reiniciar el PC, es un Jefe final de fase y el cabrón es duro de cojones.

El creador describe las siguientes “virtudes”:

  • La carga del sistema se ve a primera vista, un sistema muy cargado presentará numerosas salas llenas de Enemigos.
  • Existe la posibilidad de herir a los procesos en lugar de matarlos, dispararles en una pierna por ejemplo, con lo que los procesos se reiniciaran (al curarse!!!)
  • A cada sysadmin se le otorga un arma en concreto. De modo que los novatos tienen armas poco potentes o deben luchar con las manos desnudas. Los sysadmin importantes deberán ir con un RPG.
  • Sistemas muy cargados se regulan a si mismos. En salas realmente cargadas los enemigos se mataran entre ellos hasta autorregularse (con dos cojones… deja al sistema q se autorregule solo…. que miedo)
  • Acciones drásticas requieren esfuerzo. En la CLI es muy sencillo hacer “rm -rf /*” en cambio aquí realizar acciones como esta implica mucho esfuerzo, los sysadmin se lo pensaran dos veces antes de llevarlas a cabo.
  • Procesos importantes son Enemigos más fuertes, que incluso se defenderan de los ataques del sysadmin, esto alejará a sysadmin novatos de procesos vitales.
  • Los sysadmin podrán colaborar o competir. (simplemente sin palabras a esto…)
  • y los siguientes “defectos”:

  • Algunos procesos son vitales para el sistema. Por ejemplo, justo tras tomar una de las fotos, el proceso CSH fué atacado por otro proceso, “friendly fire” en su intento por alcanzarme. La sesión acabó de forma abrupta.
  • Asociar procesos a enemigos es complicado. ¿Debe reflejarse el tamaño del proceso en enemigos más grandes? ¿Reflejar la carga de memoria? ¿Los procesos hijos, deben parecerse a sus padres pero en versión “mini”?
  • Es complicado convencer a la gente que estas trabajando, y no “matando cosas en un videojuego”
  • La verdad…. rango friki OFF THE CHARTS!!!
    Fuente: Web del autor

    Clasificado en: Frikadas, VideoJuegos, Linux/Unix — Lupin @ 10:40

    Friday 9 March, 2007

    Si Microsoft hubiera creado VI

    Vi, y su sucesor Vim, es un editor de textos muy extendido en la comunidad Unix. Al principio parece complicado, pero cuando le dedicas unos minutos se acaba convirtiendo en algo casi imprescindible. Es facil, potente y presente en casi cualquier máquina Unix (o Linux) que puedas encontrarte en el mundo, por lo que va de perlas para conocer un método “standard” para poder editar ficheros donde y cuando sea.
    En la imagen de abajo se puede ver que habría pasado si VI, o VIM su versión “improved” hubieran sido creado for Microsoft.

    Vim by MicroSoft

    Clipo contraataca, ha vuelto, más grande más fuerte…. y no se va a ir!!!

    PD: Si alguien le interesa, existe una versión para Windows, mucho mejor que el Notepad, de lejos.

    Fuente: meneame

    Clasificado en: Tecnología, Humor, Linux/Unix — Lupin @ 16:50

    Powered by WordPress