¿Necesito protección DDoS en un servidor dedicado?

¿Qué es la protección DDoS y qué ataques detiene?

La protección DDoS es un filtrado que se coloca por delante de tu servidor: descarta el tráfico de ataque antes de que ese tráfico llegue a tu puerto de red. Un ataque distribuido de denegación de servicio (DDoS) envía tráfico desde muchas máquinas a la vez para agotar un enlace, un firewall o una aplicación. Los ataques se dividen en dos grupos:

• Ataques en la capa de red (capas 3 y 4). Inundaciones de paquetes: SYN floods, ACK floods, floods de UDP e ICMP, y ataques de reflexión como la amplificación por DNS o memcached. Las inundaciones volumétricas intentan llenar el propio enlace, así que solo ayuda filtrar antes del enlace.
• Ataques en la capa de aplicación (capa 7). Inundaciones de peticiones HTTP con aspecto real, peticiones que evitan la caché o conexiones lentas como Slowloris. Necesitan poco ancho de banda. En su lugar agotan la CPU, los workers web o la base de datos.

La documentación de Cloudflare enumera estos vectores en dos rulesets gestionados: uno para la capa de red y otro para HTTP. Un servidor puede repeler por sí solo algunas inundaciones de capa 7, pero nunca una inundación mayor que su enlace de subida.

¿Cuál es la diferencia entre protección permanente y bajo demanda?

La protección permanente inspecciona tu tráfico todo el tiempo; la protección bajo demanda redirige tu tráfico a una red de limpieza solo cuando empieza un ataque. Limpiar significa enviar el tráfico a través de una red de filtrado que descarta los paquetes de ataque y reenvía el resto limpio hacia ti.

• Permanente. Sin retardo por el cambio, pero cada paquete pasa por el filtro. Un CDN o un proxy inverso delante de una web funciona así.
• Bajo demanda. El tráfico fluye directamente hacia ti hasta que hay un ataque; entonces el proveedor anuncia tu prefijo IP desde su propia red. El modo bajo demanda de Magic Transit de Cloudflare activa ese anuncio durante un ataque y lo desactiva después. Hasta el cambio, el ataque te llega.

Para un único servidor alquilado, el filtrado permanente delante de cada servicio público es la opción práctica.

¿Quién necesita protección DDoS en un servidor dedicado y quién no?

La necesitas cuando desconocidos conocen tu dirección IP y tienen motivos para tumbar el servicio. Normalmente puedes prescindir de ella cuando solo tú y las personas de confianza os conectáis a la máquina.

¿Protege Ironatoll mi servidor dedicado frente a ataques DDoS?

Ironatoll vende bare metal, no una red filtrada. La regla, palabra por palabra: Frente a ataques DDoS no prometemos nada más allá del tratamiento por defecto de la red del centro de datos. No publicamos capacidad de mitigación, ni alcance de filtrado, ni tiempo de respuesta, porque no prometemos nada de eso.

Eso mantiene los planes baratos, y hace que un servicio UDP público sea tu proyecto a proteger. Para tráfico de juegos filtrado, pon un servicio de filtrado delante del servidor. O elige un proveedor que venda mitigación con cifras por escrito. Nuestro ranking de proveedores de servidores dedicados offshore compara proveedores con los mismos criterios.

Según la comprobación de Ironatoll sobre 30 October 2026, un servidor dedicado comparable a Atoll 64 costaba una mediana de $337.49 en 14 hosts que aceptan criptomonedas sin identificación; Ironatoll cobra $72.62. Esa diferencia de 78% deja margen para un plan de CDN o un proxy filtrado. Todos los planes están en cuánto cuesta un servidor dedicado Ironatoll.

¿Cómo protejo un sitio web en un servidor dedicado frente a DDoS?

Pon un reverse proxy o una CDN delante del sitio web y luego oculta la dirección IP real del servidor. Cloudflare es una opción. Estos puntos provienen de su documentación, leída el 30 de octubre de 2026:

• La protección DDoS viene con todos los planes de Cloudflare, incluido el plan gratuito. Cloudflare la indica como protección estándar y sin límite de uso para las capas 3 a 7.
• Solo los registros proxied están protegidos. El proxy funciona con registros A, AAAA y CNAME y cubre tráfico HTTP y HTTPS. Un registro solo DNS muestra tu IP de origen a cualquiera que lo consulte.
• El tráfico web proxied usa puertos fijos. HTTP: 80, 8080, 8880, 2052, 2082, 2086 y 2095. HTTPS: 443, 2053, 2083, 2087, 2096 y 8443.
• Acepta tráfico web solo de Cloudflare. Cloudflare publica sus rangos en cloudflare.com/ips y recomienda bloquear todo lo demás en el origen. Un atacante que descubra la IP real, en antiguos registros DNS o en la configuración de correo, puede atacar el servidor directamente.
• Otros protocolos necesitan Spectrum. SSH, los puertos de juegos y otros servicios TCP o UDP no están cubiertos por un registro proxied. Spectrum para todos los puertos TCP y UDP está solo en el plan Enterprise.

Cada servidor Ironatoll tiene una dirección IPv4, así que un registro solo DNS que apunte a ella, como un registro de correo, revela el origen.

¿Cómo limito la tasa de conexiones con nftables?

nftables puede limitar las conexiones nuevas por dirección de origen, lo que frena floods pequeños e intentos de fuerza bruta, pero no puede detener un flood que satura tu enlace. Cuando nftables ve un paquete, ese paquete ya ha consumido tu ancho de banda.

La wiki de nftables mantiene un limitador de tasa por IP de origen en un conjunto dinámico. Cada entrada caduca a los 60 segundos sin tráfico. El ruleset de abajo aplica esa idea a SSH, acepta tráfico web y descarta el resto. Detrás de Cloudflare, acepta los puertos 80 y 443 solo desde un conjunto de sus rangos publicados. Cárgalo con nft -f /etc/nftables.conf, mantén una segunda sesión SSH abierta y luego ejecuta systemctl enable nftables. El límite de SSH cubre IPv4; añade un conjunto ipv6_addr con ip6 saddr para IPv6.

#!/usr/sbin/nft -f
flush ruleset

table inet filter {
  set ssh_meter {
    type ipv4_addr
    timeout 60s
    flags dynamic
  }

  chain input {
    type filter hook input priority 0; policy drop;
    ct state established,related accept
    iif "lo" accept
    meta l4proto ipv6-icmp accept
    icmp type echo-request limit rate 10/second accept
    tcp dport 22 ct state new update @ssh_meter { ip saddr limit rate 10/minute } accept
    tcp dport { 80, 443 } accept
  }
}

# http block
limit_req_zone $binary_remote_addr zone=perip:10m rate=10r/s;

server {
    location / {
        limit_req zone=perip burst=20 nodelay;
    }
}

¿Qué más reduce el riesgo sin comprar nada?

Da menos que ver a los atacantes:

• Cierra todos los puertos que no sirvas. Una interfaz web de Proxmox, una base de datos o una API de LLM van detrás de un túnel SSH.
• Mantén los servicios privados fuera de la máquina que ejecuta los públicos. Un flood contra un servidor de juegos tumba todo lo que comparte su enlace.
• Nunca publiques la IP de origen de un sitio web proxied, ni en el historial DNS ni en las cabeceras de correo.

Nuestra comparativa de servidor dedicado o VPS explica cuándo merece la pena el bare metal para un servicio público.