Team Fortress 2: proteger o servidor TF2 contra ataques DDoS

Um servidor de comunidade de Team Fortress 2 que, à noite e a meio da ronda, perde todos os jogadores ao mesmo tempo e depois desaparece durante minutos do navegador de servidores raramente tem um problema de hardware. Na maioria dos casos está a decorrer um ataque contra a 27015/UDP. Este artigo mostra como proteger um servidor TF2 contra ataques DDoS: primeiro aquilo que pode fazer por conta própria nos próximos dez minutos e sem custos adicionais, depois o ponto em que estas medidas acabam por razões físicas e, por fim, o que tem de acontecer antes disso, na rede.

Todas as indicações se referem a um servidor dedicado Source instalado com o SteamCMD (srcds_run -game tf) 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 nada primeiro e não reinicie o servidor, guarde antes os valores medidos da secção 9. Depois do ataque desaparecem.

Porque é que os servidores de Team Fortress 2 precisam de proteção DDoS

O Team Fortress 2 é gratuito desde 2011, e é precisamente isso que desloca a economia do ataque. Um atacante tem contas descartáveis sem limite, não paga por nenhuma delas e não arrisca nada com um banimento. O que num jogo pago custa dinheiro, aqui custa um minuto.

A isto junta-se uma particularidade que distingue o TF2 da maioria dos outros jogos: desde a atualização "Meet Your Match", de julho de 2016, deixou de existir o Quickplay, que distribuía automaticamente os novos jogadores pelos servidores de comunidade. Os novos jogadores acabam no modo Casual, em servidores da Valve. Os servidores de comunidade só são encontráveis através do navegador de servidores. Quem cai dessa lista deixa, na prática, de existir para os novos jogadores, mesmo que o processo do servidor esteja a correr sem qualquer falha. Um ataque que apenas empurre o seu servidor para fora da lista já atingiu, por isso, o seu objetivo.

Os alvos típicos são, em consequência: servidores de comunidade em funcionamento permanente e com jogadores habituais (2Fort 24 horas por dia, Trade, Jailbreak, Surf, Dodgeball, Mann vs. Machine), servidores de liga com data de jogo marcada nas competições da ETF2L, da RGL e da ozfortress, e ainda servidores cujo operador acabou de banir alguém. O motivo quase nunca é técnico. O que é um ataque DDoS fica explicado no artigo O que é um ataque DDoS?.

As portas que realmente contam num servidor TF2

Um servidor TF2 precisa de exatamente uma porta para o exterior: 27015/UDP. Tudo o resto ou se desliga, ou deve ficar restringido, ou funciona apenas em sentido de saída. Esta tabela é a base de todas as regras de firewall mais abaixo:

Com várias instâncias na mesma máquina, os números vão subindo: 27016, 27017 e assim por diante para o jogo, 27021 e 27022 para o SourceTV. O ficheiro de configuração fica em tf/cfg/server.cfg e é lido de novo a cada mudança de mapa.

Porque é que a porta partilhada 27015 é o ponto mais sensível

No TF2, o tráfego de jogo e a consulta ao servidor partilham a mesma porta UDP; uma porta de consulta separada não existe. Um pedido A2S_INFO tem exatamente 25 bytes: quatro bytes FF FF FF FF, um byte 0x54 e a cadeia de caracteres "Source Engine Query", com 20 bytes, terminada por um zero. A resposta, com nome do servidor, mapa, número de jogadores e tags, é um múltiplo disso. A agência norte-americana CISA quantifica em 5,5 o fator de amplificação do protocolo Steam, no alerta TA14-017A.

Como o UDP não conhece estabelecimento de ligação e os endereços de origem são falsificáveis, isto foi durante anos uma brecha de amplificação aberta: um atacante consultava servidores Source alheios usando o endereço da sua vítima como remetente, e os servidores enviavam as respostas para a vítima. O A2S_PLAYER e o A2S_RULES sempre exigiram um challenge obtido previamente, o A2S_INFO não. Só em dezembro de 2020 é que a Valve acrescentou também ao A2S_INFO um challenge: em vez da resposta, o servidor pode devolver um S2C_CHALLENGE, que quem consulta tem de repetir, provando assim que não falsificou o endereço de origem.

Isso atenua a reflexão, mas não põe fim ao incómodo. Cada pacote de consulta continua a chegar até si e a custar tempo de processamento antes de ser respondido ou descartado. E um atacante que inunde o seu servidor diretamente não precisa de amplificação nenhuma.

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

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

1. Levantamento: o que está à escuta, e com que linha de arranque

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

ss -lntup

Tudo o que esteja ligado a 127.0.0.1 ou a ::1 não precisa de abertura. Tudo o que esteja à escuta em 0.0.0.0 ou em [::] está acessível a partir da internet, incluindo a base de dados MySQL que um plugin de estatísticas trouxe consigo e o servidor web onde estão os seus ficheiros de FastDL. Compare o resultado com a sua linha de arranque:

./srcds_run -game tf -console \
  -port 27015 -steamport 26901 -nohltv \
  +maxplayers 24 +map ctf_2fort +sv_pure 1 \
  +sv_setsteamaccount O_SEU_TOKEN_GSLT

Cada porta nesta linha é uma decisão consciente. Como se instala a base está em Instalar um servidor de jogos com o SteamCMD.

2. Deixar abertas apenas as portas de que o TF2 precisa mesmo

Um servidor TF2 público precisa de exatamente uma abertura para o exterior, mais o RCON para o seu próprio endereço. Com o UFW, e por esta ordem, para que não se tranque a si próprio fora do servidor:

ufw allow 22/tcp comment 'SSH'
ufw allow 27015/udp comment 'TF2 jogo e A2S'
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. O SourceTV não aparece aqui de propósito: quem não transmite arranca com -nohltv e nem chega a ocupar a 27020/UDP. Isso reduz a metade a superfície UDP de um servidor TF2 acessível a partir do exterior. Se transmitir jogos de liga, junta-se o ufw allow 27020/udp, e nesse caso deve ser definida uma tv_password.

As instruções completas, incluindo a via de regresso, estão em Configurar a firewall UFW sem se trancar fora do servidor. Se mesmo assim acontecer: aos servidores root KVM e aos servidores dedicados da KernelHost chega através da consola VNC na área de cliente, que funciona independentemente da rede do sistema convidado.

3. Limitar as consultas A2S sem cair do navegador de servidores

É aqui que está o erro mais caro desta matéria: bloquear a 27015/UDP de forma genérica ou aplicar-lhe um limite de taxa grosseiro expulsa os seus próprios jogadores e termina o ataque no sentido pretendido pelo atacante. Como o tráfego de jogo e a consulta ocupam a mesma porta, a fronteira tem de passar entre os tipos de pacote, não pela porta.

O motor traz para isso três variáveis de consola, que pertencem ao tf/cfg/server.cfg:

sv_max_queries_sec 3
sv_max_queries_sec_global 60
sv_max_queries_window 30

A primeira limita as consultas respondidas por endereço de origem, a segunda a soma sobre todos os endereços e a terceira fixa em segundos a janela de média. Protegem o CPU de gerar respostas inúteis. Os valores predefinidos variam consoante o jogo e a build; find sv_max_queries na consola do servidor mostra que valores o seu servidor conhece.

No TF2, o valor delicado é o segundo: ele impõe um teto às respostas sobre todos os endereços. Se o definir demasiado baixo, durante uma enxurrada de consultas o seu servidor deixa de responder também aos pedidos dos serviços de listagem e desaparece do navegador de servidores, ou seja, do único caminho pelo qual os novos jogadores o encontram. Comece com uma margem generosa e só aperte o limite quando conseguir medir que as consultas legítimas continuam a passar.

Um nível abaixo, o mesmo tráfego pode ser separado com rigor. Todos os pacotes sem ligação do motor Source começam com quatro bytes preenchidos (0xffffffff), enquanto o tráfego dos jogadores já ligados não leva esse cabeçalho. É sobre isso que se pode aplicar um limite de taxa sem tocar no tráfego de jogo:

table inet tf2 {
    chain input {
        type filter hook input priority -10; policy accept;
        udp dport 27015 @th,64,32 0xffffffff \
            meter a2sflood { ip saddr limit rate over 10/second burst 20 packets } drop
    }
}

O ficheiro carrega-se com nft -f. A prioridade -10 faz com que a regra atue antes da cadeia de filtragem do UFW, e @th,64,32 lê os primeiros quatro bytes a seguir ao cabeçalho UDP.

4. Travar as enxurradas de pacotes divididos que aparecem no registo como NET_GetLong

Este ataque é uma particularidade do motor Source e atinge o TF2 de forma especial, porque o TF2 continua até hoje a correr sobre o ramo antigo do motor. Além dos pacotes normais sem ligação, o motor conhece pacotes divididos: começam com FE FF FF FF em vez de FF FF FF FF e anunciam que se segue uma mensagem maior, repartida em várias partes. O servidor tem de guardar as partes e esperar pelo resto.

É precisamente disso que se pode abusar. Um atacante envia em massa partes anunciadas, mas nunca completas, com endereços de origem falsificados. A carga do CPU sobe, o jogo engasga, e no registo do servidor acumulam-se linhas com NET_GetLong. Uma única máquina chega para isso, e largura de banda quase não é precisa. Os operadores comunicam isto regularmente como ataque DDoS, apesar de a linha estar quase vazia.

Como um cliente TF2 normal quase não tem motivo para enviar pacotes divididos ao servidor, um limite apertado é aqui defensável:

udp dport 27015 @th,64,32 0xfffffffe \
    meter tf2split { ip saddr limit rate over 5/second burst 10 packets } drop

A linha pertence à mesma cadeia que a regra da secção 3. Um dos poucos motivos legítimos para envios a partir do cliente elimina-o adicionalmente com sv_allowupload 0 (ver secção 7).

5. Retirar o RCON da internet aberta

O protocolo RCON do motor Source transmite a palavra-passe em texto simples por TCP. Quem conseguir ler o caminho entre si e o servidor fica com a sua palavra-passe de RCON, e quem tem RCON pode mudar o mapa, banir todos os jogadores e parar o servidor. Isto não é um problema de DDoS, é uma tomada de controlo, mas é comunicado regularmente como ataque.

Nunca deixe a rcon_password vazia nem escolhida a olho, um valor saído de openssl rand -base64 32 chega. A isso junta-se um travão contra tentativas de início de sessão:

rcon_password "O_SEU_VALOR_ALEATORIO"
sv_rcon_maxfailures 3
sv_rcon_minfailures 3
sv_rcon_minfailuretime 30
sv_rcon_banpenalty 1440

Com isto, o servidor bloqueia um endereço durante 24 horas após três tentativas falhadas em 30 segundos; find sv_rcon mostra que variáveis a sua build conhece. Ainda assim, a regra de firewall da secção 2 continua a ser mais eficaz, porque nem sequer deixa a tentativa chegar à aplicação. Para o acesso a partir de ligações que mudam, configure um encaminhamento local através de SSH e fale depois com o RCON em 127.0.0.1:

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

6. Pôr um teto nas taxas e deixar a hibernação ligada

O Team Fortress 2 corre de forma fixa a 66,67 ticks por segundo. Quanto tráfego resulta daí não o decide o tick, mas sim aquilo que um cliente concreto pode pedir. Sem um limite superior, cada jogador leva tudo o que o seu cliente reclamar, e isso paga-o o operador com a sua largura de banda de saída:

sv_minrate 50000
sv_maxrate 100000
sv_mincmdrate 40
sv_maxcmdrate 66
sv_minupdaterate 40
sv_maxupdaterate 66

Faça uma vez as contas: com sv_maxrate 100000, cada jogador pode receber 100 kilobytes por segundo, o que em 24 lugares dá 2,4 megabytes por segundo, ou seja, cerca de 19 Mbit/s em saída. Se definir sv_maxrate 0, deixa de existir limite superior. Os servidores de liga fazem-no conscientemente, um servidor público com muitos lugares não o deve fazer. Os plugins que desbloqueiam a tickrate multiplicam a taxa de pacotes por jogador e, com ela, a mesma conta.

O segundo ponto é muitas vezes mal resolvido. O TF2 adormece assim que ninguém está ligado e nesse estado quase não consome CPU. Muitos operadores desligam isso para que o servidor se sinta "acordado". Numa máquina com várias instâncias, isso significa que o CPU já está ocupado em repouso e que um ataque atinge um sistema que já está cheio. Deixe a predefinição como está:

sv_hibernate_when_empty 1
sv_hibernate_postgame_delay 5
tf_allow_server_hibernation 1

7. Separar o FastDL e desligar os envios do cliente

Os servidores de comunidade vivem de mapas próprios, e é precisamente daí que nasce uma segunda superfície de ataque. Sem sv_downloadurl, cada jogador descarrega os conteúdos pelo canal de rede do jogo, ou seja, pela mesma porta e pelo mesmo processo que ao mesmo tempo calcula a partida. São poucos kilobytes por segundo e um ficheiro de cada vez, e com uma coleção de mapas de 200 megabytes isso bloqueia o seu servidor durante minutos por cada jogador:

sv_allowdownload 1
sv_allowupload 0
net_maxfilesize 64
sv_downloadurl "https://fastdl.example.org/tf/"

O net_maxfilesize está por predefinição em 15 e pode ser subido até 64 megabytes. O sv_allowupload 0 impede que os clientes enviem ficheiros próprios (por exemplo sprays) para o servidor e retira assim um dos poucos motivos legítimos para os pacotes divididos da secção 4.

O decisivo é onde está o host de FastDL. Se estiver no mesmo endereço IP que o servidor de jogo, basta uma enxurrada HTTP contra a 443/TCP para encher a linha e sufocar com ela também a 27015/UDP. Coloque o download rápido noutro host ou atrás de uma rede de distribuição de conteúdos, e assim um ataque contra os ficheiros não atinge o jogo.

8. Limitar o sistema de votações, as enxurradas de entradas e os plugins

Nem toda a falha é largura de banda. Como o TF2 é gratuito, um ataque à lógica de jogo não custa mais do que contas: enxurradas de entradas que ocupam todos os lugares, spam de voz e de chat, e votações abusadas que expulsam jogadores normais. As predefinições do TF2 já são aqui razoáveis, mas são frequentemente amolecidas:

sv_allow_votes 1
sv_vote_issue_kick_allowed 0
sv_vote_allow_spectators 0
sv_vote_creation_timer 150
sv_vote_failure_timer 300
sv_vote_quorum_ratio 0.6

Estes são os valores padrão: as votações são permitidas, as votações de expulsão não, os espetadores não votam, entre duas votações passam 150 segundos, depois de uma falhada passam 300, e uma votação precisa de 60 por cento de aprovação. Quem definir sv_vote_issue_kick_allowed 1 deve saber que abre com isso uma ferramenta que, num servidor público, é abusada de forma fiável.

Tudo o que vá além disto vem, no TF2, do SourceMod e do Metamod:Source. Ambos ficam em tf/addons/ e anunciam-se na consola com meta version e sm version. Ao contrário do que acontece no Counter-Strike 2, a base é aqui madura, e os plugins para listas de bloqueio, verificação na entrada e limitação do chat são o caminho habitual. Duas regras a este respeito: cada plugin é código no mesmo processo, e um plugin que rebente leva o servidor consigo. E os plugins que trazem serviços web próprios abrem mais portas e chegam a publicar exatamente o endereço que quer proteger. O sm plugins list mostra o que está de facto a correr.

Abril de 2020 mostra como se deve levar a sério o lado do motor: depois de terem circulado versões antigas do código-fonte do TF2 e do CS:GO, grandes operadores de comunidade como a Creators.TF e a Red Sun desligaram temporariamente os seus servidores, por receio de exploração. Mantenha o binário do servidor atualizado e as extensões compatíveis com a versão do motor.

9. Medir e registar antes de o problema chegar

O passo mais importante é aquele que quase ninguém dá com antecedência: criar uma base de comparação enquanto tudo corre 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 uma sexta-feira à noite. Durante um incidente bastam quatro comandos:

ip -s link show eth0
nstat -az | grep -i udp
tcpdump -ni eth0 -c 200 "udp port 27015 and udp[8:4] = 0xffffffff"
tcpdump -ni eth0 -c 200 "udp port 27015 and udp[8:4] = 0xfffffffe"

O primeiro comando mostra pacotes, erros e descartes por interface; execute-o duas vezes com dez segundos de intervalo e terá uma taxa em vez de um valor absoluto. As duas capturas separam a enxurrada de consultas da enxurrada de pacotes divididos e respondem assim à pergunta sobre qual das duas regras, a da secção 3 ou a da secção 4, tem realmente de atuar. Limite-as sempre com -c, porque uma captura a plena carga custa ela própria tempo de processamento.

Dentro do servidor, o comando de consola stats devolve numa linha a carga do CPU, a carga de rede de entrada e de saída em kilobytes por segundo, os FPS do servidor e o número de jogadores. Se os FPS do servidor caírem bastante abaixo do valor do tick enquanto o número de jogadores está normal, o servidor está a trabalhar noutra coisa que não o jogo. Como interpretar os valores está em Detetar um ataque DDoS no servidor.

Onde estas medidas acabam: 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.

Coloque o funcionamento normal de um servidor TF2 cheio ao lado de um ataque real e a relação fica clara:

Um gameserver típico está ligado a 1 Gbit/s, ou seja, 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 ela costuma chegar ao limite antes da largura de banda: cada pacote custa uma passagem pela stack de rede, mesmo que seja descartado a seguir. Um ataque que nem sequer enche um terço da sua linha deixa, ainda assim, o seu servidor inoperacional. Quem opera servidores vive isto como "a utilização nem sequer estava alta e mesmo assim desapareceu tudo".

Para dar uma ideia das ordens de grandeza que ocorrem na realidade: em servidores da KernelHost foram filtrados em tempo real, entre outros, um flood UDP contra um gameserver com mais de 112,2 Gbit/s e mais de 8,7 milhões de pacotes por segundo, e um ataque multivetor contra um servidor de voz com mais de 473,4 Gbit/s e mais de 41,5 milhões de pacotes por segundo. 473,4 Gbit/s são cerca de 470 vezes uma ligação de 1 Gbit/s. Para isso não existe nenhuma definição local.

Os dois travões de emergência mais comuns não ajudam. O null-routing retira da rede o endereço IP atacado e termina o ataque, mas termina também o seu servidor. Um desvio reativo custa, no tempo de comutação, exatamente os minutos em que a partida se decide. Só é eficaz uma filtragem que corra em permanência na rede à frente do servidor.

O que a KernelHost põe contra os ataques a servidores TF2

A proteção permanente incluída em cada pacote de servidor

A proteção DDoS da KernelHost está construída em dois níveis e fica permanentemente ativa a partir da disponibilização, sem que tenha de encomendar, ativar 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 para um servidor TF2. A filtragem corre em permanência e não precisa de reagir primeiro a um ataque, pelo que não existe um tempo de comutação em que os seus jogadores são expulsos e o seu servidor cai do navegador de servidores. E não é usado null-routing: o seu endereço IP mantém-se na rede e só os pacotes nocivos são descartados. Que jogos e protocolos estão cobertos é o que lista Proteção DDoS em tempo real para servidores de jogos.

Advanced DDoS Protection para servidores sob fogo permanente

Alguns projetos não são atacados de forma ocasional, mas sim de forma dirigida e ao longo de semanas, com padrões que mudam e sempre à hora exata do jogo. Para esses 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:

• 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 em separado o que é permitido na 27015/UDP, o que é permitido na 27020/UDP e o que é permitido na 27015/TCP, 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 em vez de esperar pelo fim da partida.
• Perfil de proteção adequado ao jogo, tanto para o Team Fortress 2 e os restantes títulos Source como perfis TCP e UDP livres para aplicações próprias.

A oferta destina-se a servidores que correm na KernelHost. Se o seu servidor TF2 estiver atualmente noutro sítio e for atacado com regularidade, a mudança é o caminho para chegar a esta proteção.

Os dois níveis em comparação

Para a maioria dos servidores de comunidade de TF2, 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

"O servidor corre, mas já não está no navegador de servidores": verifique primeiro o Game Server Login Token. Os servidores TF2 precisam de um token para o registo público, definido com sv_setsteamaccount e gerado para o App ID 440. A Steam retira os tokens que não sejam usados durante 30 dias. Um servidor que desapareça depois de uma pausa mais longa precisa, portanto, muitas vezes apenas de um token novo e não está sequer a ser atacado. Só depois disso entram em causa um sv_max_queries_sec_global demasiado baixo ou uma regra de firewall demasiado grosseira na 27015/UDP.

"O CPU está nos 100 por cento e a linha está quase vazia": esse é o quadro típico de uma enxurrada de consultas ou de pacotes divididos. Procure no registo do servidor linhas com NET_GetLong e meça com as duas linhas de tcpdump da secção 9 que tipo de pacote está a chegar.

"As minhas regras de nftables ou de iptables não fazem efeito": há três causas frequentes. A regra está atrás das cadeias do UFW e nunca chega a ser alcançada (daí a prioridade -10), desapareceu no último reinício, ou o ataque é volumétrico e a regra trabalha corretamente numa linha que já está cheia. Verifique com nft list ruleset se os contadores sobem. Se ficarem a zero, a regra não está a ser alcançada.

"Mudei de endereço IP e no dia seguinte estava outra vez offline": o atacante encontra o endereço novo na mesma fonte do antigo. O seu servidor publica-o por iniciativa própria assim que volta a estar no navegador de servidores, e os registos DNS antigos e os bots de estado do Discord fazem o resto. Mudar de endereço é ganhar horas, não é uma solução.

"O servidor rebenta de forma reproduzível sem que a largura de banda se note": normalmente não é um ataque DDoS, mas sim um plugin que não combina com a versão do motor, ou um binário de servidor desatualizado. O sm plugins list e uma comparação das versões são aqui mais rápidos do que qualquer regra de filtragem.

"O servidor reage com atraso depois de um período em repouso": isso é a hibernação e não é um erro. Ela baixa a carga do CPU para quase zero enquanto ninguém está ligado, e esse é exatamente o estado em que quer ter reservas.

"Estão a correr comandos de administração alheios no servidor": não é um ataque DDoS, é um acesso RCON comprometido. Defina imediatamente uma palavra-passe nova, restrinja a porta ao seu próprio endereço e lembre-se de que a palavra-passe segue em texto simples pela linha.

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

Em resumo

• Um servidor TF2 precisa, para o exterior, exatamente da 27015/UDP. O RCON na 27015/TCP deve ficar restringido ao seu próprio endereço, e o SourceTV na 27020/UDP desliga-se com -nohltv se não transmitir.
• O tráfego de jogo e a consulta A2S partilham a mesma porta. Quem bloqueia ou limita a taxa da 27015/UDP de forma genérica expulsa os seus próprios jogadores. A fronteira tem de passar entre os tipos de pacote, reconhecíveis nos primeiros quatro bytes a seguir ao cabeçalho UDP.
• As enxurradas de pacotes divididos com o cabeçalho FE FF FF FF geram carga de CPU em vez de largura de banda e aparecem no registo como NET_GetLong. No TF2, um limite apertado a este tipo de pacote é defensável.
• Desde o "Meet Your Match", os novos jogadores só encontram os servidores de comunidade através do navegador de servidores. Qualquer medida que o empurre para fora da lista funciona como o próprio ataque.
• Um servidor cheio de 24 lugares processa cerca de 1 600 pacotes de entrada por segundo. Os ataques contra gameservers de comunidade situam-se habitualmente entre 5 e 50 Gbit/s e em vários milhões de pacotes por segundo.
• 1 Gbit/s transporta, com pacotes mínimos, cerca de 1,49 milhões de pacotes por segundo. Acima deste limite decide exclusivamente a rede à frente do servidor, e não uma regra no servidor.
• Na KernelHost, a proteção permanente em dois níveis está incluída em cada pacote de servidor sem sobretaxa e fica ativa a partir da disponibilização, sem null-routing. A Advanced DDoS Protection junta-se a partir de 50,00 EUR por mês, se quiser controlar por si próprio as regras por porta.

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. Indique logo quatro dados: endereço IP, porta, período no seu fuso horário e o que está a ver. Isso poupa uma ronda de perguntas, e ela conta quando há uma partida a decorrer.