Proteger o servidor Project Zomboid contra ataques DDoS

Quem quer proteger o seu servidor de Project Zomboid contra ataques DDoS tem primeiro de saber contra o que é que um atacante dispara. Um servidor dedicado ocupa exatamente duas portas UDP, a 16261 e a 16262, e ambas têm de estar abertas na rede, porque de outra forma ninguém consegue entrar. Este artigo segue a ordem que conta no momento difícil: primeiro aquilo que pode fazer por conta própria e sem custos adicionais nos próximos dez minutos, depois o ponto em que estas medidas terminam do ponto de vista técnico e, por fim, aquilo que tem de acontecer antes disso, na rede.

Todas as indicações se referem ao servidor dedicado (aplicação Steam 380870) em Debian 12, Debian 13, Ubuntu 22.04 LTS ou Ubuntu 24.04 LTS, tanto para a build 41 como para a build 42. O ficheiro de configuração chama-se servertest.ini e encontra-se em ~/Zomboid/Server/, os dados do mundo estão em ~/Zomboid/Saves/Multiplayer/. Os comandos estão escritos para root; como utilizador normal, anteponha sudo.

Se o ataque estiver a decorrer neste momento: não altere agora nada na servertest.ini e não reinicie o servidor. Guarde primeiro os valores medidos (secção 9), porque depois do ataque desaparecem. Um reinício custa ainda o tempo de que o servidor precisa para carregar o mundo, e é precisamente esse tempo que o atacante lhe quer tirar.

Porque é que os servidores de Project Zomboid se tornam alvo de ataques DDoS

Project Zomboid é um jogo com morte permanente e com um mundo que continua a correr durante meses. Uma quebra de ligação a meio de uma situação perigosa custa aqui mais do que em quase todos os outros géneros: a personagem desaparece, e o mundo lembra-se disso. É precisamente isso que transforma uma falha numa arma. Um ataque às 20 horas atinge uma comunidade fixa, e atinge-a no ponto em que ela tem mais a perder.

A isso acresce que o próprio ataque não custa nada nem exige competência. Os serviços de ataque contratáveis, no meio chamados booters ou stressers, apontam com poucos cliques a um endereço IP e a uma porta, e em Project Zomboid o alvo é sempre o mesmo: 16261 UDP. Quem estiver em conflito com um jogador banido ou gerir uma comunidade concorrente tem assim nas mãos uma ferramenta para a qual não precisa nem de conhecimentos nem de dinheiro digno de nota.

A isso acresce ainda que um gameserver tem de publicar o seu endereço. Com Public=true na servertest.ini, o servidor aparece no browser de servidores do jogo, e um servidor com ligação à Steam está de qualquer forma visível no browser de servidores da Steam. A pergunta nunca é, portanto, se um atacante encontra o seu endereço IP, mas apenas o que acontece quando ele dispara contra ele.

Do lado técnico, a parte mais desagradável fica para o fim: todo o tráfego de jogo corre sobre UDP. O UDP não tem um estabelecimento de ligação que se possa exigir, cada pacote vale por si, e o endereço de origem deixa-se falsificar. Um atacante não precisa, portanto, de entrar no seu servidor nem de o contactar corretamente para lhe gerar carga. O que é em detalhe um ataque DDoS fica explicado no artigo O que é um ataque DDoS?.

Que portas um servidor de Project Zomboid precisa mesmo

Um servidor dedicado de Project Zomboid precisa exatamente de duas portas abertas: 16261 UDP e 16262 UDP. A lista oficial de portas do jogo não nomeia uma terceira. Na servertest.ini constam como duas diretivas separadas, e a segunda porta não resulta automaticamente da primeira:

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

A divisão de tarefas é inequívoca. A 16261 UDP transporta o tráfego de jogo e o estabelecimento da ligação e responde às consultas do browser de servidores. A 16262 UDP é a porta para a ligação direta dos clientes. Se faltar a primeira, ninguém encontra o servidor; se faltar a segunda, os seus jogadores veem a entrada na lista e mesmo assim não conseguem entrar. É precisamente daí que vem a mensagem de erro mais conhecida do jogo, a de que a porta 16262 está fechada.

Dois pontos que dão problemas com regularidade. Primeiro: cada instância de servidor precisa de duas portas UDP livres. Quem mantiver um segundo mundo na mesma máquina atribui-lhe um segundo par, por exemplo 16274 e 16275, e escreve ambos os valores na servertest.ini da segunda instância. Segundo: SteamPort1 e SteamPort2 constam do ficheiro de configuração com 8766 e 8767, mas pertencem à ligação à Steam e não ao tráfego de jogo. Abra-as apenas se o seu servidor não aparecer na lista da Steam sem elas, e não por precaução.

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

Esta secção é a mais longa, e isso é intencional. Um servidor bem configurado aguenta ataques pequenos e médios pelos seus próprios meios, independentemente de onde esteja alojado. Não lhe tira um ataque volumétrico das mãos, mas faz com que os ataques baratos fiquem sem efeito e com que, no momento difícil, tenha números em vez de suposições.

1. Levantamento: o que está mesmo à 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:16261 e [::]:16261 significam "acessível a partir de toda a internet", 127.0.0.1:27015 significa "apenas local" e não precisa de abertura. Compare o resultado com a sua configuração em vez de confiar nos valores por omissão:

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

A perspetiva do atacante obtém-se com um scan de portas a partir de fora. Como Project Zomboid usa exclusivamente UDP, é preciso o scan UDP; um scan apenas de TCP nem sequer mostra a porta de jogo:

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

2. Deixar abertas apenas a 16261 e a 16262

Bastam duas aberturas para o exterior, tudo o resto fica restringido ou nem sequer chega a ser publicado. 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 16261/udp comment "Project Zomboid"
ufw allow 16262/udp comment "Project Zomboid ligação direta"
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

Substitua 203.0.113.10 pelo seu próprio endereço. A ordem no momento de ativar decide se se tranca ou não a si próprio fora do servidor. Ela está, com caminho de regresso e tudo, no artigo Configurar a firewall UFW sem se trancar fora do servidor. Se mesmo assim acontecer: nos servidores KVM e nos servidores dedicados da KernelHost chega ao sistema através da consola VNC na área de cliente, que funciona independentemente da rede do sistema convidado.

Uma palavra sobre bases de dados e serviços adicionais: Project Zomboid não precisa de nenhum. O que estiver à escuta em 0.0.0.0 ao lado do jogo vem de uma instalação anterior ou de um painel de administração e deve ser ligado a 127.0.0.1 ou então desligado.

3. Tirar o RCON na porta 27015 da internet

O RCON é o controlo remoto do servidor e corre, em Project Zomboid, na 27015 TCP. Na servertest.ini tal como é entregue consta RCONPassword= sem valor. Quem usa o RCON define uma palavra-passe aleatória longa, porque o protocolo transmite sem cifragem, e uma porta RCON acessível com uma palavra-passe fraca entrega o servidor por inteiro, sem que para isso seja necessário um único pacote de tráfego de ataque.

O caminho seguro é não abrir sequer a porta para o exterior e chegar até ela através de um reencaminhamento de porta por SSH. Depois disso, passa a falar localmente com 127.0.0.1:27015:

ssh -N -L 27015:127.0.0.1:27015 root@IP.DO.SEU.SERVIDOR

Quem não precisa do RCON deixa o campo da palavra-passe vazio e a porta fechada. Um serviço que não está acessível não pode ser nem testado às cegas nem inundado.

4. Limitar as taxas de pacotes por endereço de origem

Contra ataques pequenos e bots mal feitos ajuda um limite máximo por endereço de origem. Como as duas portas de jogo estão lado a lado, basta uma regra para o intervalo:

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

A regra descarta pacotes UDP assim que o mesmo endereço de origem envie, de forma continuada, mais de 400 pacotes por segundo. O valor é um valor de partida, não uma verdade absoluta: um servidor com 30 jogadores na mesma cidade gera bastante mais tráfego do que um com quatro jogadores em cantos diferentes do mapa, e quem aperta demasiado acaba por expulsar os seus próprios jogadores. Meça primeiro durante uma semana em funcionamento normal e só depois coloque o limite num múltiplo do valor de pico.

Duas notas a este respeito. 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

E com o UFW estas regras pertencem ao /etc/ufw/before.rules, porque de outra forma desaparecem no ufw reload seguinte. Verifique com os contadores de correspondências de iptables -L INPUT -n -v se a regra chega sequer a ser alcançada. Se os contadores ficarem a zero, está no sítio errado.

5. Aliviar o seguimento de ligações

Um estrangulamento muitas vezes ignorado está no kernel. O seguimento de ligações cria uma entrada por endereço de origem e porta também para o UDP, e um flood com remetentes falsificados enche essa tabela em segundos. Se ela encher, o servidor descarta também pacotes legítimos e no registo aparece "nf_conntrack: table full". O estado atual e o limite máximo são mostrados por:

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max

O tráfego de jogo de Project Zomboid não precisa de seguimento de estado, porque o UDP não tem estado. Pode, por isso, manter as duas portas de jogo fora da tabela:

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

Isso alivia o kernel de forma sensível. Importante: a regra só serve enquanto o servidor receber os pacotes diretamente. Quem tiver uma tradução de endereços à frente, por exemplo numa construção em contentores com encaminhamento de portas, não a deve definir, porque o sentido de retorno deixa de ser atribuído.

6. Proteger a entrada e os lugares

As linhas seguintes não custam nada e atuam contra tudo o que chega pelo caminho normal de entrada:

Password=UMA-PALAVRA-PASSE-LONGA-E-ALEATORIA
Open=false
MaxAccountsPerUser=1
MaxPlayers=32
DenyLoginOnOverloadedServer=true

Password é a palavra-passe comum do servidor e está separada da conta de cada jogador. Open=false significa que só podem entrar contas que um administrador tenha criado previamente, e essa é a whitelist do jogo. MaxAccountsPerUser limita quantas contas um único utilizador da Steam pode criar no seu servidor, e a predefinição 0 significa sem limite. MaxPlayers vem de origem em 32, e acima desse valor a documentação avisa expressamente de mau carregamento do mapa e de dessincronização.

PingLimit é, neste ponto, a armadilha. A diretiva expulsa jogadores a partir de uma latência em milissegundos e vem de origem em 0, ou seja, desligada. Sob um ataque, a latência sobe primeiro nos seus próprios jogadores, pelo que um valor apertado expulsa exatamente as pessoas que quer manter. Deixe o limite desligado ou defina-o de forma generosa.

E uma coisa tem de ficar clara: uma whitelist protege a sua lógica de jogo, não a sua linha. Um atacante que inunda o seu servidor nem sequer quer entrar. Os pacotes dele são recusados, mas mesmo assim chegaram, e é precisamente esse o ponto.

7. A verificação dos mods ao ligar é o momento mais caro do seu servidor

Project Zomboid verifica, ao ligar, mais do que uma palavra-passe. A lista de mods do servidor consta de duas linhas da servertest.ini: WorkshopItems contém os IDs numéricos do Workshop, Mods os IDs de carregamento dos mods, ambos separados por ponto e vírgula. Ao entrar, o cliente compara esta lista, descarrega automaticamente através da Steam os conteúdos do Workshop em falta e só depois recebe os dados do mundo em streaming. Além disso, com DoLuaChecksum=true o servidor compara as somas de verificação dos ficheiros do jogo e expulsa os clientes cujos ficheiros não coincidam com os seus.

Para um atacante é precisamente isso que interessa, porque o trabalho surge antes da participação efetiva no jogo. Cada tentativa de ligação custa ao servidor tempo de processamento para versão, soma de verificação, lista de mods e dados do mapa, incluindo a tentativa que no fim é recusada. Uma lista de mods longa torna cada uma dessas tentativas mais cara. Um flood de entradas é, por isso, mais eficaz num servidor fortemente modificado do que num servidor sem alterações, e precisa para isso de uma fração da largura de banda de um ataque volumétrico. Contra isso, o jogo traz dois travões integrados:

DenyLoginOnOverloadedServer=true
LoginQueueEnabled=true
LoginQueueConnectTimeout=60

DenyLoginOnOverloadedServer recusa novas autenticações enquanto o servidor estiver sobrecarregado, em vez de arrastar consigo a partida em curso. LoginQueueEnabled coloca quem entra numa fila de espera em vez de os processar ao mesmo tempo, e LoginQueueConnectTimeout define quanto tempo pode demorar uma entrada, com a predefinição de 60 segundos e valores permitidos de 20 a 1200.

Um detalhe pertence a este ponto, porque é resolvido erradamente com frequência: em servidores Linux existe um erro documentado em que o DoLuaChecksum dá alarme falso e não deixa entrar os jogadores. Por isso, há operadores que desligam a verificação. É compreensível, mas remove um controlo que mantém afastados os clientes com ficheiros de jogo alterados. Quem tiver de a desligar deve definir de forma tanto mais rigorosa a palavra-passe do servidor, a whitelist e o limite de contas.

8. Lista de servidores, UPnP e o próprio endereço

Aqui compensa mais a honestidade do que o pensamento mágico: o seu endereço IP não se consegue manter em segredo. Public=true mostra o servidor no browser do jogo, e um servidor com ligação à Steam está, segundo a documentação, de qualquer forma visível no browser de servidores da Steam. Public=false tira-lhe, portanto, a visibilidade para novos jogadores sem o tornar invisível.

Public=true
PublicName=O meu servidor Zomboid
UPnP=false
server_browser_announced_ip=

UPnP vem de origem em true e faz o servidor tentar criar por si próprio uma abertura de portas num gateway de internet. Num servidor alugado não existe um gateway desses, a tentativa não dá em nada e deve ser desligada. server_browser_announced_ip fica vazio, exceto se o seu servidor tiver vários endereços e dever aparecer especificamente sob um deles. É precisamente este campo de que voltará a precisar mais tarde, quando mudar para um IP de proteção dedicado.

Dois hábitos ajudam mais do que qualquer definição. Não publique você próprio o endereço IP em bruto em lado nenhum, ou seja, nem no canal de Discord nem na página do projeto, e dê aos seus jogadores um hostname. O clássico, na mudança de endereço, são os registos DNS antigos: um registo A esquecido a apontar para o endereço anterior torna qualquer mudança inútil.

9. Medir enquanto tudo corre normalmente

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

Os dois primeiros mostram a taxa de pacotes e os contadores de descarte da interface, o terceiro uma amostra curta do tráfego, o quarto as mensagens do servidor, desde que ele corra como serviço do systemd (adapte o nome do serviço). 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 avaliar os valores está em Detetar um ataque DDoS no servidor.

Onde estas medidas deixam de chegar: largura de banda e taxa de pacotes

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 são 125 megabytes por segundo, e a linha fica cheia assim que alguém enviar mais do que isso. 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 em 1 Gbit/s cerca de 1,49 milhões de pacotes por segundo, ao passo que um kernel de servidor normal processa, consoante o CPU e a placa de rede, apenas algumas centenas de milhares deles 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. Quem opera servidores vive isto como "a utilização nem sequer estava alta e mesmo assim desapareceu tudo".

Os ataques habituais contra comunidades de gameservers situam-se entre 5 e 50 Gbit/s, ou seja, entre cinco e cinquenta vezes uma linha normal. 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 contra os ataques DDoS a gameservers

A proteção permanente que está 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.

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. 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 € 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, basta indicar o novo endereço no sítio onde os seus jogadores encontram o servidor.
• Regras de proteção autogeríveis por porta e por protocolo na área de cliente: define o que é permitido na 16261 e na 16262 UDP, e todo o resto fica fechado, 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.
• Perfil de proteção adequado. Para os jogos correntes existem perfis prontos a usar; para aplicações modificadas e próprias define você mesmo as regras por porta e por protocolo. Project Zomboid deixa-se delimitar com particular precisão, porque todo o tráfego de jogo corre sobre duas portas UDP vizinhas.

Os dois níveis em comparação

Para a maioria dos servidores de Project Zomboid, a proteção permanente incluída chega, em conjunto com uma configuração limpa. A Advanced DDoS Protection é a resposta para quando alguém leva a coisa a peito.

Erros frequentes e respetivas soluções

"Os meus jogadores recebem a mensagem de que a porta 16262 está fechada": isso não é um ataque, é uma abertura em falta. O servidor precisa de ambas as portas, 16261 UDP e 16262 UDP, e como regra de UDP. Uma abertura de TCP nos mesmos números não produz efeito nenhum. Verifique com ufw status verbose e com um scan UDP a partir de fora se ambas estão mesmo abertas.

"Mudei de endereço IP e duas horas depois estava 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 indicação de estado ou de um registo DNS antigo. Em Project Zomboid a mudança custa ainda mais: os clientes guardam os dados do mapa localmente sob o endereço e a porta, numa pasta com o padrão 123.45.0.12_16261_... dentro de Zomboid/Saves. Depois de uma mudança, cada jogador volta a descarregar do servidor o mapa já explorado. Mudar de endereço é, portanto, ganhar tempo com custos adicionais, não é uma solução.

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

"Os jogadores são expulsos ao entrar, mas o servidor continua a funcionar normalmente": isso é quase sempre a verificação, não um ataque. As causas são uma diferença de versão entre cliente e servidor, uma entrada do Workshop em falta ou desatualizada, ou uma soma de verificação que não coincide. Em regra, o cliente indica os mods que não correspondem. Compare WorkshopItems e Mods linha a linha.

"De poucos em poucos minutos há picos de lag e depois volta a funcionar": esse é o padrão habitual dos ataques curtos, que só correm até os jogadores desistirem de irritação. Olhe primeiro para os contadores de rede, não para a carga do CPU. Se sar -n DEV 1 10 e os contadores de descarte não mostrarem nada de especial, não foi um ataque, foi carga: demasiados jogadores na mesma célula, um mod caro ou pouca memória para a instância Java.

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

Em resumo

• Um servidor dedicado de Project Zomboid precisa exatamente de duas portas abertas: 16261 UDP (DefaultPort) e 16262 UDP (UDPPort). Ambas constam da servertest.ini como diretivas separadas.
• O RCON corre na 27015 TCP e vem de origem inscrito sem palavra-passe. A porta não pertence à internet aberta, deve ficar restrita ao próprio endereço ou fechada.
• A verificação dos mods ao ligar é o ponto mais caro: versão, soma de verificação, lista do Workshop e dados do mapa custam tempo de processamento, também em cada tentativa recusada. DenyLoginOnOverloadedServer e a fila de espera de entrada são, contra isso, os travões integrados.
• A palavra-passe do servidor, Open=false e MaxAccountsPerUser=1 protegem a lógica de jogo. Contra uma linha saturada nenhuma destas definições produz efeito.
• O limite físico está fixado: 1 Gbit/s são 125 megabytes por segundo e, com pacotes de 64 bytes, cerca de 1,49 milhões de pacotes por segundo. Os ataques habituais contra gameservers situam-se entre 5 e 50 Gbit/s.
• Os ataques volumétricos têm de terminar na rede à frente do servidor. Na KernelHost, isso são 17 Tbps de capacidade de mitigação na rede global de scrubbing e uma filtragem Arbor em tempo real com 3,2 Tbps em Frankfurt am Main, sem sobretaxa e sem null-routing.
• Quem está sob fogo permanente controla a filtragem por si próprio com a Advanced DDoS Protection: IP de proteção dedicado, regras por porta e por protocolo, alterações em tempo real, a partir de 50,00 € por mês.

Se o seu servidor 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.