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.