Puesta en marcha de la infraestructura

Lo que vas a aprender en esta sección :

• Lanzar la infraestructura multi-contenedor
• Configurar el equilibrio de carga HTTP

IMPORTANTE: Le recomendamos encarecidamente leer este artículo antes de comenzar este TP para dominar los fundamentos.

1. Obtención de fuentes

   Debe clonar las fuentes del proyecto desde este REPO https://github.com/rousseltm/haproxy-formation.git en la carpeta que prefiera.

2. Puesta en marcha de la infraestructura

   Para probar nuestras configuraciones necesitaremos una infraestructura mínima. Debe lanzar los siguientes comandos:

   cd haproxy-formation 
   sudo docker compose -f compose-infra.yaml up -d

3. Inicio de la instancia base

   Para probar nuestras configuraciones necesitaremos una infraestructura mínima. Debe lanzar los siguientes comandos:

   cd haproxy-formation 
   sudo docker compose -f compose-infra.yaml up -d

Iniciación a la configuración

Lo que vas a aprender en esta sección :

• Localizar y editar el fichero principal
• Utilizar la directiva include para la carpeta conf.d
• Comprender la diferencia entre reload y restart

1. Acceder al fichero base haproxy.cfg

   El corazón de HAProxy reside en su fichero de configuración único. En nuestro entorno Docker, este fichero se monta en volumen.

2. Añadir un include en el fichero

   Para una gestión limpia, pediremos a HAProxy que cargue todos los ficheros de configuración terminados en .cfg situados en la carpeta conf.d.

3. Relanzar la configuración

   Cada modificación del fichero requiere que sea tenida en cuenta por el motor HAProxy.
   
   

   Reload vs Restart: En producción, no utilice nunca el restart ya que corta las conexiones. El Reload (señal HUP) permite cargar la nueva conf sin ninguna interrupción de servicio.

Gestión de Frontends

Lo que vas a aprender en esta sección :

• Configurar un frontend dedicado a las estadísticas
• Probar la accesibilidad del dashboard de estadísticas
• Configurar el frontend principal para el tráfico HTTP

1. Punto de entrada para la administración

   Cree un punto de entrada dedicado a la monitorización llamado 'admin'. Este punto de entrada debe escuchar en el puerto por defecto 8404. Debe activar la interfaz de estadísticas, definir la raíz (/) como URI de acceso y configurar un refresco automático cada 5 segundos. Note que puede realizar esta configuración con un bloque frontend o un bloque listen, el resultado será idéntico.

   El fichero de configuración se encuentra en la raíz de su carpeta de TP (config/haproxy/haproxy.cfg). Para aplicar sus modificaciones, utilice el comando docker compose restart haproxy.

2. Prueba de acceso a las estadísticas

   Después de haber configurado el frontend 'admin', verifique que la interfaz de monitorización está operativa. Puede utilizar su navegador o un comando de terminal para probar la accesibilidad del servicio en el puerto dedicado.

3. Frontend HTTP

   Configure el frontend principal llamado 'http_in' para recibir el tráfico web de los usuarios. Debe escuchar en el puerto 80 y redirigir por defecto todas las peticiones al grupo de servidores 'default' (que se creará posteriormente).

Gestión de Backends

Lo que vas a aprender en esta sección :

• Configurar un backend por defecto
• Comprender el reparto de carga Round Robin

1. El Backend por defecto

   Cree un grupo de servidores llamado 'default'. Este backend se utilizará para tratar las peticiones que no coincidan con ninguna regla específica. Debe funcionar en modo HTTP, utilizar el algoritmo 'roundrobin' y apuntar al servidor 'web1'. Configure una regla para que este backend sirva sistemáticamente el fichero 'default.html'.

2. Recarga en caliente mediante fichero de conf

   Abra su interfaz de estadísticas (puerto 8404). Normalmente debería ver 1 servidor activo en el backend default. El objetivo es añadir el servidor web2 a este pool 'en caliente', es decir, sin reiniciar el contenedor HAProxy, con el fin de preservar las conexiones en curso.

3. Recarga en caliente mediante socat

   HAProxy dispone de una Runtime API accesible mediante un socket Unix. Permite modificar el estado del balanceador de carga (peso, estado de los servidores, adición dinámica) sin ninguna recarga.

   Para inspeccionar el estado interno o pasar comandos directamente en su contenedor, conéctese a la shell mediante :
   docker exec -it <nombre_del_contenedor> sh
   
   Para utilizar la API, debe haber activado el socket en la sección global de su haproxy.cfg :
   stats socket /var/run/haproxy.stat mode 600 level admin

   Recomendación de lectura : Para profundizar en la gestión dinámica de backends y servidores mediante la Runtime API, consulte nuestro artículo dedicado : HAProxy : Adición y supresión dinámica de backends.

4. El Backend web_servers

   Cree un grupo de servidores llamado 'web_servers'. Este backend debe funcionar en modo HTTP y utilizar el algoritmo de reparto 'roundrobin'. Debe también añadir una regla para transmitir la dirección IP real del cliente al backend mediante el encabezado 'X-Real-IP' y declarar los 3 nodos aplicativos (web1, web2, web3) en el puerto 80 con una verificación de salud (check).

5. Escalado de HAProxy

   El paso a escala (scaling) horizontal consiste en multiplicar las instancias de HAProxy para garantizar la Alta Disponibilidad (HA). En una arquitectura real, tener una sola instancia de balanceador de carga crea un 'Single Point of Failure' (SPOF) : si HAProxy cae, toda la aplicación es inaccesible, incluso si los servidores web están sanos. En entorno Docker, el escalado permite repartir la carga de red y asegurar una continuidad de servicio durante las actualizaciones (rolling updates). Debe pasar el número de instancias HAProxy a 3.

Enrutamiento avanzado con ACL

Lo que vas a aprender en esta sección :

• Manipular las ACL path_beg

1. Modificación ACL

   El enrutamiento inteligente permite dirigir el tráfico a diferentes backends según criterios precisos. En este ejercicio, debe configurar HAProxy para que identifique las peticiones destinadas a la API (que comiencen por el camino /api) y las envíe exclusivamente al servidor web2. El tráfico restante debe continuar siendo distribuido por el backend por defecto.
   
   

   IMPORTANTE : Asegúrese de comprender bien el esquema de arquitectura para garantizar que sus reglas de enrutamiento permitan siempre el acceso a la consola de estadísticas y al endpoint /metrics.

2. Listas blancas de IPs (Whitelisting)

   El filtrado por dirección IP is un pilar de la seguridad. Debe ahora restringir el acceso al dashboard de estadísticas (puerto 8404) para autorizar solo la IP de su servidor Prometheus que necesita leer '/metrics' (por ejemplo 172.20.0.5).
   
   

   Whitelisting vs Blacklisting :

   HAProxy es compatible con ambos enfoques mediante sus reglas de ACL.

   • Whitelisting (Lista blanca) : Estrategia 'Default Deny'. Bloqueamos todo por defecto y solo autorizamos las fuentes conocidas. Es el enfoque más robusto para la seguridad.
     Caso de uso : Acceso a una consola de administración, API interna reservada a partners, restricción de acceso a las IPs de una VPN de empresa.
   • Blacklisting (Lista negra) : Estrategia 'Default Allow'. Dejamos pasar todo el tráfico excepto las IPs identificadas como malintencionadas.
     Caso de uso : Bloqueo de bots conocidos (scrapers), protección temporal contra una IP que realiza un ataque por fuerza bruta, o Geo-blocking (bloquear regiones enteras).

Seguridad y Endurecimiento

Lo que vas a aprender en esta sección :

• Limitar las conexiones simultáneas (Anti-DoS/DDoS)
• Protegerse contra los ataques lentos (Slowloris)
• Poner en marcha un cupo de peticiones (Rate Limiting)
• Identificar y filtrar los autómatas (Anti-bot/Scraping)
• Utilizar la terminación silenciosa (Silent Drop) para los flujos prohibidos

1. Protección contra DOS y DDOS

   Configure el frontend http_in para limitar cada IP de origen a un máximo de 15 conexiones TCP simultáneas (Capa 4). Una vez aplicada la configuración, intente abrir varias conexiones en paralelo para verificar que HAProxy rechaza las siguientes.

   Verificación : Simule una carga con un bucle shell para abrir numerosas conexiones en segundo plano :

   for i in $(seq 1 20); do curl -s http://localhost & done

   Mire sus logs de HAProxy o el dashboard : las conexiones por encima de 15 deben ser rechazadas inmediatamente.

   ¿DoS vs DDoS : Cuál es la diferencia?

   • DoS (Denial of Service) : El ataque proviene de una sola máquina. HAProxy puede bloquearlo fácilmente limitando las conexiones por IP.
   • DDoS (Distributed DoS) : El ataque proviene de miles de fuentes (botnet). Bloquear una IP ya no es suficiente porque el tráfico está distribuido.

   Recomendaciones de HAProxy (Leer el artículo oficial) :

   • Defensa en profundidad : Para los ataques volumétricos masivos (Capas 3 y 4), utilice servicios de protección Cloud (Cloudflare, AWS Shield) aguas arriba.
   • Filtrado Capa 7 : Utilice HAProxy para identificar firmas de ataque específicas en los encabezados o las URLs mediante las ACL.
   • Stick Tables : Siguen siendo esenciales para limitar el impacto de cada nodo de la botnet en sus recursos aplicativos.

2. Protección contra Slowloris

   El ataque Slowloris satura el servidor enviando encabezados HTTP muy lentamente. Implemente una protección limitando el tiempo de recepción de los encabezados a 5 segundos.

   Simulación de ataque : Lance este comando antes de la configuración (la conexión se quedará bloqueada) después después (HAProxy cortará la conexión tras 5s) :

   curl -X GET "http://localhost:80/" \
        -H "X-Slow: $(head -c 5000 < /dev/zero | tr '\0' 'A')" \
        --limit-rate 1 \
        --verbose

   Explicación de los parámetros :

   • -H "X-Slow: ..." : Genera un encabezado masivo de 5000 bytes (mediante head y tr) para forzar un envío largo.
   • --limit-rate 1 : Limita el envío a 1 byte/s. Sin protección, la conexión se quedaría abierta más de una hora.
   • --verbose : Permite observar en directo el momento exacto en el que HAProxy interrumpe la sesión.

   Recomendaciones de HAProxy (Leer el artículo oficial) : Para una protección óptima, HAProxy aconseja combinar varios ajustes :

   • timeout http-request 5s : Limita el tiempo de espera de los encabezados (defensa principal).
   • timeout http-keep-alive 1s : Libera rápidamente los slots de conexión inactivos.
   • maxconn : Limita el número global de conexiones para proteger los descriptores de ficheros del sistema contra el agotamiento.

3. Limitar las peticiones (Rate Limiting)

   Ponga en marcha un cupo de 50 peticiones máximo cada 10 segundos por IP. Pruebe la superación del umbral y verifique que HAProxy devuelve correctamente un código de error HTTP 429.

   Verificación : Ejecute una ráfaga de peticiones curl para saturar el cupo :

   for i in $(seq 1 60); do curl -I http://localhost; done

   Debe observar respuestas HTTP/1.1 429 Too Many Requests después de la 50ª petición.

4. Módulos Anti-bot y Detección de scraping

   Bloquee los aspiradores de datos (scrapers) y los bots malintencionados identificando sus firmas de User-Agent sospechosas.

   Simulación de bot : Intente acceder al sitio simulando un bot conocido mediante curl :

   curl -I -H "User-Agent: Googlebot-Scraper" http://localhost/

5. Terminación silenciosa de petición

   El 'Silent Drop' es una técnica de defensa avanzada : en lugar de enviar un código de error (403/429) que confirme al pirata la existencia de una protección, HAProxy simplemente ignora la petición. El atacante malgasta sus recursos esperando una respuesta que nunca llegará.

   Verificación : Pruebe el acceso a un camino prohibido y compruebe que curl se queda esperando (hang) hasta el tiempo de espera :

   curl -v http://localhost/admin/config

Observabilidad

1. Stats Dashboard

   Configure el listen admin.

2. Prometheus : Exposición de métricas

   Configure HAProxy para exponer las métricas de rendimiento en formato Prometheus en la URI /metrics. Esto permite a un servidor Prometheus recolectar (scrape) el estado del balanceador de carga.

   Verificación : Pruebe la recuperación de las métricas mediante curl :

   curl http://localhost:8404/metrics

   Debería ver desfilar las métricas en formato de texto plano (HELP and TYPE).

3. Soporte de OpenTelemetry (OTel)

   Configure la exportación nativa de datos de telemetría hacia un colector OpenTelemetry.

   Nota : El soporte nativo de OpenTelemetry está disponible a partir de la versión 3.4 de HAProxy.