Diez distribuciones Linux ligeras para uso en netbooks, equipos poco potentes y obsoletos (Revisión Enero 2011)

Buenas,

Hace casi 5 años (se dice pronto) publiqué una relación de 10 distribuciones Linux para usar en equipos poco potentes y obsoletos. Es uno de los artículos del blog que mas repercusión ha tenido a lo largo de estos años, y me enorgullece comprobar que todavía a día de hoy llegan enlaces de sitios que se hacen eco del texto original.

Creo que después de este tiempo merecía la pena revisar el listado, echar un vistazo al panorama actual actual y volver a escribir una versión actualizada, con la idea de traer a la palestra nuevas ideas para nuestros equipos poco potentes y/o obsoletos, así como para nuestros netbooks, que no eran excesivamente populares cuando redacté el artículo original :)

Los criterios para incluir las distros, en esta ocasión, han sido principalmente los los siguientes:

  • Que sean distribuciones especialmente dirigidas al escritorio, no entrando aquí otras distribuciones ligeras de seguridad, forenses, de recuperación y gestión de sistemas operativos que existen en la actualidad
  • Que se trate de productos que tengan pocos requisitos a la hora de ser empleadas en equipos obsoletos y poco potentes (especialmente en lo que a RAM y tamaño en disco se refiere) aunque alguna tiene requisitos más elevados de disco, siendo más aconsejables para netbooks
  • He procurado incluir distribuciones que sean recientes en el tiempo, de modo que sea mas fácil encontrar soporte
  • Dentro de lo posible, he intentado mencionar proyectos que no se recogen en el artículo original, aunque alguno sobrevive y sigue presente en este top ten actualizado

ANTES DE COMENZAR: LEER CON ATENCIÓN

Antes de instalar y usar los productos que aquí se mencionan, aseguraos que están soportados debidamente para vuestras necesidades, especialmente si vais a usarlos para conectar a Internet. Algunos de estos productos son estáticos (son imágenes ISO empaquetadas), y no siempre a la hora de descargar tendremos disponibles las últimas versiones, con lo que es probable que contengan software vulnerable. Es por tanto recomendable escoger alguno que esté soportado y que podamos actualizar periódicamente, especialmente tras la primera instalación, salvo que vayáis a ejecutar estas distribuciones en equipos totalmente aislados de cualquier tipo de red, en cuyo caso el estado de actualización no es tan acuciante (aunque siempre recomendable)

1. Tiny Core Linux

tiny core linux

  • Web: http://tinycorelinux.com
  • Tamaño del fichero ISO: 11 MB
  • Última versión: Diciembre 2010
  • Comentario: Absolutamente impresionante. Un escritorio funcional en apenas 10 MB, con kernel 2.6, Busybox, Tiny X y FLTK. Es de lo mejor que he visto. Tiene un gestor de aplicaciones con el que podremos instalar comodamente un navegador (que no viene de serie) y cualquier aplicación para usar el producto para la actividad diaria en Internet. Tremendamente rápida para cargar, consume muy pocos recursos

2. SliTaz

slitaz

  • Web: http://www.slitaz.org
  • Tamaño del fichero ISO: 30 MB
  • Última versión: Marzo 2010
  • Comentario: Funciona con kernel 2.6.30.6. Extremadamente rápida cargando y es funcional a partir de 16 MB de RAM, siendo recomendables 192 MB. Viene con el navegador Midori listo para ser usado

3. Damn Small Linux

damn small linux

  • Web: http://www.damnsmalllinux.org
  • Tamaño del fichero ISO: 50 MB
  • Última versión: Noviembre 2008
  • Comentario: Otra de las distribuciones ligeras clásicas, en este caso, basada en Knoppix. Concebida como una distribución para ser grabada en CDs de formato tarjeta, es plenamente funcional en un equipo 486DX con 16MB de RAM. Viene con Dillo, Firefox y Netrik como navegadores, así como con otras aplicaciones de productividad. Rápida en la carga y generosa con los recursos

4. Austrumi

austrumi

  • Web: http://cyti.latgola.lv/ruuni/
  • Tamaño del fichero ISO: 121 MB
  • Última versión: Enero 2011
  • Comentario: Dicen de Austrumi que es la distribución más rápida con soporte 3D NVIDIA y tarjetas Intel. Originalmente orientada la comunidad de Letonia, aunque soporta idioma inglés, usa fvwm como gestor de ventanas, tras haber pasado por Enlightenment y Metacity. Empieza a ser funcional en un equipo Pentium II con 128 MB de RAM

5. xPUD

xpud

  • Web: http://xpud.org
  • Tamaño del fichero ISO: 64 MB
  • Última versión: Enero 2010
  • Comentario: Básicamente, es un Firefox OS acompañado de un editor de texto, un reproductor de vídeo y música, un cliente BitTorrent y un editor de imágenes. Está pensada para netbooks, aunque es posible usarla en equipos más obsoletos. Un interfaz sencillo, muy amigable y que puede ser actualizado con el gestor de aplicaciones opt-get. Extremadamente rápida en la carga. Se conforma con 256 MB de RAM y 64 MB de espacio en disco

6. Puppy Linux

puppy linux

  • Web: http://www.puppylinux.com
  • Tamaño del fichero ISO: 126 MB
  • Última versión: Enero 2011
  • Comentario: Cuenta con JWM como gestor de ventanas, y puede ser usada para netbooks y equipos más obsoletos. Viene con bastantes aplicaciones instaladas, entre las que destaca SeaMonkey como navegador. Empieza a ser funcional en un Pentium 166MMX con 128 MB de RAM

7. Slax

slax

  • Web: http://www.slax.org
  • Tamaño del fichero ISO: 200 MB
  • Última versión: Junio 2009
  • Comentario: Una de las clásicas. Esta basada en Slackware, y ofrece un rendimiento excepcional. Emplea Linux 2.6.24 y gestor de ventanas X.org + KDE 4.1. Dispone de varios sabores distintos y una amplia lista de módulos para personalizar la distribución. A partir de 144 MB y arquitectura i486 o superior, Slax funciona sin problemas

8. Elive

elive

  • Web: http://www.elivecd.org
  • Tamaño del fichero ISO: 690 MB
  • Última versión: Marzo 2010
  • Comentario: Es una de mis distribuciones favoritas, ya que combina la solidez de Debian con un escritorio Enlightenment 17 realmente agradable de utilizar. Opera a partir de 128 MB de RAM y con un mínimo de 100 MHz de CPU. Habida cuenta que requiere en torno a 3 GB en disco, quizás es más recomendable para netbooks que para equipos obsoletos. Viene con una buen número de aplicaciones, y está lista para ser usada en Internet

9. Xubuntu

xubuntu

  • Web: http://www.xubuntu.org
  • Tamaño del fichero ISO: 632 MB
  • Última versión: Octubre 2010
  • Comentario: Basada en Ubuntu, con las ventajas que ello conlleva a la hora de soportarla. Utiliza Xfce como escritorio, en tremendamente sencilla de utilizar y se conforma con 333 MHz de procesador, 128 MB de RAM y 2 GB de disco. Firefox, Pidgin … está lista para ser usada en red

10. NimbleX

nimblex

  • Web: http://www.nimblex.net
  • Tamaño del fichero ISO: 99 MB
  • Última versión: Julio 2008
  • Comentario: NimbleX tiene dos versiones ligeras: una edición SUB100MB, que ocupa apenas 99 MB, y una versión reducida de esta, que ocupa 69 MB y que no soporta multimedia ni GTK, pero conserva el escritorio KDE. Kernel 2.6.33 con squashfs y aufs2. Repleta de aplicaciones: Gimp, VirtualBox, Firefox, Transmission, GParted en un agradable escritorio KDE 4

Espero que la recopilación os sea de utilidad. Existen muchas más distribuciones de este tipo, y más que irán apareciendo habida cuenta de la proliferación de equipos poco potentes, como los netbooks. Si queréis dejar un comentario hablando de alguna otra distribución ligera que utilicéis o conozcáis, o para corregir alguna errata en el texto, no dudéis en hacerlo :)

Un saludo,

Análisis de volcados de núcleo colapsado (Kernel Crash Dump) y volcados de procesos en ejecución en auditorías de sistemas Unix

Hola,

Aunque no es un tema estrictamente relacionado con la seguridad, ya que los colapsos de núcleo pueden tener otros disparadores como por ejemplo el desarrollo y la depuración, quiero compartir con vosotros estas notas sobre cómo analizar este tipo de volcados. Como parte de la explicación veremos igualmente la potencial necesidad de estudiar estos volcados en una auditorí­a de un sistema de producción Unix. Llamaremos a estos eventos de colapso Kernel Crash Dump (KCD), ya que en la literatura es frecuente que se respete la acepción anglosajona original.

¿Por qué analizar KCDs?

Una de las grandes ventajas que ofrecen los núcleos derivados de Unix es la posibilidad de modificarlos para que, en un evento catastrófico, como por ejemplo pánico en el núcleo (kernel panic) salvemos una copia de la memoria. A muchos os sonará el término core dump, o volcado del núcleo, que no deja de ser una grabación de la memoria en el momento del evento catastrófico. Esto se hace fundamentalmente para habilitar una traza que permite detectar problemas, algo especialmente útil en el desarrollo de aplicaciones y complementos para el sistema y del propio sistema, pero también pueden tener utilidad para investigaciones de seguridad.

Los volcados de núcleo suelen estar relacionados con errores en el desarrollo, pero también es factible que se provoquen por la acción maliciosa de los usuarios del sistema. Generalmente, en caso de este segundo hipotético escenario, los volcados catastróficos pueden ser provocados de manera no intencionada, por ejemplo, al tratar de modificar un componente del sistema de manera maliciosa cometiendo algún error relevante que lleve al núcleo a un estado de pánico, aunque es igualmente factible que el estado sea inducido de una manera controlada, no sólo para el núcleo completo, sino para determinados procesos. Afortunadamente estos casos son enrevesados, requieren un conocimiento elevado y no suelen ser frecuentes, siendo mucho más frecuente la grabación de volcados legí­timos que luego quedan a merced, por una pobre configuración de seguridad, de los usuarios del sistema, los cuales pueden acceder a ellos y obtener datos especialmente sensibles.

Dejando atrás las implicaciones en la seguridad, las razones usuales para inspeccionar volcados son, principalmente, debidas a problemas que requieren depuración y análisis. Ejemplos usuales son sistemas que no responden adecuadamente, kernel y aplicaciones lentas, acceso constante a disco duro, fallos catastróficos, etc.

¿Cómo se analiza un Kernel Crash Dump (KCD)?

Aunque existen numerosas herramientas quizás la más completa sea crash de Redhat. Es ventajosa por múltiples razones, la primera es que permite el análisis de sistemas en ejecución, así­ como sistemas accesibles en red. También permite el análisis estático de volcados obtenidos con Kdump, makedumpfile, Diskdump y otras facilidades similares, incluyendo volcado s390/s390x incluso en entornos virtualizados (xendump). Desde el punto de vista técnico crash resuelve las limitaciones de utilizar gdb sobre /proc/kcore, especialmente la dificultad de acceder a la totalidad de la estructura del kernel si el fichero vmlinux se ha construido con determinados flags. Tampoco conviene olvidar que a veces el acceso a /proc/kcore es limitado dependiendo del entorno que estemos estudiando, con lo que quizás no sea la mejor fuente para obtener un volcado. Estas y otras razones han convertido a crash en prácticamente un estándar de facto en el análisis de volcados.

Los requisitos par analizar un KCD

En el caso de crash la utilidad puede ser lanzada en un sistema en ejecución, y hará uso de la memoria (/dev/mem) o incluso, en sistemas Red Hat y derivados, del dispositivo /dev/crash dispuesto al efecto. De todos modos no es normal realizar análisis en sistemas en ejecución, ya que habitualmente si están en ejecución es porque no presentan problemas, siendo mucho más usual proporcionar a la utilidad un fichero de volcado procedente de un sistema que ha sufrido un evento catastrófico que requiere estudio.

Para la obtención de un volcado destacamos Linux Kernel Crash Dump (LKCD), ya que producir un colapso en el núcleo no es, por motivos obvios, una funcionalidad innata del sistema. En este modo de operación son necesarios siempre dos componentes: un fichero vmlinux construido con los flags -g C (para que contenga los datos de depuración necesarios) y un volcado del kernel.

Nótese la diferencia entre los ficheros vmlinux y vmlinuz. En la mayorí­a de sistemas sólo estará presente el segundo, que es una versión comprimida y ejecutable del primero. Si vais a usar crash aseguraos de tener la versión descomprimida o de lo contrario la utilidad arrojará un mensaje del tipo cannot find booted kernel — please enter namelist argument. Sin vmlinux no es posible ejecutar crash sobre /dev/mem ni con ficheros de volcado. Aunque es factible realizar la descompresión manualmente, tened en cuenta que no es inmediata y que suele ser mucho más fácil recompilar el núcleo para disponer de ambas versiones.

Una vez se disponga de los requisitos comentados, se puede lanzar crash para efectuar el análisis. Si queréis conocer más de esta utilidad, podéis leer el documento http://people.redhat.com/anderson/crash_whitepaper/.

Analizado volcados de procesos

Lo descrito anteriormente tiene, desde el punto de vista de la seguridad, una gran problemática asociada. Los volcados del núcleo contienen absolutamente todo lo que estaba en ejecución, y por tanto son una fuente jugosa de información, pero quizás excesivamente abundante, lo que puede dificultar encontrar información. Adicionalmente, para tener un fichero de volcado hay que o bien inducir un evento de colapso (lo cual no es tan sencillo como parece), o bien esperar a que el sistema, de manera natural, colapse para que las utilidades que hayamos dispuesto graben la memoria del núcleo, si es que estas utilidades están instaladas. Esto, en un sistema Unix bien depurado no es algo que pase todos los dí­as. Incluso teniendo lo necesario no es trivial ahondar en las cadenas de texto de un volcado para localizar, por ejemplo, contraseñas, ya que no vienen marcadas como tal.

Para resolver este problema es posible recurrir, en vez de a la grabación e inspección completa del núcleo, al forzado de colapsos en determinados procesos. Estos son mucho más silenciosos y los ficheros a analizar son mucho más pequeños y nos permiten localizar información relevante de una manera más compartimentalizada. Para obtener volcados de procesos en ejecución existen múltiples opciones, si bien gcore facilita la tarea enormemente.

El análisis de procesos tiene sentido, una vez más, desde el punto de vista del desarrollo. Desde la oṕtica de la seguridad tendrá sentido cuando querramos determinar si los volcados que se puedan estar ejecutando pueden quedar a merced de los usuarios del sistema. Que nadie espere encontrar contraseñas en el volcado de un proceso SSH o FTP, ya que lo máximo que hallará son llamadas a PAM, con lo cual el escenario tí­pico de revelación de información sensible será aquel en el que se realicen volcados legí­timos de procesos que luego pueden ser accedidos por terceros a consecuencia de una pobre configuración de seguridad. Pongamos un par de ejemplos. En el primer caso vamos a capturar un volcado de un proceso Skype:

forensics

Una vez obtenido, investigamos las cadenas y buscamos, siendo inmediato encontrar información sensible. Además de la contraseña, que lógicamente aparecerá en el volcado, en este caso obtenemos los teléfonos de los contactos del usuario:

forensics

Este ejemplo es perfecto para volver a la utilidad de los volcados desde la óptica del desarrollo y de la seguridad. Si el usuario que invoca el volcado es el mismo que tiene abierto el proceso, es obvio que desde la óptica de seguridad no hay problema alguno, ya que yo sé mi contraseña y sé a quien tengo agregado en Skype como contacto. Este volcado será útil para mí­ para analizar hipotéticos problemas técnicos, pero poco más. Sin embargo, ¿qué sucederí­a si yo ejecutase regularmente estos volcados con una tarea cron y los estuviera volcando en un recurso local o de red al que tengan acceso otros usuarios? Evidentemente se genera un problema de seguridad, ya que estoy facilitando a terceros el acceso a mis datos sensibles. Otro ejemplo con Thunderbird:

forensics
forensics

Conclusiones

Estos ejemplos sirven perfectamente para ilustrar la necesidad, en una auditorí­a Unix, de entender si existen volcados totales o parciales y dónde se almacenan. Estos volcados, útiles y frecuentes en el desarrollo y optimización de sistemas, pueden provocar problemas de seguridad si no se gestionan adecuadamente.

Estos ejemplos también deben hacernos plantearnos los alcances de las auditorí­as. Yo soy el primero que no suelo conceder mucha importancia a los volcados, ya que como se ha visto son aspectos técnicos muy concretos que no siempre están presentes, con lo que los riesgos pueden ser inexistentes si no se producen, o poco relevantes si se producen de una manera controlada. No obstante, en un sistema crí­tico de producción, donde existan datos verdaderamente relevantes, siempre dedico 5 minutos a comprender si existen volcados y cómo se gestionan.

Un saludo,