Herramientas para balanceo de carga de servidores Web.

Dentro de la seguridad informática la disponibilidad es un factor muy importante que normalmente se le suele menospreciar. Entendemos por disponibilidad a la garantía de que los usuarios autorizados puedan acceder a la información y recursos de red cuando los necesiten. La disponibilidad es un factor imprescindible en servidores Web. En este post hablare sobre unas herramientas para balanceo de carga: Edgemanage, OnionBalance y Træfik.

Edgemanage es una herramienta para la gestión de la disponibilidad de servidores Web a nivel HTTP  a través de DNS. Su funcionamiento se basa en definir unas máquinas que puedan estar en riesgo de grandes volúmenes de tráfico, ataque tipo DDoS o otra inestabilidad potencial. Cuando el trafico elevado o un ataque se envía a la maquina, si no se encuentra una máquina disponible o tiene un bajo rendimiento, es reemplazada por un anfitrión con más prestaciones para garantizar la máxima disponibilidad. Es un script simple y con una biblioteca de Python diseñado para ejecutarse a intervalos regulares, generalmente a través de crontab. Diseñada para trabajar cada 60 segundos pero las cifras más grandes se puede utilizar [^ 1].

Edgemanage obtiene un objeto de una lista de hosts a través de HTTP y utiliza el tiempo necesario para recuperar el objeto como baremo para tomar decisiones sobre qué máquinas son las que tiene mejor rendimiento para asumir el trafico . Estos anfitriones se escriben en un archivo de zona como registros A para el vértice de un dominio, además de la inserción de los archivos almacenados en la zona incluye directorio. Los archivos de zona que escriba Edgemanage se crean a través de plantillas Jinja, con los datos de SOA y NS que se definen en el archivo de configuración y se unen al formato de salida bind-compliant. Los registros para cada dominio que se incluyen son reglas de estilo de Bind.

Su modo de operación mas detallado consiste en que: un huésped se considera que está en un estado saludable cuando el objeto se devuelve bajo un valor establecido en el archivo de configuración. Anfitriones que devuelven el objeto bajo el tiempo especificado siempre serán elegidos por primera vez en caso de que surja la necesidad de reemplazar a un anfitrión que no está sobrecargado.  Hay que tener cuidado que los cambios de DNS no se hacen cuando no se necesitan, esto significa que si el último conjunto de host saludables disponibles se encuentran en buen estado, no habrá ningún cambio en el DNS.

Mantiene histórico de recuperaciones por host y puede tomar decisiones basadas en estos datos. Por defecto, si no hay suficientes anfitriones, añadirá sistemas basados en su promedio, durante una ventana de tiempo, y en su defecto, de su promedio general.

Edgemanage debe ejecutarse periódicamente para ser de utilidad. Se recomienda ejecutarlo a través de crontab. En su puesta en marcha por primera vez, es recomendable ejecutarlo en modo verbose (-v) y en el modo de ejecución (-n) escribiendo  en un lugar que no contenga la información de producción.

Mantiene un archivo de estado que se utiliza para obtener información histórica sobre los hosts en activos y los tiempos de última rotación. Si se deniega una conexión a un host, se le asignará el máximo tiempo permisible para un host (garantizando así tanto su retirada de la rotación en vivo y también una ventana de retroceso a través de sus promedios).

Más información y descarga de Edgemanage:
https://github.com/equalitie/edgemanage

OnionBalance permite que las solicitudes de servicio ocultas de Tor se distribuyan a través de múltiples instancias back-end. OnionBalance proporciona equilibrio de carga, al tiempo que hace que los servicios de Tor sean más resistentes y fiables eliminando puntos de falla únicos. Está en desarrollo activo y se agregan regularmente nuevas características, las principales son estas:

• Equilibrio de carga entre un máximo de 60 servicios ocultos de back-end.
• Almacenamiento de las claves privadas de servicios oculto separadas de los hosts.

La arquitectura se basa en que un servidor de administración ejecuta el demonio OnionBalance. OnionBalance combina la información de enrutamiento (los puntos de introducción) para múltiples instancias de servicios back-end y publica esta información en un descriptor maestro. Los servidores de aplicaciones back-end ejecutan un servicio Tor estándar. Cuando un cliente se conecta al servicio público de Tor, selecciona uno de los puntos de introducción al azar. Cuando se completa el circuito de introducción, el usuario está conectado a la instancia de backend correspondiente. De esta forma la herramienta esta dividida en dos módulos diferenciados:

• Servidor de administración. Es la máquina que ejecuta el demonio OnionBalance. Que necesita tener acceso a la clave privada del servicio de Tor correspondiente para la dirección deseada. Esta es la dirección de Tor pública que los usuarios solicitarán. Esta máquina puede ubicarse geográficamente aislada de las máquinas que alojan el contenido del servicio de Tor. No necesita servir ningún contenido.
• Instancia de back-end. Cada servidor de aplicaciones back-end ejecuta un servicio Tor con una clave de servicio única.

A nivel de uso estés módulos se traducen en dos herramientas de línea de comandos:

• Onionbalance, que actúa como un demonio de largo funcionamiento.
• Onionbalance-config, que es una utilidad de ayuda que facilita el proceso de creación de claves y archivos de configuración para onionbalance y las instancias Tor de back-end.

Hay muchas maneras de usar OnionBalance para aumentar la escalabilidad, fiabilidad y seguridad de un servicio de Tor. Los siguientes son algunos ejemplos de lo que es posible:

• Crear un back-end de un servidor de claves SKS. Formar una agrupación de servidores de claves de servicios ocultos que conecta a los usuarios a uno de los servidores de claves de servicios ocultos disponibles.
• Un servidor web o un proceso Tor sobrecargado. Un servicio que recibe un gran número de usuarios desea distribuir las solicitudes de clientes a través de varios servidores, ya que la carga es demasiado para que una única instancia de Tor la maneje. También desean equilibrar los casos en que se aplica las peteciones de servicios cifrados [2555].
• Redundancia y conmutación automática. Un usuario le gustaría mantener su servicio web accesible y seguro en caso de que alguien se apoderara de algunos de sus servidores. Por defecto, los clientes deberían automáticamente conmutar a otras instancias en línea con una interrupción mínima del servicio.
• Almacenamiento de claves de Secure Onion Service. Un operador de servicio de Tor quiere guardar sus claves de Tor permanente en un lugar seguro separado de su proceso Tor y otros servicios. Con esta propuesta las claves permanentes se pueden almacenar en un sistema independiente y aislado.

Más información y descarga de OnionBalance:
https://github.com/DonnchaC/onionbalance

Træfik es un moderno proxy inverso HTTP, que permite equilibrar carga, hecho para desplegar microservicios con facilidad. Soporta varios backends (Docker, Swarm, Kubernetes, Marathon, Mesos, Consul, Etcd, Zookeeper, BoltDB, Eureka, Amazon DynamoDB, Rest API, archivo …) para gestionar su configuración de forma automática y dinámica.

Cuando se despliega un montón de microservicios en un infraestructura, probablemente se utiliza un registro de servicios (como etcd o consul) y  un sistema distribuido (Swarm, Mesos/Marathon) para gestionar todos estos servicios. Para que los usuarios accedan a algunos de los microservicios desde Internet, hai que utilizar un proxy inverso y configurarlo utilizando hosts virtuales o rutas de prefijo:

• Dominio “api.domain.com” apuntará a la api de microservicios de la red privada.
• La ruta “domain.com/web” apuntará la web de microservicios en la red privada.
• El dominio ”backoffice.domain.com” apuntará al backoffice de la red privada, para balanceo de carga de múltiples instancias.

Pero una arquitectura de microservicios es dinámica. Los servicios se agregan, eliminan, se matan o se actualizan a menudo, eventualmente varias veces al día. Los proxys inversos tradicionales no son dinámicos nativamente. No puede cambiar su configuración y recargar en caliente fácilmente.
Træfik puede escuchar la API de registro de servicios del sistema distribuido y sabe cada vez que un microservicio es agregado, eliminado o actualizado, y puede generar su configuración automáticamente. Las rutas a los servicios serán creadas al instante.

Características principales de Traefik:

• Es rápido.
• Tiene API de reposo.
• Soporta múltiples backends: Docker, Swarm, Kubernetes, Maratón, Mesos, Cónsul, Etcd…
• Puede escuchar los cambios en backends para aplicar una nueva configuración automáticamente
• Recarga en caliente de la configuración, no es necesario reiniciar el proceso.
•  Pose equilibradores de carga de rebalanceadores en Round Robin.
• Soporte de backends SSL.
• Soporte de interfaz SSL (con SNI).
• Soporte de Websocket.
• Soporte HTTP/2.
• Reintenta la solicitud si hay un error de red.
• Alta disponibilidad con modo de clúster.

Más información y descarga de  Traefik:
https://traefik.io/

Los balanceadores de carga ocultan muchos servidores web verdaderos detrás de una IP virtual. Reciben peticiones HTTP y las dirigen a los servidores web para compartir el tráfico entre ellos. Con la herramienta Halberd permite descubrir los servidores que se encuentras detrás del balanceador de carga y auditar la seguridad de la configuración.

El modo de funcionamiento de Halberd se divide en tres etapas:

• Inicialmente, envía peticiones múltiples al servidor Web a auditar y registra sus respuestas. Esto se denomina fase de muestreo.
• Después, el programa procesa las contestaciones y busca muestras del equilibrio de carga. Esto se llama la fase de análisis.
• Finalmente, la Halberd escribe un informe de sus resultados.

Halberd utiliza las siguientes técnicas:

• Comparación de la fecha. Las respuestas HTTP revelan el reloj interno del servidor Web que las produce. Si aparecen varios resultados con tiempos de reloj diferente, Halberd identifica número de servidores verdaderos. Este método funciona si los servidores Web no están sincronizados con un NTP.
• Diferencia de nombres de campo de las cabeceras del MIME. Las diferencias en los campos que aparecen en respuestas del servidor pueden permitir que la Halberd identifique los servidores.
• Generación de altas cantidades de tráfico. Bajo ciertas configuraciones, los balanceadores de la carga comienzan a distribuir tráfico, solamente después de que se alcance cierto umbral. Esta herramienta intenta generar un volumen de tráfico importante para accionar esta condición y alcanzar tantos servidores verdaderos como sea posible.
• Usando diversas URL. Un balanceador de carga se puede configurar para redirigir el tráfico a distintos servidores según la URL a la que se acceda. Esta herramienta utiliza una araña para navegar por las diferentes URL para diferenciar los distintos servidores que contestan.
• Detección de cache del servidor. Detecta si los servidores web utilizan cache para acelerar las peticiones con programas tipo Squid.
• Obtención de IP públicas. A veces las cookies o los campos especiales del MIME en respuestas del servidor pueden revelar direcciones IP públicas de los servidores web. En estos casos se puede puentear el balanceador de carga y acceder directamente al servidor web.

Fuente:https://www.gurudelainformatica.es/2017/07/herramientas-para-balanceo-de-carga-de.html