Anticheat FiveM: como proteger seu servidor de cheaters

Guia de anticheat FiveM em camadas: validação server-side, permissões ACE, scripts seguros e como avaliar um anticheat dedicado para blindar sua cidade.

Equipe Cube Resources 6 min de leitura
Neste guia 7 seções
  1. Quais são as ameaças reais em um servidor de RP?
  2. Camada 1: validar tudo no servidor (server-side first)
  3. Camada 2: como configurar permissões ACE no server.cfg?
  4. Camada 3: a qualidade dos scripts faz parte do anticheat
  5. Camada 4: o que avaliar em um anticheat dedicado?
  6. Camada 5: higiene, staff e logs
  7. Segurança é um processo, não uma compra

Mais cedo ou mais tarde acontece: um jogador gerando dinheiro do nada, outro voando pelo mapa, um terceiro atirando do outro lado da cidade. Pesquisar “anticheat fivem” e comprar o primeiro resultado não vai te salvar, porque nenhum produto compensa um servidor mal protegido na base. A segurança real de um servidor de FiveM é construída em camadas, e a maioria delas é gratuita: depende de como o seu código é escrito e de como o servidor é configurado. Neste guia, passamos pelas ameaças reais e pelas cinco camadas de defesa que você deveria ter, em ordem de importância.

Quais são as ameaças reais em um servidor de RP?

As ameaças que mais machucam um servidor de roleplay são mod menus, injeção de eventos, spawn de dinheiro e itens, ESP e blips, e crashes por abuso de OneSync. A maioria explora o seu código, não o jogo, e é por isso que a primeira defesa é disciplina de programação, não um produto.

  • Mod menus: menus de cheat injetados no cliente que permitem ao atacante executar código, spawnar entidades, se teleportar ou ficar invulnerável.
  • Injeção de eventos: a técnica mais danosa e menos vistosa. O cheater dispara diretamente os eventos de rede dos seus scripts com os parâmetros que lhe convêm. Se a sua loja tem um evento que entrega itens, ele vai chamá-lo sem pagar.
  • Spawn de dinheiro e itens: quase sempre é consequência do ponto anterior; um evento de recompensa mal protegido vira uma impressora de dinheiro.
  • ESP e blips: visualização de jogadores, policiais ou mercadoria através das paredes. Não quebra a economia, mas destrói o roleplay competitivo.
  • Crashes e abuso de OneSync: spawn em massa de entidades para derrubar o servidor ou a região.

Repare em um detalhe: a maioria dessas ameaças explora o seu código, não o jogo. Por isso a primeira camada de defesa não é um produto, é uma disciplina.

Camada 1: validar tudo no servidor (server-side first)

Tudo o que chega do cliente pode ser mentira, então a validação precisa viver no servidor. Qualquer evento de rede pode ser disparado com parâmetros arbitrários. O preço, a existência do item e a quantidade devem ser resolvidos no servidor, e o dinheiro só sai da conta depois de uma checagem bem-sucedida.

Compare:

-- VULNERAVEL: confia no que o cliente envia
RegisterNetEvent('shop:server:buyItem', function(itemName, price)
    local player = QBCore.Functions.GetPlayer(source)
    player.Functions.RemoveMoney('cash', price)
    player.Functions.AddItem(itemName, 1)
end)

O cheater dispara esse evento com price = 0 e leva o que quiser de graça. A versão correta ignora qualquer dado sensível do cliente e resolve tudo no servidor:

-- SEGURO: o servidor decide preco e validade
RegisterNetEvent('shop:server:buyItem', function(itemName, amount)
    local src = source
    local player = QBCore.Functions.GetPlayer(src)
    if not player then return end

    local item = Config.ShopItems[itemName]
    if not item then return end

    amount = tonumber(amount)
    if not amount or amount < 1 or amount > 10 then return end

    local total = item.price * amount
    if player.Functions.RemoveMoney('cash', total, 'shop-purchase') then
        player.Functions.AddItem(itemName, amount)
    end
end)

Os princípios são sempre os mesmos: o preço sai da configuração do servidor, nunca do cliente; confere-se se o item existe e se a quantidade é razoável; e o dinheiro é retirado antes de entregar qualquer coisa, verificando que a operação deu certo. Some a isso validações de contexto (o jogador está perto da loja? tem o emprego exigido?) e você terá fechado a porta da frente por onde os cheaters entram.

Dois reforços que custam pouco: limite a frequência com que um mesmo jogador pode disparar eventos sensíveis (ninguém compra cinquenta vezes por segundo de forma legítima) e evite nomes de eventos genéricos que facilitem o palpite. Não é criptografia mágica, mas cada fricção conta.

Camada 2: como configurar permissões ACE no server.cfg?

O FiveM traz um sistema de permissões nativo, o ACE, configurado no server.cfg e complementado pelo txAdmin com o seu próprio sistema de cargos para o painel. Bem usado, ele limita o estrago mesmo que alguém comprometa uma conta da staff. A regra é dar a cada cargo apenas o que ele precisa.

add_ace group.admin command.kick allow
add_ace group.admin command.ban allow
add_ace group.mod command.kick allow
add_principal identifier.license:abc123def456 group.admin
add_principal identifier.license:789ghi012jkl group.mod

Três regras práticas: dê a cada cargo só as permissões de que ele precisa (o moderador que só modera não precisa conseguir dar itens), use o identificador license como referência porque ele é estável, e revise a lista de principals sempre que alguém sair da staff. Um ex-administrador com permissões ativas é uma brecha esperando data.

Camada 3: a qualidade dos scripts faz parte do anticheat

Cada evento de dinheiro ou itens exposto por um script de terceiros é superfície de ataque. Mesmo que o seu código seja perfeito, o servidor executa dezenas de recursos alheios, então a qualidade do que você instala é, literalmente, parte do seu anticheat. Esse critério pesa mais que qualquer produto de segurança.

Antes de instalar qualquer recurso que mexa na economia, pergunte-se: ele valida no servidor ou confia no cliente? Registra as transações para poderem ser auditadas? Limita quantidades e frequência? Um anticheat dedicado pode detectar comportamento suspeito, mas não consegue consertar um script que dá dinheiro a quem pede educadamente.

Camada 4: o que avaliar em um anticheat dedicado?

Com as três primeiras camadas no lugar, um anticheat dedicado adiciona uma rede de detecção que você não consegue montar à mão. Não vamos indicar marcas: o mercado muda rápido e o que hoje é sólido amanhã está abandonado. Em vez disso, estes são os critérios para avaliar qualquer um:

  • Detecções server-side: desconfie dos que se gabam só de proteções no cliente; o cliente está nas mãos do atacante e qualquer proteção que viva ali pode ser desativada. A detecção valiosa observa comportamento a partir do servidor: eventos impossíveis, teleportes, entidades spawnadas fora da lógica do jogo.
  • Frequência de atualizações: os cheats evoluem toda semana; um anticheat sem mudanças há meses é placebo com painel bonito.
  • Gestão de falsos positivos: pergunte como as detecções são ajustadas e se há listas de exceção por recurso. Um anticheat que bane jogadores legítimos durante um evento com muitos veículos te prejudica mais que um cheater.
  • Painel e logs úteis: você precisa revisar por que alguém foi banido e poder reverter com evidência na mão.
  • Compatibilidade com o seu stack: frameworks, inventário e OneSync com muitos jogadores. Peça referências de servidores do seu porte.

E mantenha as expectativas honestas: nenhum anticheat detém cem por cento. A função dele é aumentar o custo de trapacear e te dar visibilidade, não substituir as camadas anteriores.

Camada 5: higiene, staff e logs

A última camada é operacional e é a que mais servidores negligenciam. Ela reúne não instalar leaks, auditar o que entra no servidor, registrar toda ação sensível, treinar a staff e proteger as credenciais do server.cfg.

  • Não instale leaks. Scripts vazados são o vetor clássico de backdoors: código ofuscado que abre uma porta remota no seu servidor semanas depois da instalação. O barato sai caríssimo; no nosso guia sobre scripts grátis para FiveM explicamos como distinguir o open source legítimo da armadilha.
  • Audite o que você instala: revise os eventos que cada recurso novo registra e desconfie de código ofuscado fora do escrow oficial.
  • Registre tudo o que é sensível: transações de dinheiro, movimentação de itens, ações de administração. Sem logs não há investigação possível, só a palavra de um contra a do outro. O txAdmin cobre parte; os seus scripts precisam cobrir o resto.
  • Treine sua staff: um procedimento claro (observar, documentar, banir com evidência) evita tanto cheaters impunes quanto bans injustos que queimam a comunidade.
  • Proteja as credenciais: a senha do banco de dados vive no server.cfg; não compartilhe esse arquivo, não o suba para repositórios públicos e limite quem acessa a máquina. Muitos “hacks” são simplesmente um server.cfg colado em um Discord.

Segurança é um processo, não uma compra

O melhor anticheat FiveM é um servidor cujos scripts validam tudo no servidor, com permissões mínimas, logs completos e uma staff que sabe o que olhar. O produto dedicado é a quinta camada, não a primeira. Comece auditando seus eventos de dinheiro e itens ainda esta semana: é de graça e é onde estão os buracos de verdade.

Se levar uma única ideia deste guia, que seja esta: quando ampliar sua cidade, faça isso com recursos que tratem segurança como requisito e não como nota de rodapé.

Perguntas frequentes

Qual é o melhor anticheat para FiveM?

Não existe um produto único que resolva tudo. O melhor anticheat FiveM é um servidor com validação server-side em todos os eventos de dinheiro e itens, permissões mínimas e logs completos. O anticheat dedicado entra como quinta camada, para detectar comportamento suspeito.

Um anticheat dedicado basta para proteger meu servidor de RP?

Não. Um anticheat dedicado detecta comportamento suspeito, mas não conserta um script que entrega dinheiro a quem pede. Primeiro valide tudo no servidor, restrinja permissões e registre transações. O anticheat só amplia a rede de detecção.

Como funciona a injeção de eventos no FiveM?

O cheater dispara diretamente os eventos de rede dos seus scripts com parâmetros escolhidos por ele, como um preço igual a zero. Se o evento confia nos dados vindos do cliente, a vantagem é entregue. A defesa é validar tudo no servidor.

Scripts vazados (leaks) são perigosos para o servidor?

Sim. Leaks são o vetor clássico de backdoors: código ofuscado que abre acesso remoto ao seu servidor semanas depois da instalação. Além disso, não recebem updates nem suporte. Instale apenas recursos de fonte original ou comprados com escrow oficial.

Os scripts da Cube Resources entram à venda em 4 de novembro. Se este guia ajudou, avisamos você no dia em que a loja abrir.

A loja abre em

A loja abre em 4 de novembro de 2026 às 16:00, horário de Madri (12:00 em Brasília).

Avisamos você no dia do lançamento

Deixe seu e-mail e escrevemos quando a loja abrir. Só isso.