Debian
Debian-France
Debian-Facile
Debian-fr.org
Forum-Debian.fr
Debian ?
Communautés
Vous n'êtes pas identifié(e).
En supprimant le firewall tout fonctionne correctement
Voici ici le script iptables actuel (celui-ci a en effet été modifié de nombreuses fois sans pour autant que la panne disparaisse)
Petite précision: le module nf_conntrack_ftp a bien été chargé. Voila le contenu de /etc/modules:
Et, juste histoire de compléter les infos, le contenu de /etc/proftpd/proftpd.conf:
Voila!... Vous avez tout. Si quelqu'un a une idée sur l'endroit ou est situé mon erreur, je prends.
Merci d'avance
Dernière modification par fanch33 (13-08-2018 19:00:04)
Hors ligne
Dernière modification par Beta-Pictoris (13-08-2018 18:03:02)
Hors ligne
Dernière modification par fanch33 (13-08-2018 18:05:30)
Hors ligne
Tu peux limiter la plage de ports (--dport 5000:5100) dans proftpd, mais élargit la plage utilisée par le client. Essaye: --sport 1024:65535
Hors ligne
et rajout dans /etc/modprobe.d du fichier "conntrack.conf" dont voici le contenu:
Bien entendu faut penser à rajouter ou modifier les ports en fonction des desideratas.
Voila, je laisse la manip pour celui qui rencontre le même problème. Juste une dernière question: comment on fait pour marquer le sujet comme "résolu"?
Hors ligne
Hors ligne
Hors ligne
/sbin/iptables -A INPUT -p tcp -m tcp --dport 20 -m conntrack --ctstate ESTABLISHED -j ACCEPT
La règle ci-dessus ne sert à rien puisque la règle plus générale ci-dessous est déjà présente :
/sbin/iptables -t filter -A INPUT -p tcp -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
/sbin/iptables -A INPUT -p tcp -m tcp --sport 5000:5100 --dport 5000:5100 -m conntrack --ctstate NEW,RELATED,ESTABLISHED -j ACCEPT
Comme l'a souligné Beta-Pictoris, proftpd ne maîtrise que la plage de ports destination passifs (--dport), pas les ports source que les clients utilisent (--sport).
Les états ESTABLISHED et RELATED sont inutiles car déjà pris en compte par la règle générale citée précédemment.
L'état du premier paquet est NEW seulement si le suivi de connexion FTP (nf_conntrack_ftp) est inopérant (port de la connexion de commande non surveillé ou connexion de commande chiffrée).
L'état du premier paquet devrait être RELATED si le suivi de connexion FTP est opérant (dans ce cas la règle est inutile).
Le port tcp 20 doit être ouvert coté client si mode ftp actif.
Pas vraiment. "Ouvert", ça ne veut rien dire. Une connexion de données active est émise par le serveur depuis son port 20 (en fait le port de commande -1) vers un port arbitraire du client choisi et annoncé par ce dernier. D'ailleurs,
nf_conntrack_ftp ports=20,21
Le port 20 n'a rien à faire dans la liste de ports du paramètre "ports". Ce n'est pas un port de commande.
le bon module à charger est en fait ip_conntrack_ftp et non pas ns_conntrack_ftp
C'est le même module. ip_conntrack_ftp n'est qu'un alias de nf_conntrack_ftp. Tu peux le vérifier avec
ou bien dans la liste des modules chargés affichée par lsmod.
On y rajoute également ip_nat_ftp
Le module ip_nat_ftp n'est utile que si des règles iptables font du NAT (MASQUERADE, SNAT, DNAT, REDIRECT), ce qui n'est pas le cas ici.
rajout dans /etc/modprobe.d du fichier "conntrack.conf" dont voici le contenu:
options ip_conntrack_ftp ports=21
Note : Le paramètre "ports" aurait pu être spécifié dans /etc/modules. Et 21 est déjà la valeur par défaut donc le paramètre est redondant.
Ce qui suit comporte des modifications depuis la publication initiale de ce message
J'attire l'attention sur le fait que l'affectation automatique du suivi de connexion pour les protocoles complexes comme FTP a été désactivée par défaut à partir de je ne sais plus quelle version de noyau entre Jessie et Stretch car considérée comme risquée. Un message est envoyé dans les logs du noyau affichables par dmesg lorsque la première connexion correspondant aux critères de l'affectation automatique est détectée.
Dans Debian 8 avec le noyau 3.16 et le paramètre nf_conntrack_helper=1 par défaut, le message est le suivant :
Dans Debian 9 avec le noyau 4.9 et le paramètre nf_conntrack_helper=0 par défaut, le message est le suivant :
Pour forcer l'affectation automatique comme avant, il faut passer le paramètre nf_conntrack_helper=1 au module nf_conntrack lors de son chargement ou écrire "1" dans /proc/sys/net/netfilter/nf_conntrack_helper. Mais l'affectation automatique est considérée comme risquée, et la méthode recommandée consiste plutôt à faire une affectation explicite avec la cible CT d'iptables. Par exemple pour les connexions FTP entrantes (sur un serveur FTP ou un routeur) :
Pour les connexions sortantes (sur un client FTP), la règle doit être créée dans la chaîne OUTPUT.
Note : si on a spécifié le paramètre ports=21 du module nf_conntrack_ftp comme tu l'as fait (ce qui est superflu, je le rappelle), d'après la documentation le helper à associer s'appelle "ftp-21" au lieu de "ftp".
Dernière modification par raleur (17-08-2018 09:31:08)
Il vaut mieux montrer que raconter.
Hors ligne
Normalement, au vu des docs que l'on trouve sur le protocole FTP et sur proftp en particulier, lesquelles docs ne mentionnent JAMAIS le filtrage iptables si ce n'est par des considérations du type "ouvrez les ports 20,21, etc...), cela aurait dû suffire. Je parle bien entendu des docs ACCESSIBLES et COMPREHENSIBLES au grand public bien entendu. Nous en avons un exemple ici même sur ce site: https://debian-facile.org/doc:reseau:pure-ftpd.
Notes que nulle part, dans ce lien (aisni que dans bien d'autres d'ailleurs), on ne fait mention de nf_conntrack_ftp ni ip_conntrack_ftp. Il m'a fallu consulter de nombreux fils de discussions pour trouver l'info. C'est dans des forums en anglais (étant français je ne suis pas spécialement doué pour la langue de shakespeare qui ne m'attire pas plus que cela, n'en déplaise aux esprit bien pensant) que celle-ci se trouvait. J'attire ton attention sur le fait que PLUSIEURS de ces fils de discussion avaient exactement le même problème que moi et résolvait celui-ci par un:
Bien que mes connaissances en iptables sont empiriques, elles sont cependant suffisamment étendues pour comprendre que cette solution n'en ai pas une puisque si je ne m'abuse elle revient finalement à enlever le filtrage du firewall sur tous les ports de la machine autrement dit à enlever le script iptables ce qui est tout de même un peu limite pour un serveur.
En ce qui concerne ip_conntrack_ftp en tant qu'alias:
Effectivement, j'ai vérifié: c'est bien un alias de nf_conntrack_ftp. Merci de l'info, je ne le savais pas.
Néanmoins, pour une raison x inconnue que j'ai du mal à comprendre avec le même script iptables (toutes versions confondues) la présence de "nf_conntrack_ftp" dans /etc/modules ne fonctionne pas alors que avec "ip_conntrack_ftp" ça fonctionne sur mon serveur. (VPS chez OVH). Aussi je ne cherche pas à aller plus loin n'étant pas ingénieur informatique mais simple passionné Linux comme je te le rappelle. j'ai en effet autre chose à f... que de potasser de la doc écrite dans une langue que j'ai du mal à déchiffrer: construire mon site et animer mon blog par exemple. POINT...
Cependant je constate par ailleurs, que le problème est récurrent (cf les nombreux fils de discussions que l'on trouve ça et là sur le sujet). J'indique donc ma solution pour aider la communauté.
J'attire ton attention sur le fait que j'avais corrigé le tir en ce qui concerne la mention du port 20 puisque dans mon dernier post j'avais écrit
options ip_conntrack_ftp ports=21
Tu vois bien ici que le port 20 n'est pas indiqué.
MORALITE:
Etant donné que beaucoup de gens qui viennent ici sont comme moi, c'est-à-dire des simples particuliers qui bien que passionnés par Debian ne sont pas pour autant des gurus du libre, ce serait bien d'avoir des documentations COMPLETES, COMPREHENSIBLES pour tous et PRECISES afin d'éviter ce genre de perte de temps. Tu ne crois pas?
C'est justement parce que je trouve, tout comme certainement une grande majorité de ceux que j'ai cité dans la phrase précédente, que ça manque que je construit mon blog: il est en effet destiné à délivrer la moindre info que je trouverai en bataillant sur ce merveilleux système Debian, comme je viens justement de le faire ci-dessus. Une fois celui-ci construit je t'autorise sans aucun problème à y venir pour me corriger, dans la mesure ou bien entendu tu source tes infos plutôt que de signaler qu'elle sont "trouvables sur le net", afin d'éviter à mes lecteurs ce que je connais actuellement, c'est à dire une recherche inutile, fastidieuse et accaparante.
Dernière modification par fanch33 (15-08-2018 08:12:33)
Hors ligne
Dernière modification par Beta-Pictoris (16-08-2018 19:31:18)
Hors ligne
à l'origine, le script concernant FTP était:
/sbin/iptables -A INPUT -p tcp --dport 21 -j ACCEPT
/sbin/iptables -A INPUT -p tcp --dport 5000:5100 -j ACCEPT
Normalement, au vu des docs que l'on trouve sur le protocole FTP et sur proftp en particulier, lesquelles docs ne mentionnent JAMAIS le filtrage iptables si ce n'est par des considérations du type "ouvrez les ports 20,21, etc...), cela aurait dû suffire.
Oui, bien que ce soit trop laxiste car autorisant en permanence toute connexion depuis n'importe où à toute la plage de ports passifs définie dans proftpd au lieu d'utiliser le suivi de connexion FTP pour autoriser uniquement les connexions passives attendues par le serveur FTP.
Pourquoi "aurait dû" ? Cela ne fonctionnait pas ?
Je parle bien entendu des docs ACCESSIBLES et COMPREHENSIBLES au grand public bien entendu
Il faut être réaliste : le fonctionnement du protocole FTP, d'iptables et les particularités de la prise en charge du premier par le second ne sont pas à la portée du grand public. Si le grand public veut mettre en place un pare-feu avec prise en charge de FTP, il ne devrait pas utiliser directement iptables mais un pare-feu de plus haut niveau qui gère les règles iptables à sa place comme shorewall, ufw...
étant français je ne suis pas spécialement doué pour la langue de shakespeare qui ne m'attire pas plus que cela, n'en déplaise aux esprit bien pensant
La bien-pensance n'a rien à voir là-dedans. Il faut être conscient que l'anglais est de fait la langue de l'informatique et qu'une maîtrise insuffisante de cette langue constitue objectivement un handicap pour cette discipline. Je n'envisage pas une seule seconde de me priver des ressources en anglais et me contenter de celles disponibles en français. Mais c'est toi qui vois.
Néanmoins, pour une raison x inconnue que j'ai du mal à comprendre avec le même script iptables (toutes versions confondues) la présence de "nf_conntrack_ftp" dans /etc/modules ne fonctionne pas alors que avec "ip_conntrack_ftp" ça fonctionne sur mon serveur.
Je suis catégorique, les deux ont le même effet. J'ai vérifié. Tu dois avoir fait un autre changement.
Quelles sont les règles iptables pour les connexions FTP dans ton script actuel ?
Aussi, quelle est la version du noyau et la valeur de /proc/sys/net/netfilter/nf_conntrack_helper ?
J'attire ton attention sur le fait que j'avais corrigé le tir en ce qui concerne la mention du port 20 puisque dans mon dernier post j'avais écrit
options ip_conntrack_ftp ports=21
Tu vois bien ici que le port 20 n'est pas indiqué.
Et j'ai expliqué pourquoi à l'attention des lecteurs.
ce serait bien d'avoir des documentations COMPLETES, COMPREHENSIBLES pour tous et PRECISES afin d'éviter ce genre de perte de temps. Tu ne crois pas?
Ce que je crois importe peu. Je ne suis pas le grand public, je n'ai pas les mêmes connaissances ni les mêmes attentes.
Par contre je crois qu'iptables demande un investissement conséquent, son utilisation rationnelle et efficace demande de solides connaissances en réseau et du fonctionnement des protocoles qu'on veut gérer, sans parler des changements de comportement au gré des versions du noyau.
Une fois celui-ci construit je t'autorise sans aucun problème à y venir pour me corriger, dans la mesure ou bien entendu tu source tes infos plutôt que de signaler qu'elle sont "trouvables sur le net"
Je n'ai besoin de l'autorisation de personne pour corriger les erreurs que je vois. Quant aux sources, je ne conserve pas les URL de toutes les informations que je lis, les mots-clés que je fournis devraient permettre de se débrouiller. A condition que l'anglais ne soit pas un frein bien entendu.
Il vaut mieux montrer que raconter.
Hors ligne
Je précise que même en rajoutant une règle pour le port 20 le mode actif ne fonctionne pas mais peu importe. Tout le reste fonctionne impec y compris le serveur mail (Dovecot, Postfix, Rouncube): une vrai galère à paramétrer celui-là!...
Hors ligne
Dernière modification par Beta-Pictoris (17-08-2018 10:31:50)
Hors ligne
Et que tu modifies les suivantes comme ceci:
Est-ce que ça marche encore ?
Dernière modification par Beta-Pictoris (17-08-2018 10:38:27)
Hors ligne
Oui, bien que ce soit trop laxiste car autorisant en permanence toute connexion depuis n'importe où à toute la plage de ports passifs définie dans proftpd au lieu d'utiliser le suivi de connexion FTP pour autoriser uniquement les connexions passives attendues par le serveur FTP.
Pourquoi "aurait dû" ? Cela ne fonctionnait pas ?
Non!... Je confirme bien que ça ne fonctionnait pas. Sur l'un des sites EN ANGLAIS que j'ai consulté (et dont moi-même je n'ai pas gardé l'URL je l'avoue) j'ai constaté que d'autres avait exactement le même problème. Un des intervenants précisait bien que c'était en rapport avec le fameux modules ip_conntrack_ftp (ou nf_conntrack_ftp) lequel était OBLIGATOIRE quand on fait du FTP. C'est ce qui m'a mis la puce à l'oreille concernant ce module à charger.
Concernant le laxisme sur les ports 5000 à 5100, je suis totalement d'accord avec toi. Ceci dit je ne vois pas très bien la différence avec les nouvelles règles qui me semblent exactement identiques puisque les états NEW sont également indiqués en même temps que RELATED et ESTABLISHED mais c'est comme ça. Dans un cas ça marche et pas dans l'autre. POINT.
en ce qui concerne les renseignements demandés:
Version du noyau: 4.9.0-7-amd64
valeur proc/sys/net/netfilter/nf_conntrack_helper: 0
Voila!... Pour le reste c'est effectivement une question de point de vue. On peut en discuter mais je ne crois pas qu'ici ça soit le lieu.
Hors ligne
Hors ligne
Tu utilises, aussi, un poste linux coté client ?
Oui!... ça fait pas mal de temps que je fais une allergie au mot "Microsoft". 
:lol::lol:
Hors ligne
/sbin/iptables -A INPUT -p tcp -m tcp --dport 5000:5100 -m conntrack --ctstate NEW,RELATED,ESTABLISHED -j ACCEPT
Par rapport au script précédent, tu as retiré l'option --sport 5000:5100, ce qui permet à cette règle d'accepter les connexions FTP passives même si le suivi de connexion FTP ne fonctionne pas (état NEW au lieu de RELATED).
Je précise que même en rajoutant une règle pour le port 20 le mode actif ne fonctionne pas
Pas besoin de règle supplémentaire pour autoriser le mode actif côté serveur. La demande de connexion active sortante est autorisée par la politique ACCEPT de la chaîne OUTPUT, et les paquets de réponse du client ont l'état ESTABLISHED donc sont acceptés par la règle générale en INPUT.
Par contre comme le souligne Beta-Pictoris le mode actif a besoin de la coopération du pare-feu ou routeur NAT côté client. C'est généralement le cas pour les connexions FTP non chiffrées sur le port 21, mais pas si la connexion est chiffrée. Utilises-tu le chiffrement ?
Version du noyau: 4.9.0-7-amd64
valeur proc/sys/net/netfilter/nf_conntrack_helper: 0
Donc le suivi de connexion FTP est inactif. Peu importe que tu charges nf_conntrack_ftp, ip_conntrack_ftp ou pas du tout, il est sans effet.
Cf. les ajouts de mon premier message pour l'activer.
Si tu retires les règles suivantes:
Mauvaise idée car ces règles servent à d'autres connexions que FTP. Ça ne peut pas marcher car l'état ESTABLISHED n'est plus accepté.
Il vaut mieux montrer que raconter.
Hors ligne
Par rapport au script précédent, tu as retiré l'option --sport 5000:5100, ce qui permet à cette règle d'accepter les connexions FTP passives même si le suivi de connexion FTP ne fonctionne pas (état NEW au lieu de RELATED).
Oui!... Effectivement! j'avais vu le problème ici qui, d'ailleurs avait été souligné par Beta-Pictoris
Tu as également écrit:
Donc le suivi de connexion FTP est inactif. Peu importe que tu charges nf_conntrack_ftp, ip_conntrack_ftp ou pas du tout, il est sans effet.
Cf. les ajouts de mon premier message pour l'activer.
OK!... Du coup, c'est normal que, actuellement le mode actif ne fonctionne pas. C'est bien comme ça qu'il faut que je comprenne?
Enfin tu m'as demandé:
Utilises-tu le chiffrement ?
La réponse est oui. J'utilise "TLS connexion explicite" qui fonctionne mais pas "TLS connexion implicite. Mais je note que connexion simple fonctionne aussi et ça, j'aimerai bien désactiver
Hors ligne
Du coup, c'est normal que, actuellement le mode actif ne fonctionne pas. C'est bien comme ça qu'il faut que je comprenne?
Non. Le mode actif n'a pas besoin du suivi de connexion FTP côté serveur si les connexions sortantes sont autorisées. Le blocage doit être côté client.
J'utilise "TLS connexion explicite" qui fonctionne mais pas "TLS connexion implicite.
FTP avec TLS implicite (FTPS) n'utilise pas le port 21 mais le port 990. Pour fonctionner il doit être supporté par le serveur et autorisé par le pare-feu. De toute façon c'est obsolète et remplacé par TLS explicite qui écoute sur le port 21.
En tout cas si tu utilises du chiffrement le suivi de connexion FTP est inopérant car il ne peut pas inspecter le contenu de la connexion de commande chiffrée, donc inutile de perdre du temps avec nf_conntrack_ftp, nf_conntrack_helper, CT...
La seule solution consiste à traiter les connexions de données actives ou passives comme des connexions entrantes indépendantes. C'est ce que fait la règle autorisant la plage de ports 5000:5100 avec l'état NEW. Sans cette règle, pas de FTP chiffré en mode passif possible. C'est sous-optimal car cela autorise n'importe quelle connexion sur un de ces ports, pas seulement les connexions attendues par le serveur.
Et cela peut expliquer pourquoi le mode actif ne fonctionne pas si le client est derrière un NAT ou un pare-feu : la plage de ports actifs utilisés par le client doit être explicitement autorisée en entrée par le pare-feu du client et/ou redirigée vers le client par le NAT car le suivi de connexion FTP automatique est inopérant à cause du chiffrement.
Mais je note que connexion simple fonctionne aussi et ça, j'aimerai bien désactiver
Tu veux dire connexion en clair non chiffrée ?
Si cela se désactive, cela ne peut être que dans la configuration du serveur.
Par curiosité, as-tu testé la connexion en clair en mode actif ?
Dernière modification par raleur (17-08-2018 12:28:36)
Il vaut mieux montrer que raconter.
Hors ligne
Par curiosité, as-tu testé la connexion en clair en mode actif ?
ça ne fonctionnait pas avec l'ancien parefeu. En revanche, effectivement maintenant ça fonctionne. Si j'ai bien compris pour que tout fonctionne correctement il suffirait que je remplace toutes les règles FTP par simplement:
Et que je modifie quelque part le fichier /etc/proftpd/proftpd.conf pour empêcher l'utilisation en clair. C'est bien ça?
Hors ligne
Si j'ai bien compris pour que tout fonctionne correctement il suffirait que je remplace toutes les règles FTP
Qu'entends-tu par "tout fonctionne correctement" ?
Le mode passif chiffré ou en clair passe (mais avec filtrage non optimal).
Le mode actif en clair passe.
Le mode actif chiffré est bloqué à cause du pare-feu ou du NAT côté client, pas à cause des règles iptables côté serveur.
La règle avec la cible CT permet de faire du filtrage optimal mais ne fonctionne qu'avec les connexions FTP en clair. Et elle ne remplace pas la règle qui autorise le port 21.
Les deux modifications que tu proposes sont contradictoires puisque la première ne fonctionne qu'avec les connexions en clair et la seconde vise à les interdire.
Il vaut mieux montrer que raconter.
Hors ligne
Hors ligne
Je suppose qu'il faut que j'ailles voir au niveau de la box
Si la box est en mode routeur (ton PC reçoit une adresse IPv4 privée), il faut créer une redirection vers l'adresse IP du poste client pour la plage de ports actifs utilisée par ton logiciel client FTP. Là encore, solution non optimale puisque cela ne redirige pas que les connexions de données FTP actives attendues par le client.
Il vaut mieux montrer que raconter.
Hors ligne
Hors ligne