Discussion :

[Neckara]

Bonjour,

Je suis actuellement en train de programmer un serveur de jeux mais je rencontre des problèmes avec les sockets TCP (avec la SFML2.0):

- en cas de déconnexions brutales, le serveur n'est avertit de rien
- on peut modifier les données du paquets
- on peut "voler" la connexion
- si on transmet un hash du mot de passe, n'importe qui peut se connecter en renvoyant le même hash

J'essaye de chercher mais je ne trouve pas beaucoup de résultats. Auriez vous des idées pour sécuriser mes socket TCP ?

Cordialement,
Neckara

[gwadaboug]

Salut Neckara !

Sa fait assez longtemps que je n'ai pas fait de socket, mais je peux essayer de te guider.

Normalement tu as 2 type de liaison, le mode connecté et déconnecté. si tu es en mode connecté tu devrais pouvoir savoir si la connection a été interrompu. Un autre moyen qui peu fonctionner, c'est de créer un système de ping. pour le système connecté il permettra de maintenir la connection, et pour le mode déconnecté, le serveur pourra se dire qu'au bout d'un certain temps il concidere le client déconnecté.

Pour la modification des paquets, je ne vois pas très bien ce que tu veux dire.

Pour le vole de connection, tu peux utiliser un système de clef généré par ton serveur qu'il envoie au client après que celui-ci ce soit authentifié.

1. Le client s'authentifie
2. le serveur valide la connection, genere une clef et l'envoie au client
3. à chaque demande le client renvoie sa clef (et non ses identifiants)
4. le serveur recherche la session en fonction de la cles et valide l'identité en fonction d'autre parametre (IP, ...)

Voila je pense que c'est un bon debut pour toi

[Neckara]

Je connais déjà la différence UDP/TCP

si tu es en mode connecté tu devrais pouvoir savoir si la connection a été interrompu.

Pas en cas de déconnexion intempestives (coupure de courant, ...) apparemment.

Pour la modification des paquets, je ne vois pas très bien ce que tu veux dire.

Il est possible de modifier des paquets en transit. Une sorte de man in the middle. Bon, je ne pense pas que ce soit le plus important, vu qu'on peut considérer ceci comme un manque de vigilance du client. Donc ça ne touchera pas les comptes admins

Pour le vole de connection, tu peux utiliser un système de clef généré par ton serveur qu'il envoie au client après que celui-ci ce soit authentifié.

1. Le client s'authentifie
2. le serveur valide la connection, genere une clef et l'envoie au client
3. à chaque demande le client renvoie sa clef (et non ses identifiants)
4. le serveur recherche la session en fonction de la cles et valide l'identité en fonction d'autre parametre (IP, ...)

Je ne vois pas ce qui empêche le vol de la connexion vu que les clés vont circuler en clair.
De plus, crypter chaque échange est très lourd alors qu'on se moque qu'une personne externe voie ce qui s'échange (message sur le chat etc...).
Je veux juste qu'on ne puisse pas usurper le compte d'une personne en connaissant le couple login/password, en connaissant les premiers paquets à envoyer pour établir une connexion ou en "volant" la connexion.
Pour se connecter, le client doit au minimum s'identifier. Pour s'authentifier, comment fait-il? Il faudrait qu'il s'authentifie à chaque message envoyé non?

[DakM]

- en cas de déconnexions brutales, le serveur n'est avertit de rien

Une erreur est renvoyée lors de la deconnexion d'un client, si cela ne marche pas avec une coupure de courant ou autre, alors ping obligé.

- on peut modifier les données du paquets

Tu ne peux rien faire contre l'edition des packets, en revanche tu peux ajouter des conditions pieges dan ton code.
Mon serveur possede enormement de if qui ne peuvent QUE se declencher si le client triche sur l'envoie des packets avec un editeur

- on peut "voler" la connexion

Comment c'est possible ca ?

- si on transmet un hash du mot de passe, n'importe qui peut se connecter en renvoyant le même hash

Une connexion a l'entree du serveur suffit, pourquoi devrais tu devoir renvoyer le hash plusieurs fois?

[gwadaboug]

Non non, je me suis peut être mal expliqué !

En faite il te faut créer un système de session, comme il existe sur chaque serveur. Le but est d’éviter que le client ne renvoie sans arrêt son login mot de passe.

Dans un premier temps, le client s'identifie (via son login mot de passe). Afin de préserver et de garder caché ses identifiants, tu peux utiliser un algorithme de cryptage asymétrique (avec clés public et clés privée) tel que RSA. wikipedia

Le serveur valide alors la connection (si les identifiants sont valides bien entendu ) et créé donc une session pour cet utilisateur (dans son pool de session). La session doit contenir au minimum une clés générée aléatoirement (unique, car elle permettra d'identifier la session), une date pour le timeout (afin qu'une session ne reste pas ouverte infiniment). Le serveur renvoie donc cette clés à l'utilisateur, afin que celui ci la garde.

Maintenant, lorsque le client fera une demande au serveur, il renverra cette clés, au lieu de s'identifier à nouveau. Cela protège les identifiants de l'utilisateur.
Pour le vole de session, il existe différente façon de se protéger. par exemple, lors de la phase d'identification du client, stocker l'adresse IP et d'autres informations. Le serveur vérifiera à chaque demande du client ces paramètres la. Tu peux également encrypter tes transferts (via le cryptage asymétrique).

Pour les explications des sessions : wikipedia
Je te transmets un tuto qui à l'air pas mal, tu peux t'en inspirer je pense. De plus il te parle des hacking de session : Developpez

Je ne sais pas si ma réponse est plus clair, mais je pense qu'il faut chercher du coté des sessions (bien qu'une sécurité possède toujours des failles ...)

[Neckara]

Une erreur est renvoyée lors de la deconnexion d'un client, si cela ne marche pas avec une coupure de courant ou autre, alors ping obligé.

Justement, sur le site de la SFML, Laurent m'a dit :

Il y a des techniques pour gérer en live les deconnexions, je ne peux que te conseiller de lire un peu sur le sujet avant de t'aventurer dans des algorithmes persos, ou de tirer des conclusions trop hâtives

Comment c'est possible ca ?

J'ai vu ça ici : http://malm.tuxfamily.org/doc/vol_connexion_tcp.htm
Dans le partie 2.2

Une connexion a l'entree du serveur suffit, pourquoi devrais tu devoir renvoyer le hash plusieurs fois?

Non c'est pas le client qui envoie le hash plusieurs fois, je m'explique :

Soit Client, Serveur, Hacker :
//connexion TCP avec le client
- Client demande une connexion au serveur
- Serveur Revois un acquittement + une demande de connexion pour l'autre sens
- Client renvois un acquittement
//la connexion TCP est établie
- Client envoit un hash de son login/mdp.
- Hacker sniffait le réseau et lit le paquet.
//le connexion du client est établie
...
//le client se déconnecte.
//le hacker va tenter de se connecter
//...
//connexion TCP établie avec le hacker
- hacker renvoit le paquet qu'il a sniffé.
- le serveur accepte.
//la connexion du hacker est établie


EDIT : pas vu qu'on avait posté pendant que j'écrivais.

En faite il te faut créer un système de session, comme il existe sur chaque serveur. Le but est d’éviter que le client ne renvoie sans arrêt son login mot de passe.

On est pas en php là
J'ai juste à associer au socket une structure ou un objet.

Dans un premier temps, le client s'identifie (via son login mot de passe). Afin de préserver et de garder caché ses identifiants, tu peux utiliser un algorithme de cryptage asymétrique (avec clés public et clés privée) tel que RSA. wikipedia

Non on utilisera un système de hachage avec SHA-256.
Après on peut crypter mais :
- si la clé utilisée est publique, il n'y a aucun intérêt.
- si la clé utilisée est privée, c'est encore pire.
Je vois mal comment tu fait. Le hackeur a juste a copier/coller les données contenues dans le paquet...

La session doit contenir au minimum une clés générée aléatoirement (unique, car elle permettra d'identifier la session)

La socket identifie déjà la connection

lors de la phase d'identification du client, stocker l'adresse IP et d'autres informations.

L'usurpation se fait justement sur l'adresse IP....
D'autres informations je veux bien mais lesquelles ?

Tu peux également encrypter tes transferts (via le cryptage asymétrique).

C'est super lourd, intenable pour un serveur de tout crypter les échanges de données.

[Trademark]

Pour faire une connexion sécurisé, tu peux passer par la lib openssl. Tu encapsules leur code dans des classes C++ est c'est bon

http://www.openssl.org/docs/ssl/ssl.html

Après on peut crypter mais :
- si la clé utilisée est publique, il n'y a aucun intérêt.
- si la clé utilisée est privée, c'est encore pire.
Je vois mal comment tu fait. Le hackeur a juste a copier/coller les données contenues dans le paquet...

Dans un système comme ça, il y a une clé privée (uniquement connue par le serveur) et public connue de tous. Les détails sont très certainement beaucoup plus compliqué.

Néanmoins, les attaques Man in the middle peuvent survenir n'importe quand et même ce type de cryptage n'y changera rien... Tu peux même détourner des sessions https alors...
Tu peux lire des moyens de se défendre ici : http://en.wikipedia.org/wiki/Man-in-...nst_the_attack

À mon avis, ce dont tu dois te méfier le plus, c'est des joueurs eux-mêmes. Éviter qu'ils analysent le protocoles et craft des paquets à la volée pour les avantagés dans le jeu. Le serveur doit se munir d'un système pour vérifier les paquets incohérents par rapport à un état antérieure.

D'un autre côté, je pense que c'est le genre de truc à faire plus tard, parce que tu ajoutes un niveau de difficulté non négligeable...

[Neckara]

Pour faire une connexion sécurisé, tu peux passer par la lib openssl. Tu encapsules leur code dans des classes C++ est c'est bon

http://www.openssl.org/docs/ssl/ssl.html

J'ai regardé vite fait, apparemment il gère les timeout, les vols de connexon (avec une authentification) ainsi que les cryptages. Par contre est-ce que chaque échange est crypté? Certaines données peuvent très bien voyager en clair.

Dans un système comme ça, il y a une clé privée (uniquement connue par le serveur) et public connue de tous. Les détails sont très certainement beaucoup plus compliqué.

Le hackeur n'a pas besoin de savoir la donnée originelle, juste ce qui est produit à la fin. C'est justement mon problème pour la connexion, les données envoyée au serveur seront toujours les mêmes. Le hackeur ne connaitra jamais les mot de passes/login mais il pourra très facilement se connecter quand même

À mon avis, ce dont tu dois te méfier le plus, c'est des joueurs eux-mêmes. Éviter qu'ils analysent le protocoles et craft des paquets à la volée pour les avantagés dans le jeu. Le serveur doit se munir d'un système pour vérifier les paquets incohérents par rapport à un état antérieure.

Ce n'est pas exacte. Le serveur ne doit JAMAIS faire confiance à l'utilisateur. C'est lui qui doit calculer les collisions, les crafts, ....
Le seul problème ce sont les bots. Là c'est plus compliqué car il est plus difficile de les différencier d'un vrai joueur.

D'un autre côté, je pense que c'est le genre de truc à faire plus tard, parce que tu ajoutes un niveau de difficulté non négligeable...

Je pense quand même mettre en place de SHA-256 en premier lieu.
Ensuite, je pense que je vais suivre tes conseils et juste ajouter un TODO dans la doc en faisant référence à openSSL.

Après les seuls problèmes viendront des "sniffage" des échanges (et aussi des déconnexion subites).
Mais pour ceci il faut être près d'un des réseaux locaux du client ou du serveur non?
Ou est-il possible de sniffer les paquets envoyé par un ordinateur sur l'Internet où qu'il se situe dans le monde ?

Merci pour ta réponse.

[Trademark]

Je pense quand même mettre en place de SHA-256 en premier lieu.
Ensuite, je pense que je vais suivre tes conseils et juste ajouter un TODO dans la doc en faisant référence à openSSL.

Je suppose que tu le sais mais un SHA-256 n'est pas du cryptage. C'est du hachage. N'oublie pas de rajouter un salt. Et openssl fournit également ce genre de fonction (même du SHA-512).

Après les seuls problèmes viendront des "sniffage" des échanges (et aussi des déconnexion subites).
Mais pour ceci il faut être près d'un des réseaux locaux du client ou du serveur non?
Ou est-il possible de sniffer les paquets envoyé par un ordinateur sur l'Internet où qu'il se situe dans le monde ?

Merci pour ta réponse.

Franchement c'est une bonne question. Il y aura toujours moyen qu'il sniffe de n'importe où. La première idée qu'il me vient à l'esprit est l'installation d'un logiciel espion sur le pc cible et il re-route les paquets vers un pirate.

De toutes façons c'est des problèmes complexes qui nous sont (peut-être pour le moment seulement) hors de portée.

[Neckara]

Je suppose que tu le sais mais un SHA-256 n'est pas du cryptage. C'est du hachage. N'oublie pas de rajouter un salt. Et openssl fournit également ce genre de fonction (même du SHA-512).

J'ai déjà récupéré un sha512 implémenté, y'a juste quelques optimisations à faire^^ (et le re-coder proprement aussi ....)

Franchement c'est une bonne question. Il y aura toujours moyen qu'il sniffe de n'importe où. La première idée qu'il me vient à l'esprit est l'installation d'un logiciel espion sur le pc cible et il re-route les paquets vers un pirate.

De toutes façons c'est des problèmes complexes qui nous sont (peut-être pour le moment seulement) hors de portée.

Je pense me sécialiser dans la sécurité informatiques donc c'est le genre de chose qui m'intéresse au plus haut point p