OVH Community, votre nouvel espace communautaire.

VKS: problème iptables et FTP


benji.pial
16/12/2012, 22h48
Oui, c'est la même chose (sauf que je l'ai laissé sur 2 colonnes).
Ca fonctionne chez toi? un vks avec un serveur ftp et firewall iptables avec une config du même style que la mienne?
Si oui, je suis vraiment perdu car j'ai déjà tout réinstallé une fois sans changement.

gaboul49
16/12/2012, 08h06
Dans /proc/sys/net/netfilter j'ai :
nf_conntrack_acct
nf_conntrack_tcp_loose
nf_conntrack_buckets
nf_conntrack_tcp_max_retrans
nf_conntrack_checksum
nf_conntrack_tcp_timeout_close
nf_conntrack_count
nf_conntrack_tcp_timeout_close_wait
nf_conntrack_events
nf_conntrack_tcp_timeout_established
nf_conntrack_events_retry_timeout
nf_conntrack_tcp_timeout_fin_wait
nf_conntrack_expect_max
nf_conntrack_tcp_timeout_last_ack
nf_conntrack_frag6_high_thresh
nf_conntrack_tcp_timeout_max_retrans
nf_conntrack_frag6_low_thresh
nf_conntrack_tcp_timeout_syn_recv
nf_conntrack_frag6_timeout
nf_conntrack_tcp_timeout_syn_sent
nf_conntrack_generic_timeout
nf_conntrack_tcp_timeout_time_wait
nf_conntrack_icmp_timeout
nf_conntrack_tcp_timeout_unacknowledged
nf_conntrack_icmpv6_timeout
nf_conntrack_udp_timeout
nf_conntrack_log_invalid
nf_conntrack_udp_timeout_stream
nf_conntrack_max
nf_log
nf_conntrack_tcp_be_liberal

benji.pial
12/12/2012, 19h44
@gaboul49
Avec openvz, il n'y a pas de modules, ils sont inclus dans le noyau, en fonction de ceux qui sont chargés sur l'host. Un "lsmod" donne... rien.
Par contre l'admin ovh lui sur son host:
lsmod | grep "conntr"

nf_conntrack_ipv4 9914 11 iptable_nat,nf_nat
nf_defrag_ipv4 1531 1 nf_conntrack_ipv4
nf_conntrack_ipv6 8732 2
nf_defrag_ipv6 12283 1 nf_conntrack_ipv6
nf_conntrack 80437 5
iptable_nat,nf_nat,nf_conntrack_ipv4,nf_conntrack_ ipv6,xt_stateipv6 326387 885
ip6table_mangle,ip6t_REJECT,nf_conntrack_ipv6,nf_d efrag_ipv6
Avec openvz, il faut que le module iptables soit chargé sur l'host pour pouvoir être inclus dans le container. Conntrack doit être chargé, il y a plein de chose dans /proc/sys/net/netfilter:
nf_conntrack_acct nf_conntrack_tcp_loose
nf_conntrack_buckets nf_conntrack_tcp_max_retrans
nf_conntrack_checksum nf_conntrack_tcp_timeout_close
nf_conntrack_count nf_conntrack_tcp_timeout_close_wait
nf_conntrack_events nf_conntrack_tcp_timeout_established
nf_conntrack_events_retry_timeout nf_conntrack_tcp_timeout_fin_wait
nf_conntrack_expect_max nf_conntrack_tcp_timeout_last_ack
nf_conntrack_frag6_high_thresh nf_conntrack_tcp_timeout_max_retrans
nf_conntrack_frag6_low_thresh nf_conntrack_tcp_timeout_syn_recv
nf_conntrack_frag6_timeout nf_conntrack_tcp_timeout_syn_sent
nf_conntrack_generic_timeout nf_conntrack_tcp_timeout_time_wait
nf_conntrack_icmp_timeout nf_conntrack_tcp_timeout_unacknowledged
nf_conntrack_icmpv6_timeout nf_conntrack_udp_timeout
nf_conntrack_log_invalid nf_conntrack_udp_timeout_stream
nf_conntrack_max nf_log
nf_conntrack_tcp_be_liberal
Mais pas de nf_conntrack_ftp. Est-ce que c'est censé fonctionné sans ce module?

gaboul49
09/12/2012, 14h08
Peut-être que tu étais sur un HOST qui avait les modules (un host avec une config un peu différente héritée de la beta par exemple). Pour une raison ou pour une autre, le host a été mis à jour, ou ton container a été déplacé et tu te retrouves dans cette situation bancale.

Durant la beta on avait été nombreux a demander un maximum de module en rapport avec IPtables, donc cela m'étonne qu'un RELATED ne passe pas... Mais en même temps, si les modules ne sont pas installés...

Le mieux, c'est que tu postes sur la ML vks (je te laisse chercher comment faire)


PS : Tu tapes quelle commande pour voir la liste des modules ?

benji.pial
08/12/2012, 22h17
Réponse OVH: "les modules ip_conntrack ip_conntrack_ftp ne sont installés sur aucuns des vhost."
Dans la doc openvz, pour que les modules soient inclus dans le noyau du container (mon serveur virtuel), il faut que les modules soient chargés.
Donc, l'installation d'un serveur ftp derrière un firewall iptables avec port 21 ouvert et suivi de connexions pour le port data dynamique est impossible?
Pourtant, pendant 5 mois ça fonctionnait.
Quelqu'un a une piste???

benji.pial
02/12/2012, 14h52
C'est pourtant le fonctionnement nominal avec un firewall netfilter et le module de suivi des connexions conntrack (qui est inclus dans l'image openvz que fourni ovh sur les vks).

La connexion se fait sur le port 21. Le transfert va se faire sur un autre port avec un connexion relative à la première (c'est le RELATED de la règle). Ensuite effectivement sur ce port de donnée ce sera une connexion établie (ESTABLISHED).
L'avantage est de ne pas ouvrir une plage de donnée, mais de laisser netfilter ouvrir des ports à la volée.
Je le répète, ça a très bien fonctionné pendant 5 mois.
Est-ce qu'OVH à changé des paramètres sur l'hôte de ma VM au niveau iptables, NAT ou autre???

Freemaster
02/12/2012, 13h50
Citation Envoyé par benji.pial
une fois l'établissement de la connexion sur le port 21 d'autoriser les connexions existantes.
une fois que le port de communication sur le port 21 est établie, il doit y avoir une connexion sur le port de transfert... qui à ce moment là est inexistant... donc pas de maintien d'une connexion qui ne s'est pas faite...

benji.pial
01/12/2012, 12h21
Justement les lignes suivantes permettent (ou plutôt permettaient) une fois l'établissement de la connexion sur le port 21 d'autoriser les connexions existantes. Ça a très bien fonctionné pendant 5 mois, et c'est ce qui permet de ne pas ouvrir toute une plage de ports pour le FTP:
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
Apparemment c'est ces lignes qui ne font plus leur travail.
De plus, ce n'est pas normal non plus qu'un "iptables -F" fasse planter le serveur à chaque fois.

Freemaster
01/12/2012, 11h23
Citation Envoyé par benji.pial
Les techniciens OVH m'ont dit que le problème était logiciel, que je devais me débrouiller.
J'ai alors tout réinstallé. Avant que je mette le firewall, tout va bien, dès que je le mets, ça bloque.
donc les techniciens OVH ont raison...
et effectivement je ne vois pas de plage de port pour le ftp passif dans tes règles...
j'utilise moi même pureftpd-mysql

benji.pial
01/12/2012, 10h23
Depuis cet été j'ai un vks qui fonctionnait très bien: serveur LAMP, serveur FTP (pure-ftpd-mysql) et un peu de sécurité (iptables, portsentry, fail2ban, rkhunter).
Je me suis rendu compte le 16/11 que je ne pouvais plus me connecter avec filezilla, ma dernière connexion datait du 11/11/12. En fait je peux me connecter, mais pas lister les fichiers. Depuis un terminal c'est pareil. Je me connecte, je peux faire des "cd", mais pas de "ls"
Je n'avais fais aucun upgrade ni modification du firewall.
Le problème vient du firewall, dont la config fonctionnait très bien jusqu'à présent:

#!/bin/sh
### BEGIN INIT INFO
# Provides: iptables
# Required-Start:
# Should-Start:
# Required-Stop:
# Should-Stop:
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-description: iptables
# Description: Firewall
### END INIT INFO
### RAZ
iptables -t filter -F
iptables -t filter -X
### FERMETURE TOTALE PAR DEFAUT
iptables -t filter -P INPUT DROP
iptables -t filter -P FORWARD DROP
iptables -t filter -P OUTPUT DROP
### MAINTIEN DES CONNEXIONS EXISTANTES
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
### AUTORISATION DU LOOPBACK
iptables -t filter -A INPUT -i lo -j ACCEPT
iptables -t filter -A OUTPUT -o lo -j ACCEPT
### AUTORISATION DU PING
iptables -t filter -A INPUT -p icmp -j ACCEPT
iptables -t filter -A OUTPUT -p icmp -j ACCEPT
### AUTORISATIONS LIEES AUX SERVICES
# SSH port XXXXX
iptables -t filter -A OUTPUT -p tcp --dport XXXXX -j ACCEPT
iptables -t filter -A INPUT -p tcp --dport XXXXX -j ACCEPT
# SMTP
iptables -t filter -A OUTPUT -p tcp --dport 25 -j ACCEPT
iptables -t filter -A INPUT -p tcp --dport 25 -j ACCEPT
# DNS
iptables -t filter -A OUTPUT -p tcp --dport 53 -j ACCEPT
iptables -t filter -A INPUT -p tcp --dport 53 -j ACCEPT
iptables -t filter -A OUTPUT -p udp --dport 53 -j ACCEPT
iptables -t filter -A INPUT -p udp --dport 53 -j ACCEPT
# HTTP
iptables -t filter -A OUTPUT -p tcp --dport 80 -j ACCEPT
iptables -t filter -A INPUT -p tcp --dport 80 -j ACCEPT
# HTTPS
iptables -t filter -A OUTPUT -p tcp --dport 443 -j ACCEPT
iptables -t filter -A INPUT -p tcp --dport 443 -j ACCEPT
# FTP
iptables -t filter -A OUTPUT -p tcp --dport 21 -j ACCEPT
iptables -t filter -A INPUT -p tcp --dport 21 -j ACCEPT
# allow git
iptables -t filter -A OUTPUT -p tcp --dport 9418 -j ACCEPT
iptables -t filter -A INPUT -p tcp --dport 9418 -j ACCEPT

Premier problème: je ne peux pas effacer les iptables à chaud. Si je fait un "iptables -t filter -F", je plante le serveur, il faut le redémarrer depuis le manager (chose qui plante une fois sur dix et nécessite l'intervention d'OVH quand le reboot bloque à 10%). Du coup, je commente toute les lignes du fichier ci-dessus après "iptables -t filter -X " puis je redémarre. Je peux alors me connecter avec filezilla.

Les techniciens OVH m'ont dit que le problème était logiciel, que je devais me débrouiller.
J'ai alors tout réinstallé. Avant que je mette le firewall, tout va bien, dès que je le mets, ça bloque.
Je rappelle que cette configuration fonctionne depuis juin et que depuis le 12/11 ça bloque.
On dirait que tout passe bien sur le port 21 (établissement de la connexion ftp, ouvert par le firewall), mais qu'ensuite le firewall ne maintient pas les connexions établies sur un autre port:
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

Est-ce que quelqu'un rencontre ce problème???
Pour moi le problème vient d'OVH puisque ça fonctionnait très bien jusqu'à il y a 2 semaines.

Merci d'avance