Prévenir la latence artificielle ou "Lag Hacking" dans les jeux multijoueurs
Il y a une attaque que certaines personnes ont surnommée "piratage de décalage", et sa popularité gagne dans les jeux multijoueurs. Il existe au moins deux façons de créer latence artificielle . Une méthode pour introduire une latence artificielle consiste à utiliser un décalage de décalage , où l'utilisateur déconnecte intentionnellement son câble réseau. Une autre méthode consiste à utiliser un flot de paquets syn ou udp pour provoquer une interruption contrôlée et prévisible du jeu afin qu'un joueur puisse obtenir un avantage injuste. Attaques par latence artificielle affectent un grand nombre de jeux multijoueurs .
Certaines sociétés de jeux ont été informées de cette attaque par leurs utilisateurs, mais ignorent cette vulnérabilité car elles n'ont pas de solution . Les outils pour effectuer cette attaque sont simples à construire, facilement disponibles et faciles à utiliser . Ils usurpent souvent l'adresse IP source pour rendre l'attaque difficile à retracer.
Donc security.se, permet de trouver une solution à ce problème. Mais d'abord, parlons un peu des protocoles de jeu. Les jeux en ligne utilisent généralement UDP en raison d'une diminution de la latence et des frais généraux, mais cela augmente également la sensibilité à l'usurpation d'identité. Les protocoles de jeu peuvent utiliser Latency Hiding pour diminuer la "latence perçue", mais cela peut augmenter l'impact du décalage artificiel. Les jeux multijoueurs utilisent souvent une architecture p2p, par exemple Hydra: architecture Peer-to-Peer pour les jeux , et un pair est facile à inonder. L'architecture réseau Unreal est bien documentée et est également vulnérable à cette attaque . (S'il y a une autre ressource que je devrais énumérer, faites-le moi savoir!)
Je vois deux voies conceptuelles pour gérer les attaques de décalage:
Punir les retards . Lorsqu'un décalage "artificiel" est détecté, expulser le contrevenant et imposer une période d'interdiction. C'est difficile à faire dans la pratique car il y a un équilibre délicat à trouver entre les personnes qui trichent par retard et les personnes qui souffrent simplement d'un hoquet occasionnel dans leur connexion Internet. C'est une mauvaise pratique commerciale de frapper vos propres clients. De tels types de solutions aboutiront nécessairement à un seuil pour distinguer les mauvaises personnes des malchanceux. Les tricheurs resteront près du seuil et cela sera probablement suffisant pour obtenir un avantage stratégique.
Une approche prometteuse le long de la ligne de punition consiste à appliquer des pénalités petites mais cumulatives pour chaque décalage: chaque fois qu'un paquet est perdu ou apparaît en retard, supprimez un point de vie, faites clignoter le joueur, peu importe ... cela peut même être intégré dans le jeu univers (par exemple, pour un FPS convertir le décalage détecté en bourrage de fusil). Cela implique que les personnes disposant de connexions Internet fiables et de gros ordinateurs seront avantagées - et je pense que les joueurs sont prêts à accepter cela, étant donné que des choses similaires se produisent dans de nombreuses autres situations de compétition de loisirs (par exemple, si votre passe-temps est le skateboard, vous savez qu'un meilleur skateboard ne remplacera pas le talent, mais aidera néanmoins, et le skateboard l'accepte comme une réalité). En fin de compte, cela pourrait inciter les FAI à travailler un peu sur leur latence, ce qui serait bon pour tout le monde, pas seulement pour les joueurs.
Ne faites pas confiance aux clients . Les jeux massivement en ligne sont informatique distribuée . La plupart de leurs problèmes de sécurité sont dus au fait que de nombreuses règles de jeu, c'est-à-dire les propriétés du monde dans lequel les joueurs agissent, sont maintenues par les systèmes clients. Les joueurs eux-mêmes, et en particulier les tricheurs potentiels, ont un contrôle étendu de leurs machines. Existant contre-mesures ont tendance à avoir une efficacité limitée pour les mêmes raisons que les logiciels DRM et antivirus peuvent échouer: il s'agit d'une course aux armements dans laquelle les attaquants et les défenseurs sont enfermés dans une bataille rapide de correctifs et de contre-patches qui est fastidieux et nécessite un entretien coûteux et continu.
La réponse architecturale générique consiste à maintenir les règles du jeu côté serveur uniquement; les clients deviennent "légers" et ne sont que des interfaces d'affichage. Ceci est malheureusement difficile à mettre en œuvre, car les performances d'affichage (donc l'expérience de jeu) deviennent très sensibles à la latence, artificielle et naturelle; et liens ADSL aura une latence minimale proche de 50 ms, ce qui est élevé en ce qui concerne les réflexes gamer moyens. En outre, cela signifie que le jeu - serveurs a besoin de plus de muscle CPU. Mais l'avantage en matière de sécurité est énorme: lorsqu'un joueur induit un retard, il se punit intrinsèquement et nul autre.
Le maintien de tous les états et règles du jeu sur les serveurs n'est pas non plus complètement de la science-fiction. À la fin des années 1980, l'un des tout premiers MMO jeux était "CarCrash", une progéniture du défunt magazine français Jeux et Stratégie ; il a été joué sur le Minitel , une autre ancienne technologie française où les utilisateurs avaient simplement des terminaux de texte (avec des graphiques limités) sans capacités informatiques locales; le ou les serveurs centraux ont maintenu les règles du jeu et calculé les mises à jour d'écran pour tout le monde, et cela a fonctionné. À cette époque, les ordinateurs avaient beaucoup moins de muscle CPU qu'aujourd'hui; un processeur de 20 MHz suffisait pour être considéré comme un "supercalculateur". Un routeur domestique à 35 $ de 2013 est plus de dix fois plus puissant qu'un gros serveur de cette époque. Et pourtant, cela a fonctionné.
Le maintien des règles de jeu sur le serveur implique de s'écarter de la façon dont les jeux sont généralement architecturés. Historiquement, la plupart des jeux étaient locaux et sont devenus multijoueurs en connectant les clients entre eux, avec éventuellement un serveur central qui ne servait que de point de rendez-vous. Pour prendre une métaphore politique, les jeux sont devenus multijoueurs en formant confédérations , mais la sécurité contre les tricheurs nécessite un fédération .
Des stratégies mixtes sont possibles, bien sûr. L'idée centrale est la même: donner le moins de données sensibles possible aux systèmes clients; et quand vous devez leur faire confiance pour quelque chose, utilisez un gros bâton ou une grosse carotte pour les maintenir en ligne .
(Si vous comprenez que les joueurs doivent être manipulés comme des troupeaux de bovins, eh bien, ... il y a du vrai là-dedans, en effet. Vous ne voulez pas que vos vaches soient malheureuses, mais vous ne les laisserez pas non plus choisir leur direction et leur rythme de marche .)
Edit: vient d'avoir un aperçu en attendant que mon thé refroidisse un peu. Une architecture de jeu pourrait inclure plusieurs (peut-être des dizaines) de serveurs "de confiance" coopérants répartis dans le monde entier, qui "jouent le jeu" comme les clients de jeux le font aujourd'hui. Chaque joueur se connecterait à un serveur qui est "à proximité" (dans un sens réseau) afin d'avoir une faible latence, permettant la stratégie d'affichage uniquement décrite ci-dessus. Si les FAI eux-mêmes peuvent être impliqués dans l'accord (chaque FAI hébergerait quelques serveurs dans sa propre infrastructure), cela pourrait avoir un sens sur le plan commercial.
Avec la langue seulement en partie dans la joue, je vais suggérer que Xbox Live dispose déjà de contrôles pour limiter les dommages causés par les commutateurs de décalage. Je vais canaliser mon Schneier intérieur et dire que là où les contrôles techniques peuvent être problématiques à mettre en œuvre, les contrôles réactifs et sociétaux sont des options parfaitement valables:
- Marquez le joueur sur "Éviter" - il est peu probable que vous vous retrouviez à nouveau avec lui
- Déposer une plainte pour "altération du système" - permet à leur compte d'être révoqué
Cela s'est avéré être un ensemble efficace de contrôles contre les pirates "mod" dans le jeu auquel je joue régulièrement, "Call of Duty: World at War". La seule difficulté que je vois est que la commutation de décalage est difficile à prouver; contrairement à quelqu'un volant dans les airs avec noclip, il n'est pas rare de voir des joueurs innocents avec des connexions décalées qui semblent parfois les aider.
Prenons l'exemple arbitraire:
Le serveur conserve une pile de données pour chaque joueur qui contient la position du joueur et l'heure de réception de cette mise à jour. Le serveur attend une mise à jour toutes les 10 ms car il est programmé de cette façon dans le client. Chaque mise à jour reçue est vérifiée avec la mise à jour précédente.
Supposons que le serveur accepte les coordonnées X et Y pour le joueur et le jeu ne permet que le changement de 1.0 pour X et Y à chaque mise à jour, (car c'est la vitesse maximale du joueur). Si l'heure actuelle est 0,00 et que la position du joueur actuel est à (1,0,1,0), la position de mise à jour maximale pourrait être (2,0,2,0) à l'heure actuelle de 0,01. Nous devrons peut-être autoriser une certaine marge d'erreur dans ce positionnement, comme + ,1,0,1).
Cependant, les paquets UDP vont être supprimés et le serveur devra calculer les limites acceptables pour le lecteur compte tenu de la mise à jour actuelle. Si dans le paragraphe précédent, la mise à jour a été supprimée et que le joueur a également envoyé une nouvelle mise à jour avec time = 0.02 et position (2.0,2.0), ce serait une mise à jour légitime. Le serveur vérifierait et marquerait les mises à jour qui ne sont pas réelles là où si le temps de changer les coordonnées n'aurait pas pu être atteint, dans cet exemple, passer à (1000.0,1000.0) dans la prochaine mise à jour.
Étant donné que le serveur attend une mise à jour toutes les 10 ms, il doit avoir une limite acceptable aux paquets perdus qu'il n'a pas reçus. La limite peut être de 100 ms et si le serveur n'a pas reçu de mise à jour dans ce délai, nous pouvons considérer qu'il y a un certain retard. Une fois ce délai écoulé, le serveur indiquera au joueur où il se trouve actuellement afin de pouvoir envoyer de nouvelles mises à jour.
Ce décalage ne devrait pas affecter les autres joueurs car ce n'est pas leur problème. C'est assez frustrant de voir d'autres joueurs du jeu "se téléporter" parce qu'ils sont en retard. Le lag se produit et c'est --- (toujours la raison pour laquelle je meurs dans les jeux vidéo.
Si des pointes de décalage, ou quel que soit le terme, ont été détectées, le serveur devrait simplement commencer à couper les balles des joueurs pendant x secondes. Ce ne sont pas les problèmes de réseau de faute des joueurs ennemis qui le font perdre.
Si les pointes de décalage se poursuivent au cours du match, continuez à augmenter le délai de chute des balles. Connectez-vous sur le compte des joueurs. Enregistrez des informations supplémentaires telles que cela se produit lorsque les joueurs sont autour, avec des distances, et ainsi de suite afin que le joueur puisse être enquêté si nécessaire. Si cela ne se produit jamais en champ libre sans personne autour ... pourquoi? Je comprends que les réseaux s'impliquent davantage au combat, mais si c'est toujours 0,5 seconde avant qu'il tire, parce qu'il court derrière un rocher, il enclenche son interrupteur de décalage, puis attaque, ce truc devient évident.
Si vous avez un mauvais réseau, alors vous serez comme ok, j'ai un mauvais réseau, mais j'aime le jeu, donc je me rends compte que je peux perdre des balles ... Assez bien. Cela sera accepté. Les gens qui ont de mauvais réseaux savent qu'ils ont de mauvais réseaux. Les coups de pied à cause des pics ne sont pas une réponse, à moins que ce soit un pic continu tout au long de la connexion client à la vie du serveur.
Quant au pirate de lag, il devra finalement jouer loyalement. La perte prolongée de balles signifie qu'il n'utilisera pas le hack. Si quoi que ce soit, il se transformera en un outil pour s'enfuir, ce qui exposera davantage qu'il pirate. Un mauvais joueur du réseau ne réalisera pas qu'il est en retard et perd des balles.
Et enfin, le client a-t-il un mauvais réseau parce que c'est une mauvaise connexion réseau? Envoyez un e-mail en disant: "Votre réseau montre des signes de désarroi, veuillez demander de l'aide à votre FAI pour rechercher d'éventuels problèmes de ligne. pourrait faire la queue avec d'autres qui ont des problèmes similaires pour être juste envers nos joueurs compétitifs à la recherche d'un service de qualité que nous essayons de fournir. "