Cómo proteger un servidor de ataques DDoS con proxy: configuración en 15 minutos

Los ataques DDoS pueden paralizar el funcionamiento de cualquier servicio web en cuestión de minutos. Los atacantes envían miles de solicitudes desde diferentes direcciones IP, sobrecargando el servidor y haciéndolo inaccesible para los usuarios reales. Los servidores proxy son una de las herramientas efectivas de protección que permiten filtrar el tráfico malicioso, distribuir la carga y ocultar la dirección IP real de su servidor.

En esta guía, analizaremos cómo configurar un proxy para protegerse contra DDoS, qué tipos de proxies utilizar y cómo construir un sistema de seguridad en múltiples niveles. El material está orientado a administradores de sistemas, propietarios de servicios web y especialistas en DevOps.

Cómo funcionan los ataques DDoS y por qué los proxies ayudan

DDoS (Denegación de Servicio Distribuida) es un ataque distribuido que busca negar el servicio. El atacante utiliza un botnet de miles de dispositivos infectados que envían solicitudes a su servidor simultáneamente. El objetivo es agotar los recursos del servidor (CPU, memoria, ancho de banda) y hacerlo inaccesible para los usuarios legítimos.

Los principales tipos de ataques DDoS son:

• Volumetric attacks (ataques volumétricos) — llenan el ancho de banda con una gran cantidad de tráfico (amplificación DNS, inundación UDP)
• Protocol attacks (ataques de protocolo) — explotan vulnerabilidades en protocolos de red (inundación SYN, Ping of Death)
• Application layer attacks (ataques a nivel de aplicación) — imitan solicitudes legítimas a una aplicación web (inundación HTTP, Slowloris)

Los servidores proxy ayudan a protegerse contra DDoS de varias maneras:

• Ocultación de la dirección IP real del servidor — los atacantes solo ven la IP del proxy, no la de su servidor principal
• Filtrado de tráfico malicioso — el proxy analiza las solicitudes y bloquea las sospechosas
• Distribución de carga — varios servidores proxy distribuyen el tráfico entre los servidores backend
• Rate limiting — limitación de la cantidad de solicitudes desde una dirección IP
• Cacheo de contenido estático — reduce la carga en el servidor principal

Es importante entender que los proxies no son una panacea para todos los tipos de DDoS. Ataques volumétricos poderosos pueden saturar el ancho de banda hasta el servidor proxy. Por lo tanto, los proxies son efectivos en combinación con otros métodos de protección: CDN, servicios anti-DDoS en la nube (Cloudflare, AWS Shield), firewalls.

Tipos de proxies para protección contra DDoS: inversos vs directos

Para protegerse contra DDoS, se utilizan dos tipos principales de servidores proxy:

Proxies inversos (Reverse Proxy)

Un proxy inverso se coloca frente a su servidor web y acepta todas las solicitudes entrantes de los clientes. Los clientes interactúan solo con el proxy, sin conocer la dirección IP real de su servidor. Esta es la herramienta principal para protegerse contra DDoS.

Soluciones populares para proxies inversos:

• Nginx — servidor web rápido y ligero con funciones de proxy inverso
• HAProxy — balanceador de carga especializado con potentes capacidades de filtrado
• Apache mod_proxy — módulo para Apache, menos eficiente que Nginx
• Varnish — acelerador HTTP enfocado en el cacheo

Proxies directos (Forward Proxy)

Los proxies directos se utilizan del lado del cliente para solicitudes salientes. En el contexto de protección contra DDoS, se utilizan con menos frecuencia, pero pueden ser útiles para:

• Ocultar las direcciones IP de sus servidores al acceder a API externas
• Distribuir el tráfico saliente a través de múltiples direcciones IP
• Eludir bloqueos al recopilar información sobre posibles ataques

Para estas tareas, son adecuados los proxies residenciales — tienen direcciones IP reales de usuarios domésticos y parecen tráfico normal, lo que dificulta su detección y bloqueo.

Configuración de un proxy inverso en Nginx para proteger el servidor

Nginx es una de las herramientas más populares para crear un proxy inverso. Procesa rápidamente las solicitudes entrantes, soporta limitación de tasa y puede filtrar tráfico sospechoso.

Configuración básica de un proxy inverso

Instale Nginx en un servidor separado que reciba todo el tráfico entrante. El servidor web real debe estar oculto detrás del proxy y recibir solicitudes solo de él.

# /etc/nginx/nginx.conf

http {
    # Limitación de conexiones desde una IP
    limit_conn_zone $binary_remote_addr zone=conn_limit:10m;
    limit_conn conn_limit 10;

    # Limitación de solicitudes (rate limiting)
    limit_req_zone $binary_remote_addr zone=req_limit:10m rate=10r/s;
    limit_req zone=req_limit burst=20 nodelay;

    # Timeouts para protección contra Slowloris
    client_body_timeout 10s;
    client_header_timeout 10s;
    keepalive_timeout 5s 5s;
    send_timeout 10s;

    upstream backend {
        # IP de su servidor web real
        server 192.168.1.100:80;
        # Se pueden agregar varios servidores para balanceo
        # server 192.168.1.101:80;
    }

    server {
        listen 80;
        server_name example.com;

        location / {
            # Pasar solicitudes al backend
            proxy_pass http://backend;
            
            # Pasar la IP original del cliente
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header Host $host;
            
            # Timeouts para el proxy
            proxy_connect_timeout 5s;
            proxy_send_timeout 10s;
            proxy_read_timeout 10s;
        }
    }
}

Bloqueo de User-Agents sospechosos

Muchos ataques DDoS utilizan bots con User-Agents característicos. Agregue reglas para su bloqueo:

# Bloqueo de bots conocidos
map $http_user_agent $bad_bot {
    default 0;
    ~*bot 1;
    ~*crawler 1;
    ~*spider 1;
    ~*scraper 1;
    "" 1; # User-Agent vacío
}

server {
    listen 80;
    server_name example.com;

    if ($bad_bot) {
        return 403;
    }

    location / {
        proxy_pass http://backend;
    }
}

Geo-bloqueo de países no deseados

Si su servicio opera solo para ciertos países, puede bloquear el tráfico de otras regiones utilizando el módulo GeoIP:

# Instalación del módulo GeoIP
# apt-get install nginx-module-geoip

load_module modules/ngx_http_geoip_module.so;

http {
    geoip_country /usr/share/GeoIP/GeoIP.dat;

    # Permitir solo tráfico de Rusia y Ucrania
    map $geoip_country_code $allowed_country {
        default no;
        RU yes;
        UA yes;
    }

    server {
        listen 80;
        server_name example.com;

        if ($allowed_country = no) {
            return 403;
        }

        location / {
            proxy_pass http://backend;
        }
    }
}

HAProxy para distribución de carga y filtrado de tráfico

HAProxy es un potente balanceador de carga con capacidades avanzadas de filtrado de tráfico. Soporta listas de control de acceso (ACL) complejas para bloquear ataques a nivel de aplicación.

Configuración básica de HAProxy

# /etc/haproxy/haproxy.cfg

global
    maxconn 50000
    # Registro
    log /dev/log local0
    log /dev/log local1 notice

defaults
    mode http
    log global
    option httplog
    option dontlognull
    
    # Timeouts
    timeout connect 5s
    timeout client 30s
    timeout server 30s
    
    # Limitación del tamaño de la solicitud (protección contra POST flood)
    maxconn 3000

frontend http_front
    bind *:80
    
    # Limitación de tasa: máximo 100 solicitudes en 10 segundos desde una IP
    stick-table type ip size 100k expire 30s store http_req_rate(10s)
    http-request track-sc0 src
    http-request deny if { sc_http_req_rate(0) gt 100 }
    
    # Bloqueo de solicitudes sin encabezado Host
    acl has_host hdr(host) -m found
    http-request deny if !has_host
    
    # Bloqueo de User-Agents sospechosos
    acl bad_bot hdr_sub(User-Agent) -i bot crawler spider scraper
    http-request deny if bad_bot
    
    # Pasar al backend
    default_backend web_servers

backend web_servers
    balance roundrobin
    option httpchk GET /health
    
    # Lista de servidores backend
    server web1 192.168.1.100:80 check
    server web2 192.168.1.101:80 check
    server web3 192.168.1.102:80 check

Protección contra HTTP Flood con ACL

HTTP Flood es un ataque en el que el atacante envía una gran cantidad de solicitudes HTTP legítimas. HAProxy permite crear reglas complejas para su detección:

frontend http_front
    bind *:80
    
    # Seguimiento de la cantidad de solicitudes desde una IP
    stick-table type ip size 100k expire 30s store http_req_rate(10s),conn_cur
    http-request track-sc0 src
    
    # Bloqueo al exceder límites
    acl too_many_requests sc_http_req_rate(0) gt 50
    acl too_many_connections sc_conn_cur(0) gt 10
    
    http-request deny deny_status 429 if too_many_requests
    http-request deny deny_status 429 if too_many_connections
    
    # Bloqueo de solicitudes a rutas inexistentes (escaneo)
    acl valid_path path_beg /api /static /login /
    http-request deny if !valid_path
    
    default_backend web_servers

Whitelist de direcciones IP confiables

Cree una lista blanca para direcciones IP confiables (por ejemplo, sus direcciones de oficina o socios) que no estarán sujetas a limitación de tasa:

frontend http_front
    bind *:80
    
    # Whitelist de IP confiables
    acl whitelist src 203.0.113.0/24 198.51.100.50
    
    # Limitación de tasa solo para IP no en la whitelist
    stick-table type ip size 100k expire 30s store http_req_rate(10s)
    http-request track-sc0 src if !whitelist
    http-request deny if { sc_http_req_rate(0) gt 100 } !whitelist
    
    default_backend web_servers

Uso de proxies residenciales para ocultar la infraestructura

Además de los proxies inversos frente a su servidor, se pueden utilizar proxies residenciales para una protección adicional de la infraestructura. Esto es especialmente relevante si necesita:

• Ocultar las direcciones IP de sus servidores de monitoreo — si está rastreando ataques DDoS o recopilando información sobre amenazas, los proxies residenciales ayudarán a ocultar sus acciones
• Acceder a API externas sin revelar la infraestructura — sus servidores pueden hacer solicitudes a través de proxies residenciales, lo que dificultará su detección
• Probar la protección contra DDoS — simular ataques desde diferentes direcciones IP para verificar la efectividad de sus filtros

Los proxies residenciales tienen direcciones IP de usuarios domésticos reales, lo que los hace indistinguibles del tráfico normal. Esto dificulta su bloqueo y permite eludir restricciones geográficas.

Ejemplo: Monitoreo de amenazas a través de proxies residenciales

Supongamos que desea rastrear la actividad de botnets que pueden atacar su servicio. Utilizando proxies residenciales, puede recopilar información sin revelar las direcciones IP de sus servidores:

import requests

# Configuración del proxy residencial
proxies = {
    'http': 'http://username:password@residential-proxy.com:8080',
    'https': 'http://username:password@residential-proxy.com:8080'
}

# Recopilación de información sobre amenazas potenciales
threat_sources = [
    'http://suspicious-site1.com',
    'http://suspicious-site2.com'
]

for source in threat_sources:
    try:
        response = requests.get(source, proxies=proxies, timeout=5)
        # Análisis de la respuesta para identificar patrones de ataque
        print(f"Status: {response.status_code}, IP: {response.headers.get('X-Your-IP')}")
    except Exception as e:
        print(f"Error accessing {source}: {e}")

Reglas de filtrado: cómo distinguir un ataque del tráfico legítimo

La principal dificultad para protegerse contra DDoS a nivel de aplicación (L7) es distinguir el tráfico malicioso del tráfico legítimo. Los ataques modernos imitan el comportamiento de usuarios reales, lo que dificulta su detección.

Señales de un ataque DDoS

• Aumento brusco en la cantidad de solicitudes — de 2 a 10 veces más que lo habitual en un corto período
• Solicitudes con el mismo User-Agent — los bots a menudo utilizan el mismo User-Agent
• Ausencia de Referer — solicitudes directas sin provenir de otras páginas
• Solicitudes homogéneas — accesos a la misma URL con mínimas variaciones
• Ausencia de JavaScript — los bots no ejecutan código JS en la página
• Bajo tiempo en la página — los bots cierran la conexión inmediatamente después de recibir una respuesta
• Rangos de IP sospechosos — solicitudes masivas desde una misma subred

Filtrado en múltiples niveles

La protección efectiva utiliza varios niveles de filtrado:

Ejemplo: Desafío de JavaScript en Nginx

Una forma simple de filtrar bots es requerir la ejecución de JavaScript para establecer cookies:

server {
    listen 80;
    server_name example.com;

    # Verificación de la existencia de cookies
    set $has_cookie 0;
    if ($http_cookie ~* "verified=true") {
        set $has_cookie 1;
    }

    # Si no hay cookie, mostramos el desafío JS
    location / {
        if ($has_cookie = 0) {
            return 200 '
                <html>
                <head><title>Verificación</title></head>
                <body>
                <script>
                    document.cookie = "verified=true; path=/";
                    window.location.reload();
                </script>
                <noscript>Por favor, habilite JavaScript</noscript>
                </body>
                </html>
            ';
        }

        proxy_pass http://backend;
    }
}

Monitoreo y respuesta a DDoS en tiempo real

La protección efectiva contra DDoS requiere monitoreo constante del tráfico y respuesta rápida a anomalías. Configure un sistema de monitoreo que rastree métricas clave:

• Cantidad de solicitudes por segundo — un aumento brusco puede indicar un ataque
• Cantidad de direcciones IP únicas — DDoS a menudo proviene de muchas IPs
• Porcentaje de errores 4xx/5xx — un aumento en errores puede ser un signo de sobrecarga
• Tiempo de respuesta del servidor — un aumento en la latencia indica problemas
• Consumo de recursos — CPU, memoria, tráfico de red

Herramientas de monitoreo

Configuración de alertas en Prometheus

Cree reglas para alertar automáticamente al detectar anomalías:

# prometheus_alerts.yml

groups:
  - name: ddos_detection
    interval: 10s
    rules:
      # Alerta por aumento brusco de solicitudes
      - alert: HighRequestRate
        expr: rate(nginx_http_requests_total[1m]) > 1000
        for: 1m
        labels:
          severity: warning
        annotations:
          summary: "Se ha detectado una alta tasa de solicitudes"
          description: "La tasa de solicitudes es {{ $value }} req/s"

      # Alerta por aumento de errores 5xx
      - alert: HighErrorRate
        expr: rate(nginx_http_requests_total{status=~"5.."}[5m]) > 10
        for: 2m
        labels:
          severity: critical
        annotations:
          summary: "Alta tasa de errores 5xx"
          description: "Errores 5xx: {{ $value }} req/s"

      # Alerta por alto uso de CPU
      - alert: HighCPUUsage
        expr: 100 - (avg by(instance) (irate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 80
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "Alto uso de CPU"
          description: "El uso de CPU es {{ $value }}%"

Respuesta automática con Fail2ban

Fail2ban analiza logs y bloquea automáticamente direcciones IP que superan los límites de solicitudes:

# /etc/fail2ban/jail.local

[nginx-req-limit]
enabled = true
filter = nginx-req-limit
logpath = /var/log/nginx/access.log
maxretry = 100
findtime = 60
bantime = 3600
action = iptables-multiport[name=ReqLimit, port="http,https", protocol=tcp]

# /etc/fail2ban/filter.d/nginx-req-limit.conf
[Definition]
failregex = ^<HOST> -.*"(GET|POST).*HTTP.*"
ignoreregex =

Protección en múltiples niveles: combinación de proxies con otros métodos

Los servidores proxy son un elemento importante de la protección contra DDoS, pero son más efectivos en combinación con otros métodos. Analicemos la arquitectura de protección en múltiples niveles:

Nivel 1: Protección de red (L3/L4)

• Servicios anti-DDoS en la nube — Cloudflare, AWS Shield, Google Cloud Armor filtran el tráfico antes de que llegue a sus servidores
• Firewalls hardware — equipo especializado para filtrar tráfico de red
• BGP blackholing — redirigir tráfico malicioso a un "agujero negro" a nivel del proveedor

Nivel 2: CDN y cacheo

• CDN (Content Delivery Network) — distribuye contenido estático a través de múltiples servidores, reduciendo la carga en el origen
• Cacheo en proxies — Varnish, Nginx cachean páginas populares y las entregan sin consultar al backend
• Optimización de contenido — minificación de CSS/JS, compresión de imágenes reduce el volumen de tráfico

Nivel 3: Proxies y balanceo (L7)

• Proxies inversos — Nginx, HAProxy filtran solicitudes a nivel de aplicaciones
• Balanceo de carga — distribución de carga entre varios servidores backend
• Limitación de tasa — limitación de la cantidad de solicitudes desde una IP
• WAF (Web Application Firewall) — ModSecurity, AWS WAF bloquean ataques a aplicaciones web

Nivel 4: Optimización del backend

• Optimización de base de datos — índices, cacheo de consultas, réplicas de lectura
• Procesamiento asíncrono — tareas pesadas se ejecutan en segundo plano a través de colas (RabbitMQ, Redis)
• Escalado horizontal — adición de nuevos servidores a medida que aumenta la carga

Ejemplo de arquitectura

Cliente
  ↓
Cloudflare (anti-DDoS L3/L4, CDN)
  ↓
Nginx proxy inverso (limitación de tasa, filtrado)
  ↓
HAProxy (balanceo de carga)
  ↓
Servidores backend (aplicación web)
  ↓
Base de datos (con replicación)

Esta arquitectura proporciona protección en todos los niveles: red, transporte, aplicación. Incluso si un ataque supera un nivel, el siguiente lo detendrá.

Uso de proxies de centros de datos para una capa adicional

En algunos casos, tiene sentido agregar proxies de centros de datos como una capa intermedia entre la CDN y sus servidores. Proporcionan alta velocidad de procesamiento y pueden realizar filtrado adicional de tráfico. Los proxies de centros de datos son más baratos que los residenciales y móviles, lo que los convierte en una solución económica para manejar grandes volúmenes de tráfico.

Conclusión

La protección contra ataques DDoS utilizando servidores proxy es un método efectivo que permite filtrar tráfico malicioso, ocultar direcciones IP reales de los servidores y distribuir la carga. Los proxies inversos basados en Nginx o HAProxy ofrecen una configuración flexible de reglas de filtrado, limitación de tasa y bloqueo de solicitudes sospechosas.

Puntos clave que hemos revisado:

• Proxies inversos (Nginx, HAProxy) — herramienta principal de protección a nivel de aplicaciones (L7)
• Limitación de tasa y filtrado por User-Agent, reputación IP ayudan a filtrar la mayoría de los ataques
• Proxies residenciales son útiles para ocultar la infraestructura de monitoreo y recopilar información sobre amenazas
• La protección en múltiples niveles (CDN + proxies + WAF + optimización del backend) asegura la máxima resiliencia
• Monitoreo y respuesta automática son críticos para la detección y bloqueo rápido de ataques

Recuerde que los ataques DDoS están en constante evolución, por lo que el sistema de protección requiere actualizaciones y pruebas regulares. Realice pruebas de carga, analice logs, actualice reglas de filtrado y esté atento a nuevos métodos de ataque.

Si planea construir un sistema de protección en múltiples niveles utilizando proxies, le recomendamos considerar proxies residenciales para ocultar infraestructura crítica y proxies de centros de datos para procesamiento de grandes volúmenes de tráfico a alta velocidad. La combinación de diferentes tipos de proxies proporciona un equilibrio óptimo entre seguridad, rendimiento y costo.