Protection contre le flood et les raids

Introduction

La protection contre le flood et les raids protège un groupe contre deux problèmes liés : un membre isolé qui publie des messages plus vite que quiconque ne peut les lire, et une vague coordonnée de comptes qui rejoignent le groupe en même temps pour submerger la discussion. Les deux sont gérés automatiquement, mais seulement après leur activation par un administrateur. Toutes les fonctionnalités décrites ici sont désactivées par défaut et n’effectuent aucune action tant qu’elles ne sont pas activées pour le groupe ; ainsi, l’ajout du bot ne change jamais le comportement de votre discussion tant que vous ne l’avez pas décidé.

Les deux systèmes interviennent à des moments différents. L’anti-flood surveille les membres individuellement lorsqu’ils publient. L’anti-raid surveille le rythme auquel les nouveaux membres rejoignent le groupe. Avec la commande manuelle /panic et la vérification des abuseurs connus à l’arrivée, ils donnent aux administrateurs les moyens de garder un groupe lisible pendant une vague de spam et de fermer les portes lors d’une attaque coordonnée.

Anti-flood : fréquence des messages

L’anti-flood limite le nombre de messages qu’un même membre non administrateur peut envoyer sur une courte période. Il est contrôlé par trois paramètres dans le tableau de bord du groupe :

• set_antiflood_enabled — l’interrupteur d’activation/désactivation. Désactivé par défaut.
• set_antiflood_msgs — la limite de messages. Par défaut : 8.
• set_antiflood_secs — la durée de la fenêtre, en secondes. Par défaut : 5.

Avec les valeurs par défaut, un membre qui envoie plus de 8 messages dans une fenêtre de 5 secondes dépasse la limite. Le bot compte les messages de chaque membre dans une courte fenêtre glissante ; lorsque le compteur dépasse la limite, les messages qui composent la rafale sont supprimés et l’application de la sanction commence.

La sanction est progressive. La première fois qu’un membre fait du flood, le bot applique un mute temporaire de 5 minutes. Si le même membre recommence peu après, le bot le bannit à la place. Ainsi, un accident isolé ne coûte qu’un court mute, tandis qu’un membre qui continue à flooder est retiré du groupe.

Deux règles garantissent un fonctionnement équitable et sûr :

• Les administrateurs sont exemptés. La vérification de fréquence ne s’applique qu’aux membres non administrateurs ; les modérateurs et administrateurs ne sont donc jamais mutés ni bannis par l’anti-flood.
• En cas d’erreur, il laisse passer. Le compteur s’appuie sur un stockage rapide en mémoire. Si ce stockage renvoie une erreur transitoire, le bot laisse passer le message au lieu de le sanctionner. Un problème temporaire d’infrastructure ne provoque jamais un mute ou un bannissement injuste.

L’anti-flood s’exécute sur le chemin critique de chaque message : il réagit donc dès l’arrivée des messages, avant les vérifications de contenu plus lourdes. Comme le seuil et la fenêtre sont configurables, vous pouvez l’adapter au rythme normal de votre groupe — une discussion très active pourra nécessiter une limite de messages plus élevée, tandis qu’un canal d’annonces calme pourra préférer un réglage plus strict.

Anti-raid : verrouillage en cas d’afflux d’arrivées

L’anti-raid surveille la vitesse à laquelle les nouveaux membres rejoignent le groupe. Il est contrôlé par quatre paramètres :

• set_antiraid_enabled — l’interrupteur d’activation/désactivation. Désactivé par défaut.
• set_antiraid_joins — la limite d’arrivées. Par défaut : 10.
• set_antiraid_secs — la fenêtre, en secondes. Par défaut : 30.
• set_antiraid_lockdown_secs — la durée du verrouillage. Par défaut : 600 secondes (10 minutes).

Avec les valeurs par défaut, plus de 10 membres qui rejoignent le groupe en 30 secondes déclenchent un verrouillage. Lorsque cela se produit, le bot verrouille tout le groupe en supprimant les permissions de discussion par défaut, afin que les membres ne puissent plus publier. Le verrouillage reste en place pendant la durée configurée, puis se lève automatiquement en rétablissant les permissions normales du groupe.

Le verrouillage est une pause, pas une purge. Il empêche la vague de nouveaux comptes de publier pendant l’afflux, ce qui donne aux administrateurs le temps de comprendre ce qui se passe. Une fois le délai écoulé, le groupe rouvre de lui-même. Comme l’anti-flood, le compteur d’arrivées laisse passer en cas d’erreur : une erreur transitoire pendant le comptage des arrivées ne déclenche jamais un verrouillage par erreur.

Verrouillage manuel : /panic et /unpanic

Les administrateurs peuvent verrouiller un groupe manuellement à tout moment, même lorsque la détection automatique des raids est désactivée :

• /panic — verrouille immédiatement le groupe pour la durée de verrouillage configurée. Les membres ne peuvent plus publier jusqu’à la levée automatique du verrouillage ou jusqu’à ce qu’un administrateur le lève.
• /unpanic — lève le verrouillage plus tôt et permet aux membres de publier à nouveau.

Les deux commandes sont réservées aux administrateurs ; un non-administrateur qui les exécute se verra refuser l’action. /panic est utile lorsque vous voyez des problèmes commencer et souhaitez fermer le groupe avant que le seuil automatique ne soit atteint, ou lorsque vous avez laissé la détection automatique désactivée mais voulez tout de même disposer d’un arrêt d’urgence en une seule commande.

Expulser les abuseurs connus à l’arrivée

Le paramètre set_kick_known_abusers (désactivé par défaut) vérifie chaque nouveau membre par rapport au signal partagé de renseignement utilisateur du réseau. Les comptes qui ont déjà été signalés ailleurs sur le réseau comme abuseurs connus portent un marqueur global. Lorsque ce paramètre est activé et qu’un compte marqué rejoint le groupe, le bot le bannit immédiatement, avant qu’il puisse publier.

Cette vérification laisse également passer en cas d’erreur : si la recherche d’abuseur échoue, le bot considère le nouvel arrivant comme légitime et le laisse entrer, afin qu’un problème de recherche ne bannisse jamais un membre légitime. Lorsqu’un abuseur connu est banni de cette manière, l’événement est enregistré dans le journal de modération du groupe si celui-ci est configuré.

Coordination du verrouillage avec le mode nuit

L’anti-raid et le mode nuit fonctionnent tous deux en verrouillant les permissions d’envoi du groupe ; ils partagent donc le même verrou sous-jacent. Les deux fonctionnalités se coordonnent afin que l’une ne rouvre jamais le groupe tant que l’autre souhaite encore le garder fermé. Si un verrouillage anti-raid se termine alors que la période silencieuse du mode nuit est encore active, le groupe reste verrouillé pour le mode nuit ; si la fenêtre du mode nuit se termine alors qu’un verrouillage anti-raid est encore en cours, le groupe reste verrouillé pour le raid. Le groupe ne rouvre que lorsque plus aucune de ces fonctionnalités n’a besoin qu’il soit fermé.

Bonnes pratiques

• Commencez avec les seuils par défaut et ne les ajustez que si vous constatez de faux déclenchements ou des détections manquées. Les valeurs par défaut conviennent à la plupart des groupes.
• Gardez /panic en tête comme solution manuelle de secours même si vous activez la détection automatique des raids : c’est le moyen le plus rapide de figer un groupe.
• Activez la vérification des abuseurs connus pour les groupes publics que tout le monde peut rejoindre ; elle bloque les récidivistes avant qu’ils ne publient.
• N’oubliez pas que les administrateurs ne sont jamais affectés par l’anti-flood ; testez donc la fonctionnalité avec un compte non administrateur si vous voulez la voir en action.

Résumé

La protection contre le flood et les raids donne aux administrateurs un contrôle par couches : l’anti-flood gère un membre isolé trop bruyant avec une suppression, un mute, puis un bannissement ; l’anti-raid gère un afflux d’arrivées avec un verrouillage temporaire du groupe ; /panic fournit une commande de reprise en main manuelle ; et la vérification des abuseurs connus bloque les comptes signalés dès l’entrée. Tout reste désactivé tant que vous ne l’activez pas, les administrateurs sont exemptés lorsque c’est pertinent, et les vérifications automatiques laissent passer en cas d’erreur afin qu’un problème temporaire ne sanctionne jamais un membre innocent.