Pues quieren comparar SELinux que es lo que es con OpenBSD que también es lo que es. Los argumentos son de lo mejorcito:

• Es complejo: Vale, no es fácil, aunque distros como Fedora y RedHat creo que tienen asistentes. ¿Tiene OpenBSD algo tan potente? ¿Hasta dónde llega TrustedBSD? Solo hay que buscar un poco por internet para leer preguntas como Does OpenBSD have something similar to the NSA`s SELinux, RSBAC, PaX stack smashing protection, Grsecurity etc? y leer esta joya de respuesta: OpenBSD has a “secure-by-default” approach with focus on security and code correctness. There`s no need for extra addons like SELinux and grsec kernel patches.
• Insinuan, o me lo parece a mi, que APPArmor es mejor que SELinux cuando APPArmor tiene al menos que yo conozca, limitaciones, como que no permite controlar sockets, o que se referencia a los ficheros por su ruta y no mediante labels en el sistema de ficheros (Como si de una ACL o atributo extendido se tratase). Aquí una comparación de ambos.

Os dejo un artículo que me gusta mucho ya que explica muy bien como funciona PaX (Parte de la suite GRSecurity para Linux, que aunque no tenga nada que ver con SELinux, es un elemento más en la fortificación de un sistemas Linux) y W^X de OpenBSD.

Vamos, que en mi opinión no es solamente qué se usa, sino cómo se usa y como de implementa, y en mi opinión Linux ofrece más herramientas para fortificar el sistema que un sistema OpenBSD y quien no quiera ver más allá de la calidad del código en mi opinión no está haciendo una buena evaluación de todo el rol. OpenBSD todos sabemos que tiene fallos. Pocos, pero ahí están y sus paquetes tambien tienen fallos, y los paquetes no son parte del core, luego no son auditados, luego la misma cagada que comete el devel de determinada aplicación de lo que sea en Linux, puede cometerlo en el paquete de OpenBSD (Si lo incluye, claro, y si tiene esa misma versión). Y digo yo… de que sirve tener un sistema base con un muy buen código si luego tu aplicación que escupe html o correo es vulnerable? Creo que es ahí donde entra PaX, SELinux, RSBAC, etc intentando que la explotación de la vulnerabilidad no sea tan fácil de llevar a cabo…

Esa es mi opinión. Un saludo.

Certificado digital de la FNMT en Apache 2.x

Pero ya que pongo este link, voy a poner algún que otro link interesante, que tengo para todos.

Introducción a PaX
Más doc acerca de PaX
Y más aún
Tecnologías en materia de seguridad que aporta Windows Vista
Una buena lectura acerca del DRM en Microsoft Windows

El otro post en un tono, en mi opinión, humorístico, dice que tiene que dejar de lado su necesidad por la cerveza, ya que no puede gastar todo su sueldo en ella, ¡O aún peor! Una hackathon sin ella.

Parece que ha perdido su trabajo por lo que está en el paro. Necesita un nuevo trabajo de 8 horas para tener los suficientes fondos para continuar con el proyecto (OpenBSD).

En este momento he llegado a la confusión total, y es donde necesito aclaraciones. Theo anuncia de forma no oficial un 0 day en OpenSSH. Si leéis el mensaje es una broma, pero luego dice que tiene que ponerse a trabajar, que venderá todo el hardware que tiene para comprarse un portátil nuevo, ya que OpenBSD soportará solamente la arquitectura x86. Esto es alarmante, o podemos tomarlo a broma, pero es en el último post cuando confirma la venta del hardware (Máquinas Sun principalmente) y la compra de un nuevo portátil económico pero nuevo, cuya tarjeta wifi no funciona bajo OpenBSD, y que, aunque esté en contra de ellos, ha recurrido a un blob para hacerla funcionar, ya que el driver de Windows soporta WPA2, y lo utilizará con ndiskwrapper. La tarjeta ethernet funciona, pero no es lo que es esperaba, además necesita la wifi para su trabajo.

¿Es confuso verdad? Un tío tan crítico con los drivers cerrados como Theo, echando mano de un blob (O eso he entendido), el pobre sin curro y por lo tanto sin dinero, y sin poder dedicarle dinero al proyecto. La verdad que es jodido, o quizá lo he entendido yo mal, así que, si no os fiáis de mi, podéis leer su blog, que es muy interesante, en gran parte para conocer qué piensa Theo. Por ejemplo, cambiar Sendmail por Qmail, pero ni de coña por Postfix o Exim, por su licencia (WTF!)

¿Qué ocurre?
Pues que la rama RELENG_6 de CVS de FreeBSD está sufriendo cambios y hasta el 13 de Noviembre (Aproximadamente) no tendremos una FreeBSD 6.2-RELEASE.

Me han jodido, pues ahora tengo que esperar aproximadamente 15 días.

Enlaces interesantes para actualización e instalación de software:
Recompilar el sistema base.
Compilar un kernel.
Usar Packet Filter en FreeBSD.
Uso del sistema de Ports.
Usando el sistema de paquetes.
Jails en FreeBSD.

Una vez arrancamos NUT al completo, ejecutamos knutclient y añadimos un SAI, Su alias, su host y su nombre, además de usuario y contraseña. Luego configuramos a nuestro gusto para dejarlo como nrktk en su captura… o a vuestro gusto. Bueno, yo, al igual que él, pienso instalar 2 SAIs nuevo que me tiene que traer en serie. Uno es un Zaapa de 1000 VA, tonto, como una batería no monitorizable. El otro será un APC de 700 VA, que NUT parece soportar además de tener su propio daemon. La idea es colgar el/los servidores y el firewall, así como el AP y los switches y modems de ambos (1000 y 700 VA) y mi equipo de mi viejo Energy System de 1200 VA.

Como NUT es fabuloso y soporta monitorización por red (Con ACLs, usuarios contraseñas…) y además está disponible en casi todo SO *NIX que os podáis imaginar, puedo instalar los SAIs en el equipo que yo quiera (Tampoco tengo muchas opciones) y monitorizarlo desde el equipo que quiera (¿Desde el mío?). Además cuando mande al sistema apagarse puede retransmitir a sus esclavos que también se apaguen. Como veis, todo son ventajas . Lo haré y lo documentaré, aunque quizá se me adelante nrktk .

Bueno, la aplicación está diseñada para KDE (QT3) y se integra muy bien en el systray. Personalmente me gusta mucho, así que podéis animaros a probarla.

Es una herramienta que hará paquetes binarios de los parches de seguridad de OpenBSD de forma casi automática. Las ventajas saltan a la vista cuando tenemos más de una máquina con este Sistema Operativo instalado y queremos ahorrarnos los ciclos de CPU. Como explica en su web, su uso es sencillo y además crea una lista de los ficheros modificados.

En mi opinión está bien, pero por otro lado, no metería algo externo al sistema base para algo tan crítico como las actualizaciones de seguridad. Prefiero el sistema de toda la vida.

Usando los mismos cilindros de inicio y fin para las particiones, y usando Partimage la migración fue perfecta. Ya está funcionando con su kernel, el único contratiempo es que se me olvidó escribir grub en el MBR, por lo demás perfecto.

Abriré el servidor, lo limpiaré, cambiaré la pasta termina, le pondré más RAM y… me estoy pensando tocarle las frecuencias, pues mis memorias son de 133 MHz y el bus de este micro es de 100 MHz, con un multiplicador de 9. He de decir que no estoy muy seguro, aunque ya lo he hecho varias veces en otras máquinas, digamos que le tengo cierto cariño a esta máquina, quizá porque es el mejor servidor que tengo.

De momento se quedará apagado mientras planifico la instalación del nuevo SO y busco nuevo nombre para la máquina, anteriormente Espiral, pero como que no pega mucho si corre FreeBSD.

• Actualizar el sistema según indica su manual.
• Instalación limpia.

He optado por la instalación limpia por dos razones:

• El método usado para actualizar es, en mi opinión, algo lo sobreescribimos y venga
• Casi todo lo que uso está incluido en el sistema base, excepto Squid. Las configuraciones las guardo mediante scp.

¿Y qué gano con esto?
Pues tengo la última versión del sistema (RELEASE) la cual hay que actualizar a el PATCH BRANCH 3.9 (STABLE) pues desde que salió hasta ahora el sistema base tiene tres vulnerabilidades. Dos referentes a Sendmail y una a XOrg. Si esta máquina estuviese en un entorno de producción no sería viable la reinstalación probablemente, pero como mis configuraciones son pocas puedo apañarme aún y guardarlas.

La verdad hecho de menos 2 cosas en OpenBSD.

• Un RSS para recibir los avisos de vulnerabilidades con un lector de feeds, sin recurrir a listas de correo o visitar la web.
• Un tiempo de vida de la versión mayor.

Mientras he escrito esto he estado actualizando el sistema desde el CD, osea, el método que no iba a usar, pero… ¿Quién dijo que no lo iba a probar?
Digamos que se parece a la instalación. Tras escoger el tipo de terminal que usaremos y el mapa de teclado, nos pide confirmación para actualizar.
Acto seguido nos manda escoger el disco duro que usaremos (wd0), así como el sistema de ficheros raíz (wd0a).
Es ahora cuando nos permite configurar una interfaz de red con la configuración del sistema instalado o asignársela nosotros a mano. Es útil si vamos a hacer una actualización por red.
A continuación nos pregunta si queremos editar el fstab con ed.
Cuando le contestemos que no, como fue mi caso, procederá a comprobar con fsck la correcta integradad de las particiones.

Esta nueva fase de la actualización se parece a la instalación ya que pide el origen de los datos, cuya opción por defecto es CD. A continuación la ruta que por defecto es 3.9/i386 pero como no es una ISO oficial y la hice yo, tendrá que ser i386 a secas.
Esto ya es familiar, nos manda escoger paquetes a actualizar. Yo uso ese sistema por defecto excluyendo el paquete game39.tgz por lo que escribo -game39.tgz, doy intro, escribo done y finalizo.

Nos pide la última confirmación para actualizar y procede a copiar el kernel y extraer los paquetes.

Cuando finalice nos pedirá de nuevo una localización de los ficheros, pero como hemos terminado escribimos done, procederá a crear los ficheros de dispositivo y nos devolverá al prompt con un mensaje felicitándonos por la correcta actualización.

Cuando arranquemos continuaremos con esta guía de pasos finales.

Para actualizar nuestro nuevo sistema podemos leer este manual adaptándolo a la versión 3.9 que supongo no habrá cambiado.

Está en ello, y si os digo la verdad, por no particionar de nuevo y demás lo dejo así.

Esto hace que, lo que un día rastal comentaba que había leído en Kriptópolis acerca de hacer un cortafuegos con caché e inspección de virus, quedé en el olvido. IPCop ya dispone de Proxy caché Squid y ahora con este plugin podemos conseguir mayor seguridad (¿Confiabilidad?) en nuestra red.

En la web mencionan el software utilizado, muy útil si queremos usar algo similar en otro entorno. No estaría de más algo así para los amantes de monowall que creo que no dispone aún de ello.

Desde mi punto de vista respecto al tema de SPAM lo veo muy a la altura pues Spamassassin con las reglas que actualizamos vía RulesDuJour hace que pocos correos se escapen. También usa redes distribuidas que aunque no he oído hablar muy bien de ellas, tampoco las he probado.

Ya sabéis, atentos a la web que explicarán como ponerlo en marcha. Un saludo.