serveur ftp derriere un firewall netfilter

Freegate wrote:

Bonjour,

Sur mon reseau local, j'ai un firewall / passerelle 192.168.0.1 et un
serveur FTP avec l'adresse 192.168.0.5

Je souhaite que les utilisateurs internet accèdent au serveur FTP
192.168.0.5

Il me semble qu'il est difficile de faire cela eu égard au caractère
particulier du protocole ftp.

Michel.

Dans le message <news:435d5579$0$27414$8fcfb975@news.wanadoo.fr>,
*Freegate* tapota sur f.c.o.l.configuration :

Bonjour,

Bonsoir,

Sur mon reseau local, j'ai un firewall / passerelle 192.168.0.1 et un
serveur FTP avec l'adresse 192.168.0.5

Je souhaite que les utilisateurs internet accèdent au serveur FTP
192.168.0.5

Mes regles de port forwarding pour le serveur ftp sont les suivantes :

IPTABLES -t nat -A PREROUTING -i ppp0 -p tcp --dport 21 -j
^^^^^^^^

iptables != IPTABLES

DNAT --to-destination 192.168.0.5:80
^^

80 ?

IPTABLES -t nat -A PREROUTING -i ppp0 -p tcp --dport 20 -j
^^

Peu secure et surtout inutile si on utilise les modules ip_conntrack_ftp et
ip_nat_ftp.

DNAT --to-destination 192.168.0.5:80
^^

Encore 80 ?

Malheureusement les utilisateurs accèdent au serveur ftp installé sur le
firewall cad au 192.168.0.1 non au serveur FTP sur 192.168.0.5

Il convient de constater que le serveur ftp 192.168.0.5 est accessible en
local.
Je suppose donc que les règles de port forwarding ne marchent pas.

Avez vous une idée pour résoudre le pb ?

Donnez nous l'ensemble de vos-règles iptables actuelles via la commande
iptables-save (iptables-save > regles.txt et publiez regles.txt), sinon,
sans ça, on ne peut pas avancer.

--
TiChou

Dans le message <news:djjlk5$n8h$1@shakotay.alphanet.ch>,
*Michel Tatoute* tapota sur f.c.o.l.configuration :

Sur mon reseau local, j'ai un firewall / passerelle 192.168.0.1 et un
serveur FTP avec l'adresse 192.168.0.5

Je souhaite que les utilisateurs internet accèdent au serveur FTP
192.168.0.5

Il me semble qu'il est difficile de faire cela eu égard au caractère
particulier du protocole ftp.

Certes le protocole FTP est particulier, mais il n'y a aucun soucis sous
Linux pour «forwardé» ce protocole.

--
TiChou

Salut,

*Freegate* tapota sur f.c.o.l.configuration :

Mes regles de port forwarding pour le serveur ftp sont les suivantes :
[...]

IPTABLES -t nat -A PREROUTING -i ppp0 -p tcp --dport 20 -j
DNAT --to-destination 192.168.0.5:80

Peu secure et surtout inutile si on utilise les modules ip_conntrack_ftp
et ip_nat_ftp.

Si je ne m'abuse, rediriger/ouvrir le port 20 en entrée est inutile dans
tous les cas de figure, qu'on utilise les modules de suivi/NAT FTP ou
pas. Le port 20 est utilisé en mode actif comme port *source* d'une
connexion *sortante* établie par le serveur vers le client.

Dans le message <news:djju4t$6v7$1@biggoron.nerim.net>,
*Pascal@plouf* tapota sur f.c.o.l.configuration :

Mes regles de port forwarding pour le serveur ftp sont les suivantes :
[...]

IPTABLES -t nat -A PREROUTING -i ppp0 -p tcp --dport 20 -j
DNAT --to-destination 192.168.0.5:80

Peu secure et surtout inutile si on utilise les modules ip_conntrack_ftp
et ip_nat_ftp.

Si je ne m'abuse, rediriger/ouvrir le port 20 en entrée est inutile dans
tous les cas de figure, qu'on utilise les modules de suivi/NAT FTP ou pas.
Le port 20 est utilisé en mode actif comme port *source* d'une connexion
*sortante* établie par le serveur vers le client.

Oui, en plus tu as raison, je n'ai même pas fait attention. Mais notons
quand même que les deux modules en question seront fort utiles quand on
voudra accéder au serveur ftp forwardé en mode passif.

--
TiChou

"TiChou" <gro.uohcit@uohcit> a écrit dans le message de
news:pwet.20051025001209@florizarre.tichou.org...
| Dans le message <news:435d5579$0$27414$8fcfb975@news.wanadoo.fr>,
|
| Donnez nous l'ensemble de vos-règles iptables actuelles via la commande
| iptables-save (iptables-save > regles.txt et publiez regles.txt), sinon,
| sans ça, on ne peut pas avancer.
|


Voici les modules chargés à l'aide de rc.local

/sbin/modprobe ip_conntrack_ftp
/sbin/modprobe ip_table
/sbin/modprobe ip_nat_ftp
/sbin/modprobe ip_nat_irc
/sbin/modprobe iptable_filter
/sbin/modprobe iptable_mangle
/sbin/modprobe iptable_nat

Puis mes règles

######### REGLES PAR DEFAUT ######################
iptables -F
iptables -X
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

######## LOCAL-INTERNET ######


iptables -A local-internet -m state --state NEW -i ! ppp0 -j ACCEPT
iptables -A local-internet -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -j local-internet
iptables -A FORWARD -j local-internet

###### LES TABLES NAT ET MANGLE #########


iptables -t nat -F
iptables -t nat -X
iptables -t nat -P PREROUTING ACCEPT
iptables -t nat -P POSTROUTING ACCEPT
iptables -t nat -P OUTPUT ACCEPT
iptables -t mangle -F
iptables -t mangle -X
iptables -t mangle -P PREROUTING ACCEPT
iptables -t mangle -P OUTPUT ACCEPT

######## LE MASQUERADING ######################

iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -o ppp0 -j MASQUERADE

########### ACTIVATION DE LA PASSERELLE #########

echo 1 > /proc/sys/net/ipv4/ip_forward

########### PAS DE SPOOFING #################

if [ -e /proc/sys/net/ipv4/conf/all/rp_filter ] ; then
for filtre in /proc/sys/net/ipv4/conf/*/rp_filter
do
echo 1 > $filtre
done
fi

############ PAS DE SYNFLOOD ###########

if [ -e /proc/sys/net/ipv4/tcp_syncookies ] ; then
echo 1 > /proc/sys/net/ipv4/tcp_syncookies
fi

################### PAS DE PING ################

echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
if [ -e /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses ] ; then
echo 1 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses
fi

################ Fonctionnalité serveurs ##############

iptables -A INPUT -p tcp --dport ftp -j ACCEPT
iptables -A INPUT -p tcp --dport ftp-data -j ACCEPT

########## PORT FORWARDING ###############

iptables -t nat -A PREROUTING -i ppp0 -p tcp --dport 21 -j
DNAT --to-destination 192.168.0.5:21
iptables -t nat -A PREROUTING -i ppp0 -p tcp --dport 20 -j
DNAT --to-destination 192.168.0.5:20

Dans le message <news:435e2e03$0$7848$8fcfb975@news.wanadoo.fr>,
*Freegate* tapota sur f.c.o.l.configuration :

Voici les modules chargés à l'aide de rc.local

/sbin/modprobe ip_conntrack_ftp
/sbin/modprobe ip_table
/sbin/modprobe ip_nat_ftp
/sbin/modprobe ip_nat_irc
/sbin/modprobe iptable_filter
/sbin/modprobe iptable_mangle
/sbin/modprobe iptable_nat

Puis mes règles

######### REGLES PAR DEFAUT ######################
iptables -F
iptables -X
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT
iptables -A INPUT -i lo -j ACCEPT

Ok.

iptables -A OUTPUT -o lo -j ACCEPT

Comme en fin de script rien n'est rejetté ou bloqué en sortie et que la
politique par défaut en sortie est à ACCEPT, cette règle est alors inutile.

######## LOCAL-INTERNET ######

iptables -A local-internet -m state --state NEW -i ! ppp0 -j ACCEPT
iptables -A local-internet -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -j local-internet
iptables -A FORWARD -j local-internet

La chaîne local-internet n'existe pas par défaut dans la table filter. Il
faut donc auparavant la créer.

iptables -N local-internet

###### LES TABLES NAT ET MANGLE #########

iptables -t nat -F
iptables -t nat -X
iptables -t nat -P PREROUTING ACCEPT
iptables -t nat -P POSTROUTING ACCEPT
iptables -t nat -P OUTPUT ACCEPT
iptables -t mangle -F
iptables -t mangle -X
iptables -t mangle -P PREROUTING ACCEPT
iptables -t mangle -P OUTPUT ACCEPT

Dans la table mangle il y a aussi les chaînes INPUT, FORWARD et POSTROUTING.

######## LE MASQUERADING ######################

iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -o ppp0 -j MASQUERADE

[...]

################ Fonctionnalité serveurs ##############

iptables -A INPUT -p tcp --dport ftp -j ACCEPT

Inutile puisque déjà accepté par la première règle de la chaîne
local-internet.

iptables -A INPUT -p tcp --dport ftp-data -j ACCEPT

Inutile (cf autre post).

########## PORT FORWARDING ###############

iptables -t nat -A PREROUTING -i ppp0 -p tcp --dport 21 -j
DNAT --to-destination 192.168.0.5:21

Il ne suffit pas seulement de nater/rediriger il faut aussi accepter que la
connexion soit forwardée.

iptables -A local-internet -i ppp0 -p tcp --dport21
-m state --state NEW -j ACCEPT

iptables -t nat -A PREROUTING -i ppp0 -p tcp --dport 20 -j
DNAT --to-destination 192.168.0.5:20

Inutile.

Et enfin il faudrait terminer le script par un rejet (cible REJECT) des
paquets non acceptés.

--
TiChou

[Je fais une réponse groupée aux deux articles précédents]

*Freegate* tapota sur f.c.o.l.configuration :

######## LOCAL-INTERNET ######

iptables -A local-internet -m state --state NEW -i ! ppp0 -j ACCEPT

Cette règle présente AMA un risque de sécurité, même s'il est minime.
L'usage en matière de sécurité est de tout bloquer par défaut puis
d'autoriser ce qu'on souhaite laisser passer. Ici, c'est le contraire
qui est fait : on autorise les nouvelles connexions entrant par
n'importe quelle interface sauf ppp0. Si pour une raison quelconque
l'interface internet prenait un autre nom que ppp0 - par exemple si ppp0
est déjà utilisé par une autre connexion PPP en cours - celle-ci serait
ouverte à tous les vents.

Une façon de mieux sécuriser la règle consiste à remplacer "ppp0" par
"ppp+" qui correspond à n'importe quel nom commençant par "ppp". Mais la
meilleure façon reste encore pour moi de remplacer "! ppp0" par le nom
de l'interface reliée au réseau local jugé de confiance, typiquement
"eth0". Au besoin écrire plusieurs règles s'il y a plusieurs interfaces
de confiance, ou utiliser "eth+" si toutes les interfaces de ce type
sont dans ce cas.

###### LES TABLES NAT ET MANGLE #########
[...]

iptables -t mangle -P PREROUTING ACCEPT
iptables -t mangle -P OUTPUT ACCEPT

Dans la table mangle il y a aussi les chaînes INPUT, FORWARD et
POSTROUTING.

En effet, depuis la version 2.4.18 du noyau d'après les informations que
j'ai pu glaner. Mais on doit pouvoir trouver des docs périmés qui n'en
font pas mention.

######## LE MASQUERADING ######################

iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -o ppp0 -j MASQUERADE

Même remarque que ci-dessus concernant le caractère potentiellement
dynamique du nom d'une interface PPP. J'ai coutume de faire créer ce
genre de règle par un script exécuté par pppd à l'établissement de la
connexion (typiquement /etc/ppp/ip-up) et de la faire supprimer de la
même façon en fin de connexion (/etc/ppp/ip-down). L'avantage est que
pppd passe un certain nombre de paramètres à ces scripts, parmi lesquels
le nom de l'interface et les adresses IP locale et distante. Pratique
pour ajuster finement ses règles.

################ Fonctionnalité serveurs ##############

iptables -A INPUT -p tcp --dport ftp -j ACCEPT

Inutile puisque déjà accepté par la première règle de la chaîne
local-internet.

Cette règle est inutile à deux titres. D'une part, comme tu le dis fort
justement, la chaîne local-internet autorise déjà les connexions FTP (et
les autres) depuis toute interface autre que ppp0. D'autre part, les
connexions FTP entrant par ppp0 ont vocation à être redirigées vers le
véritable serveur. Les paquets ne traverseront donc pas la chaîne INPUT
(ni OUTPUT d'ailleurs) de la table filter mais seulement la chaîne FORWARD.

########## PORT FORWARDING ###############
[...]

Il ne suffit pas seulement de nater/rediriger il faut aussi accepter que
la connexion soit forwardée.

iptables -A local-internet -i ppp0 -p tcp --dport21
-m state --state NEW -j ACCEPT

Par précaution, j'ajouterais une condition sur l'adresse destination :
-d 192.168.0.5

Aussi, il n'est pas nécessaire que cette règle soit dans la chaîne
local-internet qui est appelée par les chaînes INPUT et FORWARD. Elle
n'est utile que dans la chaîne FORWARD.

Et enfin il faudrait terminer le script par un rejet (cible REJECT) des
paquets non acceptés.

Je réserverais le REJECT aux paquets non INVALID seulement. Les paquets
dont l'état de suivi de connexion est INVALID méritent le DROP.

Pour finir, mon avis personnel concernant le blocage de l'ICMP echo
(ping) : AMA, ce n'est pas souhaitable et le bénéfice en terme de
sécurité est bien faible devant les inconvénients pratiques (perte de
possibilité de diagnostic, toussa...). Un serveur devrait toujours
répondre au ping.