j'installe chez mes clients une application
se basant sur le client WS_FTP Pro et qui
se connecte à WS_FTP Server en FTP SSL
et mode passif.
Mon problème est que ce type de connexion
nécessite un paramétrage particulier des
firewalls et que je suis assez inculte
en la matière.
Je souhaiterais trouver un ensemble d'indications
claires que je pourrais communiquer à chaque administrateur
firewall de mes clients et qui précise les règles à appliquer
du type :
"le firewall doit laisser le client adresser
un port aléatoire > 1024 sur le serveur d'IP xxx.yyy.ddd.fff"
Je précise que mes clients FTP s'adressent tous à un seul et unique
serveur, ce qui peut permettre un paramétrage plus sécurisé
en ne laissant passer les paquets que sur cette adresse
Je vous demande de l'aide car chez le client que je viens
d'installer, un transfert FTP passive mode "non SSL"
ne pose aucun problème. C'est l'utilisation du SSL qui
ammène un blocage dès le début de la connexion.
Je crois en fait que son firewall "WatchGuard" analyse
le contenu des trames cryptées et ne veut pas les laisser
passer car non reconnues comme du FTP.
Ma méconnaissance de ce type d'administration ne me
permet pas d'édicter clairement à mes clients les consignes
à appliquer sur n'importe quel type de firewall pour que
cette connexion fonctionne.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Michel Arboi
"Gael" writes:
j'installe chez mes clients une application se basant sur le client WS_FTP Pro et qui se connecte à WS_FTP Server en FTP SSL et mode passif.
Je suppose qu'il s'agit de FTPS. Si oui, une petite explication : la négociation commence normalement, de façon à ce que les clients FTP de base puisse rester compatibles avec les serveurs FTPS (drôle d'idée). Après l'authentification par mot de passe classique, le client envoie AUTH TLS pour basculer en SSL. Si je me souviens bien, rien n'oblige à chiffrer toutes les communications, mais dans ce cas, on se demande à quoi ça pourrait bien servir :) Notez que si vous ne forcez pas l'authentification par certificat, ce bazar ce contentera du mot de passe initial, ce qui ne vaut pas mieux qu'un FTP classique.
Mon problème est que ce type de connexion nécessite un paramétrage particulier des firewalls et que je suis assez inculte en la matière.
FTP nécessite une gestion particulière car il ouvre des connexions n'importe où et dans tous les sens (sauf si on le force à travailler en mode "passif") Ça déplait aux filtres IP. Le truc classique consiste à surveiller ce qui passe sur la connexion de contrôle (client -> serveur:21), repérer les commandes PASV ou PORT et créer des règles dynamiques pour autoriser les connexions de données à la volée. Quand le tuyau est chiffré, on ne voit plus rien passer et ce "truc classique" ne marche plus. Honnêtement, ça me paraît être un obstacle majeur au déploiement de FTPS en milieu paranoïaque.
Je souhaiterais trouver un ensemble d'indications claires que je pourrais communiquer à chaque administrateur firewall de mes clients et qui précise les règles à appliquer du type : "le firewall doit laisser le client adresser un port aléatoire > 1024 sur le serveur d'IP xxx.yyy.ddd.fff"
Supérieur _ou égal_ à 1024, mais sinon c'est ça. Il est possible que le serveur FTPS puisse être configurer pour allouer les ports DATA dans une plage plus restreinte. Ça pourrait être pire : en mode "actif", il faudrait autoriser le serveur à se connecter sur tous les ports > 1023 des clients.
Je précise que mes clients FTP s'adressent tous à un seul et unique serveur, ce qui peut permettre un paramétrage plus sécurisé en ne laissant passer les paquets que sur cette adresse
L'autre solution, c'est SFTP, c'est-à-dire un genre de FTP sur SSH. Quand on voit la pile d'avis de sécurité contre la bête, ça fait un peu peur aussi.
Je crois en fait que son firewall "WatchGuard" analyse le contenu des trames cryptées et ne veut pas les laisser passer car non reconnues comme du FTP.
Ben voila.
Ma méconnaissance de ce type d'administration ne me permet pas d'édicter clairement à mes clients les consignes à appliquer sur n'importe quel type de firewall pour que cette connexion fonctionne.
Vous aviez bien compris le problème.
-- http://arboi.da.ru FAQNOPI de fr.comp.securite http://faqnopi.da.ru/
"Gael" <nospam@nospam.fr> writes:
j'installe chez mes clients une application
se basant sur le client WS_FTP Pro et qui
se connecte à WS_FTP Server en FTP SSL
et mode passif.
Je suppose qu'il s'agit de FTPS. Si oui, une petite explication :
la négociation commence normalement, de façon à ce que les clients FTP
de base puisse rester compatibles avec les serveurs FTPS (drôle
d'idée). Après l'authentification par mot de passe classique, le
client envoie AUTH TLS pour basculer en SSL. Si je me souviens bien,
rien n'oblige à chiffrer toutes les communications, mais dans ce cas,
on se demande à quoi ça pourrait bien servir :)
Notez que si vous ne forcez pas l'authentification par certificat, ce
bazar ce contentera du mot de passe initial, ce qui ne vaut pas mieux
qu'un FTP classique.
Mon problème est que ce type de connexion
nécessite un paramétrage particulier des
firewalls et que je suis assez inculte
en la matière.
FTP nécessite une gestion particulière car il ouvre des connexions
n'importe où et dans tous les sens (sauf si on le force à travailler
en mode "passif")
Ça déplait aux filtres IP. Le truc classique consiste à surveiller ce
qui passe sur la connexion de contrôle (client -> serveur:21), repérer
les commandes PASV ou PORT et créer des règles dynamiques pour
autoriser les connexions de données à la volée.
Quand le tuyau est chiffré, on ne voit plus rien passer et ce "truc
classique" ne marche plus. Honnêtement, ça me paraît être un obstacle
majeur au déploiement de FTPS en milieu paranoïaque.
Je souhaiterais trouver un ensemble d'indications
claires que je pourrais communiquer à chaque administrateur
firewall de mes clients et qui précise les règles à appliquer
du type :
"le firewall doit laisser le client adresser
un port aléatoire > 1024 sur le serveur d'IP xxx.yyy.ddd.fff"
Supérieur _ou égal_ à 1024, mais sinon c'est ça. Il est possible que
le serveur FTPS puisse être configurer pour allouer les ports DATA
dans une plage plus restreinte.
Ça pourrait être pire : en mode "actif", il faudrait autoriser le
serveur à se connecter sur tous les ports > 1023 des clients.
Je précise que mes clients FTP s'adressent tous à un seul et unique
serveur, ce qui peut permettre un paramétrage plus sécurisé
en ne laissant passer les paquets que sur cette adresse
L'autre solution, c'est SFTP, c'est-à-dire un genre de FTP sur
SSH. Quand on voit la pile d'avis de sécurité contre la bête, ça fait
un peu peur aussi.
Je crois en fait que son firewall "WatchGuard" analyse
le contenu des trames cryptées et ne veut pas les laisser
passer car non reconnues comme du FTP.
Ben voila.
Ma méconnaissance de ce type d'administration ne me
permet pas d'édicter clairement à mes clients les consignes
à appliquer sur n'importe quel type de firewall pour que
cette connexion fonctionne.
Vous aviez bien compris le problème.
--
arboi@alussinan.org http://arboi.da.ru
FAQNOPI de fr.comp.securite http://faqnopi.da.ru/
j'installe chez mes clients une application se basant sur le client WS_FTP Pro et qui se connecte à WS_FTP Server en FTP SSL et mode passif.
Je suppose qu'il s'agit de FTPS. Si oui, une petite explication : la négociation commence normalement, de façon à ce que les clients FTP de base puisse rester compatibles avec les serveurs FTPS (drôle d'idée). Après l'authentification par mot de passe classique, le client envoie AUTH TLS pour basculer en SSL. Si je me souviens bien, rien n'oblige à chiffrer toutes les communications, mais dans ce cas, on se demande à quoi ça pourrait bien servir :) Notez que si vous ne forcez pas l'authentification par certificat, ce bazar ce contentera du mot de passe initial, ce qui ne vaut pas mieux qu'un FTP classique.
Mon problème est que ce type de connexion nécessite un paramétrage particulier des firewalls et que je suis assez inculte en la matière.
FTP nécessite une gestion particulière car il ouvre des connexions n'importe où et dans tous les sens (sauf si on le force à travailler en mode "passif") Ça déplait aux filtres IP. Le truc classique consiste à surveiller ce qui passe sur la connexion de contrôle (client -> serveur:21), repérer les commandes PASV ou PORT et créer des règles dynamiques pour autoriser les connexions de données à la volée. Quand le tuyau est chiffré, on ne voit plus rien passer et ce "truc classique" ne marche plus. Honnêtement, ça me paraît être un obstacle majeur au déploiement de FTPS en milieu paranoïaque.
Je souhaiterais trouver un ensemble d'indications claires que je pourrais communiquer à chaque administrateur firewall de mes clients et qui précise les règles à appliquer du type : "le firewall doit laisser le client adresser un port aléatoire > 1024 sur le serveur d'IP xxx.yyy.ddd.fff"
Supérieur _ou égal_ à 1024, mais sinon c'est ça. Il est possible que le serveur FTPS puisse être configurer pour allouer les ports DATA dans une plage plus restreinte. Ça pourrait être pire : en mode "actif", il faudrait autoriser le serveur à se connecter sur tous les ports > 1023 des clients.
Je précise que mes clients FTP s'adressent tous à un seul et unique serveur, ce qui peut permettre un paramétrage plus sécurisé en ne laissant passer les paquets que sur cette adresse
L'autre solution, c'est SFTP, c'est-à-dire un genre de FTP sur SSH. Quand on voit la pile d'avis de sécurité contre la bête, ça fait un peu peur aussi.
Je crois en fait que son firewall "WatchGuard" analyse le contenu des trames cryptées et ne veut pas les laisser passer car non reconnues comme du FTP.
Ben voila.
Ma méconnaissance de ce type d'administration ne me permet pas d'édicter clairement à mes clients les consignes à appliquer sur n'importe quel type de firewall pour que cette connexion fonctionne.
Vous aviez bien compris le problème.
-- http://arboi.da.ru FAQNOPI de fr.comp.securite http://faqnopi.da.ru/
