Sistema de cortafuegos redundantes con OpenBSD y Packet Filter en modo bridge.

Crear una solución de Firewall con los siguientes requisitos:

• Escalabilidad. Con una buena implementación de la pila TCP/IP
• Sin alteraciones a la topología de red. Por medio de un “bridge”.
• Redundancia. Aqui es donde entra (R)STP (Rapid Spanning Tree Protocol).
• Sencillez. Uso de PacketFilter (PF), IPFireWall (IPFW).
• Potencia.

Algunas soluciones serian IPTables en Linux y PF/IPFW en *BSD.

Un punto muy importante es que bajo el sistema operativo Linux, también se tiene soporte para RSTP, por lo que si quieres montar una solución de redundancia, tendrás soluciones para ambos S.O., para proveer este servicio con redundancia. Aunque se tendrá que compilar dicha solución y su rendimiento puede que no sea el óptimo, así que no lo implementéis en entornos de producción sin probarlo en un entorno controlado.

Aunque la seguridad del sistema operativo es mejor la de OpenBSD. Así como soporte para RSTP desde la versión 4.1. Por lo que garantizamos su correcta implementación de dicha solución.

¿Como implementar la redundancia?

• En IP: CARP (Common Address Redundancy Protocol).
• En modo bridge: STP/RSTP.
• Sistema activo/pasivo: pfsync.

¿Qué tipo de HW para dicha solución, bajo OpenBSD?

• CPU: Lamentablemente no se puede implementar, por el soporte nulo a  multiprocesadores. jordi hizo enfasis en este tema, por que la tecnologia esta avanzado y el soporte para estos nucleos esta mermando las implementaciones de OpenBSD por esta falta de soluciones.
• Memoria: Entre más rápida y potencia mejor. ya que hay que compensar por la falta de soporte en CPU.
• Disco Duro:
• NIC’s: em(4) para chipset Intel, bge(4) para chipset Broadcom y sk(4) chipset SysKonnect.
• IRQ’s y bus de datos.

Implementación de la Configuración de Red. Jordi hizo menciono que hay que tener cuidado al momento de declarar las banderas (flags), hay que declarar el protocolo STP (Spanning Tree Protocol) para los puertos de red de em.
Para ahorrarse un dinero en implementar un TAP para sniffers, ahorrense el dinero, ya que por medio de comandos se pueden abrir bocas en el cortafuegos para montar los sniffers que quieran.

Monitorizando el FireWall. 

• Pfstats.
• Pftop.
• Symon.
• Las Clásicas: top, vmstat, ps

Apunto a un manuscrito en la red que habla de la optimizacion de PF. Aqui esta el link.

Una buena platica relacionada a la implementación de una solución para un cortafuegos redundante y los detalles de ejecutarlo.

Jordi manejo muy bien el tema y siempre estuvo abierto a las preguntas del público, asi como a los comentarios sobre soluciones alternativas.

ATF: Sistema de pruebas automatizado para NetBSD

Julio es un desarrollador para de NetBSD (gracias por la correcion Julio ).

El objetivo es probar la corrección y estabilidad de los errores en un sistema operativo. Para garantizar la calidad del sistema.

NetBSD tiene las siguientes características:

• Multitud de Funcionalidades
• Soporte para muchas plataformas

Anteriormente las pruebas que se llevaban acabo son totalmente independientes y el código esta dentro de un Makefile. El problema es que tiene algunas dificultades, como la inconsistencia de las pruebas y que el usuario tiene que compilar el archivo de prueba. Así como la carencia de informes descriptivos de las pruebas.

Dichos aspectos están relacionados:

• Aislamiento y/o ejecución remota.
• Una instalación sin dependencia en las utilidades de desarrollo.
• Por ultimo la automatización. Ya que los desarrolladores no efectuaran esta comprobación, si las pruebas no son automáticas.

Este proyecto surgio por medio del Google Summer of Code del 2007.

¿Que es ATF?

Es una infraestructura de pruebas automáticas, esta integrado en NetBSD.

Sus funcionalidades son:

• Bibliotecas en C, C++ y POSIX shell.
• Tiene una misma linea de comandos y configuración para los programas de prueba.
• Tiene una independencia de las utilidades de desarrollo.

Su estructura esta dividida en:

1. Test Case. Prueba única de funcionalidad.
2. Test Program. Es un conjunto de “test case’s”.
3. Test Suite. Al mismo tiempo es un grupo de “test program’s”.

Cabe mencionar que tiene una estructura de prueba solido y una consistencia en la manera de realizar las pruebas. Ya que se puede configurar el tiempo de ejecución y podemos hacer uso de varias herramientas para probar varios parámetros dentro del comportamiento que deseamos auditar.

Se hizo una prueba en directo y Julio explico cada uno de los pasos que componen las pruebas realizadas, exportando los resultados dentro de la consola y en versión HTML, para poder verlo en cualquier formato que utilicemos. Espero que así como lo explico, este descrito dentro del sitio del ATF.

Obejtivos a futuro:

1. Pasar todo al directorio src/tests
2. distribuir las pruebas por medio de tests-tgz
3. Automatizar pruebas de Kernel.
4. Entrar al Google summer of Code 2008.

Se hablo de PC-BSD, que tiene buen soporte a manera de Ubuntu en Linux.

Asi como tambien DragonFly BSD.

Son algunos sistemas operativos que vienen en un LiveCD y se pueden probar sin necesidad de instalarlos.

Animense a probarlo.

Colabora para la rama core de desarrolladores de España para FreeBSD.

Habla acerca del historial de BSD. Recalca que Darwin por parte de Apple no es FREEBSD.

Habla como el kernel de Linux tomo la delantera, ya que se retrazo en entregar las nuevas.

Menciono a DragonFly BSD. Que es un proyecto que es un fork de FreeBSD. Lidereado por uno de los mejores desarrolladores de BSD.

Toco el tema de Plan9, que es un proyecto por parte de los laboratorios Bell, donde el sistema operativo esta en la red. Que es un sistema operativo en clustering.

Hablo también de como se realizo el evento. Que tiene el objetivo de llevar el nombre de BSD a nivel nacional, hizo el llamado para poder realizar este evento en cualquier parte de España.

Se tiene la iniciativa para traer a presentadores por parte de la fundación BSD, para dar una charla el año que viene. Así como el examen de certificación para este sistema operativo. Para que todos los sysadmin que utilizan BSD, se vayan preparando.

Nota: Aunque un poco nervioso el presentador (cosa que menciono antes de empezar), le felicito por hecharse el clavado y realizar este evento.

En horabuena para todo el equipo organizador.

Y que empiece la función.

¿Qué gama de BSD se adapta mejor para clustering de Correo Electrónico?

• Las respuestas, básicamente si tienes muy claro toda tu arquitectura a nivel de red y servicios (puertos), no debes de tener problemas para instalar un S.O. BSD.
• Depende muchos de las necesidades por parte del cliente, por que hasta Windows puede ir mejor ó Red Hat Linux.

¿Quien implementa mejor el stack IP?

• Todos los sistemas operativos son buenos en la implementación de la pila TCP/IP, depende más en la configuración del servidor IMAP, iptables o PF. Una correcta configuración pueden optimizar considerablemente como el Sistema Operativo gestiona los paquetes.

¿Han recibido apoyo por parte de EuroBSD?

¿A nivel enterprise, se podria migrar un entorno de gama alta?

• Es un poco complicado, por que no hay empresas, ni consultoras que le den soporte a proyectos de migración.
• El soporte de HW para tarjetas de fibra, deja mucho que desear. Ya que hay pocos desarrolladores tienen el tiempo y los recursos para hacerlo.
• Tambien tiene un rendimiento poco fiable para la maquina virtual de Java.

¿Qué sistemas operativos usan?

• 8 -Linux
• 2 – HP-UX
• 10 – FreeBSD.
• 4 – NetBSD.
• 2 – OpenBSD.

Así se cerro el Opening.