inicio mail me! sindicaci;ón

Archive for OpenBSD

Instalando Gentoo 2006.1

Desde hace casi tres años uso Gentoo GNU/Linux como distribución de escritorio. Gentoo goza de una excelente documentación y de un aún mejor sistema de paquetería en lo que a organización se refiere.

Durante todo este tiempo la pega que le achaco es que requiere tiempo.

La idea de Gentoo es construir el sistema desde cero, lo cual requiere cierto nivel de conocimientos y tiempo y paciencia disponibles, pero a cambio da la posibilidad de aprender muchísimo acerca de los internals del sistema.

Aunque en teoría uno no tiene por qué compilar absolutamente todo el sistema sino que uno se puede bajar los binarios ya precompilados, yo aún no he conseguido encontrar binarios para mi arquitectura (Prescott) por lo que me veo obligado a compilar todo paquete que quiero instalar. Compilar emacs, vi, gedit, … bueno, si lo tienes que hacer unas cuántas veces aburre, pero hay paquetes como xorg-server, gcc, gnome y sus dependencias que tranquilamente pueden tirarse más de media hora compilando, y esto en cada actualización del sistema se hace un tanto insoportable.

Si el año pasado me cargué la distribución instalando GNU/Hurd (y trabajando como root cuando no debía acabé sobreescribiendo la libc de gentoo con la libc de Bee GNU/Hurd) este año fue al actualizar portage (el gestor de paquetes de gentoo, como el apt-get o el dpkg de debian) al 2006.1 cuando la toolchain volvió a hacer chof! y desde entonces conté sin la posibilidad de poder compilar programa alguno, y por tanto de instalar nada.

Ha sido ahora en estas vacaciones, tras comprarme un disco duro nuevo, cuando me he decidido a hacer las copias de seguridad esas que siempre hay que hacer y que nunca se hacen y tras ello arramplar con todo lo que había instalado y partir de cero.

Los objetivos eran tener instalado OpenBSD, Solaris 10 (del cuál recibí los DVDs gratuitos que enviaban si los pedías) y varias distribuciones de Linux: una para trabajar habitualmente (Gentoo), otra por si todo falla (Debian) y otras por probar. Respecto a Windows: en la facultad tan sólo voy a verme obligado a usar windows durante este cuatrimestre y un mes el segundo cuatrimestre del año que viene (y para eso puedo emplear otro ordenador o un emulador), no acostumbro a jugar con el ordenador, y además es una fuente de problemas, incompatibilidades, virus y otros disgustos, así que finalmente he decidido no instalarlo. Llevo 3 años sin usar windows, y salvo cuando los colegas me piden que les arregle el ordenador que ya no me acuerdo ni dónde está el panel de control, no tengo mayor problema en apañármelas a diario sin windows.

OpenBSD desde hace ya tiempo me llamaba la atención por estar enfocado a la seguridad y tener ese sistema de desarrollo que a veces he echado en falta en Linux. Quise probarlo y tras comprar el CD de la versión 3.9 al final he conseguido instalarlo. Hay que decir que el fdisk que trae es difícil de usar, de hecho primero instalé Debian en un segundo disco duro y desde allí particioné el primer disco con el fdisk de debian, que es bien cómodo. Salvado ese escollo la instalación fue sencilla y apenás duró diez minutos, esencialmente porque no instala casi ningún programa. Una vez acabada y haciendo uso del sistema de ports (que por cierto, la base de datos de ports no la encontré en el CD) ya instalé más aplicaciones como p.ej. GNU screen. No es un sistema agradable a los sentidos, ni creo que lo pretenda, más bien es un sistema espartano, orientado a la seguridad y a cumplir ese objetivo de ser seguro, no el de ser amigable.

Solaris es software no libre, pero es un Unix bastante usado en servidores y sólo por eso merece conocerse un poquito, al menos probarlo, y ya que me enviaban una copia a casa gratuitamente… (llegaron tres DVDs: Solaris 10 x86, Solaris 10 SPARC y las Developer Tools). Parece ser que no reconoce los discos SATA (tuve un problema similar hace 2 años con FreeBSD) así que trataré de apañar un disco IDE de al menos 20 gb., ya que Solaris es caprichosín, al menos en cuanto a espacio.

Debian: probablemente la mejor distribución de Linux. El sistema de paquetería es cómodo como el de Gentoo (inspirado en los ports de BSD). Fácil de instalar, apenas da problemas. Estrictos con las licencias libres (iceweasel, apache1.3, etc.). Tiene una gran comunidad de usuarios (probablemente sea la distribución de Linux con mayor comunidad), aunque no está tan bien documentada como Gentoo. Creo que daba ciertos problemas el instalador con mis discos SATA, pero yendo sobre aviso lo arranqué sin problemas. Dado que por cuestiones de licencias en Debian no está disponible el firefox original, sino el ice-weasel, que no es capaz de leer los ficheros de contraseñas o el historial del firefox que usaba antes, he decidido instalar firefox por mi cuenta, desde la web de mozilla y prescindir del soporte de Debian en este aspecto, e ídem para thunderbird/ice-dove.

Ubuntu: Traté también de instalar Ubuntu, pero tras bajarme y quemar el CD de instalación me encuentro con que en el particionado, si / no está asignado a una partición primaria para el instalador de Ubuntu 6.10 es como si no se le hubiera asignado partición a /, y en consecuencia se queja y no me deja instalar. Esperemos que Feisty Fawn, que sale en 10 días, resuelva este despiste de programador. Pese a esto la interfaz gráfica de Ubuntu está muy cuidada (aunque Gnome 2.16 en general me ha sorprendido muy gratamente).

OpenSUSE es lo que toca en la facultad cuando toca. Si ocurre el milagro de que allí haya algo que no sea Windows instalado, entonces ese algo es OpenSUSE (a excepción de los Macs con su OS X). Antes estuvo Kubuntu (o alguna otra ubuntu) y antes aún creo que Debian. Lo que me maravillaba de OpenSUSE es la interfaz gráfica, que pese a ser KDE es muy atractiva, incluso antes de arrancar las X, en el inicio, mediante el framebuffer se obtiene una pantalla de arranque realmente elegante. Intenté instalarlo, pero a falta de los cinco CDs o el DVD que no pensaba bajármelos ni loco, me bajé el CD de instalación, e iniciándo esta me encuentro con un simpático cuadro de diálogo que me pide la dirección IP de un mirror de SUSE. Tras reiniciar en Debian y buscarle un mirror (y resolver el FQDN, no siendo que efectivamente quisiera la IP), vuelvo a arrancar la instalación y le meto la susodicha IP y a continuación la ruta dentro del servidor hacia el repositorio de SUSE. En proceso de bajarse root.gz, un fichero de 70 megas que debía contener lo esencial para ir instalando procedo a dormitar la siesta. Y volviendo media hora después pensando en que estaría esperando mis órdenes me encuentro con que se ha quedado atascado a los 20 megas. Así que ahí se quedó. Algún día que me encuentre con ánimo para bajarme el DVD de instalación por mi canuto ADSL lo haré y lo instalaré. Algún día. Mientras tanto, si esto lo lee algún programador de SUSE, que por favor, se le ocurra poner cuanto menos una lista de mirrors en el programa de instalación, y a ser posible que use el servidor de nombres que le devuelve el servidor DHCP, que no me pida la IP.

Otro fallo que le he visto a SUSE cuando hace años la usaba (versión 6.5, 7.2, etc.) es el sistema de paquetes, que no es en absoluto comparable a lo que estoy acostumbrado a ver en otras distribuciones. Es realmente muy incómodo.

Y finalmente Gentoo

Hoy es el quinto día de la instalación :D. Tras las primeras compilaciones, reajustando el USE y recompilando, y buscando errores en el Google, he conseguido mis Xorg corriendo con Beryl (que es flipante, a todo esto). He conseguido tener también un fallo con libexpat, ya que en un inicio estaba la versión 1.95.8 instalada y al actualizar el sistema ha pasado a la 2.0.0, con el consecuente fallo de que los programas enlazados a la 1.95.8 (evince, aMule, etc.) no la encontraban y cascaban. Con un revdep-rebuild (del paquete gentoolkit) parece que poco a poco todos los programas que la enlazaban van recompilándose y reenlazándose de nuevo. Mientras tanto en el proceso alguno se queja de las USE flags con los que alguna que otra dependencia ha sido compilada y toca cambiar las USE flags, recompilar la dependencia y volver a empezar el revdep-rebuild (desde el principio). Por lo menos sólo tiene que compilar 52 paquetes (entre ellos gcc y evolution), al menos el open-office no lo tiene que tocar hasta que no lo instale.

Por cierto, para gentoo usé la guía de instalación rápida. Y rápida es, lo que pasa es que es Gentoo. Y si te pones a hacer virguerías como instalar beryl y luego te pasas a ~x86 y te surgen problemillas pues ya te tiras un rato, y si además andas instalando programas de uso obligatorio (gnome y sus dependencias, el kernel, etc.) al final… lo dicho: cinco días. Pero ya casi casi está del todo.

Como colofón, pongo aquí mi /boot/grub/menu-lst, por si a alguien le sirve de ayuda, especialmente en lo que a arrancar OpenBSD 3.9 se refiere:

default 0
timeout 30
splashimage = (hd0,0)/grub/splash.xpm.gz

#Arrancar Gentoo. Kernel instalado en /dev/sda1 (/boot), el / está en /dev/sda6
title = Gentoo Linux 2.6.20-gentoo-r5 20070408
root (hd0,0)
kernel /bzImage-2.6.20-gentoo-r5.20070408 root=/dev/sda6 real_root=/dev/sda6 vmalloc=300M

#Open está en /dev/sda3, esto es (hd0,2)
title = OpenBSD 3.9
root (hd0,2)
makeactive
chainloader +1

#Debian: kernel y la initrd en /dev/sdb1, sistema (/) en /dev/sda3
title = Debian GNU/Linux 4.0 2.6.18 … 20070406
root (hd1,0)
kernel /vmlinuz-2.6.18-4-686 root=/dev/sdb3 ro bootkbd=es noapic nolapic
initrd /initrd.img-2.6.18-4-686

Absolute OpenBSD: Unix for the practical paranoid

Es el libro que más me han recomendado como introducción a OpenBSD, y en mi caso a los Unix *BSD en general.

Su autor es Michael W. Lucas, autor de una columna llamada Big Scary Daemons en el O’Reilly Report. Autor también de Absolute BSD (publicado también por No Starch Press) y con amplia experiencia en BSD y como administrador de sistemas y redes en general.

Son unas 450 páginas sin contar el índice alfabético, que tratan de explorar a nivel introductorio las capacidades de OpenBSD, y dar una formación básica de cómo instalar el sistema en diferentes entornos y configurarlo para diferentes tareas.

Sin haberlo instalado aún fuera de un emulador y apenas sin haberlo probado este libro me ha permitido ver la enorme potencia que alberga OpenBSD. Se habla ya en los últimos tres capítulos del PF (packet filter) , el firewall de OpenBSD. Enormemente configurable (y mucho más cómodo de hacer, a diferencia de las iptables de Linux) y con unas capacidades que nada tienen que envidiar a las de los kernels de Linux. Es más, cuenta con ciertas opciones de las que Linux carece.

El protocolo TCP (v4 al menos, v6 lo desconozco) mantiene un intercambio de números de secuencia (ISNs) y de reconocimiento en cada uno de los paquetes que se envía dentro de un flujo de datos. La finalidad de este intercambio es dificultar el robo de conexiones o la suplantación de identidad de cliente o servidor. Para ofrecer de verdad seguridad las pilas TCP de los diferentes sistemas debe generar los ISNs de forma aleatoria mediante generadores de números seudoaleatorios (PRNG).

Es de sobra conocido que hay algunos dispositivos tontos (impresoras o scanners en red, etc.) que o bien usan un número constante como ISN o bien a la hora de modificarlo simplemente le suman una constante, de forma que la aleatoriedad es más bien nula. En cualquier caso, el análisis de éstas secuencias de número provenientes de una máquina dada permite saber qué tipo de PRNG ha sido usado, y por tanto qué tipo de máquina, sistema operativo y a veces incluso versión del SO ha entrado en juego. Ésta técnica de análisis es una de las más empleadas a la hora de hacer OS-fingerprinting ([1], [2, 0x0F] y [3]) por programas del estilo de nmap.

Windows al igual que Solaris o Linux o BSD usa números seudoaleatorios, el problema es que el generador de número seudoaleatorios (PRNG) es bastante pobre, por lo que a parte de averiguar que dentro de nuestra intranet hay un servidor Windows, también resta dificultad a la hora de hacer spoofing, p.ej.

PF ofrece la posibilidad, a la hora de hacer NAT/Masquerading con un router con OpenBSD, de reemplazar los ISNs de los paquetes TCP que provienen de la intranet, de forma que un sistema en el exterior pese a analizar las secuencias de ISNs no sea capaz de determinar el sistema operativo real. En su lugar lo que estarán analizando los atacantes son las secuencias generadas por el router, y por tanto por el PRNG de OpenBSD, que no sólo no es el correspondiente al servidor que tenemos en la intranet, sino que además es más seguro que el de Windows. Hasta donde yo sé Linux hoy en día no ofrece esta posibilidad.

OpenBSD es un sistema operativo orientado principalmente a la seguridad. Ya en su página principal presumen de no haber tenido más que dos agujeros de seguridad remotos en la instalación por defecto en los últimos diez años (a costa de venir con más bien poquitos servicios activados por defecto, se discutía esto en Barrapunto hace poco).

Y con tal finalidad cuenta con diverso número de medidas como son el systrace, el propolice, W^X, las pilas no ejecutables y los securelevels. Algunas de ellas compartidas con GNU/Linux.

El systrace es un sistema de políticas de interceptación de llamadas al sistema operativo. Permite interceptar todas las llamadas por parte de un proceso dado a una función determinada, y una vez interceptadas, obrar en consecuencia. Si un día se descubre que el demonio rinetd que tenemos corriendo cuenta con una vulnerabilidad que a un atacante le permite leer el fichero /etc/shadow, digamos con fope(“/etc/shadow”,”r”);, systrace nos permitiría definir una política tal que todas las llamadas de rinetd a fopen con ese argumento fallen y devuelvan NULL en vez de abrir el fichero y devolver un FILE * válido que permita leerlo. Serviría como parche hasta que se publique una nueva versión de rinetd sin ese fallo.

El propolice permite asegurarse de que la dirección de retorno de una función no ha sido modificada y el W^X se asegura de que ninguna página es ejecutable y escribible a la vez, sino que o lo uno o lo otro.

Y finalmente los securelevels: hay 4, desde el -1 (menos seguro) hasta el 2 (más seguro) , y una vez se pasa de uno menor a otro mayor no se puede bajar, salvo reiniciando la máquina. En cada securelevel se ponen en juego una serie de restricciones por parte del sistema operativo.

En el Unix File System (o Fast File System), que es el sistema de ficheros que emplean los BSDs (y Solaris) los archivos, al menos en OpenBSD, pueden tener una serie de flags activadas. Por defecto ningún fichero trae ninguna activada, pero podemos decidir activa el flag schg (system-level immutable flag) sobre un fichero. Esto impedirá que nadie pueda editar, mover o reemplazar ese fichero si no es quitando el flag antes, y para quitarlo hay que ser root, y además de estar en un securelevel menor que 1. Si estamos en el 1 o en el 2, no tendremos más remedio que reiniciar en el -1 o el 0, cambiar el flag y luego ya reiniciar normalmente y proceder.

Como consideraciones finales decir que OpenBSD soporta también varios tipos de ejecutables, a la vez que los suyos propios, soporta la ABI de Linux p.ej., y también alguna más. Me ha dado la impresión de que el sistema operativo, al menos en lo que respecta al manual, está muy bien documentado, y en mi opinión mucho mejor que Linux.

Hay quién dice que es más rápido que Linux. Yo en un análisis el año pasado vi lo contrario, entre Free, Open y Linux el peor parado en cuanto a velocidad era Open, pero teniendo en cuenta las comprobaciones de seguridad que ofrece frente a los otros no es de extrañar. De todas formas todos estos análisis sobre seguridad hay que cogerlos con pinzas, si es que uno se decide a cogerlos (¿tienen gran utilidad? ¿hay gran diferencia de velocidad? ¿compensa usar algo más rápido y más inseguro?).

Así mismo, el libro está un poquito desfasado ya que es del año 2003 y no creo que haya sido revisado mucho desde entonces. Se nota en ciertos capítulos relativos a la instalación y en que se está refiriendo a OpenBSD 3.2 (en mayo saldrá la 4.1, cada 6 meses sale una nueva). No obstante lo recomiendo para iniciarse con OpenBSD.