Version imprimable
Je suis à la recherche d'un moyen de "filtrer" les connexions à un serveur.
Je dois me connecter à un serveur au début de mon programme. Ce qui m'inquiète, c'est que quelqu'un récupère les identifiants et mdp
du ftp.
Je me demande donc si il y a un moyen pour donner accès au serveur que si la connexion vient de mon logiciel.Si non, y a t il d'autres options
pour protéger les id et mdp.
Merci!!
Vu que le FTP n'est absolument pas sécurisé, que ce soit ton programme ou autre chose, tu devrais éviter d'utiliser des user/mdp qui ont une autre utilité que celle d'accéder au FTP.
Bref, il faut que ce couple user/password ne serve qu'à ça.
De toutes façons, ce qui est dans ton programme est accessible à l'utilisateur de ton programme et doit donc être considéré comme porté à la connaissance de cet utilisateur. Que ce soient des mots de passes, des clés privées SSH ou autre.
L'ID et le MDP est dans le programme. L'utilisateur ne le voit pas en soit.
Es ce que tout simplement donner des permissions à l'utilisateur sur le serveur suffit?
Note: Mon serveur est à moi donc j'ai accès libre sur les config, etc...
Si il est un minimum malin, il y a accès. Et tous les malware ou logiciels espions qui traineraient sur sa machine aussi. Bref, ce n'est pas à considérer comme sécurisé.
Je doit avoir accès au serveur!! Que proposes-tu pour accéder et/ou protéger?
- Faire autrement. Oublier FTP
OU
- T'arranger pour que le fait de récupérer les identifiants login/mdp ne soit pas un problème. Par exemple, que chaque utilisateur différent ait un login/mdp différent, qui ne lui permet de faire qu'une seule chose sur le FTP et rien d'autre. Un autre programme pourra faire la même chose que tout ce que ton programme a le droit de faire, tant pis.
Oublier FTP ne changera pas grand chose. Tout au plus passer sur des protocoles cryptés isolera le problème des sniffeur de paquet (FTP fait passer le mot de passe en clair).
Ce qu'il faut c'est penser à ta sécurité sur le serveur et non pas sur le client. Si ton client ne peut pas faire quelque chose, alors c'est au serveur de l'interdire. C'est valable pour de la transmission de fichier tout comme c'est valable pour une connexion à une base de données.
D'accord avec toi, mais
Pas forcément. Peut-être que le problème existe uniquement du fait de l'idée d'utiliser FTP au lieu d'un protocole qui serait fait pour. Quand on fait FTP on utilise un login et un mot de passe et on échange des fichiers. Ce n'est pas forcément ce qui est voulu ici.Citation:
Envoyé par tchize_
Qui utilise encore FTP de nos jours ? Surtout pour l'exposer à des utilisateurs ?
Protocole simple et pratique pour du transfert de fichier. Contrairement à sftp / scp, il n'a pas besoin d'un account système, il traverse sans soucis la plupart des firewall, apporte peu de surcharge réseau pour les gros fichiers et dispose de serveurs robustes...Citation:
Envoyé par thelvin
Beaucoup de gens, en fait :)
Si tu maitrise le serveur FTP tu peux limiter les IP qui y accèdent . mais tu auras pas plus de protection que ça.
Si en plus tu maitrise la machine sur laquelle va être déployé ton appli, tu peux toujours faire un vpn sécurisé .
Mais si ton appli est déployée chez un utilisateur malveillant, il pourra TOUJOURS recup le MDP et s'amuser avec.
Si tu es vraiment désespéré, tu peux protéger ton serveur FTP avec des méthodes de port-knocking , ou encore modifier un serveur FTP open source pour activer les fonctions dangereuses après que ton application a " prouvé que c'était elle" en utilisant des commandes personnalisées.
Et pour info, ne pas sécuriser ses réseaux est un delit en France.
Déjà il faut passer en SFTP pour sécuriser la transmission, c'est le minimum.
Ensuite une solution acceptable serait de faire du oneshot.
Création d'un user/password jettable, dès que les données sont transmisent, hop poubelle. Comme ça personne ne peut les réutiliser.
Il y a un peu de gestion à faire coté serveur, mais rien de vraiment méchant.
Bon courage,
Bof, on peux pinailler des heures là dessus. Passer par une connexion ssh veux dire que l'on crée un compte système pour l'opération et ce compte système est accessible depuis le client. Je suis pas convaincu que ce soit un gain d'un point de vu sécurité.Citation:
Envoyé par Jimmy_
Il faut voir ce que tu veux faire concrètement pour savoir quelle est la meilleur solution (service web, ftp anonyme, scp/sftp, ftps, bittorrent?).
Du compte oneshot c'est bien, mais tu tourne en boucle, faut synchro le client et le serveur là dessus. Donc soit un moyen de communiquer cette information (et comment on sécurise ce moyen?) soit une algorithme de génération comme dans les token VPN (mais du coup cet algo est accessible au client et donc simulable....)
Oui il y a peut-être d'autres solutions, mais pour l'instant on parle de connexion ftp en début de programme.
Il n'y a pas de sécurité absolue de toute façon, on peut au moins combler les failles.
SSH permet de sécuriser la transmission.
Ensuite un système de génération de clé oneshot comme le classique OTP n'est valable qu'une fois et pendant un temps donnée.
Oui c'est le principe, tout algo de sécurité est publique. Or un système comme secureId partage un secret (le seed) avec le client et génère des mots de passe OTP.Citation:
(mais du coup cet algo est accessible au client et donc simulable....)
Il faut craquer le serveur pour récupérer les seeds des clients.
Ca fait déjà beaucoup pour un attaquant.
Ce que je voulais dire c'est que le gars qui a le client chez lui a forcément le seed, sinon le client ne saurais pas se connecter, du coup ça n'empêche pas l'utilisateur d'utiliser un autre programme pour ce connecter, comme son propre client ssh et du coup ça ne résoud en rien la problématique de départ, empêcher l'utilisateur d'avoir accès à l'ID / mot de passe.
Mais bon, au final, tant qu'on ne connait pas le but, on ne pourra pas donner de solution adaptée. Après tout, on pourrais aussi suggérer de distribuer un token à l'utilisateur. Et si ça tombe, un simple FTP anonyme dans lequel on ne peut faire que de l'upload et peut être aussi suffisant pour le besoin à couvrir.