FTP est un protocole de transfert de fichiers legacy qui utilise des canaux de contrôle et de données séparés. Tandis que le trafic web et API moderne est protégé par des tokens, TLS, des politiques de session et des contrôles WAAP, FTP dans la plupart des organisations fonctionne encore au niveau « ouvrir le port, vérifier nom d'utilisateur et mot de passe ». Les workflows EDI, les transferts batch, les échanges de fichiers partenaires, les ponts mainframe et les systèmes de documents legacy fonctionnent donc en dehors de la visibilité sécurité.
La sécurité réseau traditionnelle offre deux options faibles pour FTP. Soit le port 21 est ouvert et personne ne peut voir quelles commandes passent, soit FTP est complètement supprimé et un projet d'intégration de plusieurs mois commence. De nombreux systèmes legacy ne peuvent pas absorber rapidement cette transition.
Utiliser FTPS seul ne suffit pas non plus. Le trafic peut être chiffré, mais les questions demeurent : quel utilisateur exécute quelle commande, quel fichier est récupéré ou envoyé, quel backend est accédé, la connexion de données vient-elle de la bonne source, et depuis combien de temps la session est-elle ouverte.
La conception du protocole FTP crée une surface d'attaque spécifique. La commande PORT peut diriger les connexions de données vers des adresses tierces, les transferts serveur-à-serveur de type FXP peuvent être abusés, et les comptes anonymes ou partagés faibles peuvent rester ouverts pendant de longues périodes. Ces risques sont difficiles à observer au niveau réseau ; une conscience de session FTP au niveau applicatif est nécessaire.
La couche proxy de sécurité FTP TR7 WAAP fait fonctionner les services FTP classiques — sans les supprimer — sous liste blanche de commandes, politique par utilisateur, mitigation bounce/FXP, contrôle de session et audit forensique.
TR7 WAAP traite FTP non pas comme une décision d'ouverture de port mais comme une session applicative autorisée par utilisateur et auditée commande par commande.
Les commandes FTP telles que RETR, STOR, DELE, MKD, RMD, LIST, NLST, RNFR, RNTO, SIZE et MDTM sont placées sur une liste allow/deny individuelle. Les commandes inconnues ou absentes de la politique sont rejetées par défaut.
Le nom d'utilisateur FTP peut être utilisé comme clé de politique. Différents utilisateurs se connectant via la même VIP peuvent fonctionner avec des ensembles de commandes différents, des timeouts différents et des pools backend différents.
La source de la connexion de données est corrélée avec la connexion de contrôle. Les tentatives PORT dirigées vers des adresses tierces ou le comportement de transfert serveur-à-serveur sont bloqués par défaut ; les exceptions sont définies par une décision de politique explicite.
Chaque session, commande et transfert de fichier est écrit dans le journal d'audit. Le mode monitor affiche le chemin de fichier complet ; le mode filecopy peut stocker une copie horodatée de chaque fichier transféré.
Le Proxy de Sécurité FTP intègre les faiblesses de commandes, utilisateurs, canal de données, session et audit du protocole FTP classique dans le modèle de politique WAAP.
TR7 gère les commandes FTP standard comme des décisions allow/deny au niveau politique. Dans un rôle lecture seule, des commandes telles que RETR, LIST, NLST, SIZE, MDTM et STAT restent ouvertes tandis que STOR, DELE, RMD ou RNTO peuvent être refusées. Dans un rôle de téléchargement, seuls STOR et les commandes de répertoire nécessaires sont autorisés. Cela garantit que « a un accès FTP » ne se traduit pas par des permissions de fichiers illimitées.
Le nom d'utilisateur est lu lors de la phase de connexion et alimenté dans le moteur de politique WAAP. Deux utilisateurs se connectant à la même VIP peuvent fonctionner avec des ensembles de commandes différents, des durées de session différentes, une profondeur d'audit différente et des pools backend différents. Cette architecture consolide les transferts de fichiers basés sur les partenaires, les départements ou les tenants en un seul point d'entrée. Les équipes opérationnelles définissent les limites de sécurité par utilisateur.
Un utilisateur peut être dirigé vers un pool backend spécifique tandis qu'un autre est routé vers un pool différent. Le modèle de sélection client `user@server` peut être utilisé, ou TR7 peut résoudre l'utilisateur vers le backend approprié via une table centrale. Cela élimine le besoin d'ouvrir de nombreuses VIP séparées pour le FTP partenaire B2B, le partage de département ou la séparation de tenants. Le routage contrôlé se fait sous un seul point d'entrée.
Les modes FTP actif et passif se comportent différemment par rapport à la connexion de données. TR7 corrèle les flux PORT et PASV avec la session pour garantir que le canal de données est établi correctement. La plage de ports passifs peut être restreinte par politique ; l'IP source vers le backend peut être épinglée. Cela réduit les échecs de transfert pour les services FTP derrière NAT et pare-feux.
Dans les attaques FTP bounce, la commande PORT tente de diriger les connexions de données vers une cible tierce. TR7 peut rejeter ce comportement en faisant correspondre la connexion de données avec le point d'extrémité réel de la connexion de contrôle. Le comportement de transfert serveur-à-serveur similaire à FXP peut être maintenu désactivé par défaut. Les exceptions requises sont définies explicitement ; une faille de sécurité n'est jamais le comportement par défaut.
Les sessions FTP peuvent être évaluées par IP source, pays, ASN, fenêtre temporelle ou informations utilisateur. Les connexions en dehors de pays partenaires spécifiques ou de plages IP d'entreprise peuvent être rejetées. Cela apporte l'approche de contrôle d'accès utilisée côté web et API au FTP également. Les flux de transfert de fichiers legacy sont liés à la politique d'accès moderne.
Les sessions FTP peuvent rester ouvertes pendant de longues périodes et consommer des sockets sur le backend. TR7 peut gérer des limites telles que le timeout de connexion, le timeout d'inactivité et la durée totale de session au niveau politique. Une durée de session par défaut de 900 secondes peut être utilisée comme référence et ajustée selon les besoins. Les sessions inactives sont fermées sans garder le backend en attente.
Les clients FTP peuvent changer de répertoires avec CWD puis émettre des commandes de fichiers relatives. Le mode monitor suit le répertoire de travail au sein de la session et journalise les commandes telles que `RETR file.csv` avec leur chemin de fichier complet. L'enregistrement d'audit montre donc non seulement la commande mais aussi l'emplacement réel du fichier. L'investigation post-incident clarifie exactement quel fichier a été récupéré ou envoyé.
Pour les besoins de conformité ou d'investigation forensique, une copie de chaque fichier transféré peut être écrite dans une zone de stockage séparée. Les fichiers peuvent être maintenus dans une structure de répertoires basée sur les dates et corrélés avec le journal d'audit. Cela signifie que la question « quel fichier a été envoyé ? » peut être répondue non seulement avec une entrée de log mais avec le fichier lui-même. Les preuves d'audit sont renforcées dans les secteurs réglementés.
Lorsque FTPS est utilisé, le canal de contrôle est chiffré, mais les commandes doivent être comprises pour appliquer la politique de sécurité. La couche proxy de sécurité FTP TR7 WAAP termine la session FTPS au niveau sécurité et peut inspecter les commandes. Sous AUTH TLS, le transfert vers le backend peut être re-chiffré ou adapté au modèle de réseau interne. La politique des certificats et TLS s'aligne avec le pool de gestion central.
Le Proxy de Sécurité FTP est exploité conjointement avec le traitement des commandes, le cycle de vie de la connexion de données, le comportement HA, le streaming d'audit, les limites de ressources et les politiques de rétention de conformité.
Chaque commande FTP est reçue depuis le canal de contrôle, analysée, évaluée contre la liste ValidCommands et la politique utilisateur. Une commande autorisée est transmise au backend. Une commande rejetée retourne une réponse d'erreur compatible protocole (502 ou 550) ; le client reste compatible protocole.
Lorsqu'une commande PORT ou PASV est vue, TR7 associe la connexion de données à la session. Des connexions de données séparées existent entre le client et TR7, et entre TR7 et le backend. Cette structure permet de fermer la session de manière contrôlée si une violation de politique est détectée pendant un transfert.
Les nouvelles sessions FTP s'ouvrent sur le nœud actif avec la même politique. Les grands transferts de données en cours peuvent être interrompus lors d'un événement de basculement en raison de la nature du protocole ; si le client prend en charge la reprise, le transfert peut être redémarré ou continué. Les transferts critiques doivent donc être testés pour le comportement client avant le déploiement en production.
Des logs séparés peuvent être produits au niveau de la session, de la commande et du transfert. Les logs peuvent être envoyés au flux SIEM dans un format structuré. Le mode monitor ajoute le chemin de fichier complet à la ligne de log ; le mode filecopy ajoute l'emplacement de la copie de fichier stockée.
Le nombre de sessions simultanées, les sessions par utilisateur, les sessions par IP, la taille des fichiers et le taux de transfert peuvent tous être restreints par politique. Cela empêche un seul utilisateur ou une tâche batch dysfonctionnelle d'épuiser l'infrastructure FTP. La bande passante et le timeout doivent être planifiés ensemble pour les grands transferts de fichiers.
Le chemin complet, l'horodatage, les informations utilisateur et, si nécessaire, une copie du fichier de chaque fichier transféré peuvent être conservés. La durée de rétention est définie selon la politique de conformité de l'organisation. Lors d'un audit, le trafic FTP n'est plus une zone sombre.
Une institution financière ou une agence gouvernementale peut échanger des fichiers EDI avec des partenaires via FTP. TR7 route chaque partenaire derrière une VIP unique vers son propre pool backend, n'ouvre que les commandes autorisées et place chaque transfert sous audit.
Si une plateforme de documents legacy ne supporte que le téléchargement FTP, TR7 peut être placé en frontal sans toucher au système. La politique n'ouvre que STOR et les commandes de répertoire nécessaires tout en rejetant les commandes de suppression et de renommage.
Dans les intégrations qui récupèrent des fichiers d'un système mainframe, l'utilisateur peut être limité aux commandes lecture seule telles que RETR, LIST et SIZE. STOR, DELE, RNFR, RNTO, MKD et RMD sont rejetés, réduisant le risque de modification des données.
Lorsqu'une équipe de santé ou de recherche envoie des ensembles de données à des partenaires externes, chaque transfert peut être conservé avec filecopy. Les limites de taille de fichier, la politique par utilisateur et le streaming de logs SIEM rendent le processus de partage auditable de bout en bout.
Liste blanche de commandes, politique par utilisateur, protection bounce/FXP et audit forensique. Laissez-nous vous guider à travers une configuration en direct sur votre propre infrastructure FTP.