Discussion :

[Array]

Bonjour,

Je fais en ce moment un serveur qui envoie des "serial numbers" (un numéro unique d'identification, abrégé ici "uid") à un client afin de reconnaître ce même client à sa prochaine visite...

Le fait est que je SAIS quels IPs iront chercher ces uid (seule une liste d'IPs autorisés y auront accès) par conséquent je peux utiliser bloqeur d'autres tentatives venant d'autres addresses.

Cependant, je ne voudrais pas qu'un scénario particulier se produise:
une attaque visant le serveur, qui envoie un paquet "spoofé" (c'est à dire donc l'addresse de l'envoyeur a été modifiée dans l'entête du paquet) demandant une requête pour l'obtention d'un nouveau uid... en effet si cela se produisait, et que l'addresse corresponde à un des IPs autorisés, je pourrais bien me retrouver à gaspiller énormément de uids et même mon algorithme de génération pourrait potentiellement être découvert.
Il me faut donc empêcher cela.

Je me disais donc que le seul moyen d'être sûr que l'addresse distant soit bel et bien la bonne, je dois faire ces étapes
1- Réception d'un paquet
2- Envoie d'un paquet de confirmation à l'addresse distante
3- L'addresse distante réplique...
4- Réception du paquet de confirmation

Voici mes questions:
1- Est-ce que, lors de l'établissement d'une connection avec l'appel socket(), accept(), etc etc, ces étapes sont déjà faites d'avance (autrement dit est-ce que l'on est sûr de l'autheticité de l'addresse distante)?
2- Avez vous une meilleure idée, plus sécuritaire, afin de palier ce problème?

Merci beaucoup!

Cordialement,
Array

[gangsoleil]

Bonjour,

Lors de l'etablissement d'une connexion securisee, il y a plusieurs echanges qui sont faits - on parle par exemple de 3-way handshake.

Un paquet spoofe seul ne permet pas d'etablir une connexion, car ton serveur va repondre a l'adresse spoofee, pas a l'emetteur.

Ta seule crainte est le man-in-the-middle, et la, il est tres difficile de s'en premunir sans avoir un minimum de controle sur la machine cliente.

Au fait, j'espere bien que tes connexions sont securisees avec SSL ?

[Array]

Au fait, j'espere bien que tes connexions sont securisees avec SSL ?

Mhm en fait non :[]

Pour être franc, c'est une implémentation qui nécessite vraiment d'être rapide dans l'établissement des connexions et des réponses, Le,voie des données etc etc.
Donc... avant d'essayer je me disais... est-ce que SSL ralentit de beaucoup par rapport aux appels standards de l'OS?

Je suis peu connaissant en ce qui a trait aux connexions sécurisées.

[gangsoleil]

c'est une implémentation qui nécessite vraiment d'être rapide dans l'établissement des connexions et des réponses, L'envoie des données etc etc.
Donc... avant d'essayer je me disais... est-ce que SSL ralentit de beaucoup par rapport aux appels standards de l'OS?

Quel est le besoin :
Temps acceptable pour une connexion ?
Est-ce que la connexion peut rester ouverte en permanence, ou bien doit-elle etre refaite a chaque fois ?
Est-ce que l'utilisation CPU est genante (sur un micro-controlleur par exemple) ?
De quel niveau de securite avez-vous besoin ?

A mon avis, tu ne verras memem pas la difference en chiffrant les donnees ou non, pour peu que tu aies des serveurs et pas des terminaux mobiles - et encore.

[matafan]

Avec de l'ARP spoofing on peut tout à fait se faire passer pour autre machine.

Avec un serveur S et une machine pirate P voulant se faire passer pour un client légitime C, la machine P émet des réponses ARP qui disent "l'IP de C, elle correspond à mon adresse MAC". En plus de ça P met son interface en mode promiscuous.

P envoie à S un paquet en mettant l'adresse IP de C en adresse source. Quand S répond, il émet un requête ARP pour connaître l'adresse MAC correspondant à l'adresse IP de C. Il reçoit une des réponses ARP "pirates" émises en permanence par par P. S envoie donc un paquet destiné à C, avec l'IP destination de C, mais l'adresse MAC destination de P. P reçoit la réponse et fait ce qu'il veut avec.

[gangsoleil]

Pour l'ARP spoofing, il faut tout de meme etre sur le meme sous-reseau, donc c'est vite tres tres limitant (heureusement d'ailleurs).

[matafan]

Non pas du tout, il suffit de se faire passer pour la gateway et ça roule.

[gangsoleil]

Vu qu'on ne peut pas connaitre la route empruntee par les paquets entre Source et Destination, et que celle-ci peut etre amenee a changer (en fonction de la charge par exemple), et que pour faire du ARP spoofing il faut emettre en continue, pour que ca fonctionne, il faut en pratique etre sur le reseau de S ou de D (pas forcement le meme sous-reseau, mais au moins sur le reseau de l'entreprise ou quelque chose comme ca).

[Array]

@gangsoleil : Il n'y a pas de temps maximal de connexion, même si je privilégie, bien entendu, la philisophie "le plus rapide reste le mieux".

L'implémentation est en fait une sorte de "plugin" apportant des fonctionnalités étendues à un serveur (nommé ici serveur A pour le distinguer de mon propre programme serveur) qui lui fait d'autres multiples tâches. Néanmoins, l'important, c'est que le client (celui se connectant à mon programme serveur, que je nommerai ici server B) tournera forcément sur une machine qui elle-même tourne un serveur A.

Les machines clientes B sont en fait à nous. Elles sont sous notre contrôle total (virtualisées). Néanmoins, je crois que je vais aller avec l'approche SSL, car j'ai toujours préconisé "sécurité", à moins qu'avec ces nouvelles informations vous dites "non n'utilise pas SSL".
Cependant, il est à noter qu'autour de quatre/cinq clients B et serveurs A peuvent tourner sur une même machine (chacun des clients B apportant des fonctionnalités à son propre serveur A) et connectant à un même IP correspondant au serveur B (il reste le même pour sa part).

Le serveur B est multithread, il gère les connexions avec un socket, file d'attente de 1024, et les changements sur le socket sont auditionnés avec la fonction select(). Un thread pour les connexions, un pour le "processing" des données et un pour l'envoie des données.

Le client du server B (le plugin en question), tant qu'à lui, est aussi multithread. Un thread pour la validation des signature existantes déjà captées sur les clients se connectant au serveur A, et un thread pour la génération et l'assignation de nouvelles signatures. Ces deux threads, pour remplir leuurs tâches se connectent évidemment au serveur B (i.e. pour la validation comme pour la génération).

La connexion entre client B et serveur B peut effectivement être maintenue ouverte en permanence, je n'y vois pas d'inconvénient.

Donc, à la lumière de ces faits, trouvez vous que SSL serait appropriée?
En en passant, trouvez vous les principes (les threads et tout) bien échafaudés? Apporteriez-vous des modifications?