Volver a los artículos

Qué hacer cuando tu servicio sufre un ataque DDoS

2 de septiembre de 2026
Otros

La mitigación ya está activa en todos los servicios y trabaja sin que la pidas: la protección de RedHosting funciona en dos capas, la red GC, que absorbe ataques volumétricos con capacidad de hasta 20 Tbps antes de que el tráfico llegue a nuestra infraestructura, y un appliance A10 en el borde, que filtra lo que no es volumétrico y pasaría una inspección basada solo en volumen.

Esta guía trata de la otra mitad: la parte que te toca a ti. Reconocer que es un ataque, decidir qué hacer y no empeorarlo por reflejo.

1. ¿Es realmente un ataque?

No toda caída es un ataque, y tratar una sobrecarga común como ataque lleva el diagnóstico por mal camino. Las señales que distinguen una cosa de la otra:

SeñalAtaqueSobrecarga común
InicioRepentino, en segundosGradual, siguiendo el uso
Origen del tráficoMuchas IP sin patrón de públicoLas de siempre
Relación con un eventoNinguna, o justo tras una disputa públicaDifusión, promoción, hora pico
Contenido de las conexionesRepetitivas, sin completar nadaSolicitudes normales, solo que muchas
CPU y memoriaNormales, pero la red se saturaSuben junto con el tráfico

El último punto es el más revelador: en una sobrecarga real la máquina está trabajando; en un ataque volumétrico está ociosa y lo que se saturó es el camino hasta ella.

2. Qué hacer, en orden

  • Anota la hora. Registra cuándo empezó, con el minuto aproximado. Sin eso, encontrar el evento en el log después se vuelve una búsqueda a ciegas.
  • No reinicies una y otra vez. Reiniciar no detiene un ataque, y la máquina pasa más tiempo arrancando que sirviendo.
  • Abre el ticket pronto, con IP, hora y lo que observaste. Cuanto antes el equipo mire el tráfico en vivo, más fácil es ajustar el filtro al patrón de ese ataque específico.
  • Guarda lo que puedas del log de la aplicación y de la salida de ss -tn state established o equivalente. Ese material es lo que permite ajustar la regla después.
  • Avisa a tu comunidad si es un servidor de juego. El silencio durante una caída daña más la reputación que la caída en sí.
⚠️Lo que no funciona: Bloquear IP a mano. En una botnet distribuida los orígenes cambian todo el tiempo, y la lista crece más rápido de lo que puedes mantenerla. Las reglas por patrón de tráfico son las que se sostienen; IP por IP es achicar agua.

3. Decisiones que suelen aparecer

SituaciónDecisión recomendadaRiesgo de ignorarla
Pico de conexiones justo después de un eventoSubir el límite temporalmente y observar el origenBloquear a un jugador o cliente legítimo
Muchas conexiones cortas sin completar nadaFiltrar por firma y cadencia, no por IPAgotar la tabla de estado del firewall
Consultas anormales en un servicio auxiliarAislar el puerto y reducir la exposiciónCaída parcial de todo el ecosistema
El ataque vuelve siempre a la misma horaLlevar el patrón al soporte para una regla permanenteRepetir la mitigación manual cada semana
💡Consejo: En un incidente real, pide en el ticket un informe con la hora, el pico de tráfico y el tipo de filtro aplicado. Ese historial es lo que permite ajustar la regla antes del próximo evento, en lugar de reaccionar otra vez desde cero.

4. Reducir la superficie antes del próximo

La mitad del trabajo se hace cuando no hay ningún ataque.

Revisión que vale la pena hacer cada trimestre

✓Inventario de puertos expuestos. Cada puerto abierto que nadie usa es superficie gratis para el otro lado.
✓Servicios auxiliares cerrados al público: base de datos, panel administrativo, API interna. No necesitan internet abierta.
✓Monitoreo externo, fuera de nuestra red, para confirmar la disponibilidad desde un punto de vista independiente.
✓Un runbook de incidentes con mensajes listos para la comunidad. Redactar un comunicado durante la caída sale mal.
✓Revisión de plugins y módulos: cada uno que no usas es código expuesto sin motivo.
✓IP del servidor fuera de la difusión pública cuando hay una capa delante: publicar la IP de origen evade la protección.

5. Lo que ya es nuestro y no necesitas configurar

  • Mitigación en dos capas en todos los productos (Minecraft, Hytale, VPS, dedicados, sitios y bots), incluida en el precio.
  • Absorción de ataques volumétricos en la red, antes de consumir el ancho de banda de tu servidor.
  • Monitoreo proactivo 24/7.
  • Firewall personalizable y acceso restringido a jugadores autorizados, en los servidores de juego.

Las cifras y el funcionamiento de las dos capas están en redhosting.com.br/protecao.

Durante un incidente

WhatsApp +55 11 98833-3902 es el canal más rápido, las 24 horas, en portugués, inglés, español y alemán. Tickets en financeiro.redhosting.com.br. Los mantenimientos e incidentes en curso aparecen en redhosting.com.br/status.

Preguntas frecuentes

¿Tengo que contratar protección contra DDoS? +
No. La mitigación está incluida en todos los servicios, en dos capas: la red GC, con capacidad de hasta 20 Tbps, y un appliance A10 en el borde de RedHosting. Los detalles están en redhosting.com.br/protecao.
¿Cómo sé si es un ataque o solo sobrecarga? +
La señal más reveladora es la relación entre CPU y red. En una sobrecarga real la máquina está trabajando y los recursos suben con el tráfico; en un ataque volumétrico la máquina está ociosa y lo que se saturó es el camino hasta ella.
¿Debo bloquear las IP del ataque? +
No sirve. En una botnet distribuida los orígenes cambian todo el tiempo y la lista crece más rápido de lo que puedes mantenerla. Lo que se sostiene son reglas por patrón de tráfico.
¿Reiniciar el servidor detiene el ataque? +
No. Y empeora las cosas: la máquina pasa más tiempo arrancando que sirviendo.
¿Qué envío en el ticket durante un ataque? +
IP, hora aproximada de inicio y lo que observaste. Cuanto antes el equipo mire el tráfico en vivo, más fácil es ajustar el filtro al patrón de ese ataque específico.
¿Qué puedo hacer antes del próximo ataque? +
Reducir la superficie: cerrar puertos que nadie usa, sacar los servicios auxiliares de la internet abierta, mantener monitoreo externo y no publicar la IP de origen cuando hay una capa delante.