FTPS AVEC UNE APPLIANCE FAST360 EN COUPURE Table des matières Principes de FTPS... 2 Généralités... 2 FTPS en mode implicite... 2 FTPS en mode explicite... 3 Certificats SSL / TLS... 3 Atelier de tests avec une appliance Fast360... 4 Considérations sur l analyse FAST... 4 Choix techniques effectués... 4 Topologie réseau utilisée pour les tests... 5 Configuration du serveur FTPS... 5 Configuration de l appliance Fast360 en coupure... 7 Vérification des échanges entre le client et le serveur FTPS... 8 Page 1 sur 8 Version du 13/11/2013
Principes de FTPS Généralités Le protocole FTP induit un échange d informations en clair sur le réseau, ce qui est prohibé dans certaines organisations. Les différents modes de fonctionnement du protocole FTP (actif / passif) font l objet d une fiche préalable considérée dans ce document comme un pré-requis et ne seront pas repris ici. FTPS utilise un chiffrement de type SSL ou TLS pour protéger les échanges effectués sur le canal de données entre un client et un serveur compatibles. Par ailleurs, l identité du serveur est vérifiée à l aide d un certificat d authentification. Il est important de ne pas confondre FTPS (FTP Secure) avec SFTP, lequel permet également la sécurisation des échanges par l utilisation du protocole SSH (Secure Shell) sur le port 22, mais ne différencie pas le canal de données du canal de contrôle : un tunnel SSH est monté directement entre le client et le serveur avant tout échange FTP. Les deux méthodes de chiffrement pour FTPS sont détaillées ci-après. FTPS en mode implicite En mode implicite, le canal de contrôle se situe sur le port TCP 990, le canal de données sur le port TCP 989. La négociation SSL/TLS est effectuée dès que le client tente une connexion, en cas d échec, le serveur met fin à la connexion. Le mode implicite induit que : L intégralité de la session FTPS (sur les deux canaux) soit chiffrée. Le client doive impérativement être compatible avec FTPS, ce qui n est pas le cas de tous les clients FTP / FTPS. Le format de requête soit ftps:// Le mode implicite n est pas soutenu par l IETF (Internet Engineering Task Force), dont une des missions est de permettre un fonctionnement efficient d Internet, et de ce fait, il n est que peu ou pas utilisé en entreprise. Page 2 sur 8 Version du 13/11/2013
FTPS en mode explicite En mode explicite, le canal de contrôle se situe sur le même port TCP que pour FTP (le port 21). La première connexion initiée par le client n est pas chiffrée, la mise en œuvre du chiffrement dépend des demandes du poste client. Lorsque le client tente une connexion, il peut demander : Un chiffrement SSL en envoyant la commande «AUTH SSL», pour l échange de commandes et de données. Un chiffrement TLS en envoyant la commande «AUTH TLS» pour l échange de commandes, et / ou la commande «PROT P» pour l échange de données. Une connexion non chiffrée si le serveur le permet. Le mode explicite induit que : La session FTPS puisse être chiffrée soit sur le canal de commandes, soit sur le canal de données, ou sur les deux canaux. Le format de requête soit ftpes:// (ou ftp://). L utilisation du chiffrement entraîne la description par le client du type de protection demandé sur le canal de données (RFC2228) : La commande PBSZ (Protection Buffer SiZe) indique la taille maximum en octets de la mémoire cache utilisable lors de l échange, l indication PBSZ 0 induit un transfert sans cache (streaming). La commande PROT (data channel PROTection level) accepte 4 arguments : o C (Clear), les données ne sont pas chiffrées. o S (Safe), l intégrité des données est assurée (aucune modification possible avant d'arriver à destination). o E (Confidential), la confidentialité des données est assurée (seuls l'émetteur et le destinataire voient les informations échangées en clair). o P (Private), intégrité et confidentialité assurées, la protection est complète. Le chiffrement TLS sur FTP n accepte que les arguments C et P de la commande PROT. Certificats SSL / TLS Le fonctionnement de FTPS, comme celui de HTTPS, nécessite que le serveur soit authentifié par un certificat, lequel doit être signé par une autorité de certification. Le certificat peut être auto-signé sur le serveur FTPS, du point de vue du client FTPS, tout dépend de la confiance qu il est prêt à lui accorder, ce type de comportement est suffisant dans un réseau de confiance. En revanche, il est conseillé de faire appel à une autorité de certification publique lorsque le flux FTPS doit transiter sur Internet. Page 3 sur 8 Version du 13/11/2013
Considérations sur l analyse FAST Atelier de tests avec une appliance Fast360 FTP dépend d un module FAST spécifique sur une appliance Fast360. Ce module est chargé d effectuer une analyse protocolaire jusqu au niveau 7 du modèle OSI afin de garantir le respect des RFC d une part, et gère automatiquement la connexion secondaire d autre part. En pratique, l utilisation du seul service ftp-factory est suffisante dans une règle de flux pour autoriser le transfert par FTP, ce service étant par défaut soumis à un module FAST qui prend en charge le canal de contrôle, détermine le fonctionnement de l échange (mode actif, mode passif), et gère automatiquement le canal de données (ouverture dynamique des ports nécessaires à l échange). Un échange FTPS en mode explicite utilise le port 21 (connexion sur le canal de données), mais le module FAST bloque le comportement FTPS (commandes AUTH SSL ou AUTH TLS, demande par le client de la vérification de la clé publique du serveur, ). Il n existe pas encore de module FAST pour le protocole FTPS. Dès lors, il est impératif de créer les services FTPS (2 services puisque le protocole utilise deux canaux) manuellement. Il ne faut pas oublier que l analyse FAST permet de vérifier l adéquation des échanges avec le protocole tel que défini dans les RFC, mais que les données échangées en FTP circulent en clair sur le réseau. FTPS ne dépendant pas d un module FAST, l analyse des paquets s arrête au niveau 4 du modèle OSI, mais les flux étant chiffrés, la sécurité est très satisfaisante. Choix techniques effectués La méthode choisie est le FTPS explicite, en mode passif, avec chiffrement des deux canaux. Filezilla est le logiciel choisi pour la démonstration (il est capable de gérer les différents modes d échange avec FTP, FTPS, SFTP), côté client comme côté serveur. Le certificat du serveur est un certificat auto-signé. Page 4 sur 8 Version du 13/11/2013
Topologie réseau utilisée pour les tests eth0 192.168.10.254/24 FAST360 eth1 192.168.20.254 CLIENT FTPS 192.168.10.1 SERVEUR FTPS 192.168.20.1 Configuration du serveur FTPS Pour rappel, le serveur qui fonctionne en mode passif précise au client le port d écoute utilisé pour monter la connexion secondaire (canal de données). Les ports 2121 à 2125 sont choisis ici. Page 5 sur 8 Version du 13/11/2013
Le mode explicite choisi doit permettre le chiffrement des données sur le canal de contrôle par la commande AUTH TLS, puis sur le canal de données par la commande PROT P. Par ailleurs, un certificat généré par le serveur Filezilla (bouton «Generate new certificate») et stocké sur l hôte serveur sera présenté au client. Page 6 sur 8 Version du 13/11/2013
Configuration de l appliance Fast360 en coupure FTPS explicite utilise deux canaux qui ne dépendent pas d un module FAST, il est nécessaire de créer 2 services TCP utilisateur : FTPS-EXPLICITE-CONTROLE : service sur le port 21 mais sans module FAST, FTPS-EXPLICITE-DONNEES : service sur la plage de ports définie sur le serveur FTPS en mode passif (2121 à 2125 dans cet atelier de tests). Les deux services créés seront utilisés dans une règle de flux sur l appliance en coupure. Note Si le client FTPS se situe côté Internet, l accès au serveur FTPS s effectue par une règle de flux ayant comme destination le serveur FTPS sur lequel une translation de NAT statique est effectuée : l objet hôte représentant le serveur FTPS est édité et la case Translater l adresse IP de cet hôte (NAT statique) est cochée, avec l IP côté public de l appliance Fast360 comme adresse IP de translation. Page 7 sur 8 Version du 13/11/2013
Vérification des échanges entre le client et le serveur FTPS Le dialogue entre le client FTPS situé dans le réseau 10 et le serveur FTPS (192.168.20.1) de l atelier de tests est détaillé ci-après. Dès que le serveur répond à la requête initiale du client, ce dernier demande un chiffrement TLS sur le canal de contrôle L authentification de l utilisateur (entrée du mot de passe) est postérieure à la mise en place du chiffrement Le serveur précise les méthodes avec lesquelles il est compatible, dont le chiffrement sur le canal de données avec la commande PROT Les commandes PBSZ et PROT sont envoyées par le client FTPS pour demander le chiffrement sur le canal de données Le canal de données est utilisé pour lister le contenu du répertoire distant Connexion à 192.168.20.1:21... Connexion établie, attente du message d'accueil... 220-FileZilla Server version 0.9.41 220-written by Tim Kosse (Tim.Kosse@gmx.de) 220 Please visit http://sourceforge.net/projects/filezilla/ AUTH TLS 234 Using authentication type TLS Initialisation de TLS... Vérification du certificat... USER test Connexion TLS/SSL établie. 331 Password required for test PASS ********* 230 Logged on SYST 215 UNIX emulated by FileZilla FEAT 211-Features: MDTM REST STREAM SIZE MLST type*;size*;modify*; MLSD AUTH SSL AUTH TLS PROT PBSZ UTF8 CLNT MFMT 211 End PBSZ 0 200 PBSZ=0 PROT P 200 Protection level set to P Connecté Récupération du contenu du dossier... PWD 257 "/" is current directory. TYPE I 200 Type set to I PASV 227 Entering Passive Mode (192,168,20,1,8,73) MLSD 150 Connection accepted 226 Transfer OK Contenu du dossier affiché avec succès Page 8 sur 8 Version du 13/11/2013