Guide · 28 juillet 2026 · 9 min de lecture

Anti-nuke Discord : empêcher la destruction de son serveur

Un nuke ne vient pas de l'extérieur : il vient d'un compte à qui vous avez donné les clés. Ce guide explique comment ces attaques se produisent, pourquoi les permissions ne suffisent pas, et comment configurer une protection qui tient.

Nuke et raid : deux attaques différentes

Un nuke est la destruction d'un serveur Discord depuis l'intérieur : suppression de tous les salons et de tous les rôles, bannissement massif des membres, parfois création de centaines de salons de spam pour rendre le serveur inutilisable.

La différence avec un raid est essentielle :

Un anti-raid ne protège pas d'un nuke, et inversement. Les deux sont nécessaires.

Les trois façons dont ça arrive

1. Un compte administrateur volé

Le plus fréquent. Un membre de l'équipe clique sur un faux lien Nitro, télécharge un « jeu d'un ami » qui contient un token-grabber, ou se fait avoir par une fausse page de connexion. L'attaquant récupère le jeton de session et agit sous son identité — sans mot de passe, sans double authentification à franchir.

2. Un bot compromis

Beaucoup de serveurs ajoutent des bots avec la permission Administrateur pour ne pas se poser de questions. Si le jeton de ce bot fuite (dépôt public, hébergeur mal configuré, développeur piraté), l'attaquant dispose d'un outil de destruction déjà installé et déjà autorisé.

3. Un membre de l'équipe qui dérape

Plus rare, mais réel : un modérateur écarté, un désaccord qui tourne mal. La protection est la même, ce qui est plutôt rassurant : elle ne demande pas de faire des procès d'intention.

Pourquoi les permissions ne suffisent pas

Le réflexe naturel est de restreindre les permissions. C'est nécessaire, mais insuffisant, pour une raison simple :

Les permissions Discord déterminent qui peut agir. Elles ne disent rien de combien ni à quelle vitesse.

Un administrateur légitime a besoin de pouvoir supprimer un salon. Le même administrateur peut en supprimer cinquante en dix secondes, et aucune permission ne s'y oppose. C'est précisément là que se situe l'angle mort.

La protection doit donc porter sur le rythme et le volume des actions, pas sur le droit de les faire.

Le principe d'une détection qui marche

Une protection anti-nuke sérieuse compte les actions destructrices par auteur, dans une fenêtre de temps glissante. Concrètement : « ce compte a supprimé 6 salons en 3 secondes ».

Les actions à surveiller sont toujours les mêmes :

• Suppression de salons et de rôles
• Création massive de salons ou de rôles (spam)
• Bannissements et expulsions en série
• Création de webhooks (exfiltration, puis spam)
• Attribution soudaine de permissions sensibles
• Modification du serveur (nom, image, URL personnalisée)

Distinguer le ménage du sabotage

Le vrai défi n'est pas de détecter, c'est de ne pas sanctionner un administrateur qui range son serveur. Un seuil brut ne suffit pas : réorganiser des catégories peut légitimement supprimer une dizaine de salons.

Le signal le plus fiable pour trancher est la régularité des intervalles. Un script agit à cadence quasi constante — quelques dizaines de millisecondes entre chaque action, toujours les mêmes. Un humain qui clique dans l'interface est irrégulier : il hésite, confirme, se déplace dans le menu.

À cela s'ajoutent l'ancienneté du compte sur le serveur, sa nature (humain ou bot), l'heure, et ses antécédents. Une protection qui combine ces signaux déclenche avant le seuil quand la signature est machinale, et reste silencieuse sur un vrai ménage.

Le point aveugle : les bots

Voici le problème le moins connu, et le plus grave. La plupart des protections anti-nuke exemptent les bots par principe — souvent avec une simple condition du type « si l'auteur est un bot, ne rien faire ».

L'intention est compréhensible : éviter que le bot de tickets, qui crée et supprime des salons toute la journée, ne déclenche des alertes en permanence. Mais la conséquence est qu'un bot compromis est totalement intouchable, alors que c'est l'un des principaux vecteurs de nuke.

La bonne approche consiste à surveiller les bots, et à traiter les faux positifs autrement :

• Une liste de comptes de confiance pour les bots légitimes qui manipulent des salons en continu.
• Des seuils par type d'action : un bot de tickets crée des salons, il n'en supprime pas quarante d'un coup.
• Une sanction adaptée : retirer les rôles d'un bot coupe ses permissions immédiatement, même si l'expulsion échoue.

Configurer sa protection

Avec OriusBot, via /anti-raid puis la page Anti-nuke intelligent.

Seuils de départ

Valeurs raisonnables pour un serveur de taille moyenne, à ajuster ensuite :

Qui surveiller

• Les bots : oui. C'est le point qui fait la différence.
• Les administrateurs : oui. Un compte administrateur volé est le premier vecteur ; l'exempter revient à ne protéger de rien.
• Le propriétaire du serveur : non. Jamais. Une fausse détection ne doit pas pouvoir décapiter le serveur.
• Liste de confiance pour les bots de tickets et de salons vocaux temporaires.

Quelle sanction

La sanction la plus efficace n'est pas l'expulsion, c'est le retrait immédiat de tous les rôles. Elle coupe les permissions en une action, même si l'expulsion échoue ensuite pour cause de hiérarchie. L'expulsion ou le bannissement viennent après.

Permission indispensable

Le bot a besoin de Voir les logs d'audit. Sans elle, aucune action destructrice n'est attribuable à un auteur, et la protection ne peut rien déclencher. C'est l'oubli le plus fréquent.

L'hygiène qui évite l'incident

La protection technique est la seconde ligne. La première reste l'hygiène :

• Double authentification obligatoire pour la modération (Paramètres du serveur → Modération). Un réglage, deux clics.
• Pas de permission Administrateur aux bots. Donner exactement ce dont le bot a besoin. C'est la seule mesure qui neutralise vraiment le vecteur du bot compromis.
• Limiter le nombre d'administrateurs. Chaque compte administrateur est une clé du serveur.
• Revoir les bots installés une fois par trimestre : retirer ceux qui ne servent plus, vérifier les permissions des autres.
• Former l'équipe au phishing : faux Nitro, faux partenariats, fichiers « à tester ». C'est par là que les jetons fuient.

Après un nuke

1. Couper l'accès. Retirer les rôles du compte fautif avant toute chose — il agit peut-être encore.
2. Vérifier les webhooks. Un attaquant en laisse souvent pour revenir. Paramètres du serveur → Intégrations.
3. Restaurer. Une protection avec restauration recrée les salons et rôles supprimés. Les messages, eux, sont perdus : Discord ne propose aucune sauvegarde.
4. Vérifier les bannissements. Lever en masse ceux prononcés pendant l'incident.
5. Comprendre l'entrée. Compte volé ? Bot compromis ? Sans réponse, l'incident se reproduira.

Questions fréquentes

Un nuke peut-il être annulé ?

Partiellement. Salons et rôles se recréent, mais les messages sont définitivement perdus — Discord ne propose aucune restauration. C'est pourquoi une protection doit bloquer l'attaque en cours, pas réparer après coup.

Faut-il retirer la permission Administrateur à tous les bots ?

Dans l'idéal, oui. En pratique, certains bots la demandent pour fonctionner. Si vous devez l'accorder, réservez-la aux bots que vous connaissez, et activez la surveillance des bots pour garder un filet de sécurité.

La double authentification protège-t-elle du vol de jeton ?

Non, et c'est un malentendu répandu. Un token-grabber vole le jeton de session, qui contourne la double authentification. Elle reste indispensable contre le vol de mot de passe, mais ne dispense pas d'une protection anti-nuke.

Combien de temps dure un nuke ?

Quelques secondes. Un script supprime cinquante salons plus vite qu'un humain ne lit une notification. C'est la raison pour laquelle la réponse doit être automatique.

À lire ensuite : La checklist complète de sécurisation · Protéger son serveur des raids · Fichiers malveillants et token grabbers · Quel bot de sécurité choisir