Proteger o servidor Left 4 Dead 2 contra ataques DDoS

Um servidor Left 4 Dead 2 raramente cai num momento que dê jeito. Cai no último troço de uma campanha, na segunda volta de uma partida de Versus ou precisamente quando um jogador banido foi recusado pela terceira vez. Quem está a ser atacado neste preciso momento não precisa de uma discussão de princípios sobre tecnologia de rede, precisa de uma ordem de trabalhos. Este artigo mostra primeiro como proteger um servidor Left 4 Dead 2 contra ataques DDoS enquanto isso ainda é possível com os meios de bordo, depois onde estas possibilidades acabam do ponto de vista físico e, no fim, o que tem de acontecer antes disso, na rede.

Todas as indicações se referem a um servidor dedicado (srcds) instalado através do SteamCMD com o App ID 222860, 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. Um ponto antes de tudo o resto, porque determina a ordem: durante um ataque em curso não altere nada às cegas e não reinicie o servidor antes de ter guardado os valores medidos. Depois do ataque, esses valores desaparecem.

Porque é que os servidores Left 4 Dead 2 são um alvo DDoS apetecido

A diferença face a um shooter com 64 lugares está no tamanho da partida. Uma campanha em cooperativo tem quatro lugares para sobreviventes, uma partida de Versus tem oito lugares para os dois lados juntos. Uma falha nunca atinge, por isso, apenas alguns jogadores, atinge sempre a partida inteira: quem interrompe uma campanha no terceiro de cinco troços acabou com a noite de toda a gente. É exatamente isso que torna um ataque atrativo para quem o desencadeia, porque não lhe custa nem competência nem dinheiro digno de nota, enquanto do outro lado destrói uma hora de jogo.

A isto junta-se a arquitetura. O Left 4 Dead 2 corre no motor Source, e um servidor Source é publicamente localizável com endereço IP e porta. Isso é um requisito, não um descuido: um servidor que não responde a nenhuma consulta não consta de nenhuma lista e não é encontrado por nenhuma lobby. A pergunta nunca é, portanto, se um atacante conhece o seu endereço, mas apenas o que acontece quando dispara contra ele. O tráfego de jogo corre sobre UDP, e o UDP não tem um estabelecimento de ligação que se possa exigir, ao que acresce que os endereços de origem se falsificam. O que se passa tecnicamente fica explicado no artigo O que é um ataque DDoS?.

Um terceiro ponto é próprio do Left 4 Dead 2 e não tem equivalente no Counter-Strike, no Garry's Mod ou no Team Fortress 2: a maioria dos jogadores não chega pela lista de servidores, chega pelo sistema de lobby. Uma lobby de até quatro jogadores é encaminhada pelo matchmaking da Steam para um servidor dedicado, que recebe para isso uma reserva. Este processo é ao mesmo tempo o seu filtro de acesso mais eficaz e mais uma superfície de ataque. Ambos os lados ficam descritos em detalhe mais abaixo.

As portas que realmente contam

Um servidor Left 4 Dead 2 ocupa exatamente uma porta UDP para tudo o que constitui o jogo. A predefinição é a 27015, definida através de -port ou de +hostport na linha de arranque:

./srcds_run -game left4dead2 -console -nohltv \
  -port 27015 \
  +ip 203.0.113.10 \
  +maxplayers 4 \
  +exec server.cfg \
  +map c1m1_hotel

A primeira linha desta tabela é o cerne do problema. O tráfego de jogo e a consulta de servidor partilham a 27015/UDP, porque no Left 4 Dead 2 não existe uma porta de consulta separada. Quem bloqueia esta porta de forma genérica ou lhe aplica um rate limit grosseiro expulsa no mesmo gesto os seus próprios jogadores e termina o ataque por conta do atacante.

Um pedido A2S é um pacote de algumas dezenas de bytes, e a resposta é um múltiplo disso. Em UDP, o endereço de origem pode ser falsificado, e com isso o seu servidor deixa de ser apenas vítima e passa também a amplificador: um atacante consulta servidores de jogo alheios com o endereço do seu alvo e encaminha as respostas deles para ali. Em dezembro de 2020, a Valve acrescentou ao A2S_INFO um pedido prévio (S2C_CHALLENGE) que quem consulta tem de devolver antes de receber a resposta. Isso atenua a reflexão, mas não a termina, porque os programas de consulta mais antigos continuam a ser servidos.

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

A parte que se segue não custa nada e compensa independentemente do sítio onde o seu servidor esteja. Não o livra de um ataque volumétrico, mas faz com que os ataques pequenos e médios se percam sem efeito, e elimina as falhas que são comunicadas erradamente como ataque DDoS.

1. Levantamento: o que está mesmo à escuta

Antes de escrever uma regra, esclareça que serviços estão acessíveis. Num servidor Left 4 Dead 2 que foi crescendo ao longo do tempo, são quase sempre mais do que o esperado, porque além do srcds correm ali ainda um servidor web para as campanhas, uma base de dados de estatísticas e, por vezes, um segundo servidor para Versus:

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. A perspetiva do atacante obtém-se com um scan de portas a partir de fora, e a experiência mostra que ela diverge daquilo que se espera:

nmap -Pn -sU -sT -p 27000-27050,80,443,3306 IP.DO.SEU.SERVIDOR

Se a base estiver acabada de montar ou se a quiser perceber melhor, o artigo Instalar um servidor de jogos com o SteamCMD descreve o caminho desde o SteamCMD até ao srcds a correr.

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

Uma porta UDP para o exterior, uma porta TCP para o seu próprio endereço, e mais nada. O RCON não tem lugar na internet aberta, porque quem tem RCON muda o mapa, bane todos os jogadores e para o servidor:

ufw allow 27015/udp comment "Porta de jogo L4D2 e A2S"
ufw allow from 203.0.113.10 to any port 27015 proto tcp comment "RCON"
ufw allow from 203.0.113.10 to any port 22 proto tcp comment "SSH"
ufw default deny incoming
ufw default allow outgoing
ufw --force enable

Substitua 203.0.113.10 pelo seu próprio endereço. Se este mudar com regularidade, o caminho passa por um encaminhamento de portas por SSH em vez de uma abertura permanente. A ordem pela qual ativa a firewall decide se fica trancado do lado de fora; essa ordem, com a respetiva via de regresso, está no artigo Configurar a firewall UFW sem se trancar fora do servidor. Se mesmo assim acontecer: os servidores root KVM e os servidores dedicados da KernelHost não têm IPMI nem iDRAC, e chega ao servidor através da consola VNC na área de cliente, que não depende da stack de rede do sistema convidado.

3. Travar a consulta A2S sem cair da pesquisa por lobby

É aqui que está o erro mais caro de toda esta matéria. Como o tráfego de jogo e a consulta de servidor ocupam a mesma porta, o travão tem de distinguir entre as duas classes de pacotes, e não entre portas.

Desde as alterações de dezembro de 2020, a base Steam Gameserver traz para isso um limite próprio, que se define antes do arranque como variável de ambiente. O STEAM_GAMESERVER_RATE_LIMIT_200MS=N descarta os pacotes sem ligação (A2S_INFO, A2S_RULES, A2S_PLAYERS) de um endereço de origem assim que, numa janela de 200 milissegundos, chegarem mais do que N deles. A Valve indica 25 a 75 como intervalo utilizável, e por predefinição o limite está desligado:

export STEAM_GAMESERVER_RATE_LIMIT_200MS=50
./srcds_run -game left4dead2 -console -port 27015 +exec server.cfg +map c1m1_hotel

Numa unit do systemd, o mesmo valor pertence à secção [Service] como Environment=STEAM_GAMESERVER_RATE_LIMIT_200MS=50, caso contrário desaparece no reinício seguinte. Este travão só atua se a sua build de servidor trouxer a base Steamworks atual, e protege o tempo de processamento do seu servidor, não a sua linha: os pacotes já chegaram.

Um nível abaixo, o mesmo tráfego pode ser separado dentro do kernel. Todos os pacotes sem ligação do motor Source, ou seja, as consultas de servidor e o estabelecimento da ligação, 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 rate limit por endereço de origem com o nftables:

table inet l4d2 {
    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. Comece com margem e só aperte o limite quando tiver a prova de que as consultas legítimas continuam a passar: a sua própria entrada na lista de servidores depende disso.

4. Usar o sistema de lobby como filtro de acesso

Esta é a alavanca que só o Left 4 Dead 2 e o antecessor têm. O servidor decide por si próprio se aceita sequer ligações vindas de fora do matchmaking. Quatro diretivas na server.cfg determinam isso:

sv_allow_lobby_connect_only 1
sv_search_key "a-sua-propria-chave"
sv_steamgroup "103582791400000000"
sv_steamgroup_exclusive 2

• sv_allow_lobby_connect_only 1 permite exclusivamente entradas a partir de uma lobby de matchmaking. Um connect 203.0.113.10:27015 na consola de programador e um convite da Steam são recusados. O valor 0 permite as duas coisas.
• sv_search_key é uma chave de pesquisa à sua escolha. Só uma lobby onde esteja definida a mesma chave encontra o servidor através do matchmaking. Sem essa chave, ele não aparece na pesquisa pública.
• sv_steamgroup liga o servidor a um grupo da Steam e faz com que ele apareça entre os servidores desse grupo.
• sv_steamgroup_exclusive tem três níveis: 0 deixa entrar qualquer pessoa, 1 comporta-se como 0 mas exige a entrada através de uma lobby, e 2 só deixa passar os membros do grupo e o acesso direto pelo endereço IP.

Para uma comunidade fixa, a combinação de chave de pesquisa com sv_steamgroup_exclusive 2 é o filtro de acesso gratuito mais eficaz que o jogo conhece. Um servidor público não a pode usar, porque um servidor que ninguém encontra fica tão vazio como um que está offline.

E agora a parte que os textos publicitários gostam de omitir: estas diretivas protegem a sua lógica de jogo, não a sua linha. Um atacante que inunda a 27015/UDP nem sequer quer entrar. Os pacotes dele são recusados, mas mesmo assim chegaram, consumiram largura de banda e custaram uma passagem pela stack de rede. Contra uma enxurrada de entradas feita de contas descartáveis, o sv_allow_lobby_connect_only 1 resulta muito bem; contra um booter não resulta de todo.

5. A reserva de lobby e quando sv_force_unreserved é a melhor escolha

Uma reserva de lobby é uma ocupação limitada no tempo do seu servidor por parte de uma lobby de matchmaking. Enquanto ela existir, o servidor conta como ocupado para outras lobbies, e só expira sozinha passado algum tempo. Para um servidor com quatro lugares, isso é um recurso escasso: ao contrário de um shooter com 32 ou 64 lugares, basta muito pouco para bloquear uma partida.

Quem não opera o seu servidor através do matchmaking retira esta superfície por completo:

sv_force_unreserved 1
sv_allow_lobby_connect_only 0

O sv_force_unreserved 1 faz com que o servidor deixe de responder aos pedidos de reserva vindos do sistema de lobby e recuse entradas com uma marca de reserva. Precisa desta mesma definição de qualquer forma se operar mais de quatro lugares de cooperativo com o L4DToolZ, porque de outro modo a lobby recebe uma reserva assim que os primeiros quatro lugares ficam ocupados, e os restantes lugares ficam inalcançáveis. A contrapartida é clara: os seus jogadores passam a entrar apenas pela lista de servidores ou através de connect.

Decida-se conscientemente por um dos dois modos de operação. A mistura de matchmaking meio aberto com entrada direta meio aberta é a variante que junta as duas desvantagens.

6. Proteger o RCON

Uma porta RCON aberta com uma palavra-passe fraca não é um problema de DDoS, é uma tomada de controlo. Nunca deixe rcon_password vazia nem escolhida a olho, um valor saído de openssl rand -base64 32 chega. Os títulos Source trazem ainda um travão contra tentativas de início de sessão:

rcon_password "AQUI_UM_VALOR_ALEATORIO"
sv_rcon_minfailures 3
sv_rcon_maxfailures 5
sv_rcon_minfailuretime 30
sv_rcon_banpenalty 1440

Com isto, um endereço fica bloqueado durante um dia após três tentativas falhadas em 30 segundos; find sv_rcon na consola do servidor mostra quais destas variáveis a sua build conhece. Ainda assim, a restrição na firewall do passo 2 continua a ser mais eficaz, porque nem sequer deixa a tentativa chegar à aplicação. Se não precisar do RCON, deixe a palavra-passe vazia: nesse caso a parte TCP da 27015 não fica à escuta.

7. Externalizar as campanhas personalizadas em vez de as entregar pela porta de jogo

As campanhas personalizadas são a razão pela qual o Left 4 Dead 2 ainda é jogado ao fim de quinze anos e, ao mesmo tempo, uma fonte de carga que no Counter-Strike não existe desta forma. Uma campanha é um pacote VPK com mapas, modelos, texturas e sons, ou seja, um múltiplo daquilo que pesa um único mapa de competição.

O caminho cómodo para os jogadores é o Steam Workshop: o pacote vem então da Steam e não do seu servidor, e não lhe custa largura de banda nenhuma. Se entregar ficheiros soltos por conta própria, essa entrega pertence a um servidor web e não à porta de jogo:

sv_allowdownload 1
sv_allowupload 0
sv_downloadurl "https://cdn.example.org/l4d2/"
sv_consistency 1

Os ficheiros para sv_downloadurl vão para o servidor web como arquivo bzip2, ou seja, omeumapa.bsp passa a omeumapa.bsp.bz2. Sem sv_downloadurl, o srcds envia os ficheiros ele próprio pela ligação de jogo, e então vale isto: cada tentativa de ligação de um jogador novo custa-lhe o download completo, e cada interrupção a meio do download também. É uma forma bastante barata de encher uma linha, e em nenhuma estatística se parece com um ataque.

Três pontos a este respeito que doem na prática. O sv_allowupload 0 deve ser definido, porque não precisa de uploads do cliente para o servidor. Se o servidor web para sv_downloadurl estiver no mesmo host que o jogo, o download e o tráfego de jogo partilham a mesma linha e o mesmo endereço IP, e um ataque à 443/TCP atinge então também a sua partida a decorrer. E o sv_consistency 1 não é uma proteção contra ataques, é uma proteção contra ficheiros divergentes do cliente; só o deve desligar se, de outro modo, uma campanha comprovadamente não arrancar.

8. O SourceMod, o Metamod e as extensões

Uma parte considerável das falhas comunicadas como DDoS não o é. São crashes e picos de carga que um único cliente provoca, porque há uma falha aberta no binário do servidor ou numa extensão. Contra isso não ajuda largura de banda, ajuda manutenção:

• Manter o Metamod:Source e o SourceMod a condizer com a versão do motor. O Left 4 Dead 2 continua a receber atualizações, e uma extensão desadequada é o motivo mais frequente de crashes logo a seguir a uma atualização.
• Left4DHooks em vez de intervenções próprias. Os eventos típicos do L4D2 estão reunidos nesta extensão. Intervir por conta própria nas mesmas funções é o caminho mais rápido para um binário de servidor que desiste perante certas sequências de pacotes.
• Usar o L4DToolZ apenas de forma consciente. A extensão levanta os limites de lugares fixados no jogo. Cada lugar adicional é mais um jogador a gerar tempo de processamento e, em conjunto com o sistema de lobby, ela precisa de sv_force_unreserved 1.
• Menos extensões. Cada plugin é código dentro do mesmo processo. As extensões com serviços web próprios abrem portas adicionais e publicam muitas vezes justamente o endereço que quer proteger.

Os banimentos têm de ficar guardados de forma permanente, caso contrário desaparecem depois do reinício. Para isso, os títulos Source conhecem banid com writeid e addip com writeip, e os ficheiros gerados voltam a ser lidos através de exec banned_user.cfg e exec banned_ip.cfg.

9. Aliviar o seguimento de ligações e o buffer de receção

Este ponto passa muitas vezes despercebido e explica falhas que parecem um ataque de volume sem o serem. O kernel cria entradas no seguimento de ligações (conntrack) para o tráfego UDP e, com endereços de origem falsificados, cada endereço significa uma entrada nova. Quando a tabela enche, o kernel descarta pacotes sem distinguir: o ataque e os seus jogadores caem em conjunto. O estado atual e o limite máximo mostram-se com um olhar:

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max

O passo mais eficaz é não deixar sequer que o tráfego de jogo seja seguido, porque o motor gere as suas próprias sessões:

table inet raw {
    chain prerouting {
        type filter hook prerouting priority raw; policy accept;
        udp dport 27015 notrack
    }
    chain output {
        type filter hook output priority raw; policy accept;
        udp sport 27015 notrack
    }
}

Com o iptables, o equivalente é iptables -t raw -A PREROUTING -p udp --dport 27015 -j NOTRACK e a mesma linha para OUTPUT com --sport. A porta passa depois a precisar de uma abertura explícita, porque sem seguimento deixa de atuar qualquer regra que verifique um estado existente. Se os pacotes chegarem mais depressa do que o srcds os levanta, transborda além disso o buffer de receção, e para os jogadores isso parece perda de pacotes numa linha livre:

net.core.rmem_max = 16777216
net.core.rmem_default = 1048576
net.core.netdev_max_backlog = 16384

O ficheiro coloca-se em /etc/sysctl.d/ e ativa-se com sysctl -p. Se os valores são sequer necessários, é o próprio kernel que o revela: se UdpRcvbufErrors subir em nstat -az, então fazem efeito. Se o contador ficar a zero, o ajuste não muda nada. Isto é reserva, não é proteção.

10. Medir, para não ter de adivinhar durante o ataque

Durante um ataque, a pergunta mais importante é: quanto chega, em que porta, e se é tráfego de consulta ou de jogo. Bastam quatro comandos:

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

O primeiro comando execute-o duas vezes com dez segundos de intervalo, e passa a ter uma taxa em vez de um valor absoluto. A última linha mostra exclusivamente os pacotes sem ligação, ou seja, precisamente a classe que uma enxurrada de consultas explora; se o contador disparar em segundos enquanto quase ninguém está ligado, já tem a sua resposta. Mantenha a captura curta, porque sob carga consome ela própria tempo de processamento. Como enquadrar os valores está no artigo Detetar um ataque DDoS no servidor.

O passo mais importante é, no entanto, 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 muitos ou se era simplesmente sexta-feira à noite com o servidor de Versus cheio.

Onde estas medidas acabam

Agora a parte honesta. Tudo o que ficou descrito até aqui só atua depois de os pacotes terem chegado à sua placa de rede. 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. Com o tamanho de pacote mais pequeno possível, essa linha transporta cerca de 1,49 milhões de pacotes por segundo, e uma linha de 10 Gbit/s cerca de 14,88 milhões. Este é o limite físico, independentemente do CPU, do kernel e da firewall. Um kernel de servidor normal processa, consoante o processador 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".

Do outro lado estão os ataques reais. Dois exemplos da operação na KernelHost, ambos filtrados em tempo real: um UDP flood contra um gameserver na 7777/UDP 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 na 9987/UDP com mais de 473,4 Gbit/s e mais de 41,5 milhões de pacotes por segundo. Faça as contas com a sua linha: 473,4 Gbit/s são cerca de 470 vezes uma ligação de 1 Gbit/s e ainda assim cerca de 47 vezes uma ligação de 10 Gbit/s.

Por isso os dois travões de emergência mais divulgados são insatisfatórios. O null-routing (blackholing) retira da rede o endereço IP atacado e termina o ataque, sim, mas termina também com o seu servidor: para os seus jogadores, o resultado é idêntico ao de um ataque bem-sucedido. Um desvio reativo custa, no tempo de comutação, precisamente os minutos em que a campanha se decide. Só é eficaz uma filtragem que corra de forma permanente na rede, à frente do servidor.

O que a KernelHost põe do outro lado

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

A proteção DDoS da KernelHost está montada em dois níveis e permanentemente ativa, sem que tenha de ligar, 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, muito 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 nas camadas 3 a 7, pacote a pacote.

Duas características são decisivas. Primeiro, a filtragem corre de forma permanente, pelo que não existe um tempo de comutação durante o qual os seus jogadores caem. Segundo, não é usado null-routing: o endereço IP atacado mantém-se na rede e só os pacotes nocivos são descartados. A proteção está incluída em todos os pacotes de servidor sem sobretaxa, sem pacote de proteção em separado e sem qualquer configuração, e fica ativa a partir do momento da disponibilização. Os servidores estão no maincubes Premium Datacenter em Frankfurt am Main. Que jogos e protocolos estão cobertos é o que enumera o artigo Proteção DDoS para servidores de jogos em tempo real.

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, com padrões que vão mudando e sempre precisamente na noite de campanha combinada. Para esses casos existe a Advanced DDoS Protection a partir de 50,00 € 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. O seu servidor passa a usar esse endereço dentro da nossa rede, sem que seja preciso qualquer alteração do seu lado.
• Regras de proteção autogeríveis por porta e por protocolo. Define na área de cliente que porta é filtrada com que perfil, ou seja, a 27015/UDP de forma diferente do servidor web que entrega as suas campanhas.
• As alterações entram em vigor em tempo real, sem ticket e sem tempo de espera. Pode, portanto, afinar durante um ataque em curso.
• Um perfil de proteção à medida de cada jogo. Para o Left 4 Dead 2 e os restantes títulos Source, tal como para mais de 40 outros jogos e protocolos, além de perfis TCP e UDP livres para servidores modificados.

Também aqui vale o modelo PrePaid: sem prazo mínimo, sem período de aviso prévio, sem contrato e sem taxa de instalação. Quando a onda de ataques passar, basta não renovar.

Os dois níveis em comparação

Para a maioria dos projetos de Left 4 Dead 2, 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 desapareceu da pesquisa por lobby, mas continua a correr: na maioria dos casos, a 27015/UDP foi bloqueada de forma genérica ou o rate limit ficou demasiado apertado e, como o tráfego de jogo e a consulta partilham a mesma porta, uma regra grosseira atinge as duas coisas. Trabalhe antes com uma comparação sobre os pacotes sem ligação. Se a porta estiver acessível e o servidor continuar invisível, verifique sv_search_key, sv_steamgroup_exclusive, sv_lan 0 e sv_region 255, e ainda se o arranque foi feito por engano com -nomaster.

Na consola do servidor aparece constantemente "Invalid split packet length": isso não é um ataque volumétrico, é um pacote de rede mal montado que chega em sucessão rápida. O tráfego mantém-se minúsculo e o servidor engasga na mesma. Verifique primeiro se a largura de banda se destaca sequer e ponha o binário do servidor e as extensões em dia. Aqui a largura de banda não ajuda em nada.

Todos os jogadores têm ping alto, mas a linha não está cheia: isso aponta para taxa de pacotes em vez de volume. Observe os pacotes descartados em ip -s link show e os contadores UDP em nstat -az. Se no log do sistema aparecer nf_conntrack: table full, retire a porta de jogo com notrack.

A regra da firewall está correta e mesmo assim não faz efeito: 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, porque está atrás das cadeias do UFW ou porque se perdeu no último reinício. Se subirem e nada mudar, a linha à frente do servidor está saturada, e a partir daí só ajuda a filtragem na rede.

O servidor deixou de aceitar jogadores, apesar de haver lugares livres: na maioria dos casos está uma reserva de lobby pendurada. Ou opera o servidor de forma consequente através do matchmaking, ou define sv_force_unreserved 1 e deixa os seus jogadores entrar pela lista de servidores. Com mais de quatro lugares de cooperativo e o L4DToolZ, esta definição é obrigatória de qualquer forma.

Os jogadores novos demoram uma eternidade a carregar e a linha fica cheia: nesse caso é o srcds que entrega ele próprio os ficheiros da campanha pela porta de jogo. Aponte o sv_downloadurl para um servidor web e coloque ali os ficheiros como arquivo bzip2, ou encaminhe os seus jogadores para o Steam Workshop.

O ataque faz uma pausa depois de uma mudança de IP e regressa ao fim de um a dois dias: é o caso normal, porque é o próprio servidor que publica o novo endereço assim que volta a estar registado, e um registo DNS esquecido ou um bot de Discord com indicação de estado tratam do resto. Uma mudança de IP dá horas, não dá uma solução.

Estão a ser executados comandos de administração alheios no servidor: não é um ataque DDoS, é um acesso RCON comprometido. Mude a palavra-passe de imediato e restrinja a parte TCP da 27015 ao seu próprio endereço.

Em resumo

• Um servidor Left 4 Dead 2 precisa exatamente de uma porta aberta para o exterior: 27015/UDP. O tráfego de jogo e a consulta A2S partilham-na, e uma porta de consulta separada não existe.
• A 27015/TCP é o RCON e pertence exclusivamente ao seu próprio endereço. Quem não precisa do RCON deixa rcon_password vazia.
• O sistema de lobby é o filtro de acesso gratuito mais eficaz que o jogo conhece: sv_allow_lobby_connect_only 1, um sv_search_key próprio e sv_steamgroup_exclusive 2 excluem tudo o que não venha do matchmaking. Filtra entradas, não pacotes.
• As campanhas personalizadas pertencem ao Steam Workshop ou a um sv_downloadurl, nunca à porta de jogo. De outro modo, cada tentativa de ligação interrompida é paga com a sua largura de banda.
• O rate limit tem de distinguir entre pacotes sem ligação (começados por 0xffffffff) e tráfego de jogo. Uma regra grosseira na 27015/UDP expulsa os seus próprios jogadores.
• Com pacotes de 64 bytes, uma linha de 1 Gbit/s transporta cerca de 1,49 milhões de pacotes por segundo. Acima disso, quem decide é exclusivamente a rede à frente do servidor, e não uma definição no próprio servidor.
• Na KernelHost, 17 Tbps de scrubbing global e uma filtragem Arbor em tempo real com 3,2 Tbps em Frankfurt am Main filtram de forma permanente e sem sobretaxa, sem null-routing e sem tempo de comutação.

Se o seu projeto já estiver 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 a nossa equipa reajuste as regras de filtragem para o seu endereço IP. Durante um ataque em curso pode ainda contactar-nos através do chat de emergência do WhatsApp em +43 650 8209883. Indique logo quatro dados: endereço IP, porta, período de tempo no seu fuso horário e o que está a observar (jogadores a serem expulsos, servidor fora da pesquisa por lobby, ping alto). Isso poupa uma ronda de perguntas, e essa ronda conta quando há uma campanha a decorrer.

Se estiver alojado noutro sítio e for atacado com regularidade, mudar-se para a KernelHost é um caminho mais curto do que mais uma regra num servidor cuja linha acaba antes. A proteção permanente faz parte de todos os pacotes de servidor, não é um extra que se contrata quando já é tarde.