Ataques DDoS: qué puede frenar el proveedor y qué depende de vos

Tres ataques distintos con el mismo nombre

Por qué el volumen no se frena en tu servidor

Un servidor cloud de InHosting tiene un puerto de hasta 100 Mbps. Un ataque volumétrico modesto mueve varios gigabits por segundo. Cuando ese tráfico llega a tu placa de red, el caño ya está lleno: no importa qué reglas tenga el firewall del servidor, porque descartar paquetes no libera el enlace que ya ocuparon.

Por eso el tráfico de volumen se trata antes, en la red del proveedor o en la de un servicio especializado que lo absorbe y deja pasar solo lo legítimo. Y cuando el ataque es tan grande que pone en riesgo a los demás clientes, el proveedor puede descartar todo el tráfico hacia la IP atacada. Ese servicio queda fuera de línea, pero el resto de la red sigue funcionando. Es una medida dura y a veces la única posible.

Protocolo: lo que Linux ya hace por vos

Contra la inundación de conexiones a medio abrir (SYN flood), el núcleo de Linux usa SYN cookies: cuando la cola de conexiones se llena, deja de guardar estado para las nuevas y las valida con un cálculo. Viene activado en Debian, Ubuntu y AlmaLinux; comprobalo así:

sysctl net.ipv4.tcp_syncookies
# tiene que responder: net.ipv4.tcp_syncookies = 1
ss -s
# resume cuántas conexiones hay en cada estado
ss -tan state syn-recv | wc -l
# cuenta las conexiones a medio abrir

• Miles de conexiones en SYN-RECV que no avanzan indican un ataque de protocolo, no un pico de visitas.
• Si el volumen supera lo que el servidor puede descartar, pasale esos números a tu proveedor: el filtro tiene que ir antes.

Aplicación: donde vos tenés el control

1. Caché de página. Un pedido que se responde con una copia guardada cuesta una fracción de uno que ejecuta PHP y consulta la base. Es la defensa más barata contra una avalancha de pedidos, y está explicada en las tres capas de caché.
2. Límites por IP en las rutas caras: el acceso al administrador del CMS, la búsqueda, el carrito, la API. Nginx lo hace con limit_req, como en el ejemplo de abajo.
3. Bloqueo automático de quien insiste. Con Fail2ban, una IP que falla el login o dispara errores en serie queda afuera un rato. En firewall y Fail2ban está cómo armarlo.
4. Un CDN adelante, que absorbe buena parte del tráfico y no deja ver la IP real de tu servidor.
5. Alertas. Enterarte por un aviso de carga alta y no por un cliente que llama.

Un ejemplo para Nginx. La primera línea va en el bloque http y crea una zona que lleva la cuenta por IP; la de adentro limita el login de WordPress a diez intentos por minuto, con un margen de cinco. Lo que se pase recibe un error 503.

limit_req_zone $binary_remote_addr zone=acceso:10m rate=10r/m;
server {
    # ...
    location = /wp-login.php {
        limit_req zone=acceso burst=5 nodelay;
        # acá va la misma configuración de PHP que usa el resto del sitio
    }
}

No dejes la IP de tu servidor a la vista

Un CDN protege solo si el atacante no conoce la dirección real del servidor. Estas son las fugas más comunes:

• Subdominios como mail., ftp. o webmail. que apuntan directo a la misma IP del sitio.
• El correo enviado desde el propio servidor: la IP queda en los encabezados de cada mensaje.
• Registros DNS viejos. Hay servicios que guardan el historial de qué IP tuvo cada dominio: si el sitio estuvo un tiempo sin CDN, esa IP ya es pública.
• La solución de fondo es aceptar tráfico web solo desde las redes del CDN, con reglas en el firewall del servidor.

Tu servidor también puede ser parte de un ataque

Los ataques de amplificación usan servidores mal configurados de terceros para multiplicar el tráfico: un resolvedor DNS abierto, un NTP con las consultas de estado habilitadas o un memcached expuesto a Internet responden a pedidos chicos con respuestas enormes, dirigidas a la víctima. Si tu VPS tiene alguno de esos servicios escuchando hacia afuera, puede estar participando sin que lo sepas, y tu IP termina en listas de bloqueo.

sudo ss -ulpn
# lista los servicios UDP que escuchan y en qué dirección

• Lo que escuche en 0.0.0.0 o en [::] está abierto a Internet, salvo que el firewall lo impida.
• Si un DNS, un NTP o un memcached no tiene que atender a terceros, limitalo a 127.0.0.1 o cerralo en el firewall.

Durante un ataque

1. Confirmá que es un ataque: muchos orígenes pidiendo lo mismo, o conexiones que no avanzan, sin una campaña ni una publicación que lo explique.
2. Juntá datos: hora de inicio, IP y puerto atacados, las direcciones que más piden y qué páginas. Con ss y el registro de accesos alcanza.
3. Abrí un ticket con esos datos. Con números concretos, quien opera la red puede actuar; con un "no anda nada", primero tiene que averiguar lo que vos ya sabías.
4. Subí la caché al máximo y, si tenés CDN, activá su modo de protección reforzada.
5. No cambies los DNS a las apuradas: con el TTL que ya tienen, el cambio llega tarde y suma confusión.

sudo cut -d " " -f1 /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20
# las 20 IP que más pidieron. Con Apache, el registro está en
# /var/log/apache2/access.log (Debian, Ubuntu) o /var/log/httpd/access_log (AlmaLinux)

Qué preguntarle a tu proveedor antes de necesitarlo

• ¿Qué hacen con un ataque volumétrico contra mi IP: lo filtran, lo desvían o sacan la IP de circulación?
• Si la sacan de circulación, ¿por cuánto tiempo y cómo me entero?
• ¿Cómo reporto un ataque y qué datos necesitan?
• ¿El tráfico del ataque cuenta como consumo mío?
• ¿Puedo poner un servicio de mitigación externo adelante sin problemas?