Iptables - redirection de port

Salut,

Droopy191 a écrit :

Je débute avec iptables. J'ai réussi à mettre en place une passerelle
qui fait du nat. Sur cette passerelle, un serveur ssh en écoute sur le
port 22. Je voudrais coté WAN uniquement rediriger le port 14722 vers le
port 22 de la passerelle.

Les goûts et les couleurs...

J'ai réussi à faire ce que veux de la facon suivante mais je m'interroge
si c'est la bonne manière:
J'autorise le port 22 en entrée, je redirige le port 14722 vers le port
22 du serveur,

Jusque là c'est bon.

mais je suis obligé de dropper le port 22 classique car
sinon le serveur est aussi accessible sur le port 22.

En effet, puisque la redirection a lieu avant le filtrage.

De plus la régle PREROUTING + DROP est noté dépréciée.

# drop du port 22
iptables -t nat -I PREROUTING -i $WAN_interface -p tcp --dport ssh -j DROP

C'est mal. La table nat n'est pas faite pour le filtrage, et il y a un
risque d'effet de bord. La table filter est là pour ça.

# transfert de port sur la passerelle pour le coté WAN
iptables -t nat -I PREROUTING -i $WAN_interface -p tcp --dport 14722 -j
REDIRECT --to-ports ssh
# Connexions ssh depuis internet sur la passerelle
iptables -A INPUT -i $WAN_interface -p tcp --dport ssh -m conntrack
--ctstate NEW -j ACCEPT

Comment feriez vous ?

Le plus simplement, je demanderais directement à sshd d'écouter sur le
port 14722 au lieu du port 22.
Sinon, mais c'est un peu plus compliqué, il est possible de marquer les
paquets dans la chaîne PREROUTING de la table mangle (donc avant nat)
avec la cible MARK en fonction du port de destination et de filtrer en
fonction de la marque avec la correspondance mark dans la chaîne INPUT.

Serait il plus adapté de faire une redirection de port classique comme
pour une machine du LAN ?

Que veux-tu dire exactement ?

Le 15/02/2010 08:11, Pascal Hambourg a écrit :

J'ai réussi à faire ce que veux de la facon suivante mais je m'interroge
si c'est la bonne manière:
J'autorise le port 22 en entrée, je redirige le port 14722 vers le port
22 du serveur,

Jusque là c'est bon.

mais je suis obligé de dropper le port 22 classique car
sinon le serveur est aussi accessible sur le port 22.

En effet, puisque la redirection a lieu avant le filtrage.

De plus la régle PREROUTING + DROP est noté dépréciée.

# drop du port 22
iptables -t nat -I PREROUTING -i $WAN_interface -p tcp --dport ssh -j DROP

C'est mal. La table nat n'est pas faite pour le filtrage, et il y a un
risque d'effet de bord. La table filter est là pour ça.

Je l'avais soupçonné comme iptables grognait sur la commande.
Mais je ne vois pas comment c'est possible, puiqu'il faut autoriser le
port 22 dans la table filter ( c'est bien le port d'écoute de ssh)
14722- > PREROUTING -> 22 -> FILTER -> ssh
22 -> FILTER -> ssh
Dans ce cas les 2 ports sont accessibles depuis le coté WAN.
Je crois que vous donnez une piste plus bas avec la table mangle.

Comment feriez vous ?

Le plus simplement, je demanderais directement à sshd d'écouter sur le
port 14722 au lieu du port 22.

Bien évidement. Mais ici, je m'applique à comprendre iptables, ne jugez
pas trop sévèrement le bien fondé de ma demande ;-)

Sinon, mais c'est un peu plus compliqué, il est possible de marquer les
paquets dans la chaîne PREROUTING de la table mangle (donc avant nat)
avec la cible MARK en fonction du port de destination et de filtrer en
fonction de la marque avec la correspondance mark dans la chaîne INPUT.

Bon il va falloir que je retourne à la doc.
Si j'ai bien compris, la table mangle sert à manipuler les paquets.

Je marque les paquets qui m'interesse pour pouvoir les filtrer à l'étape
suivante FILTER ? Ceci dit, je ne vois pas comment je vais pouvoir
distinguer les 2 types, puisque à l'arrivée dans la table MANGLE ils
seront tous les 2 sur le port 22.

Serait il plus adapté de faire une redirection de port classique comme
pour une machine du LAN ?

Que veux-tu dire exactement ?

Qq chose de ce gout la( je faire une redirection de port comme si ma
passerelle était une machine différente sur le LAN )
#iptables -t nat -A PREROUTING -i $WAN_interface -p tcp --dport 14722 -j
DNAT --to-destination 192.168.50.1:22
#iptables -A FORWARD -i $WAN_interface -p tcp --dport 22 -o
$LAN_interface -d 192.168.50.1 -m conntrack --ctstate NEW -j ACCEPT



--
DR

Droopy191 a écrit :

Le 15/02/2010 08:11, Pascal Hambourg a écrit :

Sinon, mais c'est un peu plus compliqué, il est possible de marquer les
paquets dans la chaîne PREROUTING de la table mangle (donc avant nat)
avec la cible MARK en fonction du port de destination et de filtrer en
fonction de la marque avec la correspondance mark dans la chaîne INPUT.

Bon il va falloir que je retourne à la doc.
Si j'ai bien compris, la table mangle sert à manipuler les paquets.

Oui. Ici on va juste leur donner une marque à usage interne du noyau,
sans les modifier.

Je marque les paquets qui m'interesse pour pouvoir les filtrer à l'étape
suivante FILTER ? Ceci dit, je ne vois pas comment je vais pouvoir
distinguer les 2 types, puisque à l'arrivée dans la table MANGLE ils
seront tous les 2 sur le port 22.

Comme dit plus haut, la chaîne PREROUTING de la table mangle est
parcourue avant la chaîne de même nom de la table nat.

Qq chose de ce gout la( je faire une redirection de port comme si ma
passerelle était une machine différente sur le LAN )
#iptables -t nat -A PREROUTING -i $WAN_interface -p tcp --dport 14722 -j
DNAT --to-destination 192.168.50.1:22

Ça peut aussi marcher. Ensuite pour le filtrage la distinction peut se
faire sur l'adresse de destination. Mais attention si l'adresse interne
peut être atteinte depuis l'extérieur (qui contrôle le routage amont ?).

Encore une autre possibilité : rediriger le port 22 vers un port ou une
adresse inutilisé(e) et filtrer les paquets ensuite. On peut même
exploiter une particularité intéressante du noyau qui jette tout paquet
destiné à une adresse de loopback (127.0.0.0/8) reçu par une interface
autre que loopback (lo), ce qui économise la règle de filtrage.

#iptables -A FORWARD -i $WAN_interface -p tcp --dport 22 -o
$LAN_interface -d 192.168.50.1 -m conntrack --ctstate NEW -j ACCEPT

Ça, par contre, ce n'est pas bon. Les paquets destinés à la machine
passent par INPUT, pas par FORWARD.

Le 15/02/2010 11:12, Pascal Hambourg a écrit :

Je marque les paquets qui m'interesse pour pouvoir les filtrer à l'étape
suivante FILTER ? Ceci dit, je ne vois pas comment je vais pouvoir
distinguer les 2 types, puisque à l'arrivée dans la table MANGLE ils
seront tous les 2 sur le port 22.

Comme dit plus haut, la chaîne PREROUTING de la table mangle est
parcourue avant la chaîne de même nom de la table nat.

J'ai beau avoir un schema du processus ;-)
http://www.csie.ntu.edu.tw/~b92035/cnl/hw1/Iptables.gif
j'avais mal compris.
J'étais sur la table mangle avant Input.
Ok

Qq chose de ce gout la( je faire une redirection de port comme si ma
passerelle était une machine différente sur le LAN )
#iptables -t nat -A PREROUTING -i $WAN_interface -p tcp --dport 14722 -j
DNAT --to-destination 192.168.50.1:22

Ça peut aussi marcher. Ensuite pour le filtrage la distinction peut se
faire sur l'adresse de destination. Mais attention si l'adresse interne
peut être atteinte depuis l'extérieur (qui contrôle le routage amont ?).

L'adresse interne n'est accessible que depuis le LAN.
L'étape suivante serait de de filtrer suivant la destination ( ip locale
192.168.50.1 accepté / ip WAN rejeté ) ?

Encore une autre possibilité : rediriger le port 22 vers un port ou une
adresse inutilisé(e) et filtrer les paquets ensuite. On peut même
exploiter une particularité intéressante du noyau qui jette tout paquet
destiné à une adresse de loopback (127.0.0.0/8) reçu par une interface
autre que loopback (lo), ce qui économise la règle de filtrage.

#iptables -A FORWARD -i $WAN_interface -p tcp --dport 22 -o
$LAN_interface -d 192.168.50.1 -m conntrack --ctstate NEW -j ACCEPT

Ça, par contre, ce n'est pas bon. Les paquets destinés à la machine
passent par INPUT, pas par FORWARD.

Ok, c'est logique une fois dit. J'avais dans l'idée de faire "ressortir"
les paquets et de les faire entrer comme si ils venaient du LAN.


merci pour vos éclaircissements



--
DR

Droopy191 a écrit :

#iptables -t nat -A PREROUTING -i $WAN_interface -p tcp --dport 14722 -j
DNAT --to-destination 192.168.50.1:22

Ça peut aussi marcher. Ensuite pour le filtrage la distinction peut se
faire sur l'adresse de destination. Mais attention si l'adresse interne
peut être atteinte depuis l'extérieur (qui contrôle le routage amont ?).

L'adresse interne n'est accessible que depuis le LAN.

Ça dépend du routage amont.

L'étape suivante serait de de filtrer suivant la destination ( ip locale
192.168.50.1 accepté / ip WAN rejeté ) ?

Par exemple.

Ça, par contre, ce n'est pas bon. Les paquets destinés à la machine
passent par INPUT, pas par FORWARD.

Ok, c'est logique une fois dit. J'avais dans l'idée de faire "ressortir"
les paquets et de les faire entrer comme si ils venaient du LAN.

Ça ne marche pas comme ça sous Linux. Un paquet qui sort, il sort et ne
rentre pas. Seules exeptions : les paquets émis par l'interface de
loopback et les paquets émis en broadcast ou multicast, qui reviennt par
INPUT mais toujours pas par FORWARD.

Le 15/02/2010 11:46, Droopy191 a écrit :

Le 15/02/2010 11:12, Pascal Hambourg a écrit :

Je marque les paquets qui m'interesse pour pouvoir les filtrer à l'étape
suivante FILTER ? Ceci dit, je ne vois pas comment je vais pouvoir
distinguer les 2 types, puisque à l'arrivée dans la table MANGLE ils
seront tous les 2 sur le port 22.

Comme dit plus haut, la chaîne PREROUTING de la table mangle est
parcourue avant la chaîne de même nom de la table nat.

J'ai beau avoir un schema du processus ;-)
http://www.csie.ntu.edu.tw/~b92035/cnl/hw1/Iptables.gif
j'avais mal compris.
J'étais sur la table mangle avant Input.
Ok

comme ceci ca marche
on marque les 2 ports en entrée, on redirige le 14722, puis on filtre

iptables -t mangle -A PREROUTING -i $WAN_interface -p tcp --dport ssh -j
MARK --set-mark 1
iptables -t mangle -A PREROUTING -i $WAN_interface -p tcp --dport 14722
-j MARK --set-mark 2
iptables -t nat -I PREROUTING -i $WAN_interface -p tcp --dport 14722 -j
REDIRECT --to-ports ssh
iptables -A INPUT -i $WAN_interface -p tcp --dport ssh -m conntrack -m
mark --mark 2 --ctstate NEW -j ACCEPT
iptables -A INPUT -i $WAN_interface -p tcp --dport ssh -m conntrack -m
mark --mark 1 --ctstate NEW -j REJECT




--
DR

Droopy191 a écrit :

comme ceci ca marche
on marque les 2 ports en entrée, on redirige le 14722, puis on filtre

Pas besoin de marquer les deux, un seul suffit.

iptables -t mangle -A PREROUTING -i $WAN_interface -p tcp --dport ssh -j
MARK --set-mark 1
iptables -t mangle -A PREROUTING -i $WAN_interface -p tcp --dport 14722
-j MARK --set-mark 2
iptables -t nat -I PREROUTING -i $WAN_interface -p tcp --dport 14722 -j
REDIRECT --to-ports ssh

La règle nat pourrait exploiter la marque plutôt que répéter l'interface
d'entrée et le port.

iptables -A INPUT -i $WAN_interface -p tcp --dport ssh -m conntrack -m
mark --mark 2 --ctstate NEW -j ACCEPT
iptables -A INPUT -i $WAN_interface -p tcp --dport ssh -m conntrack -m
mark --mark 1 --ctstate NEW -j REJECT

1) La marque a déjà été posée en fonction de l'interface d'entrée et du
port, inutile de les répéter.
2) J'éviterais de mélanger les correspondances et leurs options :
-m conntrack --ctstate NEW -m mark --mark 2
3) Je ne vois pas trop l'intérêt de limiter à l'état NEW ici.
4) Par défaut REJECT envoie un ICMP port unreachable. Pour imiter le
comportement d'un port TCP fermé, il vaut mieux utiliser REJECT
--reject-with tcp-reset (envoi d'un TCP RST).

Le 23/02/2010 11:29, Pascal Hambourg a écrit :

Droopy191 a écrit :

comme ceci ca marche
on marque les 2 ports en entrée, on redirige le 14722, puis on filtre

Pas besoin de marquer les deux, un seul suffit.

ok

iptables -t mangle -A PREROUTING -i $WAN_interface -p tcp --dport ssh -j
MARK --set-mark 1
iptables -t mangle -A PREROUTING -i $WAN_interface -p tcp --dport 14722
-j MARK --set-mark 2
iptables -t nat -I PREROUTING -i $WAN_interface -p tcp --dport 14722 -j
REDIRECT --to-ports ssh

La règle nat pourrait exploiter la marque plutôt que répéter l'interface
d'entrée et le port.

Pour des questions de performances ou simplement une autre manière de
faire ?

iptables -A INPUT -i $WAN_interface -p tcp --dport ssh -m conntrack -m
mark --mark 2 --ctstate NEW -j ACCEPT
iptables -A INPUT -i $WAN_interface -p tcp --dport ssh -m conntrack -m
mark --mark 1 --ctstate NEW -j REJECT

1) La marque a déjà été posée en fonction de l'interface d'entrée et du
port, inutile de les répéter.

ok

2) J'éviterais de mélanger les correspondances et leurs options :
-m conntrack --ctstate NEW -m mark --mark 2

là, je n'ai pas compris

3) Je ne vois pas trop l'intérêt de limiter à l'état NEW ici.

en effet, pour la regle de rejet

4) Par défaut REJECT envoie un ICMP port unreachable. Pour imiter le
comportement d'un port TCP fermé, il vaut mieux utiliser REJECT
--reject-with tcp-reset (envoi d'un TCP RST).

ok

--
DR

Droopy191 a écrit :

Le 23/02/2010 11:29, Pascal Hambourg a écrit :

La règle nat pourrait exploiter la marque plutôt que répéter l'interface
d'entrée et le port.

Pour des questions de performances ou simplement une autre manière de
faire ?

Pour faire plus simple, plus court donc plus lisible...

[...] -m conntrack -m mark --mark 2 --ctstate NEW [...]

2) J'éviterais de mélanger les correspondances et leurs options :
-m conntrack --ctstate NEW -m mark --mark 2

là, je n'ai pas compris

Tu as écrit : match1 match2 option-match2 option-match1
Il vaut mieux écrire : match1 option-match1 match2 option-match2
C'est plus logique et lisible, non ?

Le 26/02/2010 07:27, Pascal Hambourg a écrit :

Droopy191 a écrit :

Le 23/02/2010 11:29, Pascal Hambourg a écrit :

La règle nat pourrait exploiter la marque plutôt que répéter l'interface
d'entrée et le port.

Pour des questions de performances ou simplement une autre manière de
faire ?

Pour faire plus simple, plus court donc plus lisible...

[...] -m conntrack -m mark --mark 2 --ctstate NEW [...]

2) J'éviterais de mélanger les correspondances et leurs options :
-m conntrack --ctstate NEW -m mark --mark 2

là, je n'ai pas compris

Tu as écrit : match1 match2 option-match2 option-match1
Il vaut mieux écrire : match1 option-match1 match2 option-match2
C'est plus logique et lisible, non ?

ok merci

--
DR