Encore du FTP derriere pfSense
-
Bonjour à tous,
Voici les données du probleme:
- Un serveur FTP sur un lan derriere pfSense
- Un client qui ne peut faire que du passif
- Un client qui ne comprend pas quand le ftp lui demande de passer en mode passif sur l'ip privée du serveur
- Un serveur qui ne sait pas donner autre chose que son ip privée
Bilan, ça rale…
Sur notre ancienne infra, nous avions un PIX Cisco qui savait faire le NAT de l'ip privée du serveur sur la couche 7 dans le protocole FTP. Bilan, le serveur annonçait son ip privée et le client recevait l'ip publique
Comment nous en sortir avec pfSense ? Je suppose que nous ne sommes pas les seuls dans ce cas...
Merci d'avance pour votre aide
-
Depuis la version 2.2, les concepteurs ont retiré le 'helper' (et le ftp-proxy) nécessaire à cause du NAT arguant du fait que le protocole est peu sûr.
La page https://doc.pfsense.org/index.php/Howto_setup_ftp_server_behind_pfsense indique la méthode à utiliser.
A noter :
- le mode idéal est 'actif' mais sous certaines (fortes) conditions le client pourra être en passif
- tous les serveurs n'ont pas la possibilité d'être configuré comme indiqué : vsftpd et filezilla sont OK
NB : le client incapable sera remplacé par un client capable et sérieux (filezilla par exemple) !
Pour être plus précis,
- avec pfsense 1.x, présence du 'helper'
- depuis pfsense 2.0, remplacement par 'ftp-proxy' (dans le kernel)
- depuis pfsense 2.2, retrait du 'ftp-proxy' (!)
Quelques liens utiles :
- https://doc.pfsense.org/index.php/FTP_without_a_Proxy : position après 2.2
- https://doc.pfsense.org/index.php/FTP_Troubleshooting : point de vue concepteurs et suggestion de remplacement
- http://shorewall.net/FTP.html : tour d'horizon sur le protocole et les problématiques
-
@jdh:
La page https://doc.pfsense.org/index.php/Howto_setup_ftp_server_behind_pfsense indique la méthode à utiliser.
Mais cette méthode nécessite que le serveur sache répondre avec une IP publique, autrement dit pas la sienne, et si je comprends bien, le serveur actuellement utilisé ne sait pas faire ça.
Pour en revenir au problème initial, un proxy FTP sur une dmz me semble être une bonne solution qui permet en plus de servir éventuellement plusieurs serveurs FTP internes.
-
Tout, ou presque a été dit sur le sujet. Il certain que le proxy en dmz est une bonne méthode.
Mais il en est une meilleure, difficile à intégrer à cause des contraintes opérationnelles : supprimer l'utilisation du protocole FTP. Ce n'est pas très facile à réaliser compte tenu de l'héritage. Toutefois aucun nouveau projet ne devrait envisager FTP comme solution technique compte tenu de sa conception qui rend très aléatoire (et difficile) sa sécurisation. -
Tout n'a pas été dit.
Bien sur, le protocole est vieux et insecure en standard (= sans cryptage)
Bien sur, il est probable que le helper ou le ftp-proxy puissent être faible voire faillible.
Bien sur, il est souhaitable de considérer d'autres protocoles pour l'avenir …Mais des serveurs et des clients peuvent fonctionner (avec des contraintes, certes) !
S'il existe variétés de serveurs et de clients, c'est que certains ont observé des faiblesses !Je refuse d'entendre "il faut que cela fonctionne avec le client ftp intégré à Internet Explorer" !
Et oui cela ne fonctionne pas avec le client ftp d'IE et surement le serveur ftp d'IIS.
Alors que cela devrait fonctionner avec Filezilla client et vsftpd.Je ne dis pas que ce sont les meilleurs, mais je dis qu'un bon sysadmin doit savoir changer ses habitudes et changer d'outils s'il le faut !
-
Je ne dis pas que ce sont les meilleurs, mais je dis qu'un bon sysadmin doit savoir changer ses habitudes et changer d'outils s'il le faut !
C'est à ce prix que l'on sécurise !