Bonjour à tous,
Je dois mettre en place un ftp public sécurisé dans la DMZ public de mon entreprise (Ceci est mon projet de bts ig).
J'ai des difficultés à cerner leurs fonctionnements. Notamment qui initie la connexion, quelles sont les problématiques avec les nat, nat multiple, FW et proxy à prendre en compte.
Nous avons 2 FW chez nous et 2 chez notre FAI (donc double NAT ?), que ce passe t'il pour le client ?
 
Voici ce que j'ai synthétisé :
 
SFTP : Secure File Tranfert Protocol (RFC 4253), l’ abréviation "SFTP" est souvent utilisé à tord pour spécifier une sorte de Secure FTP (tunnel FTP via une connexion SSH), alors qu’elle signifie « SSH File Transfer Protocol ». SFTP n’est donc pas du FTP bien qu’il en reprend des commandes. C’est est un protocole de transfert de fichier à part entière utilisant des clés SSH. Il fonctionne uniquement sur le ports22 (commande et data). Il gère la reprise des transferts, l'annulation d'un transfert ne ferme pas la session, le serveur doit connaitre le client
 
   Problématique FW :
 
   Problématique NAT :
 
   Problématique de NAT multiple (ex de notre coté et celui du client) :
 
   Cryptage utiliser (type de certificat, procédure d'échange des clés):  
          - clés SSH
          - fonctionnement de l'échange des clés ?  

 
FTPS : Variante du FTP fonctionnant via un cryptage SSL ou TLS.  
      FTP avec chiffrement SSL implicite
La méthode implicite exige que tous les clients du serveur FTPS soient conscients que le protocole SSL est utilisé sur la session.
La connexion au serveur se fait sur le port 990 qui est le port de commande et sur lequel la négociation SSL s'effectue. Le port de données est le 989 et est lui aussi chiffré.
La négociation SSL se fait lors de la connexion.
 
 
      FTP avec chiffrement SSL explicite
La connexion s'effectue sur le port 21, le port de commande FTP standard, et la commande "AUTH SSL" ou "AUTH TLS-P" demande au serveur de chiffrer le transfert de commande et de données.
 - Utilise des ports aléatoire  ?
 - vue que la trame est cryptée, que ce passe t'il lors du passage dans les nat (le FW ne peu pas lire et donc modifier la trame ...)
 
      FTP avec chiffrement TLS explicite
La connexion s'effectue sur le port 21, le port de commande FTP standard, et la commande "AUTH TLS" ou "AUTH TLS-C" demande au serveur de chiffrer le transfert de commande. Le chiffrement du transfert de données se fait par la commande "PROT P".
 
     Ports utilisés, :  
 
     Problématique FW :
 
     Problématique NAT :
 
     Problématique de NAT multiple (ex de notre coté et celui du client) :
 
     Cryptage utiliser (type de certificat, procédure d'échange des clés):  
           - certificats X.509.  
           - procédure d'échanges des clés ?  
 
Comment vous le voyez, je suis encore dans le flou, au début je pensais que le FTPS serais la solution à ma problématique, mais j'ai l'impression qu'elle va être plus complexe que SFTP (à cause du/des nat).
Sinon que pensez vous du Secure FTP ? (ftp via un tunel ssh, comment cela fonctionne -t'il exactement (port aléatoire, port de commande et data utilisé etc)
 
 
 

Question indiscrète, est-ce qu'il ne serait pas possible de faire du scp, qui n'utilise qu'un port et ne nécessite aucune configuration pour le nat ?  
 
 

SFTP non plus.
 
FTPS est possible mais complexe à paramétrer.

J'ai trouvé cette article, chose intéressante, il semble être plus rapide que le sftp    
http://www.answers.com/topic/ssh-f [...] r-protocol
 
Après le problème c'est que sa commence à être un protocole spécifique et que nos clients on des moyens technique très varié.
J'avais choisi sftp et ftps car ils sont relativement bien supportés par les principaux clients ftp.
 
Donc concrètement Dreamer, tu prendrais le SFTP ?  
tout les échanges son bien sur le même port ?
Est ce que vous avez des précisions sur la procédure d'échange des clé ssh ?

que veux-tu savoir concernant l'échange de clés ?  
 
si c'est pour l'authentification, tu peux faire de l'authentification avec des jeux de clés publiques/privées;  
 
c'est décrit dans pas mal de docs, dont chez openssh.
 
en gros chaque client génère une paire de clés. La clé publique du client est renseignée côté serveur, et ça sert d'authentification en remplacement du login/mdp.

merci pour ces infos, je commence une maquette en dmz pour essayer tout ça