Proteger o servidor Terraria contra ataques DDoS

Quem quer proteger o seu servidor Terraria contra ataques DDoS está perante um caso especial: o Terraria fala exclusivamente TCP. O tráfego de jogo corre por uma única porta, 7777 TCP, e o jogo não abre porta UDP nenhuma. Quase todos os conselhos que circulam na internet sobre proteção de gameservers foram escritos para jogos UDP e, aqui, ou caem no vazio ou atuam no sítio errado.

Este artigo mostra primeiro o que pode proteger por conta própria e sem custos adicionais, depois onde estas medidas terminam do ponto de vista técnico e, por fim, o que tem então de acontecer na rede à frente do servidor. Todas as indicações se referem a um servidor dedicado de Terraria (vanilla, TShock ou tModLoader) em Debian 12, Debian 13, Ubuntu 22.04 LTS ou Ubuntu 24.04 LTS. Os comandos estão escritos para root; como utilizador normal, anteponha sudo. Se o ataque estiver a decorrer neste momento, não altere primeiro nada na configuração e não reinicie o servidor: guarde os valores medidos (ver a secção "Registar em log"), porque depois do ataque desaparecem.

Porque é que são precisamente os servidores Terraria a ser atingidos por ataques DDoS

Os servidores Terraria são um alvo cómodo porque o seu endereço é forçosamente público. O Terraria vanilla não tem um navegador de servidores integrado: os jogadores ligam-se através de "Multiplayer" e "Join via IP", ou seja, através de um endereço que alguém tem de ter divulgado antes. Quem quer novos jogadores inscreve o servidor em páginas de listagem como terraria-servers.com, tserverweb.com ou topg.org, ou distribui o endereço pelo Discord. Cada um destes caminhos entrega a um atacante exatamente o mesmo que entrega ao jogador: endereço IP e porta em texto simples.

Quando um servidor Terraria fica constantemente offline, apesar de nada ter mudado no hardware, no mundo e na lista de mods, um ataque é por isso a explicação mais provável. A isto junta-se a constelação típica de um projeto: horários de jogo fixos, servidores concorrentes, jogadores banidos e conflitos na comunidade. Um ataque não custa a quem o encomenda nem competência nem dinheiro digno de nota, e um Terraria server booter vende-se como subscrição por poucos euros por mês. O que é tecnicamente um ataque DDoS e como ele é montado fica explicado no artigo O que é um ataque DDoS?.

O Terraria corre sobre TCP, não sobre UDP

Esta é a diferença mais importante em relação a praticamente qualquer outro gameserver. O servidor dedicado de Terraria recebe as ligações com um listener TCP (no motor de jogo, a classe Terraria.Net.Sockets.TcpSocket) e não abre nenhum socket UDP. Isso tem quatro consequências que determinam toda a sua defesa:

• Uma ligação TCP totalmente estabelecida não se pode falsificar. O atacante tem de receber o SYN-ACK do servidor para concluir o aperto de mão. Quem está de facto ligado vem, portanto, de um endereço verdadeiro. Os bloqueios de IP e os limites de ligações resultam por isso bastante melhor no Terraria do que num jogo UDP.
• Um SYN flood, esse, pode muito bem ser falsificado, porque nunca conclui o aperto de mão. Contra esse tipo não ajuda nenhum bloqueio de IP, apenas as SYN cookies e a filtragem à frente.
• Cada ligação TCP aceite na porta 7777 ocupa recursos no processo de jogo, e não apenas no kernel. É isso que faz do esgotamento de slots o ataque mais eficaz com a menor largura de banda.
• Um flood UDP atinge o seu servidor à mesma. Os pacotes não têm de ser aceites para encherem a sua linha. O facto de o Terraria não falar UDP não protege a linha, apenas impede que o próprio processo de jogo processe os pacotes.

Há uma exceção: se o servidor dedicado for iniciado com -steam e -lobby friends ou -lobby private, a ligação passa pela rede da Steam e, com isso, por portas UDP na faixa de 27000 a 27100. Esse é um modo de funcionamento diferente e não o servidor clássico, acessível através do endereço IP.

As portas que realmente contam

Um servidor Terraria precisa de exatamente uma porta na rede aberta: 7777 TCP. Tudo o resto nesta tabela ou não pertence de todo à internet, ou apenas ao seu próprio endereço.

O facto de o Terraria não conhecer nem uma porta de query nem RCON é uma boa notícia para a proteção: os dois endpoints que no Counter-Strike, no Rust ou no ARK são regularmente abusados para ataques de reflection não existem aqui, pura e simplesmente. Em contrapartida, a superfície de ataque fica tanto mais concentrada na porta 7777, e quem usa o TShock traz consigo uma segunda superfície com a porta 7878.

O que pode fazer por conta própria antes de gastar dinheiro

Esta secção é a mais longa, e isso é intencional. Um servidor Terraria bem configurado aguenta ataques pequenos e médios pelos seus próprios meios, independentemente de onde esteja alojado.

1. Levantamento: o que é que está sequer à escuta?

Antes de escrever uma única regra, veja o que o seu servidor oferece para o exterior. Não adivinhe, verifique:

ss -lntup

A coluna interessante é a do endereço local. 0.0.0.0:7777 significa "acessível a partir de toda a internet", 127.0.0.1:7878 significa "apenas local" e não precisa de regra de firewall. Se nesta lista aparecer uma entrada UDP para o seu processo do Terraria, o servidor está a correr em modo Steam. A perspetiva do atacante obtém-se com um scan de portas a partir de fora:

nmap -Pn -p- --min-rate 1000 IP.DO.SEU.SERVIDOR

2. Deixar aberta apenas a 7777 TCP e fechar tudo o resto

Para o Terraria basta uma única abertura para o exterior. Não precisa de uma regra UDP e uma regra UDP para a 7777 seria simplesmente errada: deixaria passar tráfego para uma porta onde não está nada à escuta. Com o UFW isso fica assim, e exatamente por esta ordem, para que não se tranque a si próprio fora do 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

Substitua 203.0.113.10 pelo seu próprio endereço. As instruções completas, incluindo o caminho de recuperação, encontram-se em Configurar a firewall UFW sem se trancar fora do servidor. Quem tem um painel restringe também a 8080 e a 2022 ao próprio endereço.

3. serverconfig.txt: definir corretamente password, maxplayers e secure

O ficheiro de configuração central do servidor Terraria chama-se serverconfig.txt e é passado no arranque com -config serverconfig.txt. Quatro diretivas são decisivas para a proteção:

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

O password= é a medida gratuita mais eficaz contra os floods de entradas que usam o caminho normal. A razão está no protocolo: um cliente envia primeiro a mensagem 1 com o seu identificador de versão (por exemplo Terraria279), o servidor responde com a mensagem 37 quando há palavra-passe definida, o cliente tem de responder corretamente com a mensagem 38 e só depois disso é que o servidor envia com a mensagem 3 a autorização juntamente com o slot de jogador. Sem a palavra-passe correta, um atacante nunca chega, portanto, à transmissão do mundo, que é a parte cara de uma entrada.

O maxplayers aceita valores de 1 a 255, sendo a predefinição 16 (antes da versão 1.4.0.1 eram 8). O limite máximo de 255 não é um número arbitrário: o Terraria endereça os jogadores com um único byte. Não defina o maxplayers acima do que precisa mesmo, porque cada slot é um recurso que um atacante pode ocupar. O secure=1 liga a verificação de cheats integrada (na linha de comandos -secure) e o upnp=0 impede que o servidor abra portas por sua iniciativa num router.

4. Proteger o TShock: API REST na 7878 e flood de autenticação

O TShock é a extensão de servidor mais divulgada para Terraria e traz consigo, com a API REST, uma segunda superfície de ataque a sério. Fica por predefinição na porta 7878 TCP e é configurada em tshock/config.json, ou seja, não na serverconfig.txt. De origem vem desligada ("RestApiEnabled": false), e é assim que deve continuar enquanto não precisar dela.

Se precisar, estes são os valores relevantes:

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

Duas coisas são importantes aqui. Primeiro, o endpoint /status entrega sem token o nome do servidor, a porta, o número de jogadores e os nomes dos jogadores, enquanto EnableTokenEndpointAuthentication estiver a false. Isso é cómodo para páginas de estado e bots do Discord e é, ao mesmo tempo, reconhecimento gratuito para qualquer atacante que queira saber quando é que vale a pena atacar. Segundo, o endpoint /v2/token/create gera um token de acesso a partir de nome de utilizador e palavra-passe, e fica acessível a partir do exterior assim que a porta 7878 estiver aberta: um ataque de adivinhação de palavra-passe contra a sua conta de administrador que, de caminho, custa tempo de processamento. O balde formado por RESTMaximumRequestsPerInterval e RESTRequestBucketDecreaseIntervalMinutes trava isso, mas não substitui uma regra de firewall.

Para o acesso ao próprio jogo aplicam-se outros valores do TShock. O MaximumLoginAttempts está a 3 e expulsa um jogador ao fim de três tentativas falhadas. O RequireLogin (predefinição false) exige uma conta a cada jogador. O EnableIPBans (predefinição true) e o KickProxyUsers (predefinição true) são especialmente eficazes num jogo TCP, porque o endereço de origem de uma ligação estabelecida não pode mesmo ser falsificado. Contra o griefing, que muitas vezes é comunicado como ataque, resultam os limiares TileKillThreshold (60), TilePlaceThreshold (20), TileLiquidThreshold (15) e ProjectileThreshold (50), cada um em ações por segundo.

5. Limitar as ligações por endereço de origem e verificar as SYN cookies

Como o Terraria corre sobre TCP, a regra local mais eficaz é um limite máximo de ligações em simultâneo por endereço de origem. Um jogador verdadeiro precisa exatamente de uma:

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

A primeira regra descarta novas ligações assim que um endereço tenha mais de três delas abertas em simultâneo. A segunda limita a dez por minuto, com uma margem de 20, a taxa de tentativas de ligação da mesma origem. Os dois números são valores de partida, não verdades absolutas: um servidor atrás de uma ligação partilhada (casa partilhada, rede escolar, operador móvel) vê vários jogadores legítimos sob o mesmo endereço. Meça primeiro durante uma semana em funcionamento normal.

As regras puras de iptables desaparecem depois de um reinício; no Debian e no Ubuntu guardam-se assim:

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

Com o UFW, estas regras pertencem ao /etc/ufw/before.rules, porque de outra forma desaparecem no ufw reload seguinte. Contra pacotes SYN falsificados, que nunca concluem o aperto de mão, não ajuda nenhuma destas regras, mas sim o próprio kernel. Verifique os três valores:

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

O net.ipv4.tcp_syncookies tem de estar a 1, o que no Debian e no Ubuntu já costuma ser o caso. As SYN cookies dispensam a fila de espera das ligações meio abertas e reconstroem o estado a partir da resposta do cliente, pelo que um SYN flood cai no vazio enquanto a linha não estiver cheia. O net.core.somaxconn está desde o Linux 5.4 em 4096 e, antes disso, em 128: se o valor for pequeno, o kernel descarta ligações já estabelecidas antes de o processo de jogo as chegar sequer a aceitar.

6. Evitar o esgotamento de slots: porque é que um scan de portas enche o seu servidor

O esgotamento de slots é o ataque eficaz mais barato contra um servidor Terraria: o atacante abre para a porta 7777 tantas ligações TCP quantos os slots de jogador do servidor e mantém-nas abertas. Isso quase não lhe custa largura de banda, mas enche o servidor. Os jogadores verdadeiros veem "Server is full" e deixam de conseguir entrar, apesar de na sua linha não estar a acontecer nada de especial. É precisamente por isso que, no Terraria, quem opera o servidor muitas vezes não dá conta de que está a ser atacado.

A causa está na forma de contar: uma ligação é aceite antes de o cliente ter sequer enviado o seu identificador de versão. Historicamente, essas ligações fantasma ficavam ocupadas até a sessão TCP expirar. A série 1.4.5 atenuou isso: aí deixaram de ser reservados slots para clientes que se desligam imediatamente a seguir. Nas primeiras versões da 1.4.5.7 e da 1.4.5.8, porém, o servidor dedicado ia abaixo com uma ObjectDisposedException não tratada assim que uma ligação TCP fosse aberta sem concluir o aperto de mão. Bastava um nc -z ou uma verificação de disponibilidade de um sistema de monitorização. O erro foi corrigido em silêncio ao fim de poucas semanas, mas em imagens de contentor mais antigas ainda está parcialmente presente. Mantenha por isso a versão do seu servidor atualizada: aqui isso não é um lugar-comum, é uma questão concreta de disponibilidade.

Duas definições ajudam ainda. Quem usa o TShock define o MaxSlots com o número de jogadores pretendido e o maxplayers na serverconfig.txt dois lugares acima: assim o TShock descarta as ligações excedentes com uma mensagem limpa, em vez de o processo de jogo as deixar entrar na última brecha. E o limite de ligações da secção anterior é exatamente a regra que impede um único endereço de ocupar todos os slots de uma só vez.

7. Desligar o UPnP e não publicar o endereço por iniciativa própria

O servidor Terraria tenta por predefinição abrir a sua porta num router através de UPnP. Num servidor alugado isso não tem efeito; numa rede doméstica abre portas de que mais tarde já não se lembra. Desligue-o com upnp=0 na serverconfig.txt ou com -noupnp na linha de comandos.

Aqui compensa, além disso, a honestidade em vez do pensamento mágico: o seu endereço IP não se consegue manter em segredo. Qualquer jogador que se tenha ligado uma vez conhece-o, e uma entrada numa página de listagem publica-o de qualquer forma. Eficazes são dois hábitos. Não publique a si próprio o endereço IP em bruto em lado nenhum; ligue antes os seus jogadores através de um hostname: o cliente do Terraria resolve um hostname, pelo que pode mudar de endereço em caso de necessidade sem que todas as referências deixem de funcionar. E limpe os registos DNS antigos, porque um registo A esquecido a apontar para o endereço anterior torna qualquer mudança inútil.

8. Guardar as consultas de estado em cache em vez de as encaminhar

Como o Terraria não tem protocolo de consulta, as páginas de estado, os bots do Discord e as páginas de listagem apuram o estado do seu servidor por uma de duas vias: ou estabelecem uma ligação TCP verdadeira à 7777 e se fazem passar por cliente, ou consultam a API REST do TShock. Ambas custam trabalho ao seu servidor, e ambas crescem com o número de quem consulta.

A contramedida não custa nada: nunca consulte a partir do visitante. Deixe um único serviço obter o estado a intervalos fixos (30 ou 60 segundos chegam), guarde o resultado em cache e entregue a todos os visitantes o valor guardado. Assim, uma página de estado muito visitada gera uma consulta por intervalo em vez de uma por visitante. Quem usar a API REST para isso restringe a porta 7878 ao endereço desse único serviço.

9. Registar em log, para ter dados quando for preciso

O passo mais importante é aquele que quase ninguém dá com antecedência: criar uma base de comparação enquanto tudo funciona normalmente. Sem um valor normal, depois de um incidente não consegue dizer se 40 000 pacotes por segundo foram muito ou se era simplesmente sábado à noite. Com apt-get install -y vnstat sysstat, a medição fica sempre a correr. Durante um incidente bastam 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

O terceiro comando é o específico do Terraria: conta as ligações meio abertas. Um valor de dois algarismos é normal, um de quatro ou cinco algarismos é um SYN flood. O ss -s mostra a par disso o número total de ligações TCP e, se esse número corresponder aproximadamente ao seu maxplayers enquanto no jogo não está ninguém, está a ver um esgotamento de slots. Quanto ao tcpdump vale a regra: limitar sempre com -c, porque uma captura a plena carga sobrecarrega ainda mais um servidor que já está sobrecarregado. Como interpretar os valores está em Detetar um ataque DDoS.

Onde estas medidas deixam de chegar

Agora a parte que nenhum ficheiro de configuração resolve. Todas as medidas anteriores correm no seu servidor, ou seja, no fim da linha. Uma regra de firewall decide sobre um pacote que já passou pelo cabo. Pode descartá-lo, mas não pode fazer com que ele não tenha sido enviado.

Faça as contas connosco. Um gameserver típico está ligado a 1 Gbit/s, o que corresponde a 125 megabytes por segundo, e a linha fica cheia assim que alguém enviar mais do que isso. Os ataques contra projetos de gameserver desta dimensão situam-se habitualmente entre 5 e 50 Gbit/s, ou seja, entre cinco e cinquenta vezes a sua linha. Nessa altura já não interessa se a sua regra connlimit por trás é boa, porque os pacotes dos seus jogadores nem chegam a passar. É exatamente assim que surgem os picos de lag num servidor Terraria em que a utilização do CPU parece normal.

A segunda grandeza é a taxa de pacotes, e muitas vezes ela chega ao limite antes da largura de banda. Com pacotes pequenos de 64 bytes cabem numa linha de 1 Gbit/s cerca de 1,49 milhões de pacotes por segundo. Um kernel de servidor normal processa, consoante o CPU e a placa de rede, algumas centenas de milhares deles antes de começar a descartar. Num SYN flood o limite fica ainda mais baixo, porque cada pacote SYN desencadeia uma decisão de estado: bastam algumas dezenas de milhares de pacotes SYN por segundo para paralisar a aceitação de ligações de um Linux padrão, muito antes de a linha estar cheia. Quem opera servidores vive isto como "a utilização nem sequer estava alta e mesmo assim desapareceu tudo".

E o terceiro ponto é aquele que no Terraria mais vezes passa despercebido: um atacante não se orienta pelo seu protocolo. Ele envia floods UDP e tráfego de reflection para o seu endereço, apesar de não haver nada à escuta em nenhuma porta UDP. O seu servidor descarta esses pacotes corretamente, mas eles já ocuparam a sua linha, e o seu servidor Terraria fica offline sem que um único pacote tenha chegado ao processo de jogo. Para dar uma ideia das ordens de grandeza que ocorrem na realidade: em servidores da KernelHost foram filtrados, entre outros, um ataque com mais de 473,4 Gbit/s e mais de 41,5 milhões de pacotes por segundo e um flood UDP com mais de 112,2 Gbit/s contra um gameserver. Para isso não existe nenhuma definição local. Os ataques volumétricos têm de terminar na rede à frente do servidor.

O que a KernelHost põe do outro lado

A proteção permanente incluída em todos os servidores

A proteção DDoS da KernelHost está construída em dois níveis e permanentemente ativa, sem que tenha de ativar, encomendar ou configurar seja o que for:

• Nível 1: 17 Tbps de capacidade de mitigação na rede global de scrubbing. Os ataques volumétricos são limpos perto da sua origem, antes de chegarem ao datacenter.
• Nível 2: filtragem Arbor em tempo real com 3,2 Tbps em Frankfurt am Main. Mesmo à frente do servidor são reconhecidos e descartados os padrões específicos de cada protocolo, pacote a pacote. Para o Terraria isso significa, em concreto: os floods de SYN e de ligações contra a 7777 TCP terminam aqui, e não na sua placa de rede.

Duas características são decisivas. A proteção corre em permanência e não precisa de reagir primeiro a um ataque, pelo que não existem aqueles minutos iniciais em que o servidor desaparece. E não é usado null-routing: o seu endereço IP mantém-se na rede e só os pacotes nocivos são descartados. Quem retira o endereço IP da rede consegue, para si, o mesmo resultado que o atacante. O local é Frankfurt am Main. Que jogos e protocolos estão cobertos é o que lista Proteção DDoS em tempo real para servidores de jogos.

Advanced DDoS Protection para projetos sob fogo permanente

Alguns projetos não são atacados de forma ocasional, mas sim de forma dirigida e ao longo de semanas. Para esses existe a Advanced DDoS Protection a partir de 50,00 EUR por mês, PrePaid, sem prazo mínimo e sem taxa de instalação. A diferença não está em mais capacidade, mas sim no controlo:

• IP de proteção dedicado a partir do núcleo de Frankfurt, para o qual o seu servidor é comutado dentro da nossa própria rede. Do seu lado não é preciso qualquer alteração.
• Regras de proteção autogeríveis por porta e por protocolo na área de cliente: define o que é permitido na 7777 TCP e pode fechar tudo o resto, sem ter de escrever um ticket para isso.
• As alterações entram em vigor em tempo real, pelo que pode afinar durante um ataque em curso, por exemplo apertando a taxa de ligações permitida por endereço de origem.
• Perfil de proteção adequado à aplicação. Para jogos TCP como o Terraria e para aplicações próprias ou modificadas em quaisquer portas TCP ou UDP existem perfis apropriados.

Os dois níveis em comparação

Para a maioria dos projetos de Terraria, a proteção permanente incluída chega, em conjunto com uma configuração de servidor limpa. A Advanced DDoS Protection é a resposta para quando alguém leva a coisa a peito. Quem tem neste momento o servidor noutro sítio não consegue acrescentar a proteção depois, obtém-na sim através da mudança para a KernelHost: a filtragem faz parte da rede e não é um extra no servidor.

Erros frequentes e respetivas soluções

"O servidor está cheio, mas não está lá ninguém": isso é um esgotamento de slots. Verifique com ss -tn dst :7777 | wc -l quantas ligações estão de facto abertas e compare o valor com a lista de jogadores (consola do servidor: playing). Se os números não coincidirem, são ligações alheias que ocupam os slots. Os remédios são o limite de ligações por endereço de origem, uma palavra-passe de servidor e uma versão de servidor atualizada.

"Abri a 7777 UDP e não muda nada": correto, porque na 7777 UDP não está nada à escuta. O Terraria usa exclusivamente TCP. A abertura UDP não faz mal direto, mas é uma abertura desnecessária e um sinal seguro de que foi copiado um guia para outro jogo.

"As minhas regras de iptables não fazem efeito": há três causas frequentes. As regras estão atrás das cadeias do UFW e nunca chegam a ser alcançadas; desapareceram no último reinício (nesse caso ajudam o netfilter-persistent save ou uma entrada em /etc/ufw/before.rules); ou o ataque é volumétrico e a regra trabalha corretamente numa linha que já está cheia. Verifique com iptables -L INPUT -n -v se os contadores de correspondências sobem. Se ficarem a zero, a regra não está a ser alcançada.

"Os jogadores são expulsos sem que haja ataque nenhum": se apertar demasiado o seu limite connlimit, atinge jogadores atrás de ligações partilhadas. Em TCP isso acontece mais depressa do que em jogos UDP, porque uma reconexão depois de uma falha gera logo uma ligação nova enquanto a antiga ainda está pendurada em TIME_WAIT. Aumente o valor por etapas e observe os contadores de correspondências.

"O servidor engasga e a linha está calma": isso é mais vezes um mod ou um plugin do que um ataque. Em tModLoader, cada mod adicional custa tempo de processamento no mesmo processo, e um mundo com muitas entidades ocupa um núcleo por completo sem que chegue um pacote a mais. Se o sar -n DEV 1 10 não mostrar nada de especial, não foi um ataque DDoS.

"O meu fornecedor anterior bloqueou o meu endereço IP": isso é null-routing. Com isso o fornecedor protege a sua própria rede; para si, o resultado é idêntico ao de um ataque bem-sucedido, normalmente ainda durante horas depois. Na dúvida, pergunte se filtram ou se aplicam null-routing. A resposta decide mais sobre a sua disponibilidade do que qualquer indicação de hardware.

"No tcpdump não vejo nada de especial": se o tráfego já é filtrado na rede à frente, é natural que nada chegue ao servidor. Esse é o caso normal quando a filtragem funciona. O inverso também é verdade: se a linha estiver saturada, é possível que nem sequer consiga estabelecer a sessão SSH com que queria medir. Nesse caso utilize a consola VNC na área de cliente, que funciona independentemente da rede do sistema convidado.

Em resumo

• Um servidor Terraria precisa de exatamente uma porta aberta: 7777 TCP. O jogo não abre socket UDP, não tem protocolo de consulta e não tem RCON.
• A API REST do TShock na porta 7878 TCP é a segunda superfície de ataque. Deixe o RestApiEnabled a false ou restrinja a porta ao seu próprio endereço.
• Uma palavra-passe de servidor na serverconfig.txt é a medida gratuita mais eficaz, porque um atacante sem a resposta correta à mensagem 37 nunca chega à transmissão do mundo.
• O esgotamento de slots é o ataque mais barato contra o Terraria: cada ligação TCP aceite na 7777 ocupa um lugar, sem largura de banda digna de nota. Contra isso resultam um limite por endereço de origem, uma palavra-passe e uma versão de servidor atualizada.
• Como o Terraria usa TCP, o endereço de origem de uma ligação estabelecida não se pode falsificar: os bloqueios de IP resultam aqui melhor do que em jogos UDP. Contra floods de SYN falsificados só ajudam as SYN cookies e a filtragem à frente.
• Um flood UDP deixa o seu servidor Terraria inoperacional, apesar de ele não falar UDP, porque enche a linha antes de o processo de jogo ver o que quer que seja.
• A partir sensivelmente da dimensão da sua largura de banda de uplink, quem decide é exclusivamente a rede à frente do servidor. Na KernelHost essa filtragem tem dois níveis, está permanentemente ativa e vem incluída em todos os pacotes de servidor sem sobretaxa.

Se o seu projeto já estiver alojado na KernelHost, a filtragem está ativa sem que tenha de fazer o que quer que seja. Se, ainda assim, notar anomalias, abra um ticket de suporte, para que as regras de filtragem sejam afinadas para o seu endereço IP. Durante um ataque em curso pode ainda falar connosco pelo chat de emergência do WhatsApp, através do +43 650 8209883.