[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: vsftpd sur ssl



Pascal Hambourg wrote:
bonjour pascal
Salut,

Matthieu a écrit :

mon architecture reseau est la suivante:
- un routeur assure la connexion entre la dmz et l'internet via du nat.

Du NAT -> gagné ! ;-)
Sous Linux le routeur ?
non un routeur materiel.

- le serveur a pour ip 192.168.25.10
- sur le serveur un iptables avec comme regles a la fin un logging des
packets non autorisés

Et comment sont gérées les connexions de données FTP ?

- une configuration de vsftpd en mode passif pour des hotes virtuels:

listen=YES
pasv_enable=YES
pasv_promiscuous=YES
pasv_min_port=10000
pasv_max_port=20000
ssl_enable=YES
[...]
seulement lorsque je me connectes avec mon client ftp filezilla 2.2.18 en
ftp sur tls, j'obtiens le log suivant:
[...]
Commande :    PASV
Réponse :    227 Entering Passive Mode (192,168,25,10,59,167)
Commande :    LIST
Erreur :    Le canal de transfert n'a pas pu être ouvert.


et puis plus rien. rien dans le syslog concernant iptables, rien dans les
logs de mon routeur concernant des paquets rejetés.

Examine la réponse du serveur à la commande PASV : l'adresse transmise en vue d'établir la connexion de données est 192.168.25.10, l'adresse privée du serveur. Il est évidemment impossible pour un client extérieur de joindre le serveur à cette adresse qui n'a de sens que sur le réseau local du serveur. Comme le client cherche à se connecter à cette adresse privée non routée sur internet, il est normal que ni le routeur ni le serveur ne voient rien arriver.
oui j'ai bien vu la reponse, mais ce comportement n'est pas genant en mode non ssl.

que puis je faire ou que me manque t'il dans ma configuration vsftpd ou ssl
pour que je puisse utiliser vsftpd sur ssl?

Quand le routeur NAT est un Linux 2.4 ou ultérieur, la solution classique consiste à utiliser les modules de suivi et de NAT FTP ip_conntrack_ftp et ip_nat_ftp de Netfilter qui lisent et modifient à la volée l'adresse et le port des commandes PASV et PORT dans le flux de la connexion FTP de contrôle. Mais le chiffrement par SSL/TLS de cette connexion les empêche de le faire.

Que reste-t-il ?

Première option, passer vsftpd en mode FTP actif. Ainsi les connexions de données seront sortantes. Mais si le client est aussi derrière un NAT ou un firewall, il risque d'avoir en mode actif le même problème que le serveur en mode passif.

L'autre solution que je connais consiste à :
- limiter la plage de ports en mode passif de vsftpd (déjà fait mais la plage 10000-20000 me semble inutilement étendue) ;
ok

en ce qui concerne ces trois points, ils sont a utiliser separement j'imagines?
- au niveau du routeur NAT et du firewall, autoriser en entrée depuis l'extérieur et rediriger cette plage de ports vers l'adresse privée du serveur ; *
heu, il faut que je fasse du filtrage sur un grand nombre de port? pas que ce soit impossible mais moins j'ai de ports d'ouverts, mieux je me porte :)
- forcer vsftpd à annoncer l'adresse IP publique du routeur au lieu de son adresse locale dans les réponses aux commandes PASV avec l'option "pasv_address". (*)
(*) Ça peut être laborieux si l'adresse en question n'est pas fixe : il faut la récupérer, modifier vsftpd.conf et relancer vsftpd s'il fonctionne en démon.
c'est une ip fixe, ca ne pose pas de problemes

Opinion personnelle : ce ne devrait pas être bien difficile de permettre de spécifier un nom d'hôte au lieu d'une adresse IP numérique et de résoudre ce nom d'hôte à chaque commande PASV, afin de pouvoir utiliser un DNS dynamique et de ne pas avoir besoin de modifier vsftpd.conf ni de relancer vsftpd à chaque changement d'adresse.

merci pour toutes ses pistes en tout cas :)



2006/1/21, Pascal Hambourg <pascal.mail@plouf.fr.eu.org>:
Salut,

Matthieu a écrit :
>
> je desespere quand a la configuration de mon serveur vsftpd. je n'arrive pas
> a recuperer la liste de mes dossiers bien que j'arrive a me connecter.

Sans lire la suite je parie déjà qu'il y a du NAT ou du filtrage
là-dessous. Le protocole FTP, à cause de sa complexité, ne fait pas
toujours bon ménage avec ces deux-là.

> mon architecture reseau est la suivante:
> - un routeur assure la connexion entre la dmz et l'internet via du nat.

Du NAT -> gagné ! ;-)
Sous Linux le routeur ?

> - le serveur a pour ip 192.168.25.10
> - sur le serveur un iptables avec comme regles a la fin un logging des
> packets non autorisés

Et comment sont gérées les connexions de données FTP ?

> - une configuration de vsftpd en mode passif pour des hotes virtuels:
>
> listen=YES
> pasv_enable=YES
> pasv_promiscuous=YES
> pasv_min_port=10000
> pasv_max_port=20000
> ssl_enable=YES
[...]
> seulement lorsque je me connectes avec mon client ftp filezilla 2.2.18 en
> ftp sur tls, j'obtiens le log suivant:
[...]
> Commande :    PASV
> Réponse :    227 Entering Passive Mode (192,168,25,10,59,167)
> Commande :    LIST
> Erreur :    Le canal de transfert n'a pas pu être ouvert.


> et puis plus rien. rien dans le syslog concernant iptables, rien dans les
> logs de mon routeur concernant des paquets rejetés.

Examine la réponse du serveur à la commande PASV : l'adresse transmise
en vue d'établir la connexion de données est 192.168.25.10 , l'adresse
privée du serveur. Il est évidemment impossible pour un client extérieur
de joindre le serveur à cette adresse qui n'a de sens que sur le réseau
local du serveur. Comme le client cherche à se connecter à cette adresse
privée non routée sur internet, il est normal que ni le routeur ni le
serveur ne voient rien arriver.

> que puis je faire ou que me manque t'il dans ma configuration vsftpd ou ssl
> pour que je puisse utiliser vsftpd sur ssl?

Quand le routeur NAT est un Linux 2.4 ou ultérieur, la solution
classique consiste à utiliser les modules de suivi et de NAT FTP
ip_conntrack_ftp et ip_nat_ftp de Netfilter qui lisent et modifient à la
volée l'adresse et le port des commandes PASV et PORT dans le flux de la
connexion FTP de contrôle. Mais le chiffrement par SSL/TLS de cette
connexion les empêche de le faire.

Que reste-t-il ?

Première option, passer vsftpd en mode FTP actif. Ainsi les connexions
de données seront sortantes. Mais si le client est aussi derrière un NAT
ou un firewall, il risque d'avoir en mode actif le même problème que le
serveur en mode passif.

L'autre solution que je connais consiste à :
- limiter la plage de ports en mode passif de vsftpd (déjà fait mais la
plage 10000-20000 me semble inutilement étendue) ;
- au niveau du routeur NAT et du firewall, autoriser en entrée depuis
l'extérieur et rediriger cette plage de ports vers l'adresse privée du
serveur ;
- forcer vsftpd à annoncer l'adresse IP publique du routeur au lieu de
son adresse locale dans les réponses aux commandes PASV avec l'option
"pasv_address". (*)

(*) Ça peut être laborieux si l'adresse en question n'est pas fixe : il
faut la récupérer, modifier vsftpd.conf et relancer vsftpd s'il
fonctionne en démon.
Opinion personnelle : ce ne devrait pas être bien difficile de permettre
de spécifier un nom d'hôte au lieu d'une adresse IP numérique et de
résoudre ce nom d'hôte à chaque commande PASV, afin de pouvoir utiliser
un DNS dynamique et de ne pas avoir besoin de modifier vsftpd.conf ni de
relancer vsftpd à chaque changement d'adresse.


--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench

Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"

To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org



Reply to: