Proteger o servidor RedM contra ataques DDoS

Um servidor RedM que desaparece a meio da sessão à noite e volta a aparecer dez minutos depois raramente tem um problema de hardware. Na maioria dos casos está a decorrer um ataque à porta 30120, e ele decorre precisamente quando há mais jogadores online. Este artigo mostra como proteger um servidor RedM contra ataques DDoS: primeiro o que pode proteger por conta própria e sem custos adicionais, depois o limite físico dessas medidas e, por fim, o que tem de acontecer na rede à frente do servidor quando o ataque é maior do que a sua linha.

Todas as indicações se referem a um FXServer com gamename rdr3 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. O RedM é a modificação de Red Dead Redemption 2 da Cfx.re e o projeto irmão do FiveM. Ambos correm sobre o mesmo programa de servidor, razão pela qual uma parte da técnica de rede é realmente idêntica. Onde isso se aplica, fica aqui dito numa frase e a parte detalhada está no artigo Proteger o servidor FiveM contra ataques DDoS. Tudo o resto neste texto é específico do RedM.

Se o ataque estiver a decorrer neste momento: não altere agora nada na server.cfg e não reinicie o servidor. Guarde primeiro os valores medidos (ver a secção "Recolher valores medidos"), porque depois do ataque desaparecem.

Porque é que os servidores RedM são tantas vezes alvo de ataques DDoS

Um servidor RedM é um alvo mais compensador do que o seu número de jogadores deixa supor. A razão está na dimensão da cena, não no facto de ela ser pequena. Em setembro de 2026, os rastreadores públicos de listas de servidores contavam cerca de 2 000 servidores RedM ativos com aproximadamente 12 400 jogadores em simultâneo, contra cerca de 39 000 servidores FiveM com aproximadamente 325 000 jogadores. Quem põe fora de serviço um de 2 000 servidores RedM retira da rede uma fatia bem maior de toda a cena do que quem atinge um de 39 000 servidores FiveM. Para um atacante que queira prejudicar um projeto concorrente, a alavanca é, portanto, incomparavelmente maior.

A isto junta-se a estrutura das comunidades. O roleplay em RedM vive de sessões fixas a horas fixas, muitas vezes com inscrição e aprovação da personagem. Uma falha às 20 horas não atinge uns jogadores quaisquer, atinge exatamente aqueles que se inscreveram para essa noite. Muitos projetos funcionam além disso como um passatempo com orçamento pequeno, dependem de um único servidor barato e não têm uma segunda instância para a qual se possa comutar. Casos documentados publicamente na cena do RedM descrevem séries de ataques ao longo de meses, em ritmo quase diário, que atingiram ao mesmo tempo o servidor de jogo e o servidor de voz separado.

Do lado técnico acresce que o tráfego de jogo corre sobre UDP. O UDP é um protocolo de transporte sem ligação: não existe um estabelecimento de ligação que o servidor possa exigir e os endereços de origem falsificam-se com facilidade. Um atacante não precisa, portanto, de entrar no seu servidor RedM nem de o contactar corretamente para lhe gerar carga. O que é exatamente um ataque DDoS e como ele é montado fica explicado no artigo O que é um ataque DDoS?.

As portas que realmente contam

Por predefinição, um servidor RedM liga-se a uma única porta, e nos dois protocolos. Na server.cfg consta para isso:

endpoint_add_tcp "0.0.0.0:30120"
endpoint_add_udp "0.0.0.0:30120"
set gamename rdr3
sv_enforceGameBuild 1491
sv_licenseKey "cfxk_..."

A linha set gamename rdr3 é a única que distingue um servidor RedM de um servidor FiveM. Se faltar, o mesmo FXServer regista-se como servidor de GTA V e um cliente RedM não se liga. O RedM não tem uma porta de query própria nem uma porta de RCON própria: consulta ao servidor, estabelecimento da ligação, tráfego de jogo e RCON correm todos pelas mesmas duas entradas na 30120. Estes são os números em concreto:

Das quatro portas indicadas, exatamente duas pertencem à rede aberta: 30120 TCP e 30120 UDP. A porta 40120 e a porta 3306 não pertencem ali, e o SSH na porta 22 deve estar restringido aos seus próprios endereços. Este é o erro evitável mais frequente em servidores RedM, porque muitos projetos arrancam com uma receita pronta de txAdmin e nunca mais verificam o que o servidor oferece para o exterior.

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

Esta secção é a mais longa, e isso é intencional. Um servidor RedM bem configurado aguenta ataques pequenos e médios pelos seus próprios meios, independentemente de onde esteja alojado. A ordem foi escolhida de propósito: primeiro mede, depois fecha e só a seguir limita.

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 -lntup

A coluna interessante é a do endereço local. 0.0.0.0:30120 e [::]:30120 significam "acessível a partir de toda a internet", 127.0.0.1:3306 significa "apenas local" e não precisa de regra de firewall. Além do FXServer, num servidor RedM aparecem regularmente o txAdmin na 40120, o MariaDB na 3306, um servidor web para a página do projeto e, por vezes, um serviço de voz. 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. Deixar aberta apenas a 30120 TCP e UDP

Para o RedM 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 30120/tcp comment 'RedM'
ufw allow 30120/udp comment 'RedM'
ufw allow from 203.0.113.10 to any port 40120 proto tcp comment 'txAdmin'
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. Numa ligação com endereço variável isso é pouco prático, e o melhor caminho está na secção seguinte, sobre o txAdmin. As instruções completas, incluindo o caminho de recuperação, encontram-se em Configurar a firewall UFW sem se trancar fora do servidor.

A base de dados não pertence, em caso algum, à rede aberta. O VORP, o RSGCore e o RedEM:RP precisam todos de um MariaDB ou MySQL, normalmente através do oxmysql com uma cadeia de ligação na server.cfg. Essa ligação corre localmente, pelo que a porta não tem de estar acessível a partir do exterior. Verifique em /etc/mysql/mariadb.conf.d/50-server.cnf que ali consta:

bind-address = 127.0.0.1

3. Proteger os endpoints HTTP do FXServer

O FXServer responde, na parte TCP da 30120, a pedidos HTTP sem que ninguém tenha de abrir Red Dead Redemption 2. Veja o que o seu servidor RedM entrega ali:

curl -s http://127.0.0.1:30120/info.json | head -c 600
curl -s http://127.0.0.1:30120/players.json | head -c 600
curl -s http://127.0.0.1:30120/dynamic.json

O /players.json lista os jogadores ligados juntamente com os respetivos identificadores, o /info.json a configuração do servidor e os recursos carregados, o /dynamic.json a ocupação atual. São precisamente estes três endpoints o caminho de ataque de camada 7 documentado contra servidores FiveM e RedM: estão acessíveis sem autenticação, podem ser consultados as vezes que se quiser, cada consulta custa trabalho ao seu servidor e o conteúdo revela a um atacante quando é que vale a pena atacar. Duas contramedidas não custam nada. Primeiro, os endpoints dos jogadores não pertencem à resposta, e para isso basta uma linha na server.cfg:

sv_endpointPrivacy true

Esta definição esconde os endereços IP dos seus jogadores nas saídas públicas do servidor. Segundo: se o seu bot do Discord ou a página do seu projeto mostrar o número de jogadores, não consulte o endpoint a partir do visitante, guarde antes o resultado em cache a intervalos fixos. Assim, uma página de estado muito visitada gera uma consulta por intervalo em vez de uma por visitante. Numa cena pequena como a do RedM isso pesa a dobrar, porque um único bot de estado de servidor pode estar integrado em vários servidores de Discord ao mesmo tempo.

4. Tirar o txAdmin da porta 40120 da rede aberta

O txAdmin é a interface de administração incluída na build do FXServer para FiveM e RedM, e escuta por predefinição na 40120 TCP. Por trás dela está o acesso total ao seu servidor: reinícios, lista de banimentos, base de dados de jogadores, gestão de recursos. Sem um endereço IP fixo para a regra de abertura, mantenha a porta fechada para o exterior e chegue até ela através de um reencaminhamento de porta local com SSH; depois abra no navegador http://127.0.0.1:40120:

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

Quem deixa o txAdmin exposto publicamente fica com dois problemas de uma só vez: uma máscara de autenticação contra a qual se podem lançar floods de tentativas de entrada e um serviço que trabalha a cada pedido, apesar de nada ter a ver com o jogo. Na dúvida, ligue o txAdmin logo localmente, deixando o serviço escutar apenas em 127.0.0.1.

5. Limitar as taxas de ligações e de pacotes por endereço de origem

Contra ataques pequenos e bots mal feitos ajuda um limite máximo por endereço de origem. As duas regras aplicam-se à 30120, ou seja, aos dois protocolos do jogo:

iptables -I INPUT -p tcp --dport 30120 --syn -m connlimit --connlimit-above 8 --connlimit-mask 32 -j DROP
iptables -I INPUT -p udp --dport 30120 -m hashlimit --hashlimit-name redm_udp --hashlimit-mode srcip --hashlimit-above 500/sec --hashlimit-burst 750 -j DROP

A primeira regra descarta novas ligações TCP assim que um endereço tenha mais de oito delas abertas em simultâneo; a segunda descarta pacotes UDP a partir de mais de 500 pacotes por segundo, de forma continuada, vindos da mesma origem. Os valores de partida são aqui um pouco mais baixos do que num servidor FiveM, porque um servidor RedM com 32 slots gera simplesmente menos ligações legítimas por endereço. Mas valores de partida não são verdades absolutas: uma noite de RP cheia gera bastante mais pacotes do que um servidor vazio, e quem aperta demasiado acaba por expulsar os seus próprios jogadores. Meça primeiro durante uma semana em funcionamento normal.

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

6. Proteger os 32 slots contra floods de entradas

Um servidor RedM tem, sem OneSync, exatamente 32 slots. Com OneSync são 48 e, acima disso, é preciso uma subscrição do Element Club para chegar até 1 024 lugares. Este número é relevante para a segurança, porque é o limite máximo que um atacante tem de encher: quem mantém 32 tentativas de entrada abertas em simultâneo ocupa por completo um servidor padrão, sem que um único jogador chegue de facto a entrar no jogo. Num projeto FiveM com 128 lugares, esse mesmo limiar é quatro vezes mais alto.

Uma vantagem específica do RedM compensa isso em parte: o RedM exige uma cópia verdadeira de Red Dead Redemption 2, comprada através da Steam, da Epic Games ou da Rockstar, além do launcher da Rockstar. Um flood de entradas com milhares de contas descartáveis, como é habitual em jogos gratuitos, custa aqui dinheiro a sério. Por isso, os ataques deslocam-se para a camada de rede e para os endpoints HTTP, onde não é precisa nenhuma cópia do jogo.

Contra tudo o que usa o caminho normal de entrada, uma whitelist continua, ainda assim, a resultar. É implementada do lado do servidor no evento playerConnecting, onde suspende a ligação com as funções de deferrals, verifica o identificador e só depois deixa entrar. A isto juntam-se uma verificação de conta rigorosa e um limite de jogadores realista:

sv_authMaxVariance 1
sv_authMinTrust 5
sv_maxclients 32

O sv_authMaxVariance é um valor de 1 a 5 e indica quanto é que o identificador de um jogador pode variar junto de um fornecedor; 1 é a definição mais rigorosa. O sv_authMinTrust vai igualmente de 1 a 5 e descreve quão improvável tem de ser uma identidade falsificada; aqui, 5 é o valor mais rigoroso. Defina uma palavra-passe de RCON apenas se precisar mesmo de RCON, porque esse acesso fica na mesma porta aberta 30120. 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. Avaliar corretamente a entrada na lista de servidores do RedM

Aqui compensa mais a honestidade do que o pensamento mágico: o seu endereço IP não se consegue manter em segredo. O RedM usa a mesma infraestrutura de servidores mestre da Cfx.re que o FiveM, e a entrada na lista contém, no campo connectEndPoints, o endpoint de ligação em texto simples. Através da interface pública em servers-frontend.fivem.net é possível consultar o endereço associado a qualquer código cfx.re, tanto para RedM como para FiveM. Quem não precisa de todo da entrada pública, porque o projeto funciona apenas por Discord e por ligação direta, pode manter o servidor como privado com sv_master1 "": deixa então de ser possível entrar nele através da lista de servidores. Isso custa, no entanto, toda a visibilidade junto de novos jogadores e, numa cena com 2 000 servidores, a visibilidade é o verdadeiro motor de crescimento.

Mais eficazes são dois hábitos. Não publique a si 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 ligue os seus jogadores através de um hostname, para que em caso de necessidade possa mudar de endereço sem que todas as referências deixem de funcionar. O clássico, aqui, são os registos DNS antigos: um registo A esquecido a apontar para o endereço anterior torna qualquer mudança inútil.

8. Verificar do lado do servidor os eventos do VORP, do RSGCore e do RedEM

Muitas falhas comunicadas como ataque DDoS resultam de um único script. Os recursos do RedM comunicam através de eventos de rede, e um evento que o servidor executa sem verificação é uma porta aberta: quem dispare no cliente um TriggerServerEvent com valores arbitrários pode criar dólares, fazer aparecer cavalos ou lançar consultas à base de dados em ciclo até o servidor parar. Isto atinge por igual as três frameworks mais divulgadas: o VORP Core, que desde 2020 tem a maior base de scripts, o RSGCore e o mais antigo RedEM:RP.

Particularmente vulneráveis são os recursos de inventário e de personagem, porque escrevem na base de dados a cada chamada. Um ciclo de eventos que guarda dez vezes por segundo o estado do inventário sobrecarrega um servidor RedM mais do que muita enxurrada de pacotes, e vem de dentro, onde nenhuma firewall atua.

Três regras travam a maior parte disso. Registe com RegisterNetEvent apenas os eventos que devem mesmo vir do cliente. Nunca confie nos valores que o cliente envia, determine antes o jogador do lado do servidor a partir de source. E limite quantas vezes um jogador pode disparar o mesmo evento, sobretudo em tudo o que envolva uma consulta à base de dados. Se o servidor engasga enquanto a linha está calma, o resmon 1 na consola do cliente mostra o tempo de processamento por recurso, e normalmente o culpado está logo no topo.

9. Recolher valores medidos antes de precisar deles

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 uma terça-feira à noite bem frequentada. Com apt-get install -y vnstat sysstat, a medição fica sempre a correr. Durante um incidente bastam quatro comandos: taxas de pacotes por segundo, taxa de descarte da interface, mensagens do kernel e uma amostra curta do tráfego.

sar -n DEV 1 10
ip -s link show eth0
dmesg -T | tail -50
tcpdump -ni eth0 port 30120 -c 200 -q

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. Repare ainda se a carga está na parte UDP ou na parte TCP da 30120. Carga em UDP aponta para uma enxurrada de pacotes contra o tráfego de jogo, carga em TCP para uma enxurrada contra os endpoints HTTP, e cada uma precisa de contramedidas diferentes. Como interpretar os valores está em Detetar um ataque DDoS.

Onde estas medidas deixam de chegar

Agora a parte que nenhuma server.cfg 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. Os ataques contra projetos de roleplay situam-se habitualmente entre 5 e 50 Gbit/s, ou seja, entre cinco e cinquenta vezes a sua linha. Nessa altura já não interessa se a sua regra de iptables por trás é boa, porque os pacotes dos seus jogadores nem chegam a passar.

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 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. Um ataque que nem sequer enche um terço da sua linha pode, ainda assim, deixar o seu servidor RedM 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". São precisamente estes picos de lag sem carga visível no servidor a imagem típica de um ataque por taxa de pacotes.

Para dar uma ideia das ordens de grandeza que ocorrem na realidade: em servidores da KernelHost foram filtrados, entre outros, um ataque com mais de 473,4 Gbit/s e mais de 41,5 milhões de pacotes por segundo contra um servidor de voz, e um flood UDP com mais de 112,2 Gbit/s contra um gameserver. Para isso não existe nenhuma definição local. Os ataques volumétricos têm de terminar na rede à frente do servidor.

O que é diferente no RedM em relação ao FiveM

A resposta curta: a técnica de rede é idêntica, o contexto não. Ambos correm sobre o mesmo FXServer, ambos usam a 30120 TCP e UDP, ambos são administrados através do txAdmin na 40120. Tudo o que leu acima sobre portas, taxas e endpoints vale para os dois. Diferentes são as condições em redor, e são precisamente elas que decidem com que rapidez um ataque faz efeito:

Três pontos desta tabela são decisivos para a defesa. Primeiro, a cena mais pequena torna cada servidor RedM mais valioso como alvo, porque uma falha afeta uma fatia maior dos jogadores. Segundo, o limite predefinido de 32 slots baixa o patamar a partir do qual um flood de entradas fecha o servidor. E terceiro, na internet encontram-se menos receitas de proteção prontas para RedM do que para FiveM, razão pela qual muitos projetos correm com uma configuração padrão inalterada. A defesa é a mesma, o ponto de partida é pior.

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 RedM 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. O local da filtragem é Frankfurt am Main. 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 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 30120 UDP e o que é permitido na 30120 TCP, sem ter de escrever um ticket para isso. No caso do RedM, essa separação é particularmente útil, porque o tráfego de jogo e os endpoints HTTP estão no mesmo número de porta e têm padrões completamente diferentes.
• As alterações entram em vigor em tempo real, pelo que pode afinar durante um ataque em curso.
• Perfil de proteção adequado à aplicação. Para servidores Cfx.re na 30120 existe um perfil apropriado, tal como para aplicações modificadas e próprias em quaisquer portas TCP ou UDP.

Ambos se aplicam a servidores alojados na KernelHost. Se o seu projeto RedM estiver neste momento noutro sítio e for regularmente atirado para fora da rede, a recomendação é a mudança, não um produto adicional.

Os dois níveis em comparação

Para a maioria dos projetos de RedM, 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 meu servidor não aparece na lista de servidores do RedM, suspeito de um ataque": verifique primeiro a configuração. Se faltar set gamename rdr3, o FXServer regista-se como servidor de GTA V e não aparece na lista do RedM. Se a chave de licença do portal.cfx.re faltar ou estiver errada, a entrada também não chega a ser criada. Um ataque tem outro aspeto: a entrada mantém-se, o que falha é a ligação.

"Centenas de jogadores recebem um erro ao entrar, parece uma enxurrada": normalmente é um problema de build de jogo. Se o sv_enforceGameBuild não corresponder ao que os seus recursos esperam, o cliente comunica "server specified an invalid game enforcement". Defina o valor que a sua framework exige, habitualmente 1436 ou 1491, e reinicie o servidor por completo.

"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 ou de um registo DNS antigo. Mudar de endereço é ganhar tempo, 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. Se ficarem a zero, a regra não está a ser alcançada.

"O servidor está a funcionar, mas todos os jogadores têm efeito de elástico": isso é mais vezes um script do que um ataque. Veja primeiro com o resmon 1 se algum recurso está a devorar o tempo de processamento e verifique os recursos de inventário e de personagem da sua framework. Se o sar -n DEV 1 10 não mostrar nada de especial, não foi um ataque DDoS.

"O txAdmin mostra centenas de tentativas de ligação falhadas": isso é um flood de entradas e atinge a lógica de jogo, não a linha. Contra isso resultam a whitelist, a verificação de conta através do sv_authMinTrust e o limite de ligações por endereço de origem.

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

Em resumo

• Um servidor RedM precisa de exatamente duas portas abertas: 30120 TCP e 30120 UDP, definidas com endpoint_add_tcp e endpoint_add_udp. Não existe uma porta de query nem uma porta de RCON próprias.
• O txAdmin na 40120 TCP e a base de dados na 3306 TCP não pertencem à rede aberta, mas sim ao seu próprio endereço e a 127.0.0.1, respetivamente.
• O sv_endpointPrivacy true tira os endereços IP dos jogadores das saídas públicas, e um estado de servidor guardado em cache tira carga ao /players.json, o caminho de ataque de camada 7 documentado contra servidores Cfx.re.
• Um servidor RedM tem 32 slots sem OneSync, 48 com OneSync e até 1 024 com o Element Club. Quanto menor o número de slots, mais barato fica um flood de entradas, e mais importantes se tornam a whitelist e a verificação de conta.
• O RedM e o FiveM correm sobre o mesmo FXServer, distinguidos apenas pelo set gamename rdr3. A defesa de rede é por isso idêntica, o contexto não: cerca de 2 000 servidores RedM contra cerca de 39 000 servidores FiveM tornam cada projeto RedM um alvo mais valioso.
• As regras de firewall locais acabam onde a linha fica cheia: 1 Gbit/s são 125 megabytes por segundo e, com pacotes de 64 bytes, cabem lá cerca de 1,49 milhões de pacotes por segundo. Tudo o que estiver acima disso tem de terminar na rede à frente do servidor.
• Na KernelHost, a proteção permanente em dois níveis está incluída em todos os pacotes de servidor, ativa a partir da disponibilização e sem null-routing. Quem quiser controlar a filtragem por si próprio recebe, com a Advanced DDoS Protection a partir de 50,00 EUR por mês, um IP de proteção dedicado e regras próprias por porta e por protocolo.

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