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ó la ampliación y actualización de una estructura ya existente de firewall, dotándola de equipos actualizados y varias funcionalidades nuevas.

Algunas de las nuevas funcionalidades requeridas fueron:

  • Configuración activo/activo en lugar de activo/pasivo.
  • Agregar 2 enlaces de internet adicionales a los 2 ya existentes.
  • Disponer de contingencia para los servicios entrantes y no solo para los salientes.
  • Disponer de la posibilidad de manejar mayor número de conexiones en forma simultánea.
  • Permitir que las reglas de firewall se adapten a cambios de IP de los servers externos.
  • Brindar un servicio de proxy reverso en el firewall para compartir direcciones IP públicas entre sitios en distintos servers.

Alternativas

Se consideraron alternativas propietarias de Cisco y CheckPoint, así como continuar con la configuración basada en OpenBSD.
Por una indudable diferencia de costos, pero tambien porque varias de las configuraciones eran muy específicas y más sencillas de implementar, junto con la experiencia ya adquirida, es que se decidió seguir utilizando OpenBSD para la implementación.

Se dedicaron dos servidores específicos a esta configuración y se migraron muchas de las reglas de firewall ya existentes en forma directa y otras debieron modificadas, ya que hubo algunos cambios en la sintaxis respecto a versiones anteriores.

Para los servicios entrantes, que requieren un cambio de la dirección IP asociada a un determinado server, se usaron registros en un DNS dinámico (DynDNS) que el firewall actualiza en función de la disponibilidad del enlace de Internet normalmente usado para ese servicio.
Se usa el programa ifstated provisto en el sistema operativo para monitorear los vínculos de internet y en función del resultado se cambian las reglas de firewall y se actualizan los registros de DNS.

Como requisito adicional surgió la posiblidad de utilizar un enlace de Internet que está en el site de contingencia. Ya que los dos sites están conectados por enlaces privados, se decidió configurar una VPN en modo bridge usando OpenVPN. Esto permitió que una de las interfaces de los firewall productivos fuera la conexión de internet del site de contingencia.

Conclusión

Utilizando el filtrado de paquetes (pf) de un sistema operativo de código abierto como OpenBSD, más algunos scripts o programas adicionales es posible implementar un cluster de firewall, con variadas funcionalidades, sin costo de licencias de software, resultando una solución muy eficiente y versátil.

Firewall Bajo costo con múltiples conexiones a internet

Generalidades

El requisito era la instalación de un firewall que pudiera adaptarse a diferentes opciones de conectividad, que pudiera establecer más de una VPN a un site central y que se pueda manejar distinto tipo de protocolo por cada enlace, con contingencia frente a la caída de uno de los enlaces. Los enlaces posibles pueden ser distintos tipos de conexión internet o conexiones privadas de bajo costo provistas por empresas de comunicaciones (Branch Office o ADSL-VPN).

Adicionalmente puede disponerse de una conexión internet local y un servicio de proxy con filtrado de contenidos.

Alternativas

Dada lo particular de la configuración requerida, se decidió desarrollar una solución particular para esta configuración. Se utilizó como sistema operativo base OpenBSD, por características tales como su estabilidad y seguridad, el muy bajo requermiento de hardware que tiene y básicamente por el excelente y versátil sistema de filtrado de paquetes de red “packet filtering” (pf).

Dada la variedad de configuraciones posibles se desarrolló un proceso de configuración que permite a partir de una instalación base obtener todas las alternativas.

Conclusión

Por la muy particular y variada configuración requerida se desarrolló una solución totalmente personalizada. De todas maneras se pensó en forma modular y configurable de manera que pueda adaptarse a otras situaciones similares.

Firewall / Proxy Filtrado de contenido

Generalidades

El requerimiento fue brindar a una pequeña oficina de una empresa acceso a internet con los siguientes requisitos básicos:

  • Filtrado de contenidos web, limitando el acceso a páginas de contenido no apropiado (ej. pornografía, violencia, etc)
  • Servidor DHCP
  • Acceso VPN para determinados usuarios
  • Servidor DNS
  • Generar reportes de uso de Internet
  • Contar con una sencilla administración por parte de personal no calificado en herramientas de código abierto
  • Bajo costo
  • Implementación en corto tiempo

Alternativas

Se descartaron alternativas propietarias y la evaluación fue entre brindar las soluciones con un conjunto de herramientas de código abierto (ej.: Squid, SquidGuard, dnsmasq, Lightsquid, etc.) agregando una interface de administración amigable (ej.: WebMin), desarrollar una interface para los productos más usados (filtro de contenidos, DNS) o una tercer alternativa, que es la que finalmente se implementó, que fue el producto pfsense. Este producto es una distribución completa basada en FreeBSD, que tiene un sistema de administración de todos los productos desde una interface Web y que permite configurar y administrar todas las funcionalidades requeridas, con opciones adicionales disponibles.

Conclusión

En función de los requisitos y la urgencia de implementación propuesta la opción de Pfsense fue considerada la más adecuada.

Proxy 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