Guia · 28 de julho de 2026 · 6 min de leitura

Anti-nuke no Discord: impedir a destruição do teu servidor

Um nuke não vem de fora: vem de uma conta a quem deste as chaves. Este guia explica como estes ataques acontecem, porque as permissões não chegam, e como configurar uma proteção que aguenta.

Nuke e raid: dois ataques diferentes

Um nuke é a destruição de um servidor Discord por dentro: eliminação de todos os canais e de todos os cargos, banimento em massa dos membros, por vezes criação de centenas de canais de spam para tornar o servidor inutilizável.

A diferença face a um raid é essencial:

Um anti-raid não protege de um nuke, e o inverso também não. Os dois são necessários.

As três formas de acontecer

1. Uma conta de administrador roubada

O caso mais frequente. Um membro da equipa clica numa falsa ligação de Nitro, descarrega «o jogo de um amigo» que contém um token-grabber, ou cai numa página de acesso falsa. O atacante recupera o token de sessão e age com a identidade dele — sem palavra-passe, sem dupla autenticação a ultrapassar.

2. Um bot comprometido

Muitos servidores acrescentam bots com a permissão Administrador para não terem de pensar no assunto. Se o token desse bot se escapar (um repositório público, um alojamento mal configurado, um programador pirateado), o atacante dispõe de uma ferramenta de destruição já instalada e já autorizada.

3. Um membro da equipa que descarrila

Mais raro, mas real: um moderador afastado, um desacordo que acaba mal. A proteção é a mesma, o que é até tranquilizador: não obriga a presumir má-fé de ninguém.

Porque as permissões não chegam

O reflexo natural é restringir as permissões. É necessário, mas insuficiente, por uma razão simples:

As permissões do Discord determinam quem pode agir. Não dizem nada sobre quanto nem a que velocidade.

Um administrador legítimo precisa de poder apagar um canal. Esse mesmo administrador pode apagar cinquenta em dez segundos, e nenhuma permissão o impede. É precisamente aí que está o ponto cego.

A proteção deve, portanto, incidir sobre o ritmo e o volume das ações, não sobre o direito de as fazer.

O princípio de uma deteção que funciona

Uma proteção anti-nuke a sério conta as ações destrutivas por autor, numa janela de tempo deslizante. Em concreto: «esta conta apagou 6 canais em 3 segundos».

As ações a vigiar são sempre as mesmas:

• Eliminação de canais e de cargos
• Criação em massa de canais ou de cargos (spam)
• Banimentos e expulsões em série
• Criação de webhooks (exfiltração e depois spam)
• Atribuição súbita de permissões sensíveis
• Alteração do servidor (nome, imagem, URL personalizado)

Distinguir a arrumação da sabotagem

O verdadeiro desafio não é detetar, é não sancionar um administrador que está a arrumar o servidor. Um limiar em bruto não chega: reorganizar categorias pode apagar legitimamente uma dezena de canais.

O sinal mais fiável para decidir é a regularidade dos intervalos. Um script age a uma cadência quase constante — algumas dezenas de milissegundos entre cada ação, sempre as mesmas. Um humano que clica na interface é irregular: hesita, confirma, desloca-se no menu.

A isso juntam-se a antiguidade da conta no servidor, a sua natureza (humano ou bot), a hora e os antecedentes. Uma proteção que combina estes sinais dispara antes do limiar quando a assinatura é maquinal, e mantém-se calada durante uma arrumação a sério.

O ponto cego: os bots

Eis o problema menos conhecido, e o mais grave. A maioria das proteções anti-nuke isenta os bots por princípio — muitas vezes com uma simples condição do tipo «se o autor for um bot, não fazer nada».

A intenção percebe-se: evitar que o bot de tickets, que cria e apaga canais o dia todo, dispare alertas sem parar. Mas a consequência é que um bot comprometido fica totalmente intocável, quando é um dos principais vetores de nuke.

A abordagem certa é vigiar os bots e tratar os falsos positivos de outra maneira:

• Uma lista de contas de confiança para os bots legítimos que mexem em canais continuamente.
• Limiares por tipo de ação: um bot de tickets cria canais, não apaga quarenta de uma vez.
• Uma sanção adequada: retirar os cargos a um bot corta-lhe as permissões de imediato, mesmo que a expulsão falhe.

Configurar a tua proteção

Com o OriusBot, através de /anti-raid e depois da página Anti-nuke inteligente.

Limiares de partida

Valores razoáveis para um servidor de dimensão média, a ajustar depois:

Quem vigiar

• Os bots: sim. É o ponto que faz a diferença.
• Os administradores: sim. Uma conta de administrador roubada é o primeiro vetor; isentá-la equivale a não proteger nada.
• O proprietário do servidor: não. Nunca. Uma deteção falsa não pode decapitar o servidor.
• Lista de confiança para os bots de tickets e de canais de voz temporários.

Que sanção

A sanção mais eficaz não é a expulsão, é a retirada imediata de todos os cargos. Corta as permissões numa única ação, mesmo que a expulsão falhe depois por causa da hierarquia. A expulsão ou o banimento vêm a seguir.

Permissão indispensável

O bot precisa de Ver o registo de auditoria. Sem ela, nenhuma ação destrutiva é atribuível a um autor, e a proteção não tem sobre o que disparar. É o esquecimento mais frequente.

A higiene que evita o incidente

A proteção técnica é a segunda linha. A primeira continua a ser a higiene:

• Dupla autenticação obrigatória para a moderação (Definições do servidor → Moderação). Uma definição, dois cliques.
• Nada de permissão Administrador para os bots. Dar exatamente o que o bot precisa. É a única medida que neutraliza mesmo o vetor do bot comprometido.
• Limitar o número de administradores. Cada conta de administrador é uma chave do servidor.
• Rever os bots instalados uma vez por trimestre: retirar os que já não servem, verificar as permissões dos restantes.
• Formar a equipa sobre phishing: falso Nitro, falsas parcerias, ficheiros «para testar». É por aí que os tokens se escapam.

Depois de um nuke

1. Cortar o acesso. Retirar os cargos da conta culpada antes de mais — pode ainda estar a agir.
2. Verificar os webhooks. Um atacante deixa muitas vezes algum para voltar. Definições do servidor → Integrações.
3. Restaurar. Uma proteção com restauro recria os canais e cargos apagados. As mensagens, essas, perdem-se: o Discord não oferece qualquer cópia de segurança.
4. Verificar os banimentos. Levantar em massa os aplicados durante o incidente.
5. Perceber por onde entrou. Conta roubada? Bot comprometido? Sem resposta, o incidente repete-se.

Perguntas frequentes

Um nuke pode ser anulado?

Parcialmente. Canais e cargos recriam-se, mas as mensagens perdem-se definitivamente — o Discord não oferece qualquer restauro. É por isso que uma proteção deve bloquear o ataque em curso, não reparar depois.

É preciso retirar a permissão Administrador a todos os bots?

Idealmente, sim. Na prática, alguns bots pedem-na para funcionar. Se tiveres de a conceder, reserva-a aos bots que conheces, e ativa a vigilância dos bots para manter uma rede de segurança.

A dupla autenticação protege do roubo de token?

Não, e é um mal-entendido comum. Um token-grabber rouba o token de sessão, que contorna a dupla autenticação. Ela continua indispensável contra o roubo de palavra-passe, mas não dispensa uma proteção anti-nuke.

Quanto tempo dura um nuke?

Alguns segundos. Um script apaga cinquenta canais mais depressa do que um humano lê uma notificação. É por isso que a resposta tem de ser automática.

Ler a seguir : Checklist de segurança, Proteger o servidor dos raids, Ficheiros maliciosos no Discord.