Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

Iptables, INPUT DROP et translation d'adresse

Wiggum

Bonjour à tous,

Je rencontre un problème pour le moins cocasse ... Enfin au début car maintenant je fais du lancer de souris !
J'ai repris il y a peu la gestion d'un private cloud, une machine avec 3 ip publiques et 1 dans le LAN me sert de Firewall.
Je dois upgrader ce serveur je repars donc sur une machine toute fraiche afin de m'approprier les différentes techno.

Je constate cependant que sur l'ancienne machine, dans le script iptables, après le flush des règles existantes, les règles par défauts sont :
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT

Ma première modification est donc dans le nouveau script de changer en :
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT

Et c'est là que mes problèmes commencent, avant pour rediriger un port vers une ip:port il me suffisait d'un ligne :
iptables -A PREROUTING -t nat -p tcp --dport 8080 -i ethwan -j DNAT --to 192.168.0.10:80

Maintenant ce n'est pas suffisant puisque mon INPUT est en drop ...

Dois je d'abord ouvrir le port 8080 :
iptables -A INPUT -p tcp --dport 8080 -j ACCEPT
puis :
iptables -A PREROUTING -t nat -p tcp --dport 8080 -i ethwan -j DNAT --to 192.168.0.10:80

Cela ne semble pas heureux ...

ou existe t il une commande spécifique ?
Pour info : si je passe en iptables -P INPUT ACCEPT tout se déroule comme prévu je n'ai donc pas de problème de routage.

Voilà si un vieux sage d'iptables est prêt à predre un peu de temps je suis intéressé.

Merci

xavier4811

Bonsoir,

quoi de mieux que de le découvrir par soi même :
A saisir en dernières règles pour voir ce qui bloque et dans quel sens

sudo iptables -t filter -A INPUT -j LOG --log-prefix="DROP_IN "
sudo iptables -t filter -A OUTPUT -j LOG --log-prefix="DROP_OUT "
sudo iptables -t filter -A FORWARD -j LOG --log-prefix="DROP_FORWARD "
##
tail -f /var/log/syslog ## affichage en temps réel sur la console
grep "DROP_" /var/log/syslog ## affichage filtré du syslog

Haleth

iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT

Désolé, mais ..
C'est débile.

Le vieux gourou d'iptables pourrait te donner une solution simple & secure:

iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT

Wiggum

Merci à vous deux,

J'en fais une affaire personnelle donc je vais dans un premier temps suivre le conseil de Xavier (Promis si je trouve je post la solution de mon prob).
Dans un deuxième temps si mon boss n'a pas envie que je perde 3 jours sur une connerie (ce qui s'explique aussi), je ferais comme Haleth me le conseille.

Ce qui est déroutant c'est que parmis tous les tutos trouvés sur le net pour appréhender iptables le premier conseil est de drop l'INPUT et le FORWARD puis d'implémenter les règles spécifiques.

Sans te prendre trop de temps Haleth pourrais tu me dire pourquoi le INPUT ACCEPT n'est pas un problème ?

xavier4811

Wiggum a écritCe qui est déroutant c'est que parmis tous les tutos trouvés sur le net pour appréhender iptables le premier conseil est de drop l'INPUT et le FORWARD puis d'implémenter les règles spécifiques.

C'est plus facile de tout fermer d'abord et d'ouvrir ensuite uniquement ce que l'on veut que de boucher les trous d'un gruyère.
Les commandes que je t'ai donné vont logguer tous les paquets qui ne match pas une règle juste avant qu'ils passent la règle par défaut (POLICY).

Wiggum

Comme promis voici la solution à mon problème :

Je suis relativement buté et j'ai préféré rester en INPUT DROP, FORWARD DROP et OUTPUT ACCEPT (désolé Haleth mais sans explications de ta part, j'en suis resté aux préconisations des différents tutos).

La ligne suivante ne marchait plus
iptables -t nat -A PREROUTING -p tcp -i eth0 -d xxx.xxx.xxx.xxx --dport 10001 -j DNAT --to 10.2.0.1:80

J'avais essayé de corriger le problème grâce à une autre ligne du genre :
iptables -A INPUT -p tcp --dport 8080 -j ACCEPT

Sans résultats et pour cause ... L'autorisation qui me manquait étant à rajouter dans la table FORWARD et non INPUT, du coup avec le couple :

iptables -t nat -A PREROUTING -p tcp -i eth0 -d xxx.xxx.xxx.xxx --dport 10001 -j DNAT --to 10.2.0.1:80
iptables -A FORWARD -p tcp -i eth0 -d 10.2.0.1 --dport 80 -j ACCEPT

tout fonctionne sans soucis !

Merci Xavier et Haleth, mais également merci à NeoX qui avait posté la solution sur un autre forum dans un ancien post.

Haleth

J'te quote Hoper:

Hoper a écrit Allez, comme je suis de bonne humeur ce soir, je vais essayer de t'expliquer un minimum. Imagine qu'un ordinateur est une maison avec plein de fenêtre (que des fenetres, il y a pas de portes). Informatiquement, chaque fenetre est un "port". Quand ton OS démarre (vraiment au début), toutes les fenetres sont fermées. Essaye de te connecter sur un PC qui n'a pas finit de booter, tu va voir que ça va pas bien se passer.
Ensuite, au fur et à mesure, l'OS lance des logiciels. Par exemple, si tu lance un serveur ftp sur ta machine, cela va probablement "ouvrir" la fenetre numéro 21. En réalité, c'est simplement que le programme "serveur ftp" se met derière la fenetre, et que si quelqu'un tape à cette vitre, il va ouvrir et répondre "oui, je suis un serveur ftp, qu'est ce que vous voulez ?"

Et si c'est un client ftp qui a tapé à la fenêtre, il vont se mettre à discuter ensemble. Voila comment ça marche. Donc "ouvrir" ou "fermer" un port ça ne veut rien dire. Un FW, c'est (entre autre) une clôture que tu met autour de la maison pour empêcher tout le monde de s'approcher. Sauf que si tu laisse personne entrer ou sortir, ton pc, autant débrancher le câble réseau hein... Bref, pas de firewall activé sous ubuntu par défaut parce que ça sert à rien. Le gars qui est, par exemple, derrière la fenêtre 21 est suffisamment costaux pour péter la gueule d'un gars qui voudrait entrer dans la baraque par cette fenêtre si il fait pas parti des gens autorisé à entrer. Et c'est pareil pour chaque gars derrière chaque fenêtre. LE fait de mettre une clôture devant n'y changera strictement rien, car si tu attend des invités, il va bien falloir les laisser entrer de toute façon, et c'est pas la clôture qui vérifiera leur identité.

En espérant que tu ai un peu mieux compris...

Bref, en gros, tu peux faire un telnet localhost 80, si y'a pas de serv web, tu te feras kick. Et si y'a un serv web, ben ton FW sera logiquement ouvert.

Wiggum

Dans l'absolu je suis d'accord avec toi Haleth, sur un serveur web c'est d'une logique implacable, peut être qu'après je tombe dans le panneau mais il y a autre chose que je prends en considération.

Par exemple:
En INPUT DROP je choisis qu'elles sont les IP sources ayant le droit d'utiliser mon port 22.
En input ACCEPT, c'est la fête du slip.

Quelqu'un de très pointu surveillera tous les security updates des paquets utilisés sur son serveur et les mettra à jour pour se prémunir d'une attaque, pour ma part je ne suis pas assez pointu dans le domaine et limiter les IP sources me rassurent (peut être à tort ?).

xavier4811

Wiggum a écrit En INPUT DROP je choisis qu'elles sont les IP sources ayant le droit d'utiliser mon port 22.
En input ACCEPT, c'est la fête du slip.

C'est l'avantage de netfilter. Tu peux quasiment tout filtrer, a toi de voir si tu en a l'utilité. Et pour en ajouter encore (mode parano total 😃 ) tu peux aussi filtrer les adresses ip dans la conf des services et avec les fichiers /etc/hosts.allow et /etc/hosts.deny

Et même sans en avoir vraiment l'utilité, c'est très intéressant a apprendre, a condition d'avoir la motivation pour.