Bonjour, j’ai un serveur ftp et ça fait déjà plusieurs mois que j’ai ce problème: mon serveur ftp est inaccessible.
J’ai beau désinstaller et réinstaller proftpd, que ce soit avec apt-get remove, autoremove ou purge, en supprimant tt les fichiers ayant un rapport de près ou de loin avec proftpd, à chaque réinstallation, ça fait le même problème.
j’ai donc essayé de me connecter en ligne de commande, et j’arrive à me loguer, et à afficher le nom du répertoire courant, mais aucun moyen de lister le contenu d’un répertoire ou d’afficher le contenu d’un fichier, ce qui me porte à croire que le port 21 est en parfait état de fonctionnement, mais que le port 20 est bloqué. et pour info, en localhost, le ftp marche très bien. Ce qui me porte à croire qu’il s’agit d’un firewall quelconque, j’ai un script firewall pour iptables, mais il laisse ouvert le port 20 et 21, et j’ai aussi portsentry, scanmap et fail2ban d’installé, mais je n’ai rien fait pour fermer le port 20, et même en stoppant leurs deamons respectifs, et en réinitialisant iptables, le port 20 semble toujours bloqué. comment le ré-ouvrir ? merci de votre aide.
désactive tout simplement ton firewall et ses regles iptable et fait le test premier 
Grilled !
tu peux aussi fermer fail2ban par la même occasion, toujours pour essai.
tu es derrière une box?
Un problème de pare-feu avec FTP, il y avait longtemps…
Deux rappels concernant le port 20.
-
Le port 20 est utilisé comme port source de connexions sortantes émises du serveur vers le client. Un jeu de règles iptables qui autoriserait toutes les connexions sortantes et leurs réponses entrantes ne pourrait donc pas bloquer ces connexions.
-
Le port 20 n’est utilisé que pour les connexions de données en mode actif. En mode passif, qui est le plus couramment utilisé par les logiciels clients de nos jours, le client fait une connexion vers le serveur sur un port variable, mais qui n’est pas le 20. Là encore, un jeu de règle qui autorise les paquets appartenant ou liés à une connexion existante (le fameux ESTABLISHED,RELATED) en entrée et en sortie, avec le module de suivi de connexion FTP nf_conntrack_ftp chargé, ne devrait pas bloquer ces connexions en mode passif, pas plus que celles en mode actif. Le seul cas où cela ne suffit pas est lorsque la connexion de commande sur le port 21 est chiffrée par TLS/SSL (FTPS).
comme je l’ai dit, j’ai dejà essayé en désactivant fail2ban, iptables, portsentry et scan-map mais ça ne marchait pas quand même
et sinon c’est en ftp actif que mon serveur est config
moi je veut juste savoir qu’est ce qui bloque le port 20, parce que ce n’est pas iptables apparemment
C’est pas une histoire de redirection de port sur un routeur ou une box en amont du serveur…?
Salut,
Je pense qu’il s’agit bien d’un problème de pare-feu, mais pas du port 20.
En mode passif, le ftp travaille sur une série de ports.
Avant connexion:
Après une connexion réussie:
tcp 0 0 0.0.0.0:21 0.0.0.0:* LISTEN 0 27907327 10267/pure-ftpd (SE
tcp 0 0 IP-Serveur:40180 0.0.0.0:* LISTEN 5023 31491158 30098/pure-ftpd (ID
tcp 0 0 IP-Serveur:21 IP-client:16602 ESTABLISHED 0 31491145 30098/pure-ftpd (ID
Si tu n’arrive pas à lister les répertoires c’est parceque les ports “passifs” ouverts ne sont pas accessibles depuis l’extérieur.
Pour pure-ftpd, j’ai défini une série de ports:cat /etc/pure-ftpd/conf/PassivePortRange
40110 40210
et j’ai ouvert le pare-feu pour ces ports:# iptables -S | grep 40110
-A INPUT -p tcp -m tcp --dport 40110:40210 -j ACCEPT
Ton client ftp c’est? FileZilla?
Lors de l’install de ton ProFTPd tu as bien mis le mode standalone?
Mais avant de partir dans des explications vertigineuses, peux nous copier le message de tes logs. ( que tu as sans doute deja du consulter? 
)
Tu utilises le chiffrement de la connexion de commande ?
Sinon, comme je l’ai écrit plus haut, avec un jeu de règles de filtrage “à état” il n’est normalement pas nécessaire d’autoriser les ports passifs explicitement, le suivi de connexion s’en charge automatiquement.
dric64 te pose la même question que moi,question à laquelle tu n’as toujours pas répondu.
Tu utilises le chiffrement de la connexion de commande ?
Sinon, comme je l’ai écrit plus haut, avec un jeu de règles de filtrage “à état” il n’est normalement pas nécessaire d’autoriser les ports passifs explicitement, le suivi de connexion s’en charge automatiquement.[/quote]
Oui, normalement…
Sauf que si je n’ouvre pas explicitement les ports, les clients ftp n’arrivent pas à naviguer dans l’arborescence du ftp.
iptables -S
-P INPUT DROP
-P FORWARD DROP
-P OUTPUT ACCEPT
...
-A INPUT -m state --state ESTABLISHED -j ACCEPT
-A INPUT -m state --state RELATED -j ACCEPT
...
J’ai changé le port 21 pour un autre port, c’est peut-être la raison… 
Mais j’ai répondu à côté de la plaque…[quote=“G.Alex-713”]ftp actif[/quote]Je suis en passif. 
As-tu bien chargé le module de suivi de connexion FTP en spécifiant ce port en plus du port 21 ? Par défaut il ne surveille que le port 21.
Dans un script de démarrage
ou bien dans /etc/modules
C’est généralement plus simple pour les clients car ils n’ont pas besoin d’accepter de connexion entrante.
[quote=“PascalHambourg”]As-tu bien chargé le module de suivi de connexion FTP en spécifiant ce port en plus du port 21 ? Par défaut il ne surveille que le port 21.
Dans un script de démarrage
ou bien dans /etc/modules
Je viens (enfin) de percuter:
# lsmod
Opening /proc/modules: No such file or directory
modprobe nf_conntrack_ftp ports=21,xxx
FATAL: Could not load /lib/modules/2.6.38.2-grsec-xxxx-grs-ipv6-64/modules.dep: No such file or directoryNoyau OVH, modules désactivés…
Du coup je ne sais pas trop comment procéder… Je suppose que ce que je vais mettre dans /etc/modules n’aura pas d’effet.
Il faut que je cherche, c’est forcément compilé en dur, non ?
Ce serait un peu étonnant que tous les modules soient compilés en dur, ça ferait un noyau un peu gros… Il ne manquerait pas l’installation d’un paquet pour pour les modules du noyau ? C’est un vrai serveur ou un système virtualisé avec un noyau commun (VPS) ?
Tu peux éventuellement trouver les options de compilation dans /boot/config- ou /proc/config.gz (compressé). Si CONFIG_NF_CONNTRACK_FTP=y, alors il faut ajouter l’option nf_conntrack_ftp.ports=21,xx dans la ligne de commande du noyau via le chargeur d’amorçage.
Salut et Joyeux noël!
[quote=“PascalHambourg”]Il ne manquerait pas l’installation d’un paquet pour pour les modules du noyau ? C’est un vrai serveur ou un système virtualisé avec un noyau commun (VPS) ?[/quote]C’est un “vrai” serveur (un dédié de chez ovh): ovh.com/fr/serveurs_dedies/ … est_of.xml
[quote=“PascalHambourg”]Tu peux éventuellement trouver les options de compilation dans /boot/config- ou /proc/config.gz (compressé). Si CONFIG_NF_CONNTRACK_FTP=y, alors il faut ajouter l’option nf_conntrack_ftp.ports=21,xx dans la ligne de commande du noyau via le chargeur d’amorçage.[/quote]Malheureusement, il n’y a pas d’infos de compilation (pas de /boot/config- ou /proc/config.gz)
# vdir /boot/
total 7616
-rw-r--r-- 1 root root 5735824 26 août 11:51 bzImage-2.6.38.2-xxxx-grs-ipv6-64
drwxr-xr-x 3 root root 4096 18 oct. 20:59 grub
-rw-r--r-- 1 root root 2056069 26 août 11:51 System.map-2.6.38.2-xxxx-grs-ipv6-64
Je pense que je vais me tourner vers l’installation d’un noyau classique, plus lourd et peut-être moins performant mais complet.
Leur noyau n’est pas dans leurs dépôts, donc pas moyen de recompiler ou de réinstaller avec les modules.
Je vais poser la question au support pour les options de compilation, mais ils ne sont pas réactifs, et avec les fêtes par dessus, je n’aurais certainement pas de réponse avant 2012…
J’ai bien cherché des infos sur le net, mais je n’ai rien trouvé de pertinent.
Peut-être le forum OVH…
Merci!
Re…
J’ai trouvé sur ftp://ftp.ovh.net/made-in-ovh/bzImage/ une configuration qui ressemble à celle de mon noyau.
2.6.38.2-2/2.6-config-xxxx-std-ipv6-64 mon noyau est un 2.6.38.2-xxxx-grs-ipv6-64 je suppose que les conf se ressemblent.
J’ai bien trouvé dans ce fichier CONFIG_NF_CONNTRACK_FTP=y. Il devrait donc être possible de l’activer au boot.
Je vais tenter ça…
[quote=“lol”]Je pense que je vais me tourner vers l’installation d’un noyau classique, plus lourd et peut-être moins performant mais complet.
Leur noyau n’est pas dans leurs dépôts[/quote]
Rien ne dit qu’un noyau compilé par tes soins serait plus lourd et moins performant.
D’autre part, le noyau 2.6.38 ne semble plus maintenu depuis six mois, ni sur kernel.org ni chez Debian. Donc à moins qu’OVH s’occupe de sa maintenance, il contient probablement des failles de sécurité connues et non corrigées. OVH n’a rien de plus récent ?
D’abord, désolé pour le “détournement” du sujet.
Mais comme G.Alex-713 ne semble plus s’y intéresser, j’ai moins de scrupules…
J’ai été mauvaise langue avec OVH qui m’a donné toutes les réponses que je souhaitais, et rapidement; Le support technique est plus efficace que le support commercial (et ils sont sympas).
Non. Ils proposent un noyau compilé en fonction des besoins supposé.
Pour ce qui est de mon dédié (squeeze + IspConfig) c’est un 2.6.38-2 + patch de chez grsecurity.
Donc je vais installer/compiler un autre noyau qui me permettra d’ajouter les modules.
J’ai déjà fait un essai de compil avec un 2.6.39-4 (je n’ai pas réussi à redémarrer la machine avec, j’ai du merdouiller quelque part…)
Merci.
Le noyau 2.6.39 n’a pas l’air beaucoup plus frais…
Et concernant l’ajout de l’option dans la ligne de commande du noyau au démarrage ?