Experiencia

A lo largo de la trayectoria de RedKlee hemos realizado proyectos en empresas de primera línea que han permitido resolver requerimientos de diversa complejidad técnica. Se detallan en esta sección algunos de ellos, que brindan orientación acerca del perfil de soluciones y servicios que ofrece la empresa.


Concentrador de VPN

Generalidades

El cliente utilizaba una solución de código abierto de VPN basada en OpenVPN, pero requería disponer de herramientas de administración utilizables por personal no especializado y generar un mecanismo más seguro de distribución de certificados.

Alternativas

  • Agregar las funcionalidades requeridas desarrollando una interface amigable a la solución ya establecida de código abierto
  • Utilizar un solución cerrada basada en IPSec en un concentrador de VPN Cisco Pix
  • Utilizar el producto OpenVPN Access Server

Se descartó la solución IPSec por la variedad de redes a las que se necesitaba tener acceso y por la probada capacidad de OpenVPN de manejar vínculos con mala conectividad o cortes/recuperaciones de éstos.

Si bien era prácticamente posible desarrollar una interface a la solución se consideró que era más conveniente implementar una solución basada en OpenVPN Access Server, que si bien no es de código abierto, está desarrollada por el mismo grupo que desarrolla OpenVPN, tiene una interface de administración amigable y un costo muy razonable.

Además cuenta con un mecanismo para hacer el download de los certificados de VPN a través de una página https.

Sin embargo, dado que este download de certificados puede hacerse con solo contar con un login y contraseña válidos, se consideró no suficientemente seguro este mecanismo.

Por esta causa, se desarrolló una interface Web de administración de download de certificados que habilita a una determinada dirección IP a hacer el download solo por un período predeterminado.

Conclusión

Este es un ejemplo de una solución que podría en teoría haberse resuelto por un espectro de alternativas, que vá desde lo totalmente propietario hasta lo totalmente código abierto. Se eligió una alternativa intermedia. Un producto basado en software de código abierto, pero con partes propietarias y el desarrollo de una interface agregada que el producto no contemplaba, pero que en conjunto se logra exactamente la funcionalidad requerida.

Firewall Alta disponibilidad

Generalidades

Se requirió actualización de una estructura ya existente de firewall desarrollada a partir de OpenBSD dotandola de una interfaz de Administración amigable y nuevas funcionalidades.

Los detalles de la anterior solución OpenBSD se pueden consultar aquí

Era necesario mantener las funcionalidades siguientes:

  • Configuración Alta Disponibilidad
  • Disponer de contingencia para los servicios entrantes y salientes.
  • Permitir que las reglas de firewall se adapten a cambios de IP de los servers externos.

A su vez se agregan:

  • Contar con una interfaz de Administración amigable, donde no fuera necesario el uso de la línea de comandos.
  • La interfaz debería permitir además de la administración del firewall, obtener reportes de uso en forma simple.
  • Unificar distintos firewall actuales como Máquinas Virtuales

Alternativas

Se consideraron alternativas propietarias, así como continuar con la configuración basada en OpenBSD y agregar una interface de Admimistración Web.
Se descartaron los primeros por costo y por la complicación de implementación de algunos requerimientos específicos. Se descartó la opción de agregar una interfaz al OpenBSD porque los productos existentes no manejaban toda la configuración del firewall.

Se decidió utilizar una configuración en Alta Disponibilidad de OPNSense. El producto cumple con la gran mayoría de los requisitos y para algunas configuraciones muy específicas se desarrollaron alguns scripts que pueden integrarse sin problemas con el producto.

Si bien OPNSense está basado en FreeBSD, utiliza un packet filtering similar al de OpenBSD y el hecho de contar con el Kernel HardenedBSD con varios agregados orientados a Seguridad fueron un factor adicional en la decisión.

Para cumplir con el requisito de integrar varios firewall como VMs, se configuraron dos equipos de Spectrum4 sobre los que se instaló ProxMox Virtual Environment (VE).

Los distintos firewall se definieron como dos VMs cada uno (Master en un equipo y Backup en el otro) usando la configuración nativa de HA de OPNSense. De esta manera se tiene redundancia de software y también de hardware

Conclusión

Utilizando OPNSense, Proxmox VE y dos equipos de Spectrum4, más unos pocos programas adicionales es posible implementar un cluster de firewall, con variadas funcionalidades, con una simple interfaz de Administración, sin costo de licencias de software, resultando una solución muy eficiente y versátil.

Generador de reportes

Generalidades

La solicitud del cliente fue la instalación de un sistema de reportes de uso de una solución de proxy y filtrado de contenido basada en Squid y SquidGuard.

Alternativas

Se evaluaron originalmente varios de los productos de código abierto disponibles para este tipo de ambientes (tales como Calamaris, LightSquid, Sarg, etc). Todos los productos brindaban una parte de la información requerida, pero ninguno todo y en forma sencilla de consultar.

Se decidió evaluar una solución propietaria que es SawMill. Esta solución resultó muy adecuada porque brinda en una solución única toda la información requerida. Pueden consultarse y configurarse los reportes a traves de una interface Web y admite más de 900 formatos de logs distintos como fuente de información.

Conclusión

La solución de SawMill cumplió ampliamente los requisitos a un costo muy accesible. Como valor agregado se decidió incluir en el mismo sistema de reportes, los logs del server de mail (PostFix), de los firewall (pf) y de otro proxy (Squid + DansGuardian).

DNS

Generalidades

El cliente solicitó la configuración de un servicio de DNS para ser usado en forma interna. Se requería un servicio estable y con alto grado de disponibilidad para ser utilizado por un 4000 PCs y 200 servidores.

Alternativas

Se evaluó utilizar algunos de los siguientes entornos:

  • RedHat Entreprise Linux
  • Ubuntu Server
  • OpenBSD

Para garantizar la disponibilidad del servicio se adoptó una estructura de DNS primario y DNS secundario. El DNS primario se instaló en el site productivo y el secundario en el site alternativo.
En cada nodo se instalaron dos equipos en alta disponibilidad (con una configuración activo/activo). Este último requisito fue lo que orientó la decisión para utilizar OpenBSD como sistema operativo, dada la sencillez de configurar esta estructura (basada en protocolo CARP).

Para considerar fallas del servicio de DNS, sin que haya una falla de los equipos, se agregó un monitoreo del servicio, que puede sacar un equipo del cluster en caso de ser necesario.
Por último se desarrolló una interface, para el ABM de registros del DNS, que actualiza todos los servers en forma simultánea.

Conclusión

La particular sencillez para implementar una configuración de alta disponibilidad de OpenBSD, junto con su establidad y seguridad brindaron la posibilidad de configurar la solución adecuada.

Servicio LDAP Interfaces de Administración y Autogestión

Generalidades

La solicitud del cliente fue la instalación de un servicio de LDAP para ser utilizado como medio de autenticación por todas las aplicaciones de la empresa. Algunos de los requisitos fueron los siguientes:

  • Estructura de alta disponibilidad con más de un server disponible en distintos sites.
  • Los servers deberán mantener sus datos replicados en forma continua.
  • Posibilidad de sincronizar los usuarios/contraseñas con un servicio de Active Directory ya instalado.
  • Contar con interfaces web para las siguientes funciones:
  • - ABM de usuarios por parte de los administradores.
    - Blanqueo de contraseñas para Mesa de Ayuda.
    - Autogestión de contraseñas para los usuarios finales.
  • Tener capacidad para manejar aproximadamente 6000 usuarios.

Alternativas

Se analizaron varias soluciones de servicios LDAP. Se descartó Microsoft Active Directory y Oracle Internet Directory (OID) ya conocidos por la empresa por la necesidad de tener una solución standard que no estuviera orientada a un ambiente determinado. Se evaluó el producto RedHat Directory Server (RHDS) concluyendo que éste último cubría varios de los aspectos requeridos. Haciendo una evaluación de costos se decidió usar la versión de código abierto que se denomina 389 Directory Server (389 DS) que se instaló en equipos con Sistema Operativo Ubuntu Server. Cabe aclarar que se analizó también OpenLDAP y si bien es un producto muy estable y conocido, se consideró demasiado complicado obtener todas las funcionalidades que ya estaban disponibles en 389 DS en forma nativa.

389DS es una solución completa de servicio LDAP, que permite configurar un esquema de varios servidores que mantienen sus datos sincronizados, brinda además la opción de sincronización con un servidor Active Directory y por último tiene disponibles en forma nativa una poderosa política de contraseñas que se adaptaba al requisito del usuario.

Para cubrir las necesidades de las distintas interfaces de uso solicitadas, si bien el producto dispone de una consola de administración se consideró que no era demasiado amigable para usuarios no especialistas y que no permitía el nivel de separación de funciones que el cliente requería. En función de esto, se desarrollaron una serie de interfaces Web para las distintas funciones, personalizable para cada usuario y que brinda todos las funcionalidades requeridas.

Conclusión

Se decidió usar un producto como 389DS que cumplía en forma nativa con varios requerimientos y se desarrolló una serie de interfaces de administración y autogestión de contraseñas que cumplió totalmente con el requerimiento del cliente.

La solución está en uso, con aproximadamente 6000 usuarios activos y la empresa está migrando todas sus aplicaciones para que hagan su autenticación contra esta plataforma.

Para obtener más detalles de 389DS y la implementación puede consultarse este documento