Proteger tu servidor de Terraria frente a ataques DDoS

Quien quiere proteger su servidor de Terraria frente a ataques DDoS se enfrenta a un caso especial: Terraria habla exclusivamente TCP. El tráfico del juego va por un único puerto, el 7777 TCP, y el juego no abre ningún puerto UDP. Casi todos los consejos que circulan por la red sobre protección de servidores de juego están escritos para juegos UDP y aquí, o bien caen en el vacío, o bien actúan en el sitio equivocado.

Este artículo muestra primero lo que puedes asegurar tú mismo sin coste añadido, después dónde se acaban técnicamente esas medidas, y al final lo que tiene que ocurrir entonces en la red que hay delante del servidor. Todos los datos se refieren a un servidor dedicado de Terraria (vanilla, TShock o tModLoader) sobre Debian 12, Debian 13, Ubuntu 22.04 LTS o Ubuntu 24.04 LTS. 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 la configuración y no reinicies el servidor: guarda las mediciones (consulta el apartado "Registrar datos"), porque cuando el ataque pase habrán desaparecido.

Por qué precisamente los servidores de Terraria reciben ataques DDoS

Los servidores de Terraria son un objetivo cómodo porque su dirección es forzosamente pública. Terraria vanilla no tiene un navegador de servidores integrado: los jugadores se conectan por "Multiplayer" y "Join via IP", es decir, mediante una dirección que alguien ha tenido que dar a conocer antes. Quien quiere jugadores nuevos apunta el servidor en páginas de listas como terraria-servers.com, tserverweb.com o topg.org, o reparte la dirección por Discord. Cada uno de esos caminos le entrega a un atacante lo mismo que le entrega al jugador: dirección IP y puerto en texto claro.

Por eso, cuando un servidor de Terraria se cae una y otra vez aunque no haya cambiado nada en el hardware, el mundo ni la lista de mods, un ataque es la explicación más probable. A eso se suma la situación típica de un proyecto: horarios de juego fijos, servidores competidores, jugadores baneados y peleas en la comunidad. Un ataque no le cuesta a quien lo encarga ni conocimientos ni un dinero digno de mención, y un Terraria server booter se vende como suscripción por unos pocos euros al mes. Qué es técnicamente un ataque DDoS y cómo se monta lo explica el artículo ¿Qué es un ataque DDoS?.

Terraria funciona sobre TCP, no sobre UDP

Esta es la diferencia más importante respecto a prácticamente cualquier otro servidor de juego. El servidor dedicado de Terraria acepta conexiones con un listener TCP (en el motor del juego, la clase Terraria.Net.Sockets.TcpSocket) y no abre ningún socket UDP. Eso tiene cuatro consecuencias que determinan toda tu defensa:

• Una conexión TCP completamente establecida no se puede falsificar. El atacante tiene que recibir el SYN-ACK del servidor para cerrar el handshake. Así que quien está realmente conectado viene de una dirección real. Los bloqueos por IP y los límites de conexiones funcionan por eso en Terraria bastante mejor que en un juego UDP.
• Un SYN flood sí se puede falsificar, porque nunca cierra el handshake. Contra esa variante no sirve ningún bloqueo por IP, solo las SYN cookies y el filtrado previo.
• Cada conexión TCP aceptada hacia el puerto 7777 ocupa recursos en el proceso del juego, no solo en el kernel. Eso convierte al agotamiento de slots en el ataque más eficaz con el menor ancho de banda.
• Un flood UDP golpea igualmente a tu servidor. Los paquetes no tienen que ser aceptados para llenar tu línea. Que Terraria no hable UDP no protege la línea, solo evita que el propio proceso del juego procese los paquetes.

Hay una excepción: si arrancas el servidor dedicado con -steam y -lobby friends o -lobby private, la conexión va por la red de Steam y, con ella, por puertos UDP en el rango de 27000 a 27100. Ese es otro modo de funcionamiento y no el servidor clásico accesible por dirección IP.

Los puertos que de verdad importan

Un servidor de Terraria necesita exactamente un puerto en la red abierta: 7777 TCP. Todo lo demás de esta tabla, o bien no pinta nada en internet, o bien solo debe estar abierto a tu propia dirección.

Que Terraria no conozca ni un puerto de query ni RCON es una buena noticia para la protección: los dos endpoints que en Counter-Strike, Rust o ARK se usan con regularidad para ataques de reflexión aquí sencillamente no existen. A cambio, la superficie de ataque está mucho más concentrada en el puerto 7777, y quien usa TShock se trae una segunda superficie con el puerto 7878.

Lo que puedes hacer tú mismo antes de gastar dinero

Este apartado es el más largo, y es a propósito. Un servidor de Terraria bien configurado aguanta por su cuenta los ataques pequeños y medianos, esté alojado donde esté.

1. Inventario: ¿qué está escuchando realmente?

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:7777 significa "accesible desde todo internet", 127.0.0.1:7878 significa "solo local" y no necesita ninguna regla de firewall. Si en esa lista aparece una entrada UDP para tu proceso de Terraria, el servidor está funcionando en modo Steam. La vista del atacante te la da un escaneo de puertos desde fuera:

nmap -Pn -p- --min-rate 1000 IP.DE.TU.SERVIDOR

2. Dejar abierto solo el 7777 TCP y cerrar todo lo demás

A Terraria le basta una única apertura hacia fuera. No necesitas ninguna regla UDP, y una regla UDP para el 7777 sería sencillamente falsa: deja pasar tráfico hacia un puerto en el que no escucha nada. 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 7777/tcp comment 'Terraria'
ufw allow from 203.0.113.10 to any port 7878 proto tcp comment 'TShock REST'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

Sustituye 203.0.113.10 por tu propia dirección. La guía completa, con vía de rescate incluida, la tienes en Configurar el firewall UFW sin quedarte fuera del servidor. Quien tenga un panel limita también el 8080 y el 2022 a su propia dirección.

3. serverconfig.txt: poner bien password, maxplayers y secure

El archivo de configuración central del servidor de Terraria se llama serverconfig.txt y se le pasa al arrancar con -config serverconfig.txt. Cuatro directivas son decisivas para la protección:

port=7777
maxplayers=16
password=EinLangesZufallsPasswort
secure=1
upnp=0
banlist=banlist.txt

password= es la medida gratuita más eficaz contra los floods de intentos de entrada que usan la vía normal. El motivo está en el protocolo: un cliente envía primero el mensaje 1 con su identificador de versión (por ejemplo Terraria279), el servidor responde con el mensaje 37 si hay contraseña puesta, el cliente tiene que responder correctamente con el mensaje 38, y solo después el servidor envía con el mensaje 3 el paso libre junto con el slot de jugador. Sin la contraseña correcta, un atacante nunca llega a la transferencia del mundo, que es la parte cara de una entrada.

maxplayers acepta valores de 1 a 255 y viene por defecto en 16 (antes de la versión 1.4.0.1 eran 8). El límite superior de 255 no es una cifra arbitraria: Terraria direcciona a los jugadores con un único byte. No pongas maxplayers más alto de lo que de verdad necesitas, porque cada slot es un recurso que un atacante puede ocupar. secure=1 activa la comprobación antitrampas integrada (en la línea de comandos -secure), y upnp=0 evita que el servidor abra puertos por su cuenta en un router.

4. Asegurar TShock: la API REST en el 7878 y el flood de login

TShock es la extensión de servidor más extendida para Terraria y, con su API REST, se trae una segunda superficie de ataque completa. Está por defecto en el puerto 7878 TCP y se configura en tshock/config.json, o sea, no en la serverconfig.txt. Tal como viene de fábrica está desactivada ("RestApiEnabled": false), y así debería quedarse mientras no la necesites.

Si la necesitas, estos son los valores relevantes:

"RestApiEnabled": true,
"RestApiPort": 7878,
"EnableTokenEndpointAuthentication": true,
"LogRest": true,
"RESTMaximumRequestsPerInterval": 5,
"RESTRequestBucketDecreaseIntervalMinutes": 1

Dos cosas son importantes aquí. Primero, el endpoint /status entrega sin token el nombre del servidor, el puerto, el número de jugadores y los nombres de los jugadores mientras EnableTokenEndpointAuthentication esté en false. Eso resulta cómodo para páginas de estado y bots de Discord y es al mismo tiempo un trabajo de reconocimiento gratuito para cualquier atacante que quiera saber cuándo merece la pena atacar. Segundo, el endpoint /v2/token/create genera un token de acceso a partir de usuario y contraseña, y es accesible desde fuera en cuanto el puerto 7878 está abierto: un ataque de adivinación de contraseñas contra tu cuenta de administrador que, de paso, cuesta tiempo de proceso. El cubo formado por RESTMaximumRequestsPerInterval y RESTRequestBucketDecreaseIntervalMinutes lo frena, pero no sustituye a una regla de firewall.

Para el acceso al juego en sí valen otros valores de TShock. MaximumLoginAttempts está en 3 y echa a un jugador tras tres intentos fallidos. RequireLogin (por defecto false) exige una cuenta a cada jugador. EnableIPBans (por defecto true) y KickProxyUsers (por defecto true) son especialmente eficaces en un juego TCP, porque la dirección de origen de una conexión establecida no puede estar falsificada. Contra el griefing, que muchas veces se comunica como ataque, funcionan los umbrales TileKillThreshold (60), TilePlaceThreshold (20), TileLiquidThreshold (15) y ProjectileThreshold (50), en cada caso acciones por segundo.

5. Limitar las conexiones por dirección de origen y comprobar las SYN cookies

Como Terraria funciona sobre TCP, la regla local más eficaz es un límite de conexiones simultáneas por dirección de origen. Un jugador real necesita exactamente una:

iptables -I INPUT -p tcp --dport 7777 --syn -m connlimit --connlimit-above 3 --connlimit-mask 32 -j DROP
iptables -I INPUT -p tcp --dport 7777 --syn -m hashlimit --hashlimit-name terraria_syn --hashlimit-mode srcip --hashlimit-above 10/min --hashlimit-burst 20 -j DROP

La primera regla descarta las conexiones nuevas en cuanto una dirección tiene más de tres abiertas a la vez. La segunda limita la tasa de intentos de conexión del mismo origen a diez por minuto con un margen de 20. Las dos cifras son valores de partida, no verdades absolutas: un servidor detrás de una conexión compartida (piso compartido, red escolar, operador de telefonía móvil) ve a varios jugadores legítimos bajo la misma dirección. Mide primero una semana de funcionamiento normal.

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

Con UFW, ese tipo de reglas van en /etc/ufw/before.rules, porque de lo contrario desaparecen con el siguiente ufw reload. Contra los paquetes SYN falsificados, que nunca cierran el handshake, no ayuda ninguna de esas reglas, sino el propio kernel. Comprueba los tres valores:

sysctl net.ipv4.tcp_syncookies net.ipv4.tcp_max_syn_backlog net.core.somaxconn

net.ipv4.tcp_syncookies tiene que estar en 1, y en Debian y Ubuntu suele ser así de serie. Las SYN cookies renuncian a la cola de conexiones semiabiertas y reconstruyen el estado a partir de la respuesta del cliente, con lo que un SYN flood cae en el vacío mientras la línea no esté llena. net.core.somaxconn está desde Linux 5.4 en 4096 y antes en 128: si el valor es pequeño, el kernel descarta conexiones ya establecidas antes de que el proceso del juego llegue siquiera a aceptarlas.

6. Evitar el agotamiento de slots: por qué un escaneo de puertos llena tu servidor

El agotamiento de slots es el ataque eficaz más barato contra un servidor de Terraria: el atacante abre hacia el puerto 7777 tantas conexiones TCP como slots de jugador tenga el servidor y las mantiene abiertas. Eso casi no le cuesta ancho de banda, pero llena el servidor. Los jugadores reales ven "Server is full" y ya no pueden entrar, aunque en tu línea no esté pasando nada llamativo. Justo por eso, en Terraria muchos operadores no se dan cuenta de que los están atacando.

La causa está en la forma de contar: una conexión se acepta antes incluso de que el cliente haya enviado su identificador de versión. Históricamente, esas conexiones fantasma se quedaban ocupando el slot hasta que la sesión TCP expiraba. La serie 1.4.5 lo ha suavizado: allí ya no se reservan slots para los clientes que se desconectan de inmediato. En las primeras versiones de 1.4.5.7 y 1.4.5.8, sin embargo, el servidor dedicado se caía con una ObjectDisposedException no capturada en cuanto se abría una conexión TCP y no se cerraba el handshake. Bastaba un nc -z o una comprobación de disponibilidad de un monitoring. El fallo se corrigió en silencio en pocas semanas, aunque en imágenes de contenedor antiguas sigue presente en algunos casos. Mantén por eso actualizada la versión de tu servidor: aquí no es un lugar común, sino una cuestión concreta de disponibilidad.

Dos ajustes ayudan además. Quien use TShock pone MaxSlots en el número de jugadores deseado y maxplayers en la serverconfig.txt dos plazas por encima: así TShock rechaza las conexiones sobrantes con un mensaje limpio, en lugar de que el proceso del juego las deje entrar en el último hueco. Y el límite de conexiones del apartado anterior es exactamente la regla que impide a una sola dirección ocupar todos los slots de una vez.

7. Desactivar UPnP y no publicar tú mismo la dirección

El servidor de Terraria intenta por defecto abrir su puerto por UPnP en un router. En un servidor alquilado eso no tiene efecto; en una red doméstica abre puertos de los que después ya no te acuerdas. Desactívalo con upnp=0 en la serverconfig.txt o con -noupnp en la línea de comandos.

Aquí conviene además la honestidad antes que el pensamiento mágico: tu dirección IP no se puede mantener en secreto. Cualquier jugador que se haya conectado una vez la conoce, y una entrada en una página de listas la publica de todas formas. Hay dos costumbres eficaces. No publiques tú mismo la dirección IP en bruto en ninguna parte, conecta a tus jugadores mediante un nombre de host: el cliente de Terraria resuelve un nombre de host, así que puedes cambiar la dirección llegado el caso sin que se rompan todas las referencias. Y limpia los registros DNS antiguos, porque un registro A olvidado que apunte a la dirección anterior deja sin efecto cualquier cambio.

8. Guardar en caché las consultas de estado en lugar de dejarlas pasar

Como Terraria no tiene protocolo de consulta, las páginas de estado, los bots de Discord y las páginas de listas averiguan el estado de tu servidor por uno de estos dos caminos: establecen una conexión TCP real hacia el 7777 y se hacen pasar por un cliente, o consultan la API REST de TShock. Las dos cosas le cuestan trabajo a tu servidor, y las dos escalan con el número de consultantes.

La contramedida no cuesta nada: no consultes nunca desde el visitante. Deja que un único servicio recoja el estado a intervalos fijos (bastan 30 o 60 segundos), guarda el resultado en caché y entrega a todos los visitantes ese estado guardado. Así, una página de estado muy visitada genera una consulta por intervalo en lugar de una por visitante. Quien use la API REST para eso limita el puerto 7878 a la dirección de ese único servicio.

9. Registrar datos para tenerlos llegado el caso

El paso más importante es el que casi nadie da antes de tiempo: crear una base de comparación mientras todo funciona con normalidad. 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 noche. Con apt-get install -y vnstat sysstat la medición corre de forma permanente. Durante un incidente bastan cinco comandos:

sar -n DEV 1 10
ss -s
ss -tn state syn-recv | wc -l
ip -s link show eth0
tcpdump -ni eth0 tcp port 7777 -c 200 -q

El tercer comando es el específico de Terraria: cuenta las conexiones semiabiertas. Un valor de dos cifras es normal, uno de cuatro o cinco cifras es un SYN flood. ss -s muestra además el número total de conexiones TCP, y si esa cifra se parece a tu maxplayers mientras en el juego no hay nadie, estás viendo un agotamiento de slots. 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.

El punto en el que estas medidas dejan de servir

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. Los ataques contra proyectos de servidor de juego de ese tamaño se mueven normalmente entre 5 y 50 Gbit/s, es decir, entre cinco y cincuenta veces tu línea. Que tu regla connlimit por detrás sea buena o no ya da igual, porque los paquetes de tus jugadores dejan de pasar mucho antes. Así es exactamente como aparecen los lag spikes de un servidor de Terraria con un uso de CPU de aspecto normal.

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 una línea de 1 Gbit/s unos 1,49 millones de paquetes por segundo. Un kernel de servidor normal procesa, según la CPU y la tarjeta de red, unos cientos de miles antes de empezar a descartar. Con un SYN flood el límite está todavía más abajo, porque cada paquete SYN provoca una decisión de estado: unas decenas de miles de paquetes SYN por segundo bastan ya para dejar sin capacidad la aceptación de conexiones de un Linux estándar, mucho antes de que la línea esté llena. Los operadores lo viven como "pero si la carga no era ni alta y aun así se cayó todo".

Y el tercer punto es el que más se pasa por alto en Terraria: un atacante no se guía por tu protocolo. Manda floods UDP y tráfico de reflexión hacia tu dirección, aunque en ningún puerto UDP esté escuchando nada. Tu servidor descarta esos paquetes correctamente, pero ya han ocupado tu línea, y tu servidor de Terraria se queda fuera de línea sin que un solo paquete haya llegado al proceso del juego. Para hacerse una idea de las magnitudes que se dan de verdad: en servidores de KernelHost se han filtrado, entre otros, un ataque de más de 473,4 Gbit/s con más de 41,5 millones de paquetes por segundo y un flood UDP de más de 112,2 Gbit/s contra un servidor de juego. 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 esos ataques

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 Fráncfort del Meno. Justo delante del servidor se reconocen y se descartan los patrones propios de cada protocolo, paquete a paquete. Para Terraria eso significa en concreto: los SYN floods y los floods de conexiones contra el 7777 TCP terminan aquí, no en tu tarjeta de red.

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. La ubicación es Frankfurt am Main. Qué juegos y protocolos están cubiertos lo detalla 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.
• Reglas de protección autogestionables por puerto y protocolo en el área de cliente: defines qué se permite en 7777 TCP y puedes cerrar todo lo demás, sin tener que abrir un ticket para ello.
• Los cambios surten efecto en tiempo real, así que puedes reajustar durante un ataque en curso, por ejemplo ajustando más la tasa de conexiones permitida por dirección de origen.
• Perfil de protección adaptado a la aplicación. Para juegos TCP como Terraria y para aplicaciones propias o modificadas en cualquier puerto TCP o UDP hay perfiles adecuados.

Los dos niveles, comparados

Para la mayoría de los proyectos de Terraria basta con la protección permanente incluida junto a una configuración limpia del servidor. La Advanced DDoS Protection es la respuesta a que alguien se lo tome como algo personal. Quien tenga su servidor ahora mismo en otro sitio no consigue la protección como añadido, sino con el traslado a KernelHost: el filtrado es parte de la red, no un extra en el servidor.

Errores frecuentes y sus soluciones

"El servidor está lleno, pero no hay nadie dentro": eso es un agotamiento de slots. Comprueba con ss -tn dst :7777 | wc -l cuántas conexiones hay abiertas de verdad y compáralo con la lista de jugadores (en la consola del servidor: playing). Si las cifras no coinciden, hay conexiones ajenas ocupando los slots. Los remedios son el límite de conexiones por dirección de origen, una contraseña de servidor y una versión de servidor actual.

"He abierto el 7777 UDP y no cambia nada": correcto, porque en el 7777 UDP no escucha nada. Terraria usa exclusivamente TCP. La apertura UDP no hace daño directo, pero es una apertura innecesaria y una señal segura de que se ha copiado una guía de otro juego.

"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. Si se quedan a cero, la regla no se alcanza.

"Los jugadores se caen aunque no haya ningún ataque": si aprietas demasiado tu límite connlimit, les toca a los jugadores que están detrás de conexiones compartidas. En TCP eso pasa antes que en los juegos UDP, porque una reconexión tras un corte genera de inmediato una conexión nueva mientras la antigua sigue colgada en TIME_WAIT. Sube el valor paso a paso y observa los contadores de aciertos.

"El servidor va a tirones y la línea está tranquila": eso suele ser un mod o un plugin antes que un ataque. Con tModLoader, cada mod adicional cuesta tiempo de proceso en el mismo proceso, y un mundo con muchas entidades satura un núcleo por completo sin que llegue un paquete de más. Si sar -n DEV 1 10 no muestra nada llamativo, no era un ataque DDoS.

"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, que funciona con independencia de la red del sistema huésped.

En resumen

• Un servidor de Terraria necesita exactamente un puerto abierto: 7777 TCP. El juego no abre ningún socket UDP, no tiene protocolo de consulta y no tiene RCON.
• La API REST de TShock en el puerto 7878 TCP es la segunda superficie de ataque. Deja RestApiEnabled en false o limita el puerto a tu propia dirección.
• Una contraseña de servidor en la serverconfig.txt es la medida gratuita más eficaz, porque sin la respuesta correcta al mensaje 37 un atacante nunca llega a la transferencia del mundo.
• El agotamiento de slots es el ataque más barato en Terraria: cada conexión TCP aceptada hacia el 7777 ocupa una plaza, sin ancho de banda digno de mención. Contra eso funcionan un límite por dirección de origen, una contraseña y una versión de servidor actual.
• Como Terraria usa TCP, la dirección de origen de una conexión establecida no se puede falsificar: los bloqueos por IP funcionan aquí mejor que en los juegos UDP. Contra los SYN floods falsificados solo ayudan las SYN cookies y el filtrado previo.
• Un flood UDP deja fuera de combate a tu servidor de Terraria aunque no hable UDP, porque llena la línea antes de que el proceso del juego vea nada.
• A partir aproximadamente del tamaño de tu ancho de banda de subida decide únicamente la red que hay delante del servidor. En KernelHost ese filtrado es de dos niveles, está activo de forma permanente y viene incluido sin recargo en cada paquete de servidor.

Si tu proyecto 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.