Proteger o servidor MTA:SA contra ataques DDoS

Um servidor para Multi Theft Auto: San Andreas comporta-se sob um ataque DDoS de forma diferente de qualquer outro projeto multijogador de GTA, porque oferece em simultâneo três serviços de rede separados: o tráfego de jogo na 22003 UDP, um servidor HTTP completo na 22005 TCP e a consulta ASE na 22126 UDP. Cada um destes três serviços pode ser atacado por si só, e cada um falha de maneira diferente. Este artigo mostra primeiro o que pode proteger por conta própria e sem custos adicionais, depois onde estas medidas terminam na física da linha e, por fim, o que uma proteção DDoS eficaz para MTA:SA tem de conseguir fazer na rede à frente do servidor.

Se o ataque estiver a decorrer neste momento, a pergunta mais importante é qual dos três serviços está a ser atingido. Se os jogadores se mantiverem ligados mas deixarem de carregar recursos ao entrar, está a ser atingido o servidor HTTP na 22005. Se o servidor desaparecer do navegador enquanto os jogadores ligados continuam a jogar normalmente, está a ser atingida a consulta ASE na 22126. Se todas as ligações caírem ao mesmo tempo, ou o alvo é a 22003 ou a linha está cheia. Todas as indicações se referem a um servidor MTA 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.

Porque é que os servidores MTA:SA são tantas vezes alvo de ataques DDoS

Os projetos de MTA:SA são alvos cómodos porque têm de publicar o seu endereço por iniciativa própria. Um servidor só aparece no navegador do jogo se se registar na lista de servidores mestre e responder depois a consultas vindas de fora. A lista contém o endereço IP e a porta em texto simples, pelo que um trabalho prévio de reconhecimento é, para um atacante, supérfluo.

A isto junta-se a própria cena. Servidores de roleplay de língua alemã e brasileiros, servidores de drift e adaptações de DayZ competem pela mesma comunidade de jogadores, e uma falha à hora de maior afluência é visível ao máximo. Um jogador banido, uma equipa em conflito ou um projeto concorrente não precisa de competência nem de dinheiro digno de nota para tornar uma noite inutilizável. Os serviços de ataque contratáveis, na cena chamados booters ou stressers, vendem por poucos euros por mês exatamente dois resultados: pôr o servidor MTA offline durante minutos ou torná-lo injogável com picos de lag. O que é tecnicamente um ataque DDoS e que tipos de ataque existem fica explicado no artigo O que é um ataque DDoS?.

Do ponto de vista técnico, o MTA:SA facilita a vida aos atacantes em dois pontos, mais do que outras modificações multijogador. Primeiro, a consulta está numa porta UDP própria que, perante um único byte, envia uma resposta com vários kilobytes. Segundo, a cada servidor MTA pertence um servidor HTTP que entrega os ficheiros do lado do cliente de todos os recursos, e fá-lo sem autenticação a quem quer que os peça.

As portas que realmente contam

Um servidor MTA:SA precisa de exatamente três portas: 22003 UDP para o jogo, 22005 TCP para o servidor HTTP interno e 22126 UDP para a consulta ASE. A terceira porta não é uma definição à escolha, resulta de forma fixa da porta de jogo mais 123. Quem puser serverport em 22010 fica com a consulta na 22133.

Duas subtilezas constam assim do mtaserver.conf fornecido com o servidor e são regularmente ignoradas. O httpport pode ter o mesmo valor numérico do serverport, porque uma das portas é TCP e a outra UDP. E o serverip está em auto e deve ali ficar: um valor fixo liga o socket ASE exatamente a esse endereço e quebra a entrada na lista assim que o endereço mudar.

O protocolo de consulta ASE e porque é que ele é um amplificador

O ASE (All-Seeing Eye) é um protocolo de consulta puramente UDP: o primeiro byte do pacote determina a resposta e não existe qualquer estabelecimento de ligação. O servidor MTA conhece cinco consultas e responde-lhes na 22126:

• s é a consulta ASE completa. A resposta começa com EYE1 e contém o nome do servidor, o tipo de jogo, o nome do mapa, a versão, o estado da palavra-passe, o número de jogadores, a lista completa de todas as regras definidas por setRuleValue e, a seguir, cada jogador ligado com nome, pontuação e ping. Esta resposta não tem limite de tamanho.
• b e r são as consultas mais leves para o navegador do jogo. A resposta começa com EYE2 e é cortada no código fonte aos 1340 bytes, para evitar fragmentação.
• x entrega uma mensagem de estado reduzida, v apenas o identificador de versão do ASE.

Daqui resulta o problema. Um pedido consiste num único byte de carga útil, ou seja, no cabo, em 29 bytes (20 bytes de cabeçalho IP, 8 bytes de cabeçalho UDP, 1 byte de carga útil). Uma resposta de 1400 bytes de carga útil são, no cabo, 1428 bytes. A proporção é de cerca de 49 vezes e, como o UDP não conhece estabelecimento de ligação, o endereço de origem pode ser falsificado. Um atacante pode, portanto, usar o seu servidor como amplificador contra um terceiro alvo sem alguma vez entrar no seu jogo. Na consulta completa, o fator cresce com o número de jogadores e com cada regra que o seu gamemode define.

Contra isso, o MTA traz dois travões integrados que vale a pena conhecer, porque explicam por que razão alguns floods fazem efeito e outros não. O servidor responde, por endereço de origem, no máximo a cinco consultas em seis segundos e ignora depois esse endereço durante sete segundos. Além disso, mantém as respostas em cache durante dez segundos, em vez de as montar de novo a cada pedido. A contagem por endereço de origem é, no entanto, completamente ignorada assim que estiverem em lista mais de 100 endereços de origem diferentes ao mesmo tempo. É precisamente esse o caso normal num flood distribuído a partir de uma botnet ou com remetentes falsificados, e é por isso que o travão integrado não ajuda contra um ataque a sério.

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

Esta secção é a mais longa, e isso é intencional. Um servidor MTA 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?

Veja primeiro o que o seu servidor oferece para o exterior. Não adivinhe, verifique:

ss -lntup

São de esperar três linhas do processo do MTA: 0.0.0.0:22003 em UDP, 0.0.0.0:22005 em TCP e 0.0.0.0:22126 em UDP. Se ali aparecer ainda uma base de dados em 0.0.0.0:3306, um servidor web ou um serviço de voz esquecido, isso tem de ser desligado. A perspetiva do atacante obtém-se com um scan de portas a partir de fora:

nmap -Pn -sU -p 22003,22126 IP.DO.SEU.SERVIDOR
nmap -Pn -p 22005 IP.DO.SEU.SERVIDOR

Para isso, o servidor traz também um comando de consola próprio. Na consola do servidor, o openports verifica se as três portas estão acessíveis a partir de fora.

2. Deixar abertas apenas as três portas de que o MTA precisa mesmo

Com o UFW, uma configuração de partida sólida 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 22003/udp comment 'MTA jogo'
ufw allow 22005/tcp comment 'MTA HTTP'
ufw allow 22126/udp comment 'MTA ASE'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

As instruções completas, incluindo o caminho de recuperação, estão no artigo Configurar a firewall UFW. Nos servidores KVM root e nos servidores dedicados da KernelHost, em caso de emergência chega ao sistema através da consola VNC na área de cliente, mesmo com a linha saturada.

A base de dados não pertence à rede aberta. Se o ss -lntp | grep 3306 mostrar um 0.0.0.0:3306, coloque em /etc/mysql/mariadb.conf.d/50-server.cnf a linha bind-address = 127.0.0.1 e reinicie o serviço.

3. Limitar a porta ASE sem cair da lista de servidores

Ao contrário do SA-MP, no MTA:SA a consulta está numa porta própria, pelo que a pode limitar independentemente do funcionamento do jogo. Essa é a maior vantagem prática desta arquitetura: uma regra na 22126 não expulsa um único jogador.

Com nftables numa tabela própria, para que o conjunto de regras não entre em conflito com o UFW:

nft add table inet mtaguard
nft add chain inet mtaguard input '{ type filter hook input priority -150 ; policy accept ; }'
nft add rule inet mtaguard input udp dport 22126 meter aseperip '{ ip saddr limit rate over 3/second burst 6 packets }' drop
nft add rule inet mtaguard input udp dport 22126 limit rate over 2000/second burst 500 packets drop
nft list table inet mtaguard

A primeira regra limita cada endereço de origem em separado, a segunda limita a porta no seu conjunto. Ambas em conjunto são importantes: um flood distribuído passa pela brecha entre muitas origens individuais se apenas se limitar por endereço. Os valores estão escolhidos de forma apertada, e isso é aqui defensável, porque um navegador de servidores real consulta o seu servidor apenas de poucos em poucos segundos. Com o iptables, o módulo hashlimit consegue o mesmo:

iptables -A INPUT -p udp --dport 22126 -m hashlimit --hashlimit-name mta_ase \
  --hashlimit-mode srcip --hashlimit-above 3/sec --hashlimit-burst 6 \
  --hashlimit-htable-expire 30000 -j DROP

A tentativa de fechar a porta por completo é uma ponderação e não uma dica de bastidores: sem ASE o seu servidor desaparece do navegador do jogo e, com isso, do fluxo orgânico de novos jogadores. Se ainda assim o quiser fazer, <ase>0</ase> não chega. No código fonte, a abertura da porta depende da disjunção entre o modo internet e o modo LAN, pelo que o socket continua aberto com <ase>0</ase> enquanto estiver <donotbroadcastlan>0</donotbroadcastlan>. Quem quiser mesmo fechar a porta define as duas coisas:

<ase>0</ase>
<donotbroadcastlan>1</donotbroadcastlan>

O caminho mais honesto para um projeto em crescimento é este: deixar a porta aberta, limitar a taxa e manter pequeno o efeito de amplificação, fazendo com que o seu gamemode não publique regras desnecessárias por setRuleValue. Cada regra consta da consulta completa e aumenta a resposta.

4. Aliviar o servidor HTTP interno

O servidor HTTP na 22005 é, no MTA:SA, uma superfície de ataque própria, porque cada jogador que entra descarrega ali todos os ficheiros do lado do cliente de todos os recursos em execução. Num projeto de roleplay com modelos próprios, isso são rapidamente várias centenas de megabytes, distribuídos por centenas de ficheiros individuais. O servidor integrado é deliberadamente simples: sem compressão e com um contingente fixo de threads de trabalho. Algumas dezenas de pedidos em simultâneo bastam para que os jogadores reais fiquem minutos pendurados no ecrã de carregamento.

A medida mais eficaz é retirar os downloads por completo do servidor de jogo. Para isso, o próprio MTA disponibiliza os ficheiros a entregar, em mods/deathmatch/resource-cache/http-client-files. Publique esta pasta através de nginx ou lighttpd e inscreva o endereço no mtaserver.conf:

<httpdownloadurl>http://cdn.seu-dominio.tld/mta</httpdownloadurl>

Isso traz duas coisas de uma só vez. Os downloads passam por um servidor web construído para isso e deixam de passar pelo endereço do seu servidor de jogo. Se o servidor web estiver noutra máquina ou atrás de uma Content Delivery Network, um flood contra os downloads deixa de atingir o funcionamento do jogo. Importante: se o endereço externo estiver errado ou inacessível, o MTA volta em silêncio ao servidor interno.

Se o servidor interno continuar em uso, aproveite os seus próprios limites. No mtaserver.conf:

<httpmaxconnectionsperclient>5</httpmaxconnectionsperclient>
<httpdosthreshold>20</httpdosthreshold>
<http_dos_exclude></http_dos_exclude>
<httpthreadcount>8</httpthreadcount>

O httpmaxconnectionsperclient limita as ligações simultâneas por cliente a 5, dentro do intervalo admissível de 1 a 8. O httpdosthreshold limita quantas ligações um único endereço IP pode estabelecer em pouco tempo, com a predefinição 20. O http_dos_exclude exclui disso endereços individuais, por exemplo a sua própria página de estado. O httpthreadcount determina o número de threads de trabalho, com a predefinição 8 no intervalo de 1 a 20. Um valor mais alto ajuda com muitos ficheiros pequenos, mas custa tempo de processamento que falta ao funcionamento do jogo.

Lembre-se ainda do que mais é entregue na mesma porta. Os recursos webadmin e resourcebrowser estão iniciados na configuração fornecida e são acessíveis no browser pela 22005. Uma interface de administração não pertence desprotegida à rede aberta: defina permissões limpas no acl.xml, crie uma conta própria com uma palavra-passe longa e aleatória, e pare o recurso quando não precisar dele.

5. Aproveitar os limites integrados no mtaserver.conf

O MTA traz mais limites de proteção do que a maioria dos projetos utiliza. Alguns estão fixos no código fonte, outros no mtaserver.conf. Esta tabela reúne os que têm um papel durante um ataque:

Três definições merecem uma decisão consciente. O maxplayers está em 32 e deveria corresponder à realidade: cada slot adicional aumenta a consulta completa e eleva o número de ligações que um atacante pode ocupar. O bandwidth_reduction está em medium; o valor maximum baixa a carga de saída de forma percetível, mas custa precisão de sincronização. E o <password></password> transforma o seu servidor, sem esforço, num círculo fechado enquanto a entrada na lista se mantém: é o travão de emergência mais rápido durante um flood de entradas em curso.

6. Distinguir floods de entradas de floods de eventos

Dois padrões de ataque não visam a linha, mas sim a lógica de jogo, e são regularmente confundidos.

Um flood de entradas estabelece ligações reais em sequência rápida, até todos os slots estarem ocupados ou o servidor já não dar conta do estabelecimento das ligações. O MTA limita isso por si próprio a quatro ligações por endereço de origem em 30 segundos e ignora depois esse endereço durante 30 segundos. O que o travão está a fazer nesse momento é mostrado pelo comando de consola debugjoinflood. O limite atua por endereço, e uma botnet com mil endereços passa ao lado dele. Contra isso ajudam uma palavra-passe de servidor, uma whitelist no gamemode e uma limitação de taxa na 22003.

Um flood de eventos, pelo contrário, vem de jogadores já ligados: um cliente manipulado dispara triggerServerEvent em ciclo, até o servidor deixar de ter tempo de processamento disponível. Para isso, o MTA permite de origem 100 eventos por jogador e por segundo e, acima disso, alerta com uma mensagem sobre floods de eventos. Se o seu gamemode utilizar muitos eventos pequenos, verifique o valor antes de o baixar: definido de forma demasiado apertada, expulsa os seus próprios jogadores.

Independentemente disso, do lado do servidor vale a mesma regra de sempre: nunca confie nos valores que o cliente envia, determine o jogador a partir do remetente do evento e limite tudo o que desencadeie uma consulta à base de dados. Um único evento não verificado que arranque uma consulta chega para parar um servidor sem qualquer ataque de rede.

7. Lista de servidores, endereço IP e o que mais ele revela

O seu endereço IP não se consegue manter em segredo. Qualquer jogador que se tenha ligado uma vez conhece-o, e a entrada na lista de servidores mestre publica-o de qualquer forma. Um domínio à frente não ajuda: o cliente resolve o nome uma vez e fala depois diretamente com o endereço.

Verifique antes o que mais o seu endereço revela. As fugas típicas em projetos de MTA são registos A e AAAA antigos no DNS, a página do projeto na mesma máquina, um bot do Discord com indicação de estado que lê publicamente a consulta ASE, certificados TLS com hostnames antigos e mensagens de fórum do tempo inicial. Daí resulta uma regra que muitos projetos aprendem tarde demais: se mudar para um endereço protegido, mude ao mesmo tempo o endereço antigo. Se ele se mantiver, fica em qualquer base de dados de scanners e o ataque passa ao lado da proteção.

Duas entradas do mtaserver.conf dizem respeito diretamente à visibilidade. O <serverip>auto</serverip> fica em auto, exceto se souber exatamente porque não. E o <owner_email_address> deve estar preenchido: se a entrada faltar ou estiver errada, isso pode prejudicar a visibilidade na lista de servidores mestre.

8. 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 sexta-feira à noite. Com apt-get install -y vnstat sysstat, a medição fica sempre a correr.

Durante um incidente, separe primeiro as três portas umas das outras. Estes quatro comandos bastam:

sar -n DEV 1 10
nstat -az | grep -E 'Udp(InDatagrams|InErrors|NoPorts|RcvbufErrors)'
tcpdump -ni eth0 -c 200 -q 'udp port 22126'
ss -tn state established '( dport = :22005 or sport = :22005 )' | wc -l

A avaliação é mais simples do que parece. Se os erros de buffer subirem com baixa carga de CPU, chega-lhe mais tráfego do que o processo consegue despachar. Se um núcleo estiver no limite enquanto o tráfego parece normal, o problema está no gamemode e não na rede. Se a captura na 22126 mostrar muitos pacotes com um único byte de carga útil, é um flood ASE. Se o número de ligações abertas na 22005 se mantiver de forma continuada na ordem dos milhares, está a ser atingido o servidor HTTP. Quanto ao tcpdump vale sempre a regra: limitar com -c, porque uma captura a plena carga sobrecarrega ainda mais um servidor que já está sobrecarregado. Como avaliar os valores em detalhe é descrito no artigo Detetar um ataque DDoS no servidor.

O próprio log do servidor fica em logs/server.log, o log de scripts em logs/scripts.log. Ambos os caminhos constam do mtaserver.conf e podem ser mudados.

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, com pacotes de 64 bytes, a cerca de 1,49 milhões de pacotes por segundo. 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 de nftables por trás é boa, porque os pacotes dos seus jogadores nem chegam a passar.

A taxa de pacotes chega, aliás, muitas vezes ao limite antes da largura de banda. Um kernel de servidor normal processa, consoante o CPU e a placa de rede, algumas centenas de milhares de pacotes por segundo antes de começar a descartar. Um ataque que nem sequer enche um terço da sua linha pode, portanto, deixar o seu servidor inoperacional, porque o tempo de processamento se gasta a descartar. Quem opera servidores vive isto como "a utilização nem sequer estava alta e mesmo assim desapareceu tudo".

No MTA:SA junta-se um terceiro limite, e é o que atua mais cedo. O servidor lê as portas de rede num único fluxo de trabalho. Um flood de consultas na 22126 ocupa esse fluxo de tal forma que os pacotes de sincronização dos jogadores reais expiram no buffer de receção, muito antes de a linha estar cheia. O processo não estoira, apenas fica lento, e os jogadores veem efeitos de elástico. O mesmo vale para o servidor HTTP: ele partilha o tempo de processamento com o funcionamento do 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 contra um servidor de voz, e um flood UDP com mais de 112,2 Gbit/s e mais de 8,7 milhões de pacotes por segundo contra um gameserver. O primeiro caso é cerca de 473 vezes a largura de banda e cerca de 28 vezes a taxa de pacotes que uma linha de 1 Gbit/s consegue sequer aceitar. 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

Todos os servidores na KernelHost estão atrás de uma filtragem em dois níveis, permanentemente ativa:

• 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 sequer de chegarem ao datacenter em Frankfurt am Main.
• Nível 2: filtragem Arbor em tempo real com 3,2 Tbps no próprio local, em Frankfurt am Main. Imediatamente à frente do servidor são reconhecidos os padrões específicos de cada protocolo e descartados pacote a pacote.

Três características são decisivas. A proteção está permanentemente ativa, pelo que não existe uma fase de deteção durante a qual o seu servidor fique offline. Não é usado null-routing: o endereço atacado mantém-se na rede e só os pacotes nocivos são descartados, enquanto as ligações dos jogadores reais continuam a funcionar. E não custa nada a mais, está incluída a partir da disponibilização em todos os pacotes de servidor, do servidor KVM root ao gameserver e ao servidor dedicado. A filtragem acontece nas camadas 3, 4 e 7, em qualquer porta TCP ou UDP, ou seja, na 22003 UDP, na 22005 TCP e na 22126 UDP em simultâneo. Tudo isto é operado no datacenter maincubes em Frankfurt am Main, na Alemanha. Que jogos e protocolos têm perfis próprios é o que mostra o artigo Proteção DDoS em tempo real para servidores de jogos.

Advanced DDoS Protection para projetos sob fogo permanente

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

• Um IP de proteção dedicado a partir do núcleo de Frankfurt. O seu servidor é comutado para ele dentro da rede da KernelHost, sem que tenha de mudar seja o que for do seu lado.
• Regras de proteção autogeríveis por porta e por protocolo na área de cliente. É exatamente esse o ponto no MTA:SA: define regras separadas para 22003 UDP, 22005 TCP e 22126 UDP, em vez de medir três serviços muito diferentes pela mesma bitola.
• As alterações entram em vigor em tempo real, sem ticket e sem tempo de espera. Pode, portanto, afinar a meio de um ataque em curso.
• Um perfil de proteção adequado ao jogo. O Multi Theft Auto existe como perfil próprio, tal como servidores web, servidores de voz e aplicações TCP ou UDP próprias que caibam atrás do mesmo endereço de proteção.

Os dois níveis em comparação

Para a maioria dos projetos de MTA:SA, 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.

Erros frequentes e respetivas soluções

"Bloqueei a 22126, o servidor continua a não aparecer em nenhuma lista, mas continuam a chegar consultas": então o socket ainda está aberto. O <ase>0</ase> por si só não fecha a porta enquanto estiver definido <donotbroadcastlan>0</donotbroadcastlan>. Verifique com ss -lnup | grep 22126 se realmente já não há nada à escuta.

"Os jogadores ficam pendurados no ecrã de carregamento, o jogo em si corre normalmente": isso não é um ataque à 22003, é o servidor HTTP na 22005 no limite. Externalize os downloads através do httpdownloadurl e verifique o httpmaxconnectionsperclient e o httpthreadcount.

"O servidor desapareceu do navegador e os jogadores que estão dentro não notam nada": então está a ser atingida exclusivamente a 22126. Para os jogadores ligados isso é irrelevante, para a entrada de novos jogadores não é. Uma limitação de taxa nesta única porta é a resposta certa, não uma na porta de jogo.

"Mudámos de endereço IP e duas horas depois estávamos outra vez offline": o atacante obteve o endereço novo a partir da mesma fonte que o antigo, normalmente da entrada na lista, de um bot do Discord com consulta de estado ou de um registo DNS antigo. Mudar de endereço é ganhar tempo, não é uma solução.

"Definimos um limite de 20 pacotes por segundo por endereço na 22003": isso é demasiado apertado. Já um único jogador fica acima disso com a sincronização ativa, e vários jogadores atrás do mesmo endereço NAT partilham o mesmo contingente. Está assim a expulsar os seus próprios jogadores. Na 22126, pelo contrário, valores apertados não são problemáticos.

"Trancámo-nos a nós próprios com a firewall": reiniciar não ajuda, porque o UFW repõe as suas regras no arranque. Na KernelHost, abra a consola VNC na área de cliente e execute ali o ufw disable. A consola VNC funciona independentemente da rede do sistema convidado.

"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.

"Limitamo-nos a esperar que o ataque passe": os ataques que fazem efeito repetem-se. Documente o momento com fuso horário, a duração, os valores de pico e a porta afetada. São precisamente estas indicações que um ticket de suporte também precisa, para que a filtragem seja acertada de forma dirigida.

Em resumo

• Um servidor MTA:SA precisa de exatamente três portas: 22003 UDP para o jogo, 22005 TCP para o servidor HTTP interno e 22126 UDP para a consulta ASE. A terceira resulta de forma fixa da porta de jogo mais 123.
• A consulta ASE está numa porta própria e pode, por isso, ser limitada sem excluir um único jogador. Essa é a diferença mais importante em relação ao SA-MP, onde o jogo e a consulta partilham a mesma porta.
• Um único byte de pedido na 22126 gera uma resposta de até vários kilobytes, e o endereço de origem é falsificável. Uma porta ASE sem travão é, portanto, alvo e amplificador ao mesmo tempo.
• Os travões integrados do MTA atuam por endereço de origem: cinco consultas em seis segundos, quatro entradas em 30 segundos. Com mais de 100 endereços de origem em simultâneo, a contagem das consultas é ignorada, pelo que um flood distribuído passa.
• O servidor HTTP interno na 22005 é uma superfície de ataque própria. Quem externaliza os downloads para um servidor web através do httpdownloadurl retira-os do funcionamento do jogo.
• Tudo o que corre no servidor só decide sobre ataques pequenos. Com 1 Gbit/s, acaba por volta de 1,49 milhões de pacotes por segundo, independentemente da qualidade das suas regras.
• A proteção permanente em dois níveis da KernelHost está incluída em todos os pacotes de servidor sem sobretaxa e trabalha sem null-routing. Quem quiser controlar por si próprio as regras de cada porta junta a Advanced DDoS Protection a partir de 50,00 EUR por mês.

Se o seu projeto já estiver alojado na KernelHost, a filtragem está permanentemente ativa e não tem de ligar nada. Se, ainda assim, notar anomalias, abra um ticket de suporte com o período, a porta e o comportamento observado, para que as regras sejam afinadas para o seu endereço. Durante um ataque em curso pode ainda falar connosco pelo chat de emergência do WhatsApp, através do +43 650 8209883. Se ainda estiver alojado noutro sítio e for atingido com regularidade, mudar para Frankfurt am Main é a solução mais curta: os passos seguintes para o caso agudo estão no artigo Ataque DDoS grave: o que fazer?.