Hoy en día es muy común la escalada de privilegios en sistemas GNU/Linux debido a diferentes fallos  de seguridad que se descubren en el kernel de linux. Sin embargo existe una herramienta  llamada NINJA que nos permite  detener y prevenir este tipo de ataques, monitoreando toda la actividad de los procesos locales y además guardando un log con la informacion de todos los procesos ejecutados como root. Adicionalmente Ninja puede matar todo aquel proceso que haya sido creado por usuarios no autorizados.

Ninja actualmente se encuentra en la versión 0.1.3 y se instala desde los repositorios.

apt-get install ninja

La configuración de NINJA consta de   el archivo de configuración  y un archivo llamado whitelist donde se almacenaran los ejecutables el grupo y los usuarios que podrán correrlos, estos dos se encuentran en la carpeta /etc/ninja. Adicionalmente debemos crear un archivo que guardara el log de nuestra herramienta, para esto hacemos lo siguiente:

touch /var/log/ninja.log
chmod o-rwx /var/log/ninja.log

Ahora creamos un grupo llamado ninja(por favor tomen nota del GID):

addgroup ninja

El siguiente paso consiste en agregar nuestro usuario y el usuario root al  grupo que acabamos de crear:

usermod -a -G tusuario
usermod -a -G root
usermod -a -G messagebus

Editamos el archivo de configuración:

gedit /etc/ninja/ninja.conf

Buscamos las siguientes lineas y hacemos los cambios respectivos

group= GID -> aquí debe ir el GID que guardaste cuando creaste el grupo ninja
daemon=yes
interval=0
logfile=/var/log/ninja.log // asegúrese de quitar el # del comentario
whitelist=/etc/ninja/whitelist
no_kill = no
no_kill_ppid = no

El turno es para la lista blanca abrimos el archivo  y borramos la linea de SUDO ya que en Debian no se utiliza, quedaría de esta forma:

/bin/su:users:
/bin/fusermount:users:
/usr/bin/passwd:users:
/usr/bin/pulseaudio:users:
/usr/sbin/hald:haldaemon:
/usr/lib/hal/hald-runner:haldaemon:

Por ultimo agregamos  ninja al inicio, adicionamos la siguiente linea en el archivo /etc/rc.local:

/usr/sbin/ninja /etc/ninja/ninja.conf

Solo nos queda reiniciar  y probar que nuestro ninja este funcionando como debería.

Haciendo una pequeña prueba

Después de reiniciar, y ver que ninja se esta ejecutando haremos una pequeña prueba:

Cuando detecta un proceso prohibido:

Cabe resaltar que es fundamental leer toda la documentación del paquete ya que pueden haber configuraciones diferentes para cada situación y sistema. Recordemos que  en el campo de la seguridad, no solo basta con instalar la aplicacion sino que también es importante personalizar la configuración, es decir, evitar las configuraciones por default.

Mas Información:
Pagina Oficial del NINJA

Fuente: www.dragonjar.org

Google es probablemente la organización en donde está corriendo la mayor cantidad de sistemas Linux.  Gracias a este sistema operativo fue posible crear un esquema de trabajo distribuido y a la medida que fuera suficientemente independiente para permitir convertir una tesis en lo que hoy es Google.

Pero hasta hace poco, no se sabía mucho de qué uso y qué tipo de problemas encontraba Google en su intensivo uso de Linux.  Digo hasta hace poco porque en el reciente Kernel Summit realizado en Japón, Mike Waychison de Google asistió para exponer a los principales hackers del kernel, el uso que este gigante informático le da a Linux.

Google usa un sistema de control de versiones del software bastante arcaico para lo que está acostumbrada la comunidad del código abierto, lo que provocó risas en los asistentes.  Se trata de Perforce, y en comparación a nuevos sistemas como Git, tiene limitaciones o modos de trabajo que uno jamás pensaría que tendrían en Google.  No es de extrañar el interés despertado en los asistentes a la presentación que hizo Linus Torvalds sobre Git en Google hace un tiempo atrás.

Y eso es sólo el comienzo, ya que Google maneja versiones bastante atrasadas de Linux.  Alrededor de 30 ingenieros trabajan sobre una única base de código, aplican cambios y aproximadamente cada 18 meses sincronizan su propia versión con una versión pública de Linux.  Al ritmo que se desarrolla el kernel, la cantidad de cambios acumulados en todo ese tiempo lo convierten en una tarea titánica.

Es tanto así, que muchas de las lineas de código que Google agrega a su propia versión son funcionalidades que se han implementado en Linux pero que no existían en la versión que usaron como base. Así sucedió por ejemplo con el soporte de 64-bit y el soporte de SATA.  Actualmente se están preparando para mezclar con 2.6.26, mientras que la versión pública ya se acerca a 2.6.32.  Los cambios de Google serán aproximadamente 300.000 líneas de código en donde un 25% corresponde a backports de nuevas características.

El código es horrible
Linus Torvalds quien obviamente estaba presente y no fue sólo a sacarse fotos a Japón, preguntó por qué Google no aplicaba sus cambios al kernel público.  Mike respondió que el código era bastante horrible y basado en versiones antiguas de Linux, además de que no tenían seguridad de que los cambios aplicados por ellos tuvieran alguna utilidad para otros y que probablemente sólo la mitad de éste sería publicable.  Hay que recordar que licencias como GPL no obligan a publicar el código que se usa internamente, por lo que Google está en su derecho de no publicar sus cambios.

Otro aspecto importante es que los estándares para aceptar código en el kernel son bastante altos, por lo tanto un cambio que Google puede hacer rápidamente se convertiría en un proyecto de largo o mediano plazo al entrar en un proceso más exigente como es el desarrollo de Linux.

Mike también habló de uno de los aspectos críticos del kernel para Google, que es la forma en que se ejecutan los procesos.  En un sistema multihilos como Linux, existe un componente que se encarga de decidir qué proceso usará la CPU en un momento determinado, este componente se llama scheduler o planificador.

Para Google se trata de un componente en donde los cambios tienen un alto impacto, ya que en sus sistemas corren unos 5000 hilos en 16 a 32 cores, mientras que en el equipo de Linux este aspecto se ataca con criterios de diseño que apuntan a un uso más tradicional.

En general Google aplica varios cambios a medida que los necesita, en forma independiente a cómo se implementan en el kernel, hasta que llega el momento de cambiar de versión. Según los asistentes, esta participación en Linux Summit fue bastante productiva ya que se puede decir que la comunidad aprendió mucho de uno de sus principales y extremos usuarios.
Link: How Google uses Linux (LWN.net)

Autor: Franco Catrin
Fuente: Fayerwayer

Hoy a la tarde estaré viajando a Salta para ir a las jornadas de software libre(en la UNSA) que comenzaron el Jueves(sí lo sé, un poco tarde pero bue… ), y me quedo hasta el domingo, el que asista a la misma podrá encontrarme por esos pagos, solo tiene que preguntar por mi o ver al horizonte y el que este bailando como si de un ritual aborígen se tratara… ese soy yo .

Un abrazo gigante a todos!

Luciano Laporta Podazza

De la mano de un querído amigo Facundo de la Cruz me llega esta noticia, cito con sus palabras:

Tenemos planeado integrar la cultura libre bastante fuerte al evento, de
manera que sea mas abierto y participativo a la comunidad en general,
pero va a tener detalles técnicos muy fuertes también.
Apuntaremos entre otros temas al cooperativismo y al software libre como
factor de desarrollo humano.

El lugar casi 100% seguro va a ser la Universidad Nacional de San Luis.

Las Jornadas Regionales de Software Libre son un evento regional, internacional e itinerante donde diferentes actores de la comunidad trabajan para integrar proyectos, lanzar nuevas ideas y superar los límites de los programas que utilizan.

Las Jornadas del 2010 será la décima edición del evento, que ya se ha realizado en Argentina, Uruguay y Chile. Y la sede elegida fue la ciudad de San Luis, Argentina.

(continue reading…)

Con Katana un conjunto de distribuciones de seguridad y herramientas agrupadas en una sola distribución arrancable en USB. Katana es la mejor opción para tener a mano herramientas que pueden servir para: test de penetración, auditoria, romper contraseñas, análisis forense y Honeypots.

Katana incluye las siguientes distribuciones y herramientas:

• Backtrack 4 pre.
• The Ultimate Boot CD.
• Organizational Systems Wireless Auditor (OSWA) Assistiant.
• The Ultimate Boot CD for Windows.
• Got Root? Slax.
• Ophcrack Live.
• Damn Small Linux.
• Damn Vulnerable Linux.

Instalación de Katana.

Es necesaria una memoria USB de 8GB con 6GB de espacio libre. Y después seguir los siguientes pasos:

1. Descargar el archivo “katana-v1.rar” y descomprimirlo.
2. Crear una carpeta de nombre “boot” en el USB y copiar en ella los archivos descomprimidos.
3. Hacer arrancable el USB. En Linux ejecutar el script “boostinst.sh” de la carpeta boot y en Windows ejecutar “boostinst.bat” de la carpeta “boot”.

Más información de Katana:
http://www.hackfromacave.com/katana.html

Descargar Katana:
http://mirror.cc.vt.edu/pub/katana/katana-v1.rar

Fuente: Guru de la informatica