Discussion :

[Klaim]

Je ne sais pas vraiment ou poster ca mais comme j'utilise C++, je vais commencer la.

Note: j'utilise RakNet comme abstraction reseau donc le souci se trouve plutot au niveau.. protocol de communication.


Je developpe un jeu qui est client/serveur, avec un mode solo qui lance le serveur en local, mais le client peut tres bien a tout moment se connecter a un serveur distant. Comme c'est du jeu, c'est de lUDP (gere essentiellement par RakNet)

Je mets en place des protocoles de communication, jusqu'ici tout va bien. Le souci que j'ai c'est au niveau de la securite, performances lie au comportement du serveur: que dois-je faire si un packet que je recoit ne fait apparemment pas parti des protocoles geres par l'application?


Pour l'instant je me dis que le plus efficace c'est de carrement deconnecter un client qui m'envoie des messages foireux, peut etre apres lui avoir envoye un message indiquant qu'on ne reconnais pas les siens. Je me dis que ca eviterai des trucs fourbes potentiels et de consommer la connexion, mais c'est peut etre inutile. Je manque de pratique en securite et en reseau.

Des conseils?

[Emmanuel Deloget]

Je ne sais pas vraiment ou poster ca mais comme j'utilise C++, je vais commencer la.

Note: j'utilise RakNet comme abstraction reseau donc le souci se trouve plutot au niveau.. protocol de communication.


Je developpe un jeu qui est client/serveur, avec un mode solo qui lance le serveur en local, mais le client peut tres bien a tout moment se connecter a un serveur distant. Comme c'est du jeu, c'est de lUDP (gere essentiellement par RakNet)

Je mets en place des protocoles de communication, jusqu'ici tout va bien. Le souci que j'ai c'est au niveau de la securite, performances lie au comportement du serveur: que dois-je faire si un packet que je recoit ne fait apparemment pas parti des protocoles geres par l'application?


Pour l'instant je me dis que le plus efficace c'est de carrement deconnecter un client qui m'envoie des messages foireux, peut etre apres lui avoir envoye un message indiquant qu'on ne reconnais pas les siens. Je me dis que ca eviterai des trucs fourbes potentiels et de consommer la connexion, mais c'est peut etre inutile. Je manque de pratique en securite et en reseau.

Des conseils?

Tu discardes, et au bout de N messages consécutifs, tu killes la connexion (tu ne peux pas forcément faire autre chose : après tout, ça reste de l'UDP, et il n'est pas abhérent que tu reçoive des packets incompris parce que corrompus).

Mais à aucune moment tu ne préviens l'envoyeur - ça ne sert à rien (il sera déco quand même), juste à l'assurer que, effectivement, tu reçois les messages UDP qu'il envoie. 2tant donné que c'est de l'UDP, il ne peut pas être sûr que tu réceptionne le message.

Dans le cas idéal, je laisserais le kernel faire le tri à ta place - si tu es sur Linux, tu peux ajouter un filtre de paquets (BPF : http://en.wikipedia.org/wiki/Berkeley_Packet_Filter), et forwarder ceux qui t'intéressent sur une interface particulière - ou dropper ceux qui ne t'intéressent pas. Ca te permettra d'éliminer un certain nombre de packets forgé pour essayer de te faire planter - sans que tu n'ai rien à faire.

(ok, ce n'est pas nécessairement facile à faire ; mais c'est possible)

[Klaim]

A priori la remarque sur RakNet n'a pas ete bien compris: RakNet s'occupe de tout ce qui est bas niveau, donc les messages que je recois son

1. non-corrompus (par la transmission du moins) - raknet fais le boulot de surcouche de communication
2. traites de differentes facons les dits messages

Donc en gros on peut partir du principe qu'une fois que je recois un message il est complet. En revanche il est soit envoye par RakNet lui meme (pour notification d'une connection par exemple) ou par un client (les messages de mes protocoles particuliers). Ce n'est pas de l'udp direct, RakNet donne pas mal de garanties.

Le souci c'est quand RakNet me file un message et que je n'arrive pas a l'identifier malgres tout ca. Ce n'est pas un cas que j'ai actuellement, mais en faisant le system qui dispatch les messages, je me suis rendu compte que je ne sais pas quoi faire du cas ou je ne reconnais pas ce message. Et du coup je me mefie.

Tu discardes, et au bout de N messages consécutifs, tu killes la connexion

Est-ce que ce conseil est toujours valide dans ces conditions? A priori oui, ca m'a l'air pas mal.

[koala01]

Salut,

A défaut de plus d'informations, je crois que cela reste en effet tout à fait valide comme principe...

Si, un jour, RakNet a à se plaindre de cela ou te fait savoir qu'ils ont essayé de t'envoyer des messages par ce biais mais que tu n'y a jamais répondu, tu pourras toujours faire autrement

Ce que tu peux éventuellement envisager de faire, c'est de logger le message avant de le droper, parce qu'on ne sait jamais

[Klaim]

Ce que tu peux éventuellement envisager de faire, c'est de logger le message avant de le droper, parce qu'on ne sait jamais

Effectivement, au moins pour detecter une erreur de mon cote...

[Klaim]

On me suggere de d'utiliser les fonctionalites de securite que RakNet propose: http://www.raknet.net/raknet/manual/...nnections.html

Mais pas pendant le debuggage.
Donc ajoute au log des messages ca devrait le faire.

[Emmanuel Deloget]

Est-ce que ce conseil est toujours valide dans ces conditions? A priori oui, ca m'a l'air pas mal.

Si tu reçois du bruit, ça peut être pour deux raisons :

1/ le client, en face, envoie quelque chose de raisonnable, mais UDP étant UDP, il y a des perturbations, et le message est corrompu - du coup, impossible de comprendre ce qui se passe.

2/ le client envoie déliberemment des données que tu ne peux pas comprendre (classique : c'est le principe du fuzzing, dont un des buts est de trouver des bugs - dans ton cas, un DoS dans un premier temps, et peut-être une faille exploitable par la suite).

Dans le cas numéro 2, on voit qu'on a tout intérêt à couper la comm rapidement, sans même faire d'ack (ceci dit, couper la comm en UDP, ça n'a pas vraiment de sens, quand bien même raknet fait le travail que doit faire TCP au dessus d'UDP, il n'y a toujours pas de connexion).

Dans le cas 1, si c'est rare, alors ça va passer. Le message corrompu sera discardé, et les suivant sont corrects. Si un client particulier se met à t'envoyer plusieurs datagrammes corrompus, alors ça veut dire qu'il a un problème important. Il y a une forte chance pour qu'il continue, ce qui veut dire que si tu ne le déconnecte pas, tu va devoir traiter des messages inutiles et incompréhensible pendant une durée indéterminée. C'est du temps CPU et de la bande passante qui sont consommés pour rien. Donc autant le tuer après avoir reçu quelques messages corrompus pendant un temps relativement court (si tu reçois 50% des messages corrompu en 5 seconde, c'est que le client a un sérieux soucis).

Du coup, dans les deux cas : attendre d'avoir reçu quelques messages et hop, connexion à la poubelle si le taux de message incompréhensible dans un laps de temps est supérieur à un niveau fixé au préalable.

[Klaim]

Si tu reçois du bruit, ça peut être pour deux raisons :

1/ le client, en face, envoie quelque chose de raisonnable, mais UDP étant UDP, il y a des perturbations, et le message est corrompu - du coup, impossible de comprendre ce qui se passe.

Comme je disais, RakNet s'occupe d'eliminer ces cas (sur demande).

2/ le client envoie déliberemment des données que tu ne peux pas comprendre (classique : c'est le principe du fuzzing, dont un des buts est de trouver des bugs - dans ton cas, un DoS dans un premier temps, et peut-être une faille exploitable par la suite).

Je me disais bien aussi...

Dans le cas numéro 2, on voit qu'on a tout intérêt à couper la comm rapidement, sans même faire d'ack (ceci dit, couper la comm en UDP, ça n'a pas vraiment de sens, quand bien même raknet fait le travail que doit faire TCP au dessus d'UDP, il n'y a toujours pas de connexion).

Quelqu'un d'autre m'a aussi suggere de ne pas repondre.
Pour RakNet il y a bien une notion de connexion: il a son propre protocole pour maintenir une connexion, sous entendu celui d'en face utilise RakNet aussi (ou son protocole) et apres que tu ais ouvert une connexion d'entree un client peut tout a fait faire une tentative de connexion. Une fois fait les message speciaux sont acquis (apres tout le bordel pour etre sur qu'ils sont bien formes - si c'est demande) puis retransmis au code utilisateur.
C' est a ce point la que le code utilisateur va lire les packets envoyes (qui sont donc deja filtres). Sachant que RakNet est open source (mais pas gratuit pour tous) il y a facilement une possibilite effectivement de produire un client bidon pour explorer le protocole du serveur ou des bugs j'imagine.

A ce propos, voir la suite.

Dans le cas 1, si c'est rare, alors ça va passer. Le message corrompu sera discardé, et les suivant sont corrects. Si un client particulier se met à t'envoyer plusieurs datagrammes corrompus, alors ça veut dire qu'il a un problème important. Il y a une forte chance pour qu'il continue, ce qui veut dire que si tu ne le déconnecte pas, tu va devoir traiter des messages inutiles et incompréhensible pendant une durée indéterminée. C'est du temps CPU et de la bande passante qui sont consommés pour rien. Donc autant le tuer après avoir reçu quelques messages corrompus pendant un temps relativement court (si tu reçois 50% des messages corrompu en 5 seconde, c'est que le client a un sérieux soucis).

RakNet prends en compte le discard des messages corrompus, par contre il y a un moyen d'etre notifie quand des messages corrompus arrivent souvent, ce qui me permettrais de virer ceux qui font ca. Lire la suite.

Du coup, dans les deux cas : attendre d'avoir reçu quelques messages et hop, connexion à la poubelle si le taux de message incompréhensible dans un laps de temps est supérieur à un niveau fixé au préalable.

Oui, donc en complement: l'auteur de RakNet m'a suggere de bannir la connexion (au moins le temps de la session) L'effet est que RakNet ne traitera plus les packets venant de l'ip+port en question. Ca me semble une excellente facon de gerer ce cas.