Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

iptables port forwarding et filtrage

49 réponses
Avatar
Benoit Izac
Bonjour,

J'ai un petit soucis avec iptables, je souhaiterai rediriger ce qui
arrive sur le port 200 sur eth0 vers le port 100 de la même machine.
Ceci n'est pas compliqué :

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 200 \
-j REDIRECT --to ports 100

Le problème est que je souhaiterai que le port 100 ne soit plus
accessible directement. Si je fais naïvement :
iptables -i eth0 -p tcp --dport 100 -j REJECT
iptables bloque tout se qui arrive sur le port 100 mais aussi ce qui
a été redirigé.

Comment faire pour changer un port de façon transparente (l'ancien port
n'est plus visible) ?

Merci.
--
Benoit Izac

10 réponses

1 2 3 4 5
Avatar
Pascal Hambourg
Salut,

Benoit Izac a écrit :

J'ai un petit soucis avec iptables, je souhaiterai rediriger ce qui
arrive sur le port 200 sur eth0 vers le port 100 de la même machine.
Ceci n'est pas compliqué :

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 200
-j REDIRECT --to ports 100



s/--to ports/--to-ports/

Le problème est que je souhaiterai que le port 100 ne soit plus
accessible directement. Si je fais naïvement :
iptables -i eth0 -p tcp --dport 100 -j REJECT



Tu te manges une grosse erreur de syntaxe.

iptables bloque tout se qui arrive sur le port 100 mais aussi ce qui
a été redirigé.



En effet.
"-m conntrack --ctstate DNAT" ne détecte que les changements d'adresse,
pas de port. Il reste le marquage des paquets avec "-j MARK" dans la
chaîne mangle/PREROUTING avant redirection et le test de la marque avec
"-m mark" après dans la chaîne INPUT.
Avatar
Nicolas George
Pascal Hambourg wrote in message <h8nh99$1858$:
iptables bloque tout se qui arrive sur le port 100 mais aussi ce qui
a été redirigé.


"-m conntrack --ctstate DNAT" ne détecte que les changements d'adresse,
pas de port. Il reste le marquage des paquets avec "-j MARK" dans la
chaîne mangle/PREROUTING avant redirection et le test de la marque avec
"-m mark" après dans la chaîne INPUT.



Est-ce qu'il n'y aurait pas moyen de jouer avec l'ordre des paquets. La doc
n'est pas très explicite sur ce point, mais j'ai l'impression qu'après la
règle REDIRECT, iptables considère que c'est toujours le même paquet qui est
en train de traverser les règles.

Donc peut-être qu'en mettant dans la même chaîne d'abord la règle qui
rejette les paquets pour le port 100 puis celle qui transforme le port 200
en port 100, ça passerait.
Avatar
Benoit Izac
Bonjour,

le 15/09/2009 à 09:55, Pascal Hambourg a écrit dans le message
<h8nh99$1858$ :

J'ai un petit soucis avec iptables, je souhaiterai rediriger ce qui
arrive sur le port 200 sur eth0 vers le port 100 de la même machine.
Ceci n'est pas compliqué :

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 200
-j REDIRECT --to ports 100



s/--to ports/--to-ports/

Le problème est que je souhaiterai que le port 100 ne soit plus
accessible directement. Si je fais naïvement :
iptables -i eth0 -p tcp --dport 100 -j REJECT



Tu te manges une grosse erreur de syntaxe.



J'avais qu'un petit café quand j'ai tapé le message. ;-)

iptables bloque tout se qui arrive sur le port 100 mais aussi ce qui
a été redirigé.



En effet.
"-m conntrack --ctstate DNAT" ne détecte que les changements d'adresse,
pas de port. Il reste le marquage des paquets avec "-j MARK" dans la
chaîne mangle/PREROUTING avant redirection et le test de la marque avec
"-m mark" après dans la chaîne INPUT.



C'est bien ce qu'il me semblait ; j'ai fais (copié/collé !) :

iptables -t mangle -A PREROUTING -i eth0 -p tcp --dport 200
-j MARK --set-mark 0x1234
iptables -I INPUT 3 -i eth0 --match mark --mark 0x1234 -j ACCEPT

--
Benoit Izac
Avatar
Benoit Izac
Bonjour,

le 15/09/2009 à 10:06, Nicolas George a écrit dans le message
<4aaf4b10$0$22859$ :

Pascal Hambourg wrote in message <h8nh99$1858$:
iptables bloque tout se qui arrive sur le port 100 mais aussi ce qui
a été redirigé.


"-m conntrack --ctstate DNAT" ne détecte que les changements d'adresse,
pas de port. Il reste le marquage des paquets avec "-j MARK" dans la
chaîne mangle/PREROUTING avant redirection et le test de la marque avec
"-m mark" après dans la chaîne INPUT.



Est-ce qu'il n'y aurait pas moyen de jouer avec l'ordre des paquets. La doc
n'est pas très explicite sur ce point, mais j'ai l'impression qu'après la
règle REDIRECT, iptables considère que c'est toujours le même paquet qui est
en train de traverser les règles.

Donc peut-être qu'en mettant dans la même chaîne d'abord la règle qui
rejette les paquets pour le port 100 puis celle qui transforme le port 200
en port 100, ça passerait.



Le problème c'est qu'on ne peut pas mettre ça dans une même chaîne car
il y a deux tables différentes « nat » et « filter ».

--
Benoit Izac
Avatar
Nicolas George
Benoit Izac wrote in message :
Le problème c'est qu'on ne peut pas mettre ça dans une même chaîne car
il y a deux tables différentes « nat » et « filter ».



C'est vrai qu'iptables a récemment introduit des règles plus strictes de ce
genre.

Dans ce cas, tu peux essayer de rediriger le port 100 vers le port 101 (ou
n'importe quel autre port dont tu sais qu'il est fermé) puis rediriger le
port 200 vers le port 100.
Avatar
Pascal Hambourg
Nicolas George a écrit :

Donc peut-être qu'en mettant dans la même chaîne d'abord la règle qui
rejette les paquets pour le port 100 puis celle qui transforme le port 200
en port 100, ça passerait.



Oui, mais filtrer dans les tables 'mangle' ou 'nat', c'est mal, elles ne
sont pas faites pour ça. D'ailleurs la cible REJECT n'est disponible que
dans la table 'filter'.
Avatar
Pascal Hambourg
Nicolas George a écrit :
Benoit Izac wrote in message :
Le problème c'est qu'on ne peut pas mettre ça dans une même chaîne car
il y a deux tables différentes « nat » et « filter ».



C'est vrai qu'iptables a récemment introduit des règles plus strictes de ce
genre.



Tu fais allusion à l'interdiction d'utiliser la cible DROP dans la table
'nat' introduite dans iptables 1.4.3 ? Il reste néanmoins possible de
l'utiliser dans la table 'mangle', même si c'est mal.

Dans ce cas, tu peux essayer de rediriger le port 100 vers le port 101 (ou
n'importe quel autre port dont tu sais qu'il est fermé) puis rediriger le
port 200 vers le port 100.



Après ça comment veux-tu qu'on ait encore de la crédibilité quand on dit
que le NAT n'est pas du filtrage...

Benoît, quel est le but la manoeuvre ? N'était-il pas possible de
simplement modifier le port d'écoute du service concerné ?

Avis perso : avec IPv6 qui approche, il faudrait commencer à se
désintoxiquer du NAT et de ses facilités, car il n'y a pas de NAT pour
IPv6 dans netfilter/iptables et ça n'a pas l'air d'être dans les
intentions des développeurs de l'ajouter.
Avatar
Nicolas George
Pascal Hambourg wrote in message <h8nmg7$19os$:
Après ça comment veux-tu qu'on ait encore de la crédibilité quand on dit
que le NAT n'est pas du filtrage...

Benoît, quel est le but la manoeuvre ? N'était-il pas possible de
simplement modifier le port d'écoute du service concerné ?

Avis perso : avec IPv6 qui approche, il faudrait commencer à se
désintoxiquer du NAT et de ses facilités, car il n'y a pas de NAT pour
IPv6 dans netfilter/iptables et ça n'a pas l'air d'être dans les
intentions des développeurs de l'ajouter.



Ça me semble assez stupide, comme décision. Il est clair que le NAPT
automatique pour partage d'adresse IP n'a pas lieu d'être en IPv6, mais il y
a d'autres utilisations tout à fait légitimes de ces règles qui sont tout à
fait pertinentes en IPv6. Personnellement, j'en utilise deux :

- Une redirection uniquement sur le port pour permettre à un serveur
tournant sans privilèges d'apparaître sur un port privilégié. C'est
largement plus simple que toute autre méthode envisagées, en particulier
au niveau de la quantité d'intervention requise de root (qui a peu de
temps à nous consacrer).

- Une redirection uniquement d'adresse IP pour faire apparaître un serveur
quelconque sur une adresse IP privée au choix. Je m'en sers sur mon
portable pour faire apparaître les serveurs DNS, qui varient selon
l'endroit où le portable en question est branché, toujours sur la même
adresse pour mon PDA connecté en bluetooth. Je n'ai pas envie de faire
tourner un cache DNS local sur cette machine.
Avatar
Pascal Hambourg
Nicolas George a écrit :
Pascal Hambourg wrote in message <h8nmg7$19os$:

Avis perso : avec IPv6 qui approche, il faudrait commencer à se
désintoxiquer du NAT et de ses facilités, car il n'y a pas de NAT pour
IPv6 dans netfilter/iptables et ça n'a pas l'air d'être dans les
intentions des développeurs de l'ajouter.



Ça me semble assez stupide, comme décision. Il est clair que le NAPT
automatique pour partage d'adresse IP n'a pas lieu d'être en IPv6,



Tu ne peux pas écrire "masquerading" comme tout le monde ? :-)
C'est le but originel du NAT (cible MASQ d'ipchains). Ensuite on a
ajouté la redirection de port pour les connexions entrantes (ipmasqadm
pour Linux 2.2/ipchains). L'introduction de netfilter et iptables dans
le noyau 2.4 a étendu le principe.

mais il y a d'autres utilisations tout à fait légitimes de ces règles qui
sont tout à fait pertinentes en IPv6. Personnellement, j'en utilise deux :

- Une redirection uniquement sur le port pour permettre à un serveur
tournant sans privilèges d'apparaître sur un port privilégié. C'est
largement plus simple que toute autre méthode envisagées, en particulier
au niveau de la quantité d'intervention requise de root (qui a peu de
temps à nous consacrer).

- Une redirection uniquement d'adresse IP pour faire apparaître un serveur
quelconque sur une adresse IP privée au choix. Je m'en sers sur mon
portable pour faire apparaître les serveurs DNS, qui varient selon
l'endroit où le portable en question est branché, toujours sur la même
adresse pour mon PDA connecté en bluetooth. Je n'ai pas envie de faire
tourner un cache DNS local sur cette machine.



J'en vois d'autres :
- Dans le cas d'une machine multihomée avec routage avancé, utiliser le
NAT source pour faire en sorte que l'adresse IP source corresponde bien
à l'interface de sortie.

- Le classique proxy "transparent" associant REDIRECT et squid.

Mais toutes ces applications du NAT ne sont fondamentalement que des
béquilles pour des problématiques qui devraient être résolues autrement.
Car un problème de fond demeure : le NAT ne marche pas avec tous les
protocoles et applications. Comme le NAT n'a jamais été standardisé et
inclus dans la spécification du protocole IP (v4 ou v6), chaque
implémentation fait son NAT à sa sauce. Il n'y a qu'à voir toutes les
variantes de NAT qui existent avec des noms plus exotiques les uns que
les autres : "full cone", "symmetric", "port restricted"... Et les
protocoles et applications se débrouillent (ou pas) comme ils peuvent
pour passer à travers (helpers, STUN et compagnie). Bref, on empile les
béquilles.

Je préfèrerais de loin qu'on résolve ces problèmes avec de vraies
solutions plutôt que de les masquer avec du NAT qui introduit de
nouveaux problèmes. C'est peut-être moins facile mais plus robuste et
pérenne.
Avatar
Nicolas George
Pascal Hambourg wrote in message <h8nq7a$1as0$:
Mais toutes ces applications du NAT ne sont fondamentalement que des
béquilles pour des problématiques qui devraient être résolues autrement.



Oui, mais quand on a une béquille qui marche, on ne la jette pas avant
d'avoir une solution propre et durable. Avant de cautionner l'abandon du
NAT, j'attends de voir des moyens concrets de faire ce pour quoi je
l'utilisais.

Car un problème de fond demeure : le NAT ne marche pas avec tous les
protocoles et applications.



Il marche et est utile avec certains, c'est déjà beaucoup.

Comme le NAT n'a jamais été standardisé et
inclus dans la spécification du protocole IP (v4 ou v6), chaque
implémentation fait son NAT à sa sauce.



Le NAT est quelque chose de local, il n'a pas à être standardisé par les
protocoles. Pas plus qu'ifconfig par exemple.

Et les
protocoles et applications se débrouillent (ou pas) comme ils peuvent
pour passer à travers (helpers, STUN et compagnie).



Là, tu es encore en train de restreindre le NAT à une seule de ses
utilisations.
1 2 3 4 5