Guía · 28 de julio de 2026 · 6 min de lectura
Anti-nuke en Discord: impedir la destrucción de tu servidor
Un nuke no viene de fuera: viene de una cuenta a la que le diste las llaves. Esta guía explica cómo se producen estos ataques, por qué los permisos no bastan y cómo configurar una protección que aguante.
Contenido
Nuke y raid: dos ataques distintos
Un nuke es la destrucción de un servidor de Discord desde dentro: borrado de todos los canales y de todos los roles, baneo masivo de los miembros, y a veces creación de cientos de canales de spam para dejar el servidor inservible.
La diferencia con un raid es esencial:
| Raid | Nuke | |
|---|---|---|
| Origen | Cuentas externas | Cuenta que ya tiene permisos |
| Vector | Entradas masivas | Abuso de derechos de administración |
| Daños | Reversibles (banear, limpiar) | Mensajes perdidos para siempre |
| Duración | De minutos a una hora | Unos segundos |
| Respuesta | Filtrar en la entrada | Limitar la velocidad de acción |
Un anti-raid no protege de un nuke, y al revés tampoco. Los dos son necesarios.
Las tres formas en que ocurre
1. Una cuenta de administrador robada
Lo más frecuente. Un miembro del equipo pulsa un falso enlace de Nitro, descarga «el juego de un amigo» que contiene un token-grabber, o cae en una página de acceso falsa. El atacante recupera el token de sesión y actúa con su identidad — sin contraseña, sin doble autenticación que superar.
2. Un bot comprometido
Muchos servidores añaden bots con el permiso Administrador para no complicarse. Si el token de ese bot se filtra (un repositorio público, un alojamiento mal configurado, un desarrollador hackeado), el atacante dispone de una herramienta de destrucción ya instalada y ya autorizada.
3. Un miembro del equipo que se descontrola
Más raro, pero real: un moderador apartado, un desacuerdo que acaba mal. La protección es la misma, lo cual es más bien tranquilizador: no obliga a presuponer mala fe de nadie.
Por qué los permisos no bastan
El reflejo natural es restringir los permisos. Es necesario, pero insuficiente, por una razón sencilla:
Los permisos de Discord determinan quién puede actuar. No dicen nada de cuánto ni a qué velocidad.
Un administrador legítimo necesita poder borrar un canal. Ese mismo administrador puede borrar cincuenta en diez segundos, y ningún permiso se lo impide. Ahí está justamente el punto ciego.
La protección debe recaer, por tanto, sobre el ritmo y el volumen de las acciones, no sobre el derecho a hacerlas.
El principio de una detección que funciona
Una protección anti-nuke seria cuenta las acciones destructivas por autor, en una ventana de tiempo deslizante. En concreto: «esta cuenta ha borrado 6 canales en 3 segundos».
Las acciones que vigilar son siempre las mismas:
- Borrado de canales y de roles
- Creación masiva de canales o de roles (spam)
- Baneos y expulsiones en serie
- Creación de webhooks (exfiltración y luego spam)
- Concesión repentina de permisos sensibles
- Cambios del servidor (nombre, imagen, URL personalizada)
Distinguir la limpieza del sabotaje
El verdadero reto no es detectar, es no sancionar a un administrador que está ordenando su servidor. Un umbral en bruto no basta: reorganizar categorías puede borrar legítimamente una decena de canales.
La señal más fiable para distinguirlos es la regularidad de los intervalos. Un script actúa a una cadencia casi constante — unas decenas de milisegundos entre cada acción, siempre las mismas. Un humano que pulsa en la interfaz es irregular: duda, confirma, se mueve por el menú.
A eso se añaden la antigüedad de la cuenta en el servidor, su naturaleza (humano o bot), la hora y sus antecedentes. Una protección que combina estas señales se dispara antes del umbral cuando la firma es maquinal, y se mantiene callada durante una limpieza de verdad.
El punto ciego: los bots
Aquí está el problema menos conocido y el más grave. La mayoría de las protecciones anti-nuke eximen a los bots por principio — a menudo con una simple condición del tipo «si el autor es un bot, no hacer nada».
La intención se entiende: evitar que el bot de tickets, que crea y borra canales todo el día, dispare alertas sin parar. Pero la consecuencia es que un bot comprometido resulta totalmente intocable, cuando es uno de los principales vectores de nuke.
El enfoque correcto es vigilar a los bots y tratar los falsos positivos de otra manera:
- Una lista de cuentas de confianza para los bots legítimos que manejan canales de forma continua.
- Umbrales por tipo de acción: un bot de tickets crea canales, no borra cuarenta de golpe.
- Una sanción adecuada: quitarle los roles a un bot corta sus permisos de inmediato, aunque la expulsión falle.
Configurar tu protección
Con OriusBot, mediante /anti-raid y después la página Anti-nuke inteligente.
Umbrales de partida
Valores razonables para un servidor de tamaño medio, a ajustar después:
| Acción | Umbral | Ventana |
|---|---|---|
| Canales borrados | 4 | 5 s |
| Roles borrados | 4 | 5 s |
| Baneos / expulsiones | 5 | 5 s |
| Webhooks creados | 3 | 5 s |
| Todas las acciones juntas | 10 | 5 s |
A quién vigilar
- Los bots: sí. Es el punto que marca la diferencia.
- Los administradores: sí. Una cuenta de administrador robada es el primer vector; eximirla equivale a no proteger nada.
- El propietario del servidor: no. Nunca. Una detección falsa no debe poder decapitar el servidor.
- Lista de confianza para los bots de tickets y de canales de voz temporales.
Qué sanción
La sanción más eficaz no es la expulsión, es la retirada inmediata de todos los roles. Corta los permisos en una sola acción, aunque la expulsión falle después por la jerarquía. La expulsión o el baneo vienen luego.
Permiso imprescindible
El bot necesita Ver el registro de auditoría. Sin él, ninguna acción destructiva es atribuible a un autor, y la protección no puede disparar nada. Es el olvido más frecuente.
La higiene que evita el incidente
La protección técnica es la segunda línea. La primera sigue siendo la higiene:
- Doble autenticación obligatoria para la moderación (Ajustes del servidor → Moderación). Un ajuste, dos clics.
- Nada de permiso Administrador para los bots. Dar exactamente lo que el bot necesita. Es la única medida que neutraliza de verdad el vector del bot comprometido.
- Limitar el número de administradores. Cada cuenta de administrador es una llave del servidor.
- Revisar los bots instalados una vez por trimestre: quitar los que ya no sirven, comprobar los permisos de los demás.
- Formar al equipo sobre el phishing: falso Nitro, falsas colaboraciones, archivos «para probar». Por ahí se filtran los tokens.
Después de un nuke
- Cortar el acceso. Quitar los roles de la cuenta culpable antes que nada — quizá siga actuando.
- Revisar los webhooks. Un atacante suele dejar alguno para volver. Ajustes del servidor → Integraciones.
- Restaurar. Una protección con restauración recrea los canales y roles borrados. Los mensajes, en cambio, se pierden: Discord no ofrece ninguna copia de seguridad.
- Revisar los baneos. Levantar en masa los dictados durante el incidente.
- Entender por dónde entró. ¿Cuenta robada? ¿Bot comprometido? Sin respuesta, el incidente se repetirá.
Preguntas frecuentes
¿Se puede deshacer un nuke?
Parcialmente. Canales y roles se recrean, pero los mensajes se pierden definitivamente — Discord no ofrece ninguna restauración. Por eso una protección debe bloquear el ataque en curso, no reparar después.
¿Hay que quitar el permiso Administrador a todos los bots?
En un mundo ideal, sí. En la práctica, algunos bots lo piden para funcionar. Si tienes que concederlo, resérvalo a los bots que conoces y activa la vigilancia de los bots para mantener una red de seguridad.
¿La doble autenticación protege del robo de token?
No, y es un malentendido extendido. Un token-grabber roba el token de sesión, que esquiva la doble autenticación. Sigue siendo imprescindible frente al robo de contraseña, pero no sustituye a una protección anti-nuke.
¿Cuánto dura un nuke?
Unos segundos. Un script borra cincuenta canales más rápido de lo que un humano lee una notificación. Por eso la respuesta debe ser automática.
Leer después : Checklist de seguridad, Proteger tu servidor de los raids, Archivos maliciosos en Discord.