FTP forwarding sur un port non standard et ftp-helper

GLR

Bonjour,

D'après mes tests, il semble que le ftp-helper (pftpx) ne s'active que sur un NAT sur le port standard FTP (tcp-21).
Observez-vous cette même limitation ?

Si oui, c'est une limitation importante : laisser un ftp en accès public sur le port standard de son IP publique est à déconseiller très fortement…

Au final, d'après mes tests :

Ce qui marche :

NAT FTP sur le port standard (tcp-21)
FTP helper activé sur l'interface WAN
Attention : la règle de filtrage doit alors autoriser l'accès sur l'adresse de l'interface WAN, c'est une exception dans pfSense et c'est certainement dû à l'utilisation du ftp helper qui est une sorte de proxy ftp.
Côté client : modes passif et actif supportés

Ce qui ne marche pas :

NAT FTP sur un port non standard, car le ftp-helper n'est actif que sur le port 21 (pfSense ne faisant en effet pas d'analyse protocolaire, il n'est pas capable de détecter automatiquement les connexions ftp)

Contournement (pas super propre) :

Configurer son serveur ftp pour renvoyer son IP publique
Limiter les ports data à un range de tcp high ports
Créer des règles de NAT et de filtrage renvoyant ce range de ports vers la machine serveur ftp

Etes-vous d'accord avec ce constat ?

Juve

Le ftp-helper ne s'active pas "que sur un NAT du 21", il est fait pour fonctionner avec le port officiel du protocole FTP. le 21.
Activer un serveur FTP sur un autre port c'est de la bidouille et un non respect des standards.
La protection contre les connexion en masse ne s'effectue pas en changeant le port ;-)
la premiere chose à faire:

règle pfsense, spécifier une limite de nouvelle connexion / seconde
serveur FTP, activer l'anti-hammering

"pfSense ne faisant en effet pas d'analyse protocolaire", ben justement si le proxy FTP est un proxy applicatif, lorsqu'on utilise le protocole dans sa forme standard. Tout firewall (y compri de marques très couteuses fonctionnent de la même façon, les proxy applicatifs sont activés sur les ports standards, et certains permettent de les activer sur des ports non stantard…. mais il n'y a pas de détection à la volée...ce qui est fort peu possible etant donné le fonctionnement "connecté" de TCP)

Le contournement que vous considérez "pas super propre" est justement ce qu'il faut faire dans les règles de l'art !!!
-un serveur FTP doit renvoyer son IP publique dans les commandes PORT en mode passif.
-un serveur FTP doit avoir un plage de ports (superieur a 1024) définie clairement par l'administrateur concernant les connexions entrantes (mode passif). Le nat du firewall doit coincider avec cette plage.

GLR

Le ftp-helper ne s'active pas "que sur un NAT du 21", il est fait pour fonctionner avec le port officiel du protocole FTP. le 21.

Donc cela confirme mon analyse, il n'est aujourd'hui pas en mesure d'être activé sur un autre port, ce qui est regrettable. Dans le pire des cas, si cela ne peut-être automatisé, pourquoi ne pas pouvoir configurer le port d'écoute manuellement ?

Activer un serveur FTP sur un autre port c'est de la bidouille et un non respect des standards.

Et ben qu'est ce qu'il ne faut pas entendre ! C'est pas de la bidouille, c'est du "déport de port", bien utile quand on fait du NAT overload sur une unique adresse publique.

La protection contre les connexion en masse ne s'effectue pas en changeant le port ;-)
la premiere chose à faire:

règle pfsense, spécifier une limite de nouvelle connexion / seconde

serveur FTP, activer l'anti-hammering

Cela n'empêche pas d'être en DoS…

"pfSense ne faisant en effet pas d'analyse protocolaire", ben justement si le proxy FTP est un proxy applicatif

Le proxy FTP ne détecte pas de lui-même une connexion FTP, mais seulement une connexion sur le port tcp-21. Il ne fait pas de détection protocolaire sur tous les ports, il est complètement statique et c'est bien ça sa grande limite.
Par contre, en effet une fois une connexion sur le port tcp-21 ouverte, il essaie d'interpréter le protocole applicatif comme du FTP (commande PORT…).

lorsqu'on utilise le protocole dans sa forme standard.

Un déport de port ne change pas le protocole en lui-même !

Le contournement que vous considérez "pas super propre" est justement ce qu'il faut faire dans les règles de l'art !!!

C'est pas super propre car c'est tout un range de ports TCP ouverts en permanence, au lieu d'une ouverture dynamique de ceux-ci grâce à la prise en charge du protocole FTP sur n'importe quel port.
Dans ce cas, on fait aussi bien avec une ACL…

Décidément M. Juve, je trouve vos propos forts provocateurs...

Juve

"Donc cela confirme mon analyse, il n'est aujourd'hui pas en mesure d'être activé sur un autre port, ce qui est regrettable. Dans le pire des cas, si cela ne peut-être automatisé, pourquoi ne pas pouvoir configurer le port d'écoute manuellement ?"
==> tentez un NAT vers le 127.0.0.1 8021

"Et ben qu'est ce qu'il ne faut pas entendre ! C'est pas de la bidouille, c'est du "déport de port", bien utile quand on fait du NAT overload sur une unique adresse publique."
==> ouais, c'est la même traduction pour moi :-D quand on a pas assez d'IP publique on bidouille avec ce qu'on a ;-)

"Cela n'empêche pas d'être en DoS…"
==> Rien n'empêche un Dos du momment que l'attaquant possède une bande passante égale ou supérieur à la votre. Néanmoins cela empêche une surcharge de traitement côté serveur FTP étant donné que celui-ci ne reçoit plus la connexion une fois la limite atteinte (TCP RST sur les nouvelles connexions)

"Un déport de port ne change pas le protocole en lui-même !"
En parlant de forme je ne parle pas de l'intraprotocolaire mais des ports définits officielements. Ici le problème est le RDR par défaut créé par pfsense qui prend en source le 21..

"C'est pas super propre car c'est tout un range de ports TCP ouverts en permanence, au lieu d'une ouverture dynamique de ceux-ci grâce à la prise en charge du protocole FTP sur n'importe quel port."
==> de toute façon les ports sont ouverts en direction de votre serveur FTP et uniquement en direction de celui-ci, que celui-ci écoute ou non le niveau de sécurité est le même étant donné que la plage c'est vous qui l'avez configurée, et rien d'autre a part le serveur FTP n'est censé écouter dans cette plage !!

"Décidément M. Juve, je trouve vos propos forts provocateurs..."
Désolé si vous le percevez de cette manière.

GLR

=> tentez un NAT vers le 127.0.0.1 8021

OK mais avec quelles autres règles de NAT et de filtrage exactement ?
Entre autres, il va bien me falloir un NAT pour renvoyer vers mon serveur FTP…

Juve

Je pense qu'il va falloir faire deux trois tests car je ne pourrais dir comment va se comporter le moteur de NAT.

Tout d'abord, veuillez noter que tout ce qui concerne l'activation des proxy ftp se situe dans ces deux fichiers:

/etc/inc/filter.inc
/etc/inc/config.inc
Si vous voulez "patcher" votre pfsense après les tests. ;)

Quand on active le ftp helper, pfsense active une regle de nat de type rdr invisible dans l'interface qui renvoit tout ce qui est a destination du 21 vers 127.0.0.1:8021 (port d'écoute du ftp proxy). Dans votre cas ce n'est pas pris en compte vu que vous utilisez un port autre que le 21. Vous pouvez vérifier les règle de nat actives avec un "pfctl -s nat" en console.
Il faudrait tenter d'ajouter un nat pour votre port spécifique et analyser le comportement. Il se peut également que la sortie (depuis pfsense) vers le port spécifique soit bloquée. Vérifiez les logs du firewall avec un "tcpdump -i pflog0 -ttt -n proto tcp and port <votreportftp".<br>Je dois avouez que seule une phase de débug pourra valider ou non l'éventuel fonctionnement du proxy sur un port différent.
J'ai parcouru rapidement le forum anglais et j'ai trouvé quelques questions mais peu de réponses.

En espérant que cela aide.</votreportftp".<br>

GLR

Bon, je ne suis pas très motivé pour aller triturer le code PHP, n'ayant d'ailleurs pas de compétence de développeur PHP…
Il faudrait en outre regarder de plus près comment marche pfilter, ce que je n'ai pas encore eu trop le temps de faire...

Ce que j'avais vu en faisant mes tests :

en créant une règle de NAT sur le port 21, pfSense démarrait un process :
/usr/local/sbin/pftpx -f <my.private.ftp.server.ip>-b <my.public.ip>-c 21 -g 21
le fameux proxy ftp !

En créant un NAT sur un autre port public vers le port 21 de ma machine interne serveur ftp, rien.

Voici des extraits de pfctl concernant le FTP :
vr0 = lan
vr1 = wan
vr2 = dmz -> serveur ftp
Le ftp helper est aussi activé sur l'interface lan (vr0)

TRANSLATION RULES:
nat-anchor "pftpx/" all
rdr-anchor "pftpx/" all
no rdr on vr0 proto tcp from any to <vpns>port = ftp
rdr on vr0 inet proto tcp from any to any port = ftp -> 127.0.0.1 port 8021

FILTER RULES:
scrub all no-df random-id fragment reassemble
anchor "ftpsesame/" all
anchor "ftpproxy" all
anchor "pftpx/" all
pass in quick on vr1 proto tcp from any to <ftpserver>port = ftp keep state label "USER_RULE: NAT FTP server"
pass in quick on vr1 inet proto tcp from any to <my.public.ip>port = ftp keep state label "USER_RULE: NAT FTP server"
pass in quick on vr0 inet proto tcp from any to 127.0.0.1 port = ftp-proxy keep state label "FTP PROXY: Allow traffic to localhost"
pass in quick on vr0 inet proto tcp from any to 127.0.0.1 port = ftp keep state label "FTP PROXY: Allow traffic to localhost"
pass in quick on vr1 inet proto tcp from any port = ftp-data to (vr1) port > 49000 flags S/SA keep state label "FTP PROXY: PASV mode data connection"
pass in quick on vr2 inet proto tcp from any to 127.0.0.1 port = 8022 keep state label "FTP PROXY: Allow traffic to localhost"
pass in quick on vr2 inet proto tcp from any to 127.0.0.1 port = ftp keep state label "FTP PROXY: Allow traffic to localhost"
pass in quick on vr1 inet proto tcp from any to (vr1) port > 49000 flags S/SA keep state label "FTP PROXY: RFC959 violation workaround"

Les seules lignes ajoutées en créant la règle de NAT sur le port 21 sont donc les deux premières règles de filtrage en bleu.

J'avais également bien entendu parcouru en détails le forum en anglais sans trouver de réponse à cette problématique.

Je reste donc sur mon idée d'origine : le FTP helper ne marche que sur le port par défaut.

Je trouve qu'il faudrait pouvoir spécifier un port alternatif ou même tout simplement activer le FTP helper en cochant une case à la création d'une règle de NAT.
Cela ne semble pas compliqué.
Je vais donc certainement poster une "feature request" dans la section NAT du forum…</my.public.ip></ftpserver></vpns></my.public.ip></my.private.ftp.server.ip>