Récemment, j'ai aidé plusieurs plates-formes d'échecs à renforcer leur sécurité et j'ai constaté que cette bande d'attaques CC est de plus en plus raffinée. Ne touchez pas à votre site web officiel, ne touchez pas à l'interface de paiement, concentrez-vous spécifiquement sur la salle de jeu et l'interface de connexion. La semaine dernière, un client m'a appelé à trois heures du matin pour me dire qu'au même moment, sur deux cents personnes en ligne, la charge du serveur montait directement à 90% - il s'agit manifestement d'une attaque de CC.
Les attaques de CC dans l'industrie des échecs ont depuis longtemps évolué pour atteindre le stade de la "frappe de précision". L'attaquant commence par enregistrer un compte pour découvrir la logique commerciale, l'interface pour créer une salle, l'interface pour vérifier le jeton et même l'intervalle entre les paquets de battements de cœur pour que vous puissiez les calculer clairement. J'ai attrapé quelques paquets d'attaque et j'ai constaté qu'ils simulent même le rythme de fonctionnement de vrais utilisateurs : se connecter d'abord, demander une liste de salles toutes les 30 secondes, puis entrer dans la salle à des intervalles aléatoires de quelques secondes. Ce type de trafic ne peut pas être arrêté par les pare-feu traditionnels, et chaque demande contient un cookie légitime.
Vous souvenez-vous de l'année dernière, lorsqu'une plateforme d'échecs bien connue a été attaquée à l'aide d'un marteau ? Les attaquants ont utilisé deux mille nœuds de fonction cloud pour brosser à tour de rôle l'interface de la salle, 3 000 requêtes par seconde pour paralyser le service de la salle. Le plus dommageable, c'est qu'ils ont choisi l'heure de pointe de 22 heures pour le faire, et que la rançon demandée était 30 % plus élevée que celle de leurs homologues - c'est la formation de la chaîne industrielle.
Pourquoi les CDN ordinaires à haute défense ne peuvent-ils pas se protéger contre de telles attaques ? Parce que la stratégie de protection traditionnelle dépend principalement de la fréquence des IP. Mais les gens utilisent maintenant un grand nombre d'IP proxy + des demandes à faible fréquence, chaque IP demande plus d'une douzaine de fois par minute, il semble mieux que l'utilisateur réel. J'ai testé le mode de "protection intelligente" d'un fournisseur, les gens effleurent lentement l'interface de la salle pendant une demi-heure, le CDN n'en a en fait pas arrêté un seul, mais au lieu de quelques rafraîchissements fréquents de la liste des utilisateurs réels à bloquer.
Une protection vraiment efficace commence par la dimension commerciale. Par exemple, l'interface de salle du jeu de société, la fréquence d'accès des utilisateurs normaux est plafonnée - qui peut changer dix salles en une seconde ? Mais les règles par défaut de nombreux fournisseurs de CDN ne font que limiter mécaniquement le nombre de requêtes par seconde. Plus tard, lorsque j'ai modifié le WAF de CDN07 pour mon client, j'ai directement écrit une règle personnalisée :
La signification de cet ensemble de combinaisons est la suivante : de courtes rafales de 5 requêtes sont autorisées (pour faire face aux clics rapides), mais le nombre total de requêtes par minute ne peut pas dépasser 10. En même temps, l'identification à deux facteurs "IP + ID utilisateur" empêche l'attaquant de modifier le compte en brossant la même IP. Le jour du test réel, 160 000 demandes malveillantes ont été bloquées, et le taux de blocage erroné n'a été que de 0,2%.
La protection de l'interface de connexion est encore plus mortelle. De nombreuses plateformes pensent que l'ajout d'un code de vérification est une bonne chose, mais le résultat est que les gens utilisent le code de la plateforme + des scripts pour se brosser les dents. L'année dernière, une plateforme a été victime d'une attaque. L'attaquant, qui disposait d'un dictionnaire d'un million de mots de passe, a procédé par tâtonnements, essayant chaque heure six mille fois, choisissant en particulier l'opération de trois ou quatre heures du matin. Lorsque l'équipe de sécurité l'a découvert, plus de trois cents comptes avaient déjà été piratés.
La pratique fiable consiste désormais à déployer des mécanismes de contestation dynamiques. Par exemple, le module de vérification intelligent de CDN5 déclenche une réponse à trois niveaux en cas de comportements de connexion anormaux : d'abord, il ouvre le curseur pour vérifier, puis il passe à la vérification par question calculée lorsqu'il détecte une attaque continue et, enfin, il force la vérification par SMS. La clé est que ce processus de commutation est complètement dynamique - l'attaquant ne peut tout simplement pas comprendre les règles de déclenchement. J'ai laissé l'équipe de test simuler l'attaque, le record le plus élevé a duré jusqu'à la 173e demande avant de déclencher le niveau de vérification le plus élevé, les utilisateurs normaux ne toucheront pas à la ligne de fond.
Le système de protection de 08Host est assez intéressant, il attribue des centaines de balises à chaque session utilisateur : du tracé de la souris au temps écoulé entre les requêtes, en passant par les caractéristiques de la pile TCP. J'ai une fois attrapé un groupe d'attaquants, chaque requête simulait parfaitement le navigateur Chrome, mais juste parce que le réglage initial de la taille de la fenêtre TCP et la différence réelle de Chrome de quelques octets, directement marqués comme du trafic malveillant.
L'aspect le plus dommageable des jeux de société est l'attaque des connexions TCP. Certains attaquants n'envoient pas de requêtes HTTP, ils se contentent d'établir des connexions TCP avec vous comme des fous et remplissent ensuite les ports. Pour ce scénario, vous devez limiter les connexions au niveau du CDN. Il est recommandé de diviser la stratégie par type d'entreprise :
N'oubliez pas la protection WebSocket. De nos jours, les cartes avec un peu d'envergure utilisent de longues connexions pour communiquer, et les attaquants choisissent spécifiquement le canal WebSocket pour envoyer des paquets inutiles. Un client a été piégé - l'attaquant envoie des centaines de paquets inutiles compressés par seconde, et l'unité centrale de décompression du serveur est directement saturée. Plus tard, j'ai configuré des règles spécifiques à WebSocket sur CDN07 :
Pour être honnête, on ne peut plus se contenter de la valeur de la bande passante pour choisir un CDN à haute défense. Il faut voir si l'autre partie a de l'expérience dans le domaine de la protection des échecs, les règles WAF peuvent être personnalisées, il n'y a pas d'API permettant d'ajuster dynamiquement la stratégie. Certains fournisseurs utilisent des centaines de T de bande passante de protection, le résultat est que la base de règles n'a pas été mise à jour depuis trois ans, et même les attaques d'accès non autorisé à Redis ne peuvent pas être empêchées.
Récemment, lorsque j'ai aidé des clients à effectuer une migration, j'ai comparé plusieurs fournisseurs. L'avantage de CDN5 réside dans l'algorithme de planification intelligent, qui permet de changer de ligne en quelques secondes en cas d'attaque ; le WAF de CDN07 a une forte capacité de personnalisation, même la profondeur de la détection des paramètres JSON ; la latence du réseau Anycast de 08Host est stable et rentable. En fin de compte, le client a obtenu une solution hybride : 08Host pour transporter le trafic quotidien, CDN5 pour effectuer la planification de sauvegarde de l'attaque, l'interface commerciale clé pour accrocher CDN07 WAF. Cet ensemble de combinaisons, l'augmentation du coût mensuel de moins de 20%, mais la capacité de protection de tourner plus de cinq fois.
Enfin, une leçon de larmes : ne pensez pas que vous achetez un CDN à haute défense pour être tranquille. Vérifier régulièrement la déclaration de protection est l'opération de base, le meilleur exercice hebdomadaire d'attaque et de défense. Une fois, j'ai découvert que l'ancienne interface API d'un client n'avait pas accès à la protection, l'attaquant a squatté pendant trois mois et a finalement trouvé cette faille, une nuit pour pénétrer dans le serveur. Aujourd'hui, je demande à mes clients de suivre strictement le principe "online must be protected", et toutes les nouvelles interfaces doivent subir des tests de sécurité avant d'être déployées.
La cybersécurité est aujourd'hui un jeu du chat et de la souris. Les règles déployées la semaine dernière peuvent être contournées la semaine suivante, il faut donc maintenir une mentalité de "confrontation continue". Un groupe d'attaquants a même étudié notre stratégie de protection et a utilisé un mode d'attaque bouddhiste pour vous broyer lentement - pour vous baiser pendant dix minutes toutes les heures, en choisissant le personnel de sécurité pour commencer pendant les heures de repas. Plus tard, nous avons écrit un script pour analyser automatiquement le mode d'attaque et passer directement au mode de protection lorsque nous trouvions une anomalie, ce qui nous a permis de stabiliser notre position.
Soyons honnêtes, le renforcement de la sécurité dans le secteur des échecs est un gouffre sans fond. Mais si l'on pense aux pertes et aux paiements causés par les attaques, ces investissements ne représentent vraiment rien. L'année dernière, une plateforme a été victime de trois jours d'indisponibilité à la suite d'un recours collectif des joueurs, et les indemnités versées ont suffi à acheter cinq années de services de défense de haut niveau. Aujourd'hui, les clients ont appris à être intelligents, le budget de la sécurité est passé de "poste de coût" à "poste d'assurance", ce qui est un bon indicateur des progrès de l'industrie.
(A la demande du client, une partie des détails techniques a été traitée de manière floue, la configuration spécifique, veuillez l'ajuster en fonction de l'activité réelle).
