Anti-DDoS Game : la protection qui déjoue les attaques propres à l’univers du jeu en ligne

Temps de lecture estimé : 12 minute(s)

*Attention, ce contenu a été publié il y a 3 années. Il n'est peut-être plus d'actualité.*

Réaliser une attaque par déni de service (DDoS) est aujourd’hui d’une simplicité déconcertante. Il n’est plus nécessaire de posséder un niveau technique avancé et des moyens importants pour rendre instable voire indisponible un service. Les protections anti-DDoS telles que celles développées par OVH dès 2013 permettent de limiter la portée de ces actes malveillants, en forte recrudescence (+ 80 % d’attaques comptabilisées par OVH entre 2013 et 2014). Toutefois, le secteur du game et des e-sports est particulièrement touché par le phénomène, et les protections mises en œuvre par les hébergeurs montrent souvent leurs limites face à l’intensité et à la fréquence de ces attaques, en particulier celles qui exploitent le fonctionnement en mode « non connecté » du protocole UDP, un protocole réseau utilisé par beaucoup de jeux et serveurs vocaux. C’est pourquoi OVH a développé une protection anti-DDoS spécifiquement adaptée à l’univers du gaming. Explications avec Clément Sciascia, développeur en charge du projet chez OVH.

Un boîtier Tilera situé au plus près de la machine analyse les paquets. Un traitement spécifique à chaque jeu hébergé est appliqué pour la protection anti-DDoS..

Pourquoi les attaques visant les serveurs de gaming constituent-elles un problème spécifique ?

Tout d’abord, les attaques qui visent les serveurs de jeux sont plus fréquentes. Un joueur mécontent, un adolescent qui se prend pour un hacker ou joue au maître chanteur, un concurrent peu scrupuleux… les prétextes des attaques sont nombreux, et souvent futiles. Si les attaques se multiplient, c’est qu’elles deviennent de plus en plus simples à réaliser. Des tutoriels et des scripts sont facilement accessibles sur Internet, et pour quelques euros on peut louer une petite armée de serveurs cloud pour bombarder un serveur de requêtes. Ce que proposent certains sites s’apparente à fournir du « DDoS as a Service ». Ils prétendent commercialiser un service de test de montée en charge, mais beaucoup ont compris l’usage détourné que l’on peut en avoir.
Par ailleurs, les serveurs de jeux (ou hébergeant des serveurs vocaux) sont particulièrement sensibles : le moindre lag, engendré par une surcharge du serveur ou une saturation de la bande passante, est ressenti par les joueurs. La partie est ralentie ou, lorsqu’il s’agit d’un serveur vocal, les conversations sont hachées ou tout simplement perdues.
Or, le VAC , exploité pour l’anti-DDoS « classique », fonctionne en trois temps : l’analyse des paquets, l’aspiration du trafic entrant en cas d’attaque, puis la mitigation (filtrage des paquets non légitimes). Cela signifie que l’aspiration s’active avec un léger différé par rapport au début de l’attaque. On parle de quelques secondes seulement, qui se traduisent par des ralentissements à peine perceptibles sur une application ordinaire, mais qui, sur un serveur de jeu, occasionnent des perturbations assez significatives pour les joueurs.
De plus, de nombreux jeux et services de communication vocale tels que TeamSpeak ou Mumble (que les joueurs d’une même équipe utilisent pour se parler durant une partie) exploitent le protocole de communication UDP. Le principal intérêt de ce protocole, également utilisé par les services de streaming, est la rapidité avec laquelle on peut transmettre de petits paquets de données, tout en consommant peu de ressources. La contrepartie, c’est que l’UDP, à l’inverse du TCP, fonctionne sans négociation. Il n’y a pas d’autorisation préalable (handshake) à l’envoi des paquets de la part des machines qui discutent entre elles. L’autorisation de connexion accordée à un joueur rejoignant une partie est gérée côté applicatif (couche L7), en conséquence de quoi il est a priori difficile de distinguer un paquet envoyé par une adresse IP autorisée, d’un paquet envoyé par une adresse IP spoofée.
Autrement dit, la mitigation est complexe puisque les paquets illégitimes ont, en apparence, les mêmes caractéristiques que des paquets légitimes. Un exemple : dans le cas de l’attaque dite « Source Engine Query » visant les serveurs Counter Strike: Source, l’attaque consiste à surcharger le serveur de requêtes Query, dont le but est de récupérer des informations sur l’état du serveur. Si l’on filtre ce type de paquets sans discernement, les joueurs (les vrais !) ne peuvent plus voir le serveur et recevoir ses informations.
Le VAC, qui gère avec efficacité une grande variété d’attaques, rencontre plus de difficultés face à ce type d’attaque. C’est pourquoi il fallait innover. Par exemple en intervenant, aussi, au niveau du trafic sortant des machines : dans le cas de l’attaque « Source Engine Query », la parade consiste en effet à conserver en cache la réponse du serveur, pour répondre à sa place en cas de flood, de sorte à ce que les requêtes illégitimes ne parviennent pas à épuiser les ressources du serveur.

Justement, en quoi la protection anti-DDoS Game diffère-t-elle de la protection anti-DDoS classique ? Quels mécanismes avez-vous mis en place, et comment en êtes-vous arrivés là ?

La première étape de notre travail, qui a duré au total plus de six mois, fut d’établir une liste de jeux et services de communication vocale selon deux critères : leur succès commercial et leur capacité à « attirer » les attaques DDoS — comme nous l’a expliqué VeryGames, l’un de nos clients spécialisés dans l’hébergement de services liés aux jeux vidéo, il y a des jeux populaires mais très peu attaqués, Farming Simulator par exemple, dont les joueurs sont en moyenne plus âgés que ceux de Minecraft. Au sein de notre laboratoire, nous avons installé cette sélection de jeux sur des laptops et nous nous sommes connectés à des serveurs pour analyser les trames réseau. Ceci nous a permis d’envisager les différentes stratégies d’attaque possibles pour chaque jeu. Dans un premier temps, il était plus simple pour nous de faire du reverse engineering que de prendre contact avec les éditeurs de jeux un par un. Pour l’amateur de jeux en ligne que je suis, ce fut un peu frustrant : pas question de se lancer dans des grandes parties sous couvert de R&D, ce qui nous intéressait se situe essentiellement dans la phase de connexion entre le poste du joueur et le serveur, car c’est à ce niveau que les attaques doivent être détectées et traitées.
Ensuite, nous avons imaginé une infrastructure complémentaire à celle de l’anti-DDoS « classique » (le VAC), qui nous permet d’analyser le trafic entrant, mais aussi de garder un œil sur le trafic sortant (ce qui n’est pas le cas du VAC). La mitigation est donc bidirectionnelle (en entrée et en sortie) et, autre différence, elle est constamment active, ceci pour être en capacité de réagir dès le premier paquet d’une attaque. Le but étant que le serveur reste « jouable » pendant toute la durée du DDoS, et même mieux, que les joueurs ne se rendent compte de rien.

Un boîtier Tilera situé au plus près de la machine analyse les paquets. Un traitement spécifique à chaque jeu hébergé est appliqué.

Concrètement, comme on peut le voir sur le schéma, c’est un boîtier Tilera, situé au plus près de la machine, qui inspecte les paquets TCP/IP et UDP, déclenche la mitigation et peut faire office de cache pour alléger la charge de la machine attaquée lorsqu’il est difficile de filtrer les paquets illégitimes des paquets légitimes. Dans le cas d’attaques « classiques », c’est-à-dire que le VAC sait parfaitement mitiger, le boîtier Tilera assure la protection simplement le temps que le VAC s’active et prenne le relais. De plus, le boîtier Tilera étant situé au plus près du serveur (au même niveau que les switches), la protection est efficace même lorsque l’attaque provient du réseau OVH lui-même. La mitigation filtre alors l’attaque le temps que les machines à l’origine de l’attaque situées chez OVH soient identifiées et suspendues.
Le matériel Tilera a été choisi pour sa puissance de calcul, étant donné la charge à laquelle il est confronté : plusieurs millions de paquets par seconde, passés au crible d’algorithmes particulièrement complexes, le tout à très haut débit. La différence avec la solution Arbor, à laquelle Tilera est couplée au sein du VAC, est que Tilera est un matériel livré sans le software : l’analyse logique du trafic est à développer intégralement. L’implémentation de ce code de mitigation (des algorithmes) s’est basé sur les informations collectées lors de la phase de reverse engineering. Il était impossible de concevoir un code de mitigation universel. Pour chaque grande famille de jeux (Counter Strike, Minecraft…), nous avons développé un « profil », soit un ensemble de règles prédéfinies que l’utilisateur déploie en un clic sur le boîtier Tilera (via son espace client) pour filtrer avec le plus d’exactitude possible le trafic illégitime entrant et sortant de son serveur.

Pour chaque grande famille de jeux (Counter Strike, Minecraft…), nous avons développé un « profil », que l’utilisateur déploie en un clic sur le boîtier Tilera pour filtrer avec le plus d’exactitude possible le trafic illégitime entrant et sortant de son serveur.

Cette protection est-elle unique en son genre ? À quels résultats êtes-vous parvenus ?

Une fois la solution déployée, nous l’avons testée. D’abord en interne, puis dans le cadre d’un bêta test ouvert au public, durant lequel une cinquantaine de machines pouvaient être louées pour une durée maximale de quinze jours. Le but était alors de multiplier les jeux testés, pour éprouver l’efficacité de l’anti-DDoS, en repérer les faiblesses et corriger les algorithmes pour éradiquer les faux positifs. Nous nous sommes ainsi aperçus que Counter Strike: Global Offensive avait un protocole de connexion qui varie en fonction de la méthode de connexion utilisée par le joueur (via un explorateur, en rejoignant un ami, en connexion directe…). Le casse-tête !
En juin 2015 nous sommes arrivés à un résultat satisfaisant, nous permettant d’envisager sereinement la mise sur le marché de serveurs Game incluant cette protection.
Pour autant, notre travail ne s’est pas arrêté là. Nous avons toujours un œil rivé sur les attaques, et nous étudions avec beaucoup d’attention celles que nous n’avions pas répertoriées jusqu’ici. Certaines sont le fruit d’une mauvaise configuration du serveur par l’administrateur. Les autres nous permettent d’optimiser encore la protection proposée, en intégrant la parade à nos algorithmes. Il faut de toute façon rester modeste : nous jouons au chat et à la souris avec ceux qui lancent les attaques – ou plutôt ceux, moins nombreux heureusement, qui tentent de passer à travers notre protection, procédant par tests successifs pour mettre au point de nouveaux procédés d’attaques. Nous ne trouverons jamais une parade intemporelle. L’important est de toujours conserver une longueur d’avance suffisante pour anticiper les stratégies d’attaques de demain. Pour cette raison, il serait contre-productif d’en dévoiler davantage sur le fonctionnement de nos algorithmes. Et, par ailleurs, les jeux sont régulièrement mis à jour, aussi nous devons actualiser nos « profils » en conséquence.
Sommes-nous les seuls à proposer une protection anti-DDoS Game efficace ? Aujourd’hui, peu d’hébergeurs en effet proposent une telle protection. Néanmoins, elle n’est pas impossible à copier : cela coûte de l’argent, du matériel et du temps humain. Cela nécessite un certain savoir-faire, et probablement d’être reconnu comme un acteur crédible sur le marché de l’hébergement de serveurs de jeux, pour coopérer à l’avenir davantage avec les éditeurs de jeux. En revanche, OVH a un argument tout à fait différenciant : la capacité excédentaire de bande passante sur son réseau backbone (environ 3 Tbps de plus que l’usage courant de l’ensemble des clients d’OVH réunis, sur un total de 4 Tbps).
Car les protections les plus perfectionnées ne pourront jamais garantir la disponibilité des serveurs si les attaques parviennent à saturer les liens réseau en amont des équipements de mitigation. Et c’est probablement la raison pour laquelle les éditeurs qui exploitent leur propre plateforme rencontreront à l’avenir encore davantage de difficultés. L’intensité maximale des attaques augmente (plusieurs centaines de Gbps actuellement, et plusieurs dizaines de millions de paquets par seconde), ce qui a deux conséquences pour les opérateurs dont le réseau n’est pas dimensionné pour absorber ce volume de trafic : saturation de leur backbone et interruption de service pour l’ensemble de leurs clients, et/ ou conséquences financières non négligeables (frais de transit à régler pour le trafic excédentaire).

Les recherches menées dans le cadre du développement de l’anti-DDoS Game vont-elles bénéficier à d’autres services d’OVH, d’autres secteurs d’activité que le jeu en ligne ? Cela va-t-il conduire à une amélioration de l’anti-DDoS « classique » (VAC) ?

Cela n’a pas de sens d’observer le trafic sortant des 200 000 serveurs hébergés chez OVH. Le VAC fonctionne très bien sur une large majorité des attaques. Mais on pourrait effectivement imaginer d’autres applications à la protection que nous avons déployée spécifiquement pour les serveurs Game. Par exemple dans le but d’améliorer la protection des serveurs VoIP, qui utilisent eux aussi le protocole UDP et sont donc exposés aux mêmes risques que beaucoup de serveurs de jeux. Ou encore pour protéger des serveurs SQL, dont certains exploitent également ce protocole non-connecté (MSSQL notamment). De la même façon, si l’on imagine une option anti-DDoS Pro bidirectionnelle, des services tels que le streaming vidéo ou musical pourraient se montrer intéressés.
Enfin, l’évolution envisagée à plus long terme est la fusion de l’anti-DDoS et du routage au sein du vRouter (en projet), ceci pour simplifier l’architecture du réseau OVH, assurer une meilleure maîtrise du dispositif et une traçabilité complète. Une évolution qui nécessitera un changement de technologie puisqu’il faut être compatible avec du x86, ce qui n’est pas possible avec Tilera.

UPDATE (13.04.2016) : Nos développeurs ont récemment étendu la protection de l’Anti-DDoS Game au jeu Rust, développé par Facepunch Studio. Celui-ci vient s’ajouter à Minecraft, Team Fortress 2 et Counter Strike, déjà supportés auparavant.

Copywriter at OVH.