Proteger um servidor Lineage 2 contra ataques DDoS

Um servidor privado de Lineage 2 em que, à noite, ninguém consegue passar do ecrã de login enquanto os jogadores que já estão no mundo continuam a jogar sem serem incomodados, não tem um problema de hardware. Essa é a impressão digital de um ataque DDoS ao servidor de login, e é exatamente aí que uma proteção DDoS para Lineage 2 tem de atuar. Este artigo mostra primeiro o que pode proteger por conta própria e sem custos adicionais, depois onde estas medidas terminam do ponto de vista técnico e, por fim, o que tem de acontecer na rede à frente do servidor.

Todas as indicações se referem ao L2J e aos seus derivados (L2J-Mobius, aCis) em Debian 12, Debian 13, Ubuntu 22.04 LTS ou Ubuntu 24.04 LTS, bem como a pacotes L2OFF com AuthD, CacheD e L2Server. 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 configuração e não reinicie nem o servidor de login nem o servidor de jogo. Guarde primeiro os valores medidos (ver a secção "Registar em log"), porque depois do ataque desaparecem.

Proteger um servidor Lineage 2 contra DDoS: porque é que os servidores L2 privados são atacados

Um servidor privado de Lineage 2 reúne várias características que fazem dele um alvo cómodo, e a proteção DDoS para Lineage 2 tem de atuar precisamente sobre essas características. Em primeiro lugar, o seu endereço é público, e logo desde o início: os jogadores descarregam uma pasta System modificada, e no l2.ini dessa pasta está a linha ServerAddr= com o endereço IP do seu servidor de login. Qualquer pessoa que tenha instalado o seu projeto uma vez conhece esse endereço, independentemente de alguma vez ter criado uma personagem.

Em segundo lugar, a comunidade de jogadores está presa a horários fixos. Cercos, raid bosses épicos e eventos estão no calendário, e uma falha precisamente a essa hora tem a máxima visibilidade possível. Em terceiro lugar, os projetos concorrem diretamente entre si: quem abre um servidor disputa os mesmos poucos milhares de jogadores que outros três projetos no mesmo fim de semana. Desligar um concorrente é, nesta cena, uma estratégia corrente. Um ataque é contratado como um serviço (na cena isso corre sob os nomes booter ou stresser) e não custa a quem o encomenda nem competência nem dinheiro digno de nota. O que é ao certo um ataque DDoS fica explicado no artigo O que é um ataque DDoS?.

Porque é que o servidor de login na porta 2106 é o verdadeiro alvo

O Lineage 2 está dividido em dois processos separados: um servidor de login e um ou mais servidores de jogo. O cliente liga-se primeiro à 2106 TCP do servidor de login, autentica-se, recebe dali a lista de servidores com o endereço externo e a porta do servidor de jogo e estabelece depois uma segunda ligação à 7777 TCP do servidor de jogo. Os dois processos têm ficheiros de configuração próprios, portas próprias e limites de carga próprios.

Daqui resulta o padrão de ataque que os operadores de L2 descrevem repetidamente: um flood na 2106 bloqueia exclusivamente as novas autenticações. Quem já está no mundo continua a jogar até perder ele próprio a ligação. O número de jogadores online desce portanto lentamente em vez de cair de golpe, e no fórum aparece "o servidor está a funcionar, mas eu não consigo entrar". É exatamente esta imagem que distingue um ataque ao servidor de login de um ataque ao servidor de jogo, no qual todos são expulsos ao mesmo tempo.

O servidor de login é além disso o alvo mais barato, porque o esforço está distribuído de forma desigual. O servidor de login do L2J gera no arranque uma reserva de dez pares de chaves RSA de 1024 bits e vinte chaves Blowfish. Cada tentativa de autenticação custa ao cliente o envio de um pacote e ao servidor uma desencriptação com a chave RSA privada. Uma sessão a meio ocupa entretanto um lugar até o temporizador integrado a descartar: LOGIN_TIMEOUT está no código-fonte em 60 segundos. A predefinição MaxConnectionPerIP = 50 permite a cada endereço de origem cinquenta ligações em simultâneo. Mil endereços de origem chegam assim para 50.000 sessões abertas ao mesmo tempo, cada uma delas a manter-se durante um minuto.

A isto junta-se uma particularidade do jogo que o distingue da maioria dos gameservers: o Lineage 2 funciona exclusivamente sobre TCP. O fabricante indica para o jogo as portas TCP 80, 2009, 2106 e 7777 e, em UDP, exclusivamente a porta 53 para a resolução de nomes. Não existe portanto tráfego de jogo em UDP que fosse preciso filtrar, mas em contrapartida o clássico SYN flood com endereços de origem falsificados é diretamente eficaz, e o seguimento de ligações do kernel torna-se o primeiro estrangulamento.

Porque é que os ataques a servidores Lineage 2 são sazonais e coincidem com as aberturas

Os ataques a servidores privados de Lineage 2 concentram-se em torno das aberturas de servidores, porque a data e a hora da abertura são públicas semanas antes. Os calendários de aberturas de projetos de Lineage 2 listam os arranques que se aproximam por crónica (Interlude, High Five, Classic, Essence), com as rates e a hora exata de arranque, e são atualizados diariamente. O atacante não tem de investigar nada: o momento que lhe é mais favorável está no anúncio do próprio operador.

A segunda razão é económica. Um servidor privado de Lineage 2 ganha o seu dinheiro à cabeça: toda a base de jogadores é angariada nos primeiros dias, os donativos entram nas primeiras semanas e depois disso a população encolhe continuamente. Um jogador que não consegue entrar na primeira hora muda para o projeto que abre no mesmo fim de semana, e esse projeto existe sempre. Uma hora de indisponibilidade no dia da abertura não custa, por isso, uma hora de receita, mas sim uma parte de toda a vida útil do servidor.

A terceira razão é técnica. No grand opening, milhares de jogadores tentam autenticar-se ao mesmo tempo. O servidor de login está nesse exato minuto já no limite, e um flood adicional dificilmente se distingue do pico de carga. Um ataque que numa terça-feira calma não teria consequências chega para derrubar a hora da abertura. O mesmo vale para as datas anunciadas durante o funcionamento normal: os cercos a castelos e os raid bosses épicos estão no calendário e são, pela mesma razão, janelas de ataque apreciadas. Depois da corrida da abertura, o incentivo volta a baixar, razão pela qual os operadores vivem os ataques como ondas e não como um estado permanente.

As portas que realmente contam

A tabela seguinte lista as portas de um servidor privado de Lineage 2, o respetivo ficheiro de configuração e a diretiva que define o valor. As predefinições vêm dos ficheiros de configuração fornecidos com o L2J e das instruções de instalação dos pacotes L2OFF.

Esta tabela responde de caminho a duas perguntas: o Lineage 2 não tem porta de consulta nem porta de RCON. Não existe um serviço separado que entregue o estado dos jogadores para uma lista de servidores, nem uma porta de controlo remoto como nos jogos baseados em Source. A lista de servidores é gerada pelo próprio servidor de login e enviada pela mesma ligação na 2106 ao cliente autenticado. O controlo remoto no L2J faz-se através de comandos dentro do jogo e através da base de dados. Desaparecem assim dois vetores de ataque que outros jogos têm, e fica tanto mais pendurado na porta 2106.

Ordens de grandeza que deve conhecer

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

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

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

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

ss -lntp

A coluna interessante é a do endereço local. 0.0.0.0:2106 e 0.0.0.0:7777 pertencem ali. 0.0.0.0:9014 e 0.0.0.0:3306 são erros: são as duas portas através das quais um atacante se pode pendurar na sua lista de servidores ou sondar a sua base de dados. 127.0.0.1:3306 significa, pelo contrário, "apenas local" e não precisa de regra de firewall. A perspetiva do atacante obtém-se com um scan de portas a partir de fora:

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

2. Manter a porta 9014 e a base de dados fora da rede aberta

A porta 9014 é o canal através do qual o servidor de jogo se regista no servidor de login, e não pertence em caso algum à rede aberta. O L2J já traz para isso a predefinição correta: LoginHostname = 127.0.0.1 liga a porta à interface de loopback, pelo que ela não é sequer alcançável a partir de fora. Se o servidor de login e o servidor de jogo correrem em duas máquinas diferentes, indique o endereço interno concreto em vez de * e abra a porta exclusivamente para a contraparte.

A mesma regra vale para a base de dados. Verifique em /etc/mysql/mariadb.conf.d/50-server.cnf que ali consta:

bind-address = 127.0.0.1

E troque o utilizador da base de dados. A Server.properties fornecida está em Login = root, e o próprio ficheiro comenta isso com a indicação de que é precisamente aquilo que não se recomenda. Como criar um utilizador próprio com direitos mínimos está em Proteger o MariaDB e o MySQL. Depois controle o resultado:

ss -lntp | grep -E ':9014|:3306'

A firewall por cima disso fica curta. Para um servidor de Lineage 2 bastam duas aberturas para o exterior, 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 2106/tcp comment 'L2 Login'
ufw allow 7777/tcp comment 'L2 Game'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

As instruções completas, incluindo o caminho de recuperação, encontram-se em Configurar a firewall UFW sem se trancar fora do servidor.

3. Desligar o AcceptNewGameServer assim que o seu servidor estiver registado

Na LoginServer.properties consta de fábrica AcceptNewGameServer = True, e o comentário por cima descreve exatamente o que isso significa: qualquer servidor de jogo pode registar-se num lugar livre do seu servidor de login. Enquanto a 9014 estiver apenas na interface de loopback, isso não tem consequências. Assim que a porta ficar alcançável por outro motivo qualquer, passa a ser uma porta aberta. Coloque por isso o valor em False assim que o seu próprio servidor de jogo estiver registado e tiver a sua identificação:

AcceptNewGameServer = False

Na contraparte, do lado do servidor de jogo, consta AcceptAlternateID = True. Isso é cómodo durante a montagem, porque o servidor de login atribui então outra identificação quando a pretendida está ocupada. Num sistema em produção quer o contrário: uma identificação fixa, e um erro quando ela está ocupada.

4. Configurar corretamente a flood protection do servidor de login

O L2J traz um travão de ligações próprio no servidor de login. Está na LoginServer.properties, e todos os valores de tempo são milissegundos:

EnableFloodProtection = True
FastConnectionLimit = 15
NormalConnectionTime = 700
FastConnectionTime = 350
MaxConnectionPerIP = 50

Os valores estão relacionados entre si. Uma ligação que chega menos de FastConnectionTime depois da anterior a partir do mesmo endereço de origem conta como rápida. Ao fim de FastConnectionLimit ligações dessas, o endereço é recusado. NormalConnectionTime é o intervalo a partir do qual o contador volta a ser reduzido. MaxConnectionPerIP é o limite máximo de ligações abertas em simultâneo por endereço.

Cinquenta ligações em simultâneo são muito generosas para um único jogador, e valores mais baixos ajudam de forma sensível. Ainda assim, aqui é preciso cuidado: vários jogadores na mesma casa, um cibercafé e sobretudo as ligações atrás de um NAT de operadora (na cena de L2 isso afeta muitos jogadores da Turquia, do Brasil e de partes da Europa de Leste) partilham um endereço público. Quem aqui colocar 3 tranca jogadores reais fora do servidor. Meça primeiro durante uma semana em funcionamento normal e baixe depois por etapas.

E uma limitação que tem de conhecer: este travão corre no processo Java do servidor de login. Cada pacote sobre o qual ele decide já passou pela sua linha e já custou tempo de processamento. Contra um punhado de origens funciona, contra uma botnet não.

5. Limitar as tentativas falhadas e usar o banned_ip.cfg

Outras duas diretivas na LoginServer.properties controlam durante quanto tempo alguém pode andar a adivinhar:

LoginTryBeforeBan = 5
LoginBlockAfterBan = 900

LoginTryBeforeBan é o número de combinações inválidas de conta e palavra-passe a partir do qual o endereço é bloqueado, LoginBlockAfterBan é a duração do bloqueio em segundos (900 correspondem a 15 minutos). Depois disso a contagem recomeça do princípio.

Os bloqueios permanentes são inscritos no ficheiro banned_ip.cfg, no diretório de configuração do servidor de login. São permitidos endereços individuais, redes inteiras e um momento de expiração opcional como marca temporal Unix em milissegundos; tudo o que vem depois de # é um comentário:

198.51.100.7
203.0.113.0
198.51.100.44 1789689600000

Coloque além disso AutoCreateAccounts = False. A predefinição True cria automaticamente uma conta em cada autenticação com um nome de conta desconhecido. Isso é prático durante a montagem e, em funcionamento, é um presente: um atacante gera com isso as contas que quiser, e cada uma delas pode consultar a lista de servidores com o endereço do seu servidor de jogo. Deixe antes que as contas nasçam através do registo no seu site, assim controla quem recebe um acesso.

6. Limitar no kernel as taxas de ligação na 2106 e na 7777

O que o travão em Java decide demasiado tarde, o kernel decide mais cedo e mais barato. Contra ataques pequenos e bots mal feitos ajuda um limite máximo por endereço de origem:

iptables -I INPUT -p tcp --dport 2106 --syn -m connlimit --connlimit-above 8 --connlimit-mask 32 -j DROP
iptables -I INPUT -p tcp --dport 2106 --syn -m hashlimit --hashlimit-name l2login --hashlimit-mode srcip --hashlimit-above 6/sec --hashlimit-burst 20 -j DROP
iptables -I INPUT -p tcp --dport 7777 --syn -m connlimit --connlimit-above 6 --connlimit-mask 32 -j DROP

A primeira regra descarta novas ligações ao servidor de login assim que um endereço tenha mais de oito delas abertas em simultâneo. Um cliente normal precisa exatamente de uma. A segunda limita a taxa de novas ligações a seis por segundo por endereço, com um amortecedor de vinte, o que ainda deixa passar uma tempestade de reconexões depois de um reinício do servidor. A terceira permite no servidor de jogo seis ligações em simultâneo por endereço, porque a autenticação múltipla (dualbox e triplebox) é normal no Lineage 2 e um limite demasiado apertado atinge os seus jogadores pagantes.

Os três números são valores de partida, não verdades absolutas. Um servidor com 2000 jogadores em simultâneo comporta-se de forma diferente de um com 200. Meça primeiro, configure depois. As regras puras de iptables desaparecem depois de um reinício; no Debian e no Ubuntu guardam-se assim:

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

Com o UFW, regras destas pertencem ao /etc/ufw/before.rules, porque de outra forma desaparecem no ufw reload seguinte.

7. Travar um SYN flood: syncookies, backlog e seguimento de ligações

Como o Lineage 2 funciona exclusivamente sobre TCP, o SYN flood é o vetor óbvio. Um SYN flood é um ataque que envia pedidos de ligação com endereços de origem falsificados e nunca responde à confirmação, de modo que o servidor reserva para cada pedido memória que nunca chega a ser usada. Quatro definições atenuam isso:

sysctl -w net.ipv4.tcp_syncookies=1
sysctl -w net.ipv4.tcp_max_syn_backlog=8192
sysctl -w net.core.somaxconn=4096
sysctl -w net.ipv4.tcp_synack_retries=2

Os SYN cookies são aqui a linha mais importante: o kernel responde ao pedido sem guardar nada e só cria o estado quando a contraparte conclui mesmo a ligação. Os endereços de origem falsificados ficam assim sem efeito. De forma permanente, os valores são guardados num ficheiro em /etc/sysctl.d/ e carregados com sysctl --system.

Um estrangulamento muitas vezes ignorado é o seguimento de ligações do kernel. Se encher, o servidor passa a descartar também pacotes legítimos e no log aparece "nf_conntrack: table full, dropping packet". O estado atual e o limite máximo são mostrados por:

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max

8. Site, servidor de login e servidor de jogo em endereços IP separados

O site do projeto, com registo, loja de donativos e páginas de voto, é sempre localizável através do seu domínio. Se estiver no mesmo endereço IP que o servidor de login, um ataque ao site paralisa ao mesmo tempo a autenticação, e o contrário também. Separe os três papéis por endereços diferentes. Assim, num ataque ao site o jogo continua acessível, e num ataque à 2106 os jogadores já ligados continuam a jogar.

Mantenha ao mesmo tempo os registos DNS limpos. O erro mais frequente é um registo A esquecido a apontar para um endereço anterior: torna inútil qualquer mudança de endereço, porque o atacante encontra o endereço novo pelo mesmo nome que os seus jogadores.

E aqui compensa a honestidade em vez do pensamento mágico: o endereço do seu servidor de login não se consegue manter em segredo. Está no l2.ini dentro da pasta System que todos os jogadores descarregam. O endereço do servidor de jogo, por sua vez, é distribuído pelo próprio servidor de login: no L2J está como endereço externo no ipconfig.xml (em derivados mais antigos como ExternalHostname na Server.properties), e é comunicado a todos os clientes que se autenticaram com sucesso. Esconder não é uma estratégia, filtrar é.

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

O passo mais importante é aquele que quase ninguém dá com antecedência: criar uma base de comparação enquanto tudo funciona normalmente. Sem um valor normal, depois de um incidente não consegue dizer se 40.000 pacotes por segundo foram muito ou se era simplesmente 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
ss -tn state syn-recv | wc -l
ip -s link show eth0
tcpdump -ni eth0 'tcp port 2106' -c 200 -q

A segunda linha é, no Lineage 2, a mais reveladora: conta as ligações semiabertas. Um valor de cinco dígitos com umas poucas centenas de jogadores é um SYN flood e mais nada. Quanto ao tcpdump vale a regra: limitar sempre com -c, porque uma captura a plena carga sobrecarrega ainda mais um servidor que já está sobrecarregado. Como interpretar os valores está em Detetar um ataque DDoS.

Onde estas medidas deixam de chegar

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

Faça as contas connosco. Um gameserver típico está ligado a 1 Gbit/s, o que corresponde a 125 megabytes por segundo, e a linha fica cheia assim que alguém enviar mais do que isso. Contra um servidor de Lineage 2 nem sequer é preciso um ataque grande, porque a segunda grandeza bate mais cedo: a taxa de pacotes. Com pacotes pequenos de 64 bytes cabem numa linha de 1 Gbit/s cerca de 1,49 milhões de pacotes por segundo. Um kernel de servidor normal processa, consoante o CPU e a placa de rede, algumas centenas de milhares deles antes de começar a descartar.

Num jogo puramente TCP junta-se uma terceira barreira. Cada ligação semiaberta ocupa uma entrada no seguimento de ligações e no backlog, e o servidor de login do L2J mantém as suas sessões até 60 segundos. Um ataque com umas poucas centenas de milhares de pacotes por segundo, que não enche sequer um terço da sua linha, pode portanto bloquear por completo a autenticação. Os operadores vivem isto como "a utilização nem sequer estava alta e mesmo assim ninguém conseguia entrar".

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 112,2 Gbit/s e mais de 8,7 milhões de pacotes por segundo contra um gameserver e um ataque multivetor com mais de 473,4 Gbit/s e mais de 41,5 milhões de pacotes por segundo contra um servidor de voz. Para isso não existe nenhuma definição local. Os ataques volumétricos têm de terminar na rede à frente do servidor. O que fazer num caso agudo está em Ataque DDoS grave: o que fazer?.

O que a KernelHost põe do outro lado

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

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

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

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. Precisamente num grand opening, essa é a diferença entre um arranque conseguido e um arranque perdido. 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, e na cena de Lineage 2 isso é o caso normal para qualquer servidor que chegue aos lugares cimeiros das listas de servidores. 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 separadamente o que é permitido na 2106 TCP e o que é permitido na 7777 TCP. No Lineage 2 este é o ponto decisivo, porque as duas portas têm padrões de tráfego completamente diferentes: muitas ligações curtas de um lado, poucas e muito longas do outro.
• As alterações entram em vigor em tempo real, pelo que pode afinar durante um ataque em curso, apertar as regras antes da hora da abertura e voltar a aliviá-las depois.
• Perfil de proteção adequado à aplicação, também para ficheiros de servidor modificados e próprios em quaisquer portas TCP ou UDP. Usar L2J, L2J-Mobius, aCis ou um pacote L2OFF não faz diferença para o conjunto de regras, porque ele assenta na porta e no protocolo.

Os dois níveis em comparação

Para a maioria dos projetos de Lineage 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, e isso acontece, por experiência, na semana anterior ao grand opening.

Erros frequentes e respetivas soluções

"O login não funciona, mas o servidor de jogo trabalha normalmente": isso não é acaso, é a forma habitual de um ataque a um servidor de Lineage 2. O servidor de login e o servidor de jogo são dois processos em duas portas. Meça ss -tn state syn-recv | wc -l e sar -n DEV 1 10. Se as ligações semiabertas subirem enquanto a largura de banda se mantém discreta, é um flood de ligações na 2106.

"Mudei de endereço IP e no dia seguinte estava outra vez offline": o atacante recebe o endereço novo pelo mesmo caminho que os seus jogadores, ou seja, pela nova pasta System com o l2.ini alterado, pelo seu anúncio ou por um registo DNS esquecido. Mudar de endereço é ganhar tempo, não é uma solução.

"Coloquei o MaxConnectionPerIP em 3 e agora os jogadores queixam-se": o dualbox é corrente no Lineage 2, e os jogadores atrás de um NAT de operadora partilham um endereço público com centenas de outros. Volte a um valor que cubra os seus valores medidos em funcionamento normal e limite, em vez disso, a taxa de novas ligações no kernel.

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

"Todos os jogadores têm picos de lag, mas a linha está calma": então não é um ataque DDoS. Num servidor em Java, os suspeitos do costume são as pausas da recolha de lixo, uma base de dados sem os índices adequados e um script ou um evento personalizado preso num ciclo. Verifique primeiro sar -n DEV 1 10: se as taxas de pacotes se mantiverem normais, a causa está no servidor e não na rede.

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

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

"O meu grand opening é daqui a duas semanas": então mude agora e não na semana do arranque. Uma mudança custa uma nova pasta System para os jogadores, uma alteração de DNS e um ensaio. Quer ter tudo isso resolvido antes de anunciar a data, porque a partir do anúncio todos os concorrentes conhecem o seu momento mais desfavorável.

Em resumo

• Um servidor privado de Lineage 2 precisa exatamente de duas portas na rede aberta: 2106 TCP para o servidor de login e 7777 TCP para o servidor de jogo. A porta 9014, a base de dados (3306 no L2J, 1433 no L2OFF) e as portas internas de L2OFF 2002, 2006, 2008, 2104 e 2108 não fazem parte disso.
• O Lineage 2 funciona exclusivamente sobre TCP e não tem porta de consulta nem porta de RCON. O ataque típico é por isso um SYN flood ou um flood de ligações na porta 2106, e não um flood UDP.
• Um ataque ao servidor de login bloqueia apenas as novas autenticações. Quando ninguém consegue entrar enquanto os jogadores no mundo continuam a jogar, a causa está na porta 2106 e não na 7777.
• Configure conscientemente EnableFloodProtection, MaxConnectionPerIP, LoginTryBeforeBan e AutoCreateAccounts, coloque AcceptNewGameServer em False depois do registo e limite adicionalmente as taxas de ligação no kernel, porque o travão em Java só atua depois da linha.
• Os ataques a servidores de Lineage 2 acumulam-se nas aberturas de servidores, porque a data e a hora são públicas semanas antes e o prejuízo económico é maior no dia da abertura. A proteção tem de estar montada antes do anúncio, não depois.
• Acima da capacidade da linha e acima de algumas centenas de milhares de pacotes por segundo, quem decide é exclusivamente a filtragem na rede à frente do servidor. Na KernelHost ela tem dois níveis, está permanentemente ativa, não tem sobretaxa e não usa null-routing.

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