Balanceadores de carga

Balanceadores de carga (Layer 4 y Layer 7)

1️⃣ Explicación en Profundidad

🔹 ¿Qué es?
Un balanceador de carga es como el portero de una discoteca con múltiples puertas, encargado de dirigir a los clientes a la mejor puerta disponible. Su objetivo es evitar colapsos, garantizar que nadie espere demasiado y que todas las puertas se usen eficientemente. Si una puerta (servidor) se rompe, el portero automáticamente redirige a los visitantes a otras puertas funcionales.

🔹 ¿Cómo funciona?

• Capa 4: Reparte tráfico basándose en IP/puerto. No entiende lo que hay dentro del paquete, solo ve el sobre.

• Capa 7: Analiza el contenido real del mensaje (como ver qué tipo de cliente llega, si pide música, comida o reserva) y lo redirige según esa necesidad.

🔹 Programación:
Es la estrategia de reparto. Puede ser:

• Round Robin (turnos rotativos),

• Menor carga,

• Mejor tiempo de respuesta,

• Con lógica dinámica según carga actual.

🔹 Verificación del estado (Health checks):
Comprueba si las puertas (servidores) están operativas. Si no responden, no se envía tráfico allí.

🔹 Afinidad y persistencia de sesión:

• Si el cliente necesita volver a la misma puerta (como un pedido en proceso), se asegura de que así sea.

• Se logra con cookies (capa 7) o por IP (capa 4).

2️⃣ Ejemplos Prácticos

• 🔸 Una tienda online con miles de usuarios concurrentes usa un balanceador L7 para que el tráfico de carrito vaya a servidores con lógica de compra y el tráfico de catálogo vaya a otros más ligeros.

• 🔸 Un servidor de videoconferencia usa balanceo L4 para repartir tráfico UDP de voz/video.

• 🔸 Un sitio de streaming usa persistencia de sesión por cookie para que el usuario no se desconecte al cambiar de servidor durante la película.

3️⃣ Aplicaciones y Herramientas Reales

• Herramientas:

  • NGINX

  • HAProxy

  • F5 BIG-IP

  • AWS ELB (Elastic Load Balancer)

  • Azure Load Balancer

  • Traefik (moderno y ligero, L7)

• Entornos comunes:

  • Arquitecturas de alta disponibilidad (HA).

  • Microservicios y contenedores con Kubernetes (K8s usa kube-proxy y servicios con balanceo interno).

  • Infraestructura web resiliente.

4️⃣ ¿Qué hace cada equipo?

🔴 Red Team

• Ataques:

  • Ataques de evasión: esconder el payload para que pase el balanceador L7.

  • Flooding o DDoS en una puerta concreta para sobrecargarla y provocar fallos en el balanceo.

  • Sesiones robadas aprovechando errores en la persistencia de sesión.

• Objetivo: desestabilizar la distribución de carga o romper la afinidad.

🔵 Blue Team

• Defensa:

  • Uso de health checks avanzados para excluir servidores lentos o comprometidos.

  • Monitorización activa de logs del balanceador.

  • Protección contra DoS con límites por IP y reglas en el firewall.

  • Cifrado de cookies de sesión e integración con WAF.

🟣 Purple Team

• Acciones clave:

  • Validar que la afinidad se comporta como se espera bajo estrés.

  • Simular caídas de servidores para verificar failover.

  • Medir latencia, errores 5xx, y analizar rutas mal balanceadas.

  • Automatizar respuestas con scripts de mitigación o reconfiguración vía API.

6️⃣ ✅ Resumen narrativo 

El balanceador de carga actúa como un director de tráfico inteligente que garantiza que cada cliente llegue al mejor servidor disponible. Puede hacerlo con lógica simple (como turnos) o compleja (analizando el tipo de petición). Existen balanceadores de red (L4) y de aplicación (L7). También aseguran alta disponibilidad al redirigir tráfico si un servidor falla, y gestionan sesiones persistentes con IP o cookies. Son fundamentales en arquitecturas resilientes y escalables, pero también objetivo de ataques sofisticados que intentan desestabilizar la distribución del tráfico. La coordinación entre Red, Blue y Purple Team asegura su correcta implementación y defensa.

🧠 EJERCICIOS PURPLE TEAM – Balanceadores de Carga

⚔️ Ejemplo 1 – Ataque por DDoS focalizado – Nivel Avanzado

• 🔴 Red Team: Lanza una lluvia de tráfico sobre un solo backend a través de un bug en la afinidad IP mal configurada.

• 🔵 Blue Team: Detecta tráfico anómalo, aplica rate limiting por IP y bloquea el vector desde el firewall.

• 🟣 Purple Team: Supervisa los logs del balanceador, ajusta la política de afinidad para evitar fijación persistente y evalúa las métricas de tolerancia a fallos.

🕷️ Ejemplo 2 – Ataque de Session Hijacking via Cookie – Nivel Experto

• 🔴 Red Team: Captura cookies sin cifrar de persistencia de sesión y secuestra la sesión activa del usuario.

• 🔵 Blue Team: Habilita HTTPS, firma de cookies y regeneración de tokens al login.

• 🟣 Purple Team: Testea la seguridad de cookies en múltiples entornos, evalúa si la rotación de sesión es eficaz y sugiere mejoras en la gestión de tokens.

☠️ Ejemplo 3 – Desbordamiento del balanceador y failover fallido – Nivel Maestro

• 🔴 Red Team: Simula un fallo masivo en dos nodos y genera tráfico malicioso para saturar el balanceador L7.

• 🔵 Blue Team: Aísla el tráfico, activa reglas de emergencia que redirigen a servidores de respaldo.

• 🟣 Purple Team: Valida que el failover se ejecutó correctamente, analiza por qué los backups tardaron en responder y documenta la debilidad para plan de mejora.

🧪 SECCIÓN 2 – EJERCICIOS PURPLE TEAM

Tema: Balanceadores de carga (Layer 4 y Layer 7)

🎯 Ejemplo 1 – Ataque: DoS focalizado en capa 4 – Nivel Avanzado

🔴 Red Team – Ataque

Simulo un ataque de denegación de servicio TCP SYN Flood contra un balanceador de carga de capa 4. Envío una oleada de paquetes SYN falsos que nunca completan el handshake. El balanceador, al no distinguir fácilmente si son legítimos, consume sus recursos esperando ACKs que nunca llegan.

📌 Herramientas: hping3, Metasploit DoS modules, LOIC (bajo laboratorio controlado).

🔵 Blue Team – Defensa

• Activo protección SYN cookies en el balanceador.

• Configuro límites de tasa por IP (rate limiting).

• Implemento monitorización de tráfico anómalo desde el SIEM.

• Uso un IDS como Suricata detrás del balanceador para observar patrones sospechosos que escapen al análisis de L4.

🟣 Purple Team – Gestión y Validación

• Hago un test de rendimiento tras aplicar mitigaciones para asegurar que no afectan al tráfico legítimo.

• Comparo logs antes y después para verificar si el filtro de rate-limiting bloqueó al atacante sin afectar al usuario.

• Ajusto el balance entre sensibilidad y funcionalidad, manteniendo la experiencia de usuario y la seguridad.

🎯 Ejemplo 2 – Ataque: Robo de sesión con afinidad mal gestionada (Layer 7) – Nivel Experto

🔴 Red Team – Ataque

Aprovecho que el balanceador usa cookies sin cifrar para la persistencia de sesión, y lanzo un ataque Man-in-the-Middle o de recolección de cookies en tráfico HTTP. Una vez obtengo la cookie de sesión, me hago pasar por el usuario legítimo.

📌 Herramientas: Ettercap, Burp Suite, Wireshark, mitmproxy.

🔵 Blue Team – Defensa

• Fuerzo HTTPS en todo el tráfico para evitar captura de cookies.

• Activo la opción de Secure y HttpOnly en las cookies del balanceador.

• Implemento un sistema de detección de anomalías de sesión basado en IPs y cambios de comportamiento del usuario.

• Habilito regeneración de tokens por sesión tras acciones críticas (como login o cambio de rol).

🟣 Purple Team – Gestión y Validación

• Realizo una simulación controlada para capturar y comparar cookies en entorno de staging.

• Ajusto la política del balanceador para limitar la duración y reutilización de tokens.

• Analizo logs del WAF y del balanceador para identificar si se están detectando intentos reales de suplantación.

🎯 Ejemplo 3 – Ataque: Bypass del balanceador con acceso directo a nodos – Nivel Maestro

🔴 Red Team – Ataque

Descubro mediante técnicas de fingerprinting y escaneo que los nodos detrás del balanceador exponen su IP real. Aprovecho para saltarme el balanceador y atacar directamente los servidores backend (por ejemplo, un WordPress vulnerable con CVE antigua).

📌 Herramientas: Nmap, Shodan, Burp Active Scan, sqlmap, WPScan.

🔵 Blue Team – Defensa

• Configuro los nodos para que solo acepten tráfico proveniente del balanceador (ACLs).

• Uso reglas de firewall para cerrar todos los puertos expuestos directamente.

• Valido que el DNS inverso de los nodos no esté filtrando IPs reales.

• Implemento un WAF en el balanceador y otro en los nodos como defensa en profundidad.

🟣 Purple Team – Gestión y Validación

• Realizo escaneos internos de exposición de IPs y puertas traseras.

• Verifico si los nodos pueden ser accedidos directamente desde fuera del perímetro y documento los hallazgos.

• Coordino una simulación Red vs Blue y mido tiempos de detección, bloqueo y recuperación.