Proteger un servidor de Project Zomboid frente a ataques DDoS

Quien quiera proteger su servidor de Project Zomboid frente a ataques DDoS tiene que saber primero contra qué dispara un atacante. Un servidor dedicado ocupa exactamente dos puertos UDP, el 16261 y el 16262, y los dos tienen que estar abiertos en la red, porque de lo contrario nadie puede entrar. Este artículo va en el orden que cuenta cuando la cosa se pone seria: primero lo que puedes hacer tú mismo en los próximos diez minutos sin coste añadido, después el punto en el que esas medidas se acaban técnicamente y, al final, lo que tiene que ocurrir antes, en la red.

Todos los datos se refieren al servidor dedicado (aplicación de Steam 380870) sobre Debian 12, Debian 13, Ubuntu 22.04 LTS o Ubuntu 24.04 LTS, tanto para la build 41 como para la build 42. El archivo de configuración se llama servertest.ini y está en ~/Zomboid/Server/, los datos del mundo están en ~/Zomboid/Saves/Multiplayer/. Los comandos están escritos para root; si trabajas como usuario normal, antepón sudo.

Si el ataque está en marcha ahora mismo: no cambies nada en el servertest.ini y no reinicies el servidor. Guarda primero las mediciones (apartado 9), porque cuando el ataque pase habrán desaparecido. Un reinicio cuesta además el tiempo que el servidor necesita para cargar el mundo, y ese tiempo es justo el que el atacante te quiere quitar.

Por qué los servidores de Project Zomboid se convierten en objetivo de ataques DDoS

Project Zomboid es un juego con muerte permanente y un mundo que sigue su curso durante meses. Un corte de conexión en mitad de una situación peligrosa cuesta aquí más que en casi cualquier otro género: el personaje desaparece, y el mundo se acuerda de ello. Justo eso convierte una caída en un arma. Un ataque a las ocho de la tarde alcanza a una comunidad fija, y la alcanza en el punto en el que más tiene que perder.

A eso se suma que el ataque en sí no cuesta nada y no exige ningún conocimiento. Los servicios de ataque de pago, llamados booter o stresser en ese ambiente, se dirigen con unos pocos clics contra una dirección IP y un puerto, y en Project Zomboid el objetivo es siempre el mismo: 16261 UDP. Quien esté enfrentado con un jugador baneado o lleve una comunidad rival tiene así una herramienta en la mano para la que no necesita ni saber ni un dinero digno de mención.

A eso se suma que un servidor de juego tiene que publicar su dirección. Si en el servertest.ini está Public=true, el servidor aparece en el navegador del juego, y un servidor con conexión a Steam es visible de todas formas en el navegador de servidores de Steam. La pregunta no es por tanto nunca si un atacante encontrará tu dirección IP, sino solo qué pasa cuando dispare contra ella.

Técnicamente, la parte más incómoda llega al final: todo el tráfico de juego va por UDP. UDP no tiene un establecimiento de conexión que se pueda exigir, cada paquete va por su cuenta y la dirección de origen se puede falsificar. Un atacante no necesita entonces ni entrar en tu servidor ni dirigirse a él correctamente para generarle carga. Qué es en detalle un ataque DDoS lo explica el artículo ¿Qué es un ataque DDoS?.

Qué puertos necesita de verdad un servidor de Project Zomboid

Un servidor dedicado de Project Zomboid necesita exactamente dos puertos abiertos: 16261 UDP y 16262 UDP. La lista oficial de puertos del juego no menciona un tercero. En el servertest.ini están como dos directivas separadas, y el segundo puerto no sale automáticamente del primero:

DefaultPort=16261
UDPPort=16262
SteamPort1=8766
SteamPort2=8767
RCONPort=27015
RCONPassword=

El reparto de tareas está claro. 16261 UDP transporta el tráfico de juego y el establecimiento de la conexión, y responde a las consultas del navegador de servidores. 16262 UDP es el puerto para la conexión directa de los clientes. Si falta el primero, nadie encuentra el servidor; si falta el segundo, tus jugadores ven la entrada y aun así no pueden entrar. De ahí sale justamente el mensaje de error más conocido del juego, el que dice que el puerto 16262 está cerrado.

Dos puntos que dan problemas con regularidad. Primero: cada instancia del servidor necesita dos puertos UDP libres. Quien tenga un segundo mundo en la misma máquina le asigna un segundo par, por ejemplo 16274 y 16275, y escribe los dos valores en el servertest.ini de la segunda instancia. Segundo: SteamPort1 y SteamPort2 están en el archivo de configuración con 8766 y 8767, pero pertenecen a la conexión con Steam y no al tráfico de juego. Ábrelos solo si tu servidor no aparece en la lista de Steam sin ellos, no por precaución.

Lo que puedes hacer tú mismo antes de gastar dinero

Este apartado es el más largo, y es a propósito. Un servidor bien configurado aguanta por su cuenta los ataques pequeños y medianos, esté alojado donde esté. No te quita de encima un ataque volumétrico, pero sí hace que los ataques baratos queden sin efecto y que, cuando la cosa se ponga seria, tengas cifras en vez de suposiciones.

1. Inventario: qué está escuchando de verdad

Antes de escribir una sola regla, mira qué ofrece tu servidor hacia fuera. No lo adivines, compruébalo:

ss -lntup

La columna interesante es la de la dirección local. 0.0.0.0:16261 y [::]:16261 significan "accesible desde todo internet", 127.0.0.1:27015 significa "solo local" y no necesita ninguna apertura. Contrasta el resultado con tu configuración en vez de fiarte de los valores estándar:

grep -E "^(DefaultPort|UDPPort|SteamPort1|SteamPort2|RCONPort|Public|Open|MaxPlayers|MaxAccountsPerUser)=" ~/Zomboid/Server/servertest.ini

La vista del atacante te la da un escaneo de puertos desde fuera. Como Project Zomboid usa exclusivamente UDP, hace falta el escaneo UDP: un escaneo puramente TCP no muestra siquiera el puerto de juego:

nmap -Pn -sU -p 16261,16262,8766,8767 IP.DE.TU.SERVIDOR
nmap -Pn -p- --min-rate 1000 IP.DE.TU.SERVIDOR

2. Dejar abiertos solo el 16261 y el 16262

Bastan dos aperturas hacia fuera, todo lo demás se restringe o directamente no se publica. Con UFW queda así, y en este orden exacto para que no te quedes fuera de tu propio servidor:

ufw allow 22/tcp comment "SSH"
ufw allow 16261/udp comment "Project Zomboid"
ufw allow 16262/udp comment "Project Zomboid conexión directa"
ufw allow from 203.0.113.10 to any port 27015 proto tcp comment "RCON"
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

Sustituye 203.0.113.10 por tu propia dirección. El orden al activar el firewall decide si te quedas fuera de tu propio servidor o no. Está, con vía de vuelta incluida, en el artículo Configurar el firewall UFW sin quedarte fuera del servidor. Y si aun así ocurre: en los servidores root KVM y en los servidores dedicados de KernelHost llegas al sistema por la consola VNC del área de cliente, que trabaja con independencia de la red del sistema huésped.

Una palabra sobre bases de datos y servicios añadidos: Project Zomboid no necesita ninguno. Lo que esté escuchando en 0.0.0.0 junto al juego viene de una instalación anterior o de un panel de administración, y o bien se enlaza a 127.0.0.1 o bien se apaga.

3. Sacar de internet RCON en el puerto 27015

RCON es el control remoto del servidor y en Project Zomboid corre en 27015 TCP. En el servertest.ini tal como viene está RCONPassword= sin valor. Quien use RCON pone una contraseña aleatoria larga, porque el protocolo transmite sin cifrar, y un puerto RCON accesible con una contraseña débil entrega el servidor entero sin que para ello haga falta un solo paquete de tráfico de ataque.

El camino seguro es no abrir el puerto hacia fuera y llegar hasta él mediante una redirección de puerto por SSH. Después hablas en local con 127.0.0.1:27015:

ssh -N -L 27015:127.0.0.1:27015 root@IP.DE.TU.SERVIDOR

Quien no necesite RCON deja el campo de la contraseña vacío y el puerto cerrado. Un servicio que no es accesible no se puede ni probar a la fuerza ni inundar.

4. Limitar las tasas de paquetes por dirección de origen

Contra los ataques pequeños y los bots mal hechos ayuda un límite superior por dirección de origen. Como los dos puertos de juego están uno al lado del otro, basta una regla para el rango:

iptables -I INPUT -p udp --dport 16261:16262 -m hashlimit --hashlimit-name pz_udp --hashlimit-mode srcip --hashlimit-above 400/sec --hashlimit-burst 600 -j DROP
iptables -L INPUT -n -v

La regla descarta paquetes UDP en cuanto la misma dirección de origen manda de forma sostenida más de 400 paquetes por segundo. El valor es un punto de partida, no una verdad: un servidor con 30 jugadores en la misma ciudad genera bastante más tráfico que uno con cuatro jugadores en distintos rincones del mapa, y quien ajusta demasiado fino echa fuera a sus propios jugadores. Mide primero una semana de funcionamiento normal y pon después el límite en un múltiplo del valor punta.

Dos avisos al respecto. Las reglas de iptables a secas desaparecen tras un reinicio; en Debian y Ubuntu se guardan así:

apt-get install -y iptables-persistent
netfilter-persistent save

Y con UFW, ese tipo de reglas van en /etc/ufw/before.rules, porque de lo contrario desaparecen con el siguiente ufw reload. Comprueba con los contadores de aciertos de iptables -L INPUT -n -v si la regla llega a alcanzarse siquiera. Si los contadores se quedan a cero, está en el sitio equivocado.

5. Aliviar el seguimiento de conexiones

Un cuello de botella que se pasa por alto a menudo está en el kernel. El seguimiento de conexiones crea también para UDP una entrada por dirección de origen y puerto, y un flood con remitentes falsificados llena esa tabla en segundos. Si se desborda, el servidor descarta también los paquetes legítimos, y en el registro aparece "nf_conntrack: table full". El estado y el límite los muestra:

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max

El tráfico de juego de Project Zomboid no necesita seguimiento de estado, porque UDP no tiene estado. Por eso puedes mantener los dos puertos de juego fuera de la tabla:

iptables -t raw -I PREROUTING -p udp --dport 16261:16262 -j NOTRACK

Eso alivia el kernel de forma notable. Importante: la regla solo encaja mientras el servidor reciba los paquetes directamente. Quien tenga delante una traducción de direcciones, por ejemplo en un montaje con contenedores y reenvío de puertos, no debe ponerla, porque entonces el camino de vuelta ya no se puede asignar.

6. Asegurar la entrada y los slots

Las líneas siguientes no cuestan nada y funcionan contra todo lo que llega por la vía de entrada normal:

Password=UNA-CLAVE-ALEATORIA-LARGA
Open=false
MaxAccountsPerUser=1
MaxPlayers=32
DenyLoginOnOverloadedServer=true

Password es la contraseña común del servidor y está separada de la cuenta de cada jugador. Open=false significa que solo pueden entrar las cuentas que un administrador haya creado antes, y esa es la whitelist del juego. MaxAccountsPerUser limita cuántas cuentas puede crear un único usuario de Steam en tu servidor, y el valor por defecto 0 significa sin límite. MaxPlayers viene de fábrica en 32, y por encima de ese valor la documentación avisa expresamente de carga deficiente del mapa y de desincronización.

PingLimit es la trampa en este punto. La directiva echa fuera a los jugadores a partir de una latencia en milisegundos y viene de fábrica en 0, es decir, desactivada. Bajo un ataque, la latencia que sube primero es la de tus propios jugadores, así que un valor estrecho expulsa justo a la gente que quieres conservar. Deja el límite desactivado o ponlo con generosidad.

Y algo tiene que quedar claro: una whitelist protege tu lógica de juego, no tu línea. Un atacante que inunda tu servidor no quiere entrar. Sus paquetes se rechazan, pero han llegado igualmente, y ese es justo el punto.

7. La comprobación de mods al conectar es el segundo más caro de tu servidor

Project Zomboid comprueba al conectar más que una contraseña. La lista de mods del servidor está en dos líneas del servertest.ini: WorkshopItems contiene los identificadores numéricos del Workshop y Mods los identificadores de carga de los mods, los dos separados por punto y coma. Al entrar, el cliente coteja esa lista, descarga automáticamente por Steam los contenidos del Workshop que le falten y solo después recibe los datos del mundo. Además, con DoLuaChecksum=true el servidor compara las sumas de comprobación de los archivos del juego y echa fuera a los clientes cuyos archivos no encajan con los suyos.

Para un atacante eso es justamente lo interesante, porque el trabajo se hace antes de la participación real en la partida. Cada intento de conexión le cuesta al servidor tiempo de proceso para la versión, la suma de comprobación, la lista de mods y los datos del mapa, incluido el intento que al final se rechaza. Una lista de mods larga encarece cada uno de esos intentos. Por eso una avalancha de intentos de entrada resulta más eficaz en un servidor muy modificado que en uno sin cambios, y para ello necesita una fracción del ancho de banda de un ataque volumétrico. El juego trae contra eso dos frenos integrados:

DenyLoginOnOverloadedServer=true
LoginQueueEnabled=true
LoginQueueConnectTimeout=60

DenyLoginOnOverloadedServer rechaza las conexiones nuevas mientras el servidor esté sobrecargado, en lugar de arrastrar consigo la partida en curso. LoginQueueEnabled pone a quienes entran en una cola en vez de atenderlos a la vez, y LoginQueueConnectTimeout fija cuánto puede durar una entrada, con 60 segundos por defecto y un rango permitido de 20 a 1200.

Hay un detalle que viene al caso porque se resuelve mal a menudo: en los servidores Linux existe un fallo documentado por el que DoLuaChecksum da falsas alarmas y no deja entrar a los jugadores. Por eso los operadores desactivan la comprobación. Es comprensible, pero retira un control que mantiene fuera a los clientes con archivos de juego modificados. Quien tenga que desactivarla debería poner con más rigor todavía la contraseña del servidor, la whitelist y el límite de cuentas.

8. Lista de servidores, UPnP y la propia dirección

Aquí conviene la honestidad antes que el pensamiento mágico: tu dirección IP no se puede mantener en secreto. Public=true muestra el servidor en el navegador del juego, y un servidor con conexión a Steam es visible de todas formas, según la documentación, en el navegador de servidores de Steam. Public=false te quita por tanto la visibilidad para los jugadores nuevos, sin hacerte invisible.

Public=true
PublicName=Mi servidor de Zomboid
UPnP=false
server_browser_announced_ip=

UPnP viene de fábrica en true y hace que el servidor intente abrirse él mismo un puerto en una puerta de enlace a internet. En un servidor alquilado no existe tal puerta de enlace, el intento cae en el vacío y conviene desactivarlo. server_browser_announced_ip se queda vacío, salvo que tu servidor tenga varias direcciones y deba aparecer bajo una de ellas en concreto. Ese campo exacto lo vuelves a necesitar más adelante, cuando cambies a una IP de protección dedicada.

Dos costumbres ayudan más que cualquier ajuste. No publiques tú mismo la dirección IP en bruto en ninguna parte, ni en el canal de Discord ni en la página del proyecto, y dale a tus jugadores un nombre de host. El clásico al cambiar de dirección son los registros DNS antiguos: un registro A olvidado que apunte a la dirección anterior deja sin efecto cualquier cambio.

9. Medir mientras todo funciona con normalidad

El paso más importante es el que casi nadie da antes de tiempo: crear una base de comparación mientras todo está tranquilo. Sin un valor normal no puedes decir, después de un incidente, si 40.000 paquetes por segundo eran muchos o simplemente un sábado por la tarde. Con apt-get install -y vnstat sysstat la medición corre de forma permanente. Durante un incidente bastan cuatro comandos:

sar -n DEV 1 10
ip -s link show eth0
tcpdump -ni eth0 "udp port 16261 or udp port 16262" -c 200 -q
journalctl -u zomboid --since "-15 min" | tail -50

Los dos primeros muestran la tasa de paquetes y los contadores de descartes de la interfaz, el tercero una muestra breve del tráfico y el cuarto los mensajes del servidor, siempre que corra como servicio de systemd (ajusta el nombre del servicio). Con tcpdump vale una norma: limítalo siempre con -c, porque una captura a plena carga añade trabajo a un servidor que ya está saturado. Cómo interpretar los valores lo explica Detectar un ataque DDoS.

Dónde se acaban estas medidas: ancho de banda y tasa de paquetes

Llega ahora la parte que ningún archivo de configuración puede resolver. Todas las medidas anteriores corren en tu servidor, es decir, al final de la línea. Una regla de firewall decide sobre un paquete que ya ha pasado por el cable. Puedes descartarlo, pero no puedes hacer que no se haya enviado.

Echa cuentas una vez. Un servidor de juego típico está conectado a 1 Gbit/s, o sea, 125 megabytes por segundo, y la línea se llena en cuanto alguien manda más. La segunda magnitud es la tasa de paquetes, y golpea a menudo antes que el ancho de banda: con paquetes pequeños de 64 bytes caben en 1 Gbit/s unos 1,49 millones de paquetes por segundo, mientras que un kernel de servidor normal procesa, según la CPU y la tarjeta de red, solo unos cientos de miles antes de empezar a descartar. Un ataque que no llena ni un tercio de tu línea puede por tanto dejar tu servidor fuera de combate. Los operadores lo viven como "pero si la carga no era ni alta y aun así se cayó todo".

Los ataques habituales contra comunidades de servidores de juego están entre 5 y 50 Gbit/s, es decir, entre cinco y cincuenta veces una línea normal. Para eso no existe ningún ajuste local. Los ataques volumétricos tienen que terminar en la red que hay delante del servidor.

Lo que KernelHost pone frente a los ataques DDoS contra servidores de juego

La protección permanente incluida en todos los servidores

La protección DDoS de KernelHost está estructurada en dos niveles y activa de forma permanente, sin que tengas que activar, pedir ni configurar nada:

• Nivel 1: 17 Tbps de capacidad de mitigación en la red global de scrubbing. Los ataques volumétricos se limpian cerca de su origen, antes de que lleguen al centro de datos.
• Nivel 2: filtrado Arbor en tiempo real con 3,2 Tbps en Frankfurt am Main. Justo delante del servidor se reconocen y se descartan los patrones propios de cada protocolo, paquete a paquete.

Dos propiedades marcan la diferencia. La protección funciona de forma permanente y no tiene que reaccionar primero a un ataque, así que no hay unos minutos iniciales en los que el servidor esté fuera. Y no se utiliza null-routing: tu dirección IP se queda en la red y solo se descartan los paquetes dañinos. Quien retira la dirección IP de la red consigue para ti el mismo resultado que el atacante. Qué juegos y protocolos están cubiertos lo lista Protección DDoS para servidores de juego en tiempo real.

Advanced DDoS Protection para proyectos bajo fuego continuo

Algunos proyectos no reciben ataques de vez en cuando, sino de forma dirigida y durante semanas. Para esos existe la Advanced DDoS Protection desde 50,00 € al mes, PrePaid, sin permanencia mínima y sin cuota de instalación. La diferencia no está en más capacidad, sino en el control:

• IP de protección dedicada del núcleo de red de Fráncfort, a la que se cambia tu servidor dentro de nuestra propia red. En tu lado no hace falta ninguna modificación: la dirección nueva solo la escribes allí donde tus jugadores encuentran el servidor.
• Reglas de protección autogestionables por puerto y protocolo en el área de cliente: defines qué se permite en 16261 y 16262 UDP, y todo lo demás sigue cerrado, sin tener que abrir un ticket para ello.
• Los cambios surten efecto en tiempo real, así que puedes reajustar durante un ataque en curso.
• Perfil de protección adecuado. Para los juegos habituales hay perfiles listos, y para las aplicaciones modificadas y propias pones tú mismo las reglas por puerto y protocolo. Project Zomboid se puede acotar aquí con especial precisión, porque todo el tráfico de juego va por dos puertos UDP contiguos.

Los dos niveles, comparados

Para la mayoría de los servidores de Project Zomboid basta con la protección permanente incluida junto a una configuración limpia. La Advanced DDoS Protection es la respuesta a que alguien se lo tome como algo personal.

Errores frecuentes y sus soluciones

"Mis jugadores reciben el mensaje de que el puerto 16262 está cerrado": eso no es un ataque, sino una apertura que falta. El servidor necesita los dos puertos, 16261 UDP y 16262 UDP, y como regla UDP. Una apertura TCP con los mismos números no sirve de nada. Comprueba con ufw status verbose y con un escaneo UDP desde fuera si de verdad están abiertos los dos.

"Cambié la dirección IP y dos horas después estaba otra vez fuera": el atacante ha sacado la dirección nueva de la misma fuente que la antigua, normalmente la entrada de la lista, un bot de Discord con indicador de estado o un registro DNS viejo. En Project Zomboid el cambio cuesta además algo más: los clientes guardan los datos del mapa en local bajo dirección y puerto, en una carpeta con el patrón 123.45.0.12_16261_... dentro de Zomboid/Saves. Tras un cambio, cada jugador vuelve a descargar del servidor el mapa explorado. Cambiar de dirección es por tanto tiempo ganado con coste añadido, no una solución.

"Mis reglas de iptables no hacen nada": hay tres causas frecuentes. Las reglas están detrás de las cadenas de UFW y no se alcanzan nunca, se perdieron con el último reinicio (entonces ayudan netfilter-persistent save o una entrada en /etc/ufw/before.rules), o el ataque es volumétrico y la regla trabaja correctamente en una línea que ya está llena. Comprueba con iptables -L INPUT -n -v si suben los contadores de aciertos.

"Los jugadores salen despedidos al entrar, pero el servidor sigue funcionando con normalidad": eso casi siempre es la comprobación, no un ataque. Las causas son una diferencia de versión entre cliente y servidor, una entrada del Workshop que falta o está desactualizada, o una suma de comprobación que no encaja. El cliente suele nombrar los mods que no coinciden. Coteja WorkshopItems y Mods línea por línea.

"Cada pocos minutos hay picos de lag y luego vuelve a ir bien": ese es el patrón habitual de los ataques cortos, que solo duran hasta que los jugadores se hartan y lo dejan. Mira primero los contadores de red, no la carga de la CPU. Si sar -n DEV 1 10 y los contadores de descartes no muestran nada llamativo, no era un ataque, sino carga: demasiados jugadores en la misma celda, un mod caro o poca memoria para la instancia de Java.

"Mi proveedor anterior bloqueó mi dirección IP": eso es null-routing. Con ello el proveedor protege su propia red; para ti el resultado es idéntico al de un ataque con éxito, normalmente durante horas después. En caso de duda, pregunta si se filtra o si se hace null-routing. La respuesta dice más sobre tu disponibilidad que cualquier dato de hardware.

"En el tcpdump no veo nada llamativo": si el tráfico ya se filtra en la red anterior, al servidor no llega nada, como cabe esperar. Ese es el caso normal cuando el filtrado funciona. Al revés también vale: si la línea está saturada, puede que ni siquiera te llegue la sesión SSH con la que querías medir. Usa entonces la consola VNC del área de cliente.

En resumen

• Un servidor dedicado de Project Zomboid necesita exactamente dos puertos abiertos: 16261 UDP (DefaultPort) y 16262 UDP (UDPPort). Los dos están como directivas separadas en el servertest.ini.
• RCON corre en 27015 TCP y viene de fábrica sin contraseña. Ese puerto no va en el internet abierto, sino limitado a tu propia dirección o cerrado.
• La comprobación de mods al conectar es el punto más caro: versión, suma de comprobación, lista del Workshop y datos del mapa cuestan tiempo de proceso, también en cada intento rechazado. DenyLoginOnOverloadedServer y la cola de entrada son los frenos integrados contra eso.
• La contraseña del servidor, Open=false y MaxAccountsPerUser=1 protegen la lógica de juego. Contra una línea saturada no sirve ninguno de esos ajustes.
• El límite físico está fijado: 1 Gbit/s son 125 megabytes por segundo y, con paquetes de 64 bytes, unos 1,49 millones de paquetes por segundo. Los ataques habituales contra servidores de juego están entre 5 y 50 Gbit/s.
• Los ataques volumétricos tienen que terminar en la red que hay delante del servidor. En KernelHost eso son 17 Tbps de capacidad de mitigación en la red global de scrubbing y un filtrado Arbor en tiempo real con 3,2 Tbps en Frankfurt am Main, sin recargo y sin null-routing.
• Quien está bajo fuego continuo dirige el filtrado él mismo con la Advanced DDoS Protection: IP de protección dedicada, reglas por puerto y protocolo, cambios en tiempo real, desde 50,00 € al mes.

Si tu servidor ya está en KernelHost, el filtrado está activo sin que tengas que hacer nada. Si aun así notas algo raro, abre un ticket de soporte para que ajustemos con más precisión las reglas de filtrado de tu dirección IP. Durante un ataque en curso puedes localizarnos además en el chat de emergencia de WhatsApp en el +43 650 8209883.