Bonjour,
Voila mon problème.
J’ai une machine (A) qui fait passerelle entre mon réseau LAN et mon firewall (B)
Je voudrais que mon iptables de la machine A redirige tout le traffic venant à lui vers le firewall (B) sauf le port 80.
Pour par exemple, qu’une application d’un des PC de mon LAN puisse se connecter au port 50000 d’un serveur qui se trouve sur Internet.
Mais comment faire ?
Un schéma de la topologie du réseau en ASCII art, ainsi que le plan d’adressage et les tables de routage des diverses machines seraient appréciables.
Qu’est-ce que (A) doit faire des connexions (TCP je suppose) vers le port 80 ? Les bloquer, les envoyer ailleurs ?
PascalHambourg à raison, ton problème est difficilement compréhensible avec si peut de détail 
Repose nous ton problème tranquillement…
Voila un schéma fait très rapidement 
:
---- Informations :
– PC 1 :
– Machine A (Proxy HTTP) :
– Machine B (Firewall) :
---- Objectifs :
Les PC du réseaux ont comme passerelle la machine A (Proxy HTTP), pour l’instant ce dernier reçoit toutes les requêtes, j’aimerais que tout ce qu’il reçoit qui n’est pas du HTTP(80) soit redirigé vers la machine B (Firewall) comme si ça n’était jamais passé par la machine A.
un exemple :
J’ai une machine qui se trouve sur Internet avec un serveur VNC dessus qui écoute sur le port 50000,
Je veux me connecter à ce serveur depuis un client VNC qui se trouve sur le PC1. Comme ce n’est pas une requête HTTP, j’aimerais que la machine A transmette directement le paquet à la machine B pour aller sur Internet, puis vers mon serveur VNC.
Voila
Comment peut-on faire ?
Merci
Ah… Vu la position de la machine A dans le réseau, on a du mal à imaginer qu’elle soit une passerelle. Une topologie plus traditionnelle aurait consisté à l’intercaler entre les postes du LAN et la machine B. Bref.
Au fait, pourquoi la machine A est-elle la passerelle par défaut des postes du LAN ? Elle fonctionne en proxy HTTP transparent et ce serait trop pénible de la définir comme proxy HTTP explicite dans la configuration des postes du LAN ?
(Ouais, je sais, je suis chiant avec toutes mes questions à la noix, mais je suis curieux quand je vois un truc atypique comme ça)
Pour rediriger le trafic vers sa propre passerelle par défaut, la machine A doit fonctionner en routeur IP, pour cela il faut activer le “forwarding” (ajouter net.ipv4.ip_forward=1 dans /etc/sysctl.conf, pris en compte au démarrage ; écrire la valeur avec sysctl pour prise en compte immédiate). Si iptables ne fait pas de filtrage dans la chaîne FORWARD ni de NAT source/masquerading, c’est à peu près suffisant. Pour approfondir le sujet notamment concernant le routage asymétrique, l’ICMP redirect et leurs conséquences potentielles, voir la page 3 du fil intitulé “regle Iptables” qui traite une situation proche (la passerelle par défaut retransmet vers un routeur de secours situé sur le même LAN).
En faite le LAN est composé d’un peu plus d’une centaine de PC, pour ne pas modifier les configurations réseaux de chaque PC je voulais changer la passerelle (firewall) par le proxy HTTP.
Ensuite que tout traverse le Proxy HTTP sans être filtré sauf le HTTP par Squid.
J’avais déjà activer le forward sur ma machine.
Et voici mes règles mon petit script iptables :
#!/bin/sh
/sbin/iptables -F
/sbin/iptables -F PREROUTING -t nat
/sbin/iptables -F POSTROUTING -t nat
/sbin/iptables -X
/sbin/iptables -F
/sbin/iptables -A INPUT -i lo -j ACCEPT
#autorise l'acces au port http - ssh
/sbin/iptables -A INPUT -i eth0 -p tcp --dport 80 -j ACCEPT
/sbin/iptables -A INPUT -i eth0 -p tcp --dport 22 -j ACCEPT
##### Squid (Redirection du 80 sur 3128)
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 3128
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 50000 -j DNAT --to-destination 172.16.15.254
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADESinon y’aurait t’il une autre topologie réseau que je pourrais faire, en ayant le proxy comme n’importe quel PC dans le réseau et qu’il n’y ait rien à changer sur les postes clients ?
Tiens, c'est rigolo, tu fais la même erreur que guigui69 dans le fil que je cite : tu confonds redirection NAT (modification de l'adresse destination) et simple routage (retransmission) vers une autre passerelle. Cette règle dit que le firewall est la nouvelle destination [b]finale[/b] de la connexion, ce qui n'est probablement pas ce que tu veux.
Si la machine A fait du masquerading, il est d'autant plus impératif que tu lises ce fil à partir du messsage dont j'ai mis le lien. Je signale que je n'ai pas de préférence masquerading / routage asymétrique / ICMP redirect, le tout est de faire un choix et qu'au final la configuration soit cohérente.
Je ne vois pas le réglage des politiques par défaut des chaînes filter. Si c'est la valeur par défaut ACCEPT, alors les règles ACCEPT dans la chaînes INPUT ne servent à rien. Accessoirement, dans le cas contraire c'est le port 3128 qu'il aurait fallu autoriser et non le port 80 car la chaîne INPUT est parcourue après la chaîne PREROUTING et donc après que la redirection par la cible REDIRECT ait eu lieu.
[quote]Sinon y'aurait t'il une autre topologie réseau que je pourrais faire, en ayant le proxy comme n'importe quel PC dans le réseau et qu'il n'y ait rien à changer sur les postes clients ?
[/quote]
Garder "le proxy comme n'importe quel PC dans le réseau", c'est la même topologie. Si je comprends bien, la machine A est un proxy HTTP transparent. Tu aurais pu en faire aussi un pont semi-transparent avec deux interfaces intercalé entre les postes et le firewall, ce qui aurait évité de modifier le plan d'adressage. Mais je reconnais que cette solution est un peu délicate à mettre en oeuvre.
Une autre solution, si le firewall le permet (c'est quoi au fait ?), consiste à laisser le firewall comme passerelle par défaut pour les postes et à rediriger (au sens NAT) ou rerouter (au sens routage) les connexions HTTP vers le proxy (sauf celles qui viennent du proxy évidemment).
Enfin, l'utilisation de VLAN si le matériel (switch, firewall, proxy) le supporte permettrait de modifier la topologie logique sans modifier les liaisons physiques.
[quote]En faite le LAN est composé d'un peu plus d'une centaine de PC, pour ne pas modifier les configurations réseaux de chaque PC je voulais changer la passerelle (firewall) par le proxy HTTP.[/quote]
Mais pour cela tu dois bien modifier la passerelle par défaut sur tous les postes, non ?
Ce ne serait pas plus simple de donner l'adresse IP du firewall au proxy et de déplacer le firewall derrière le proxy, dans un autre sous-réseau ?Tiens, c’est rigolo, tu fais la même erreur que guigui69 dans le fil que je cite : tu confonds redirection NAT (modification de l’adresse destination) et simple routage (retransmission) vers une autre passerelle. Cette règle dit que le firewall est la nouvelle destination finale de la connexion, ce qui n’est probablement pas ce que tu veux.
Si la machine A fait du masquerading, il est d’autant plus impératif que tu lises ce fil à partir du messsage dont j’ai mis le lien. Je signale que je n’ai pas de préférence masquerading / routage asymétrique / ICMP redirect, le tout est de faire un choix et qu’au final la configuration soit cohérente.
Je ne vois pas le réglage des politiques par défaut des chaînes filter. Si c’est la valeur par défaut ACCEPT, alors les règles ACCEPT dans la chaînes INPUT ne servent à rien. Accessoirement, dans le cas contraire c’est le port 3128 qu’il aurait fallu autoriser et non le port 80 car la chaîne INPUT est parcourue après la chaîne PREROUTING et donc après que la redirection par la cible REDIRECT ait eu lieu.
[quote]Sinon y’aurait t’il une autre topologie réseau que je pourrais faire, en ayant le proxy comme n’importe quel PC dans le réseau et qu’il n’y ait rien à changer sur les postes clients ?
[/quote]
Garder “le proxy comme n’importe quel PC dans le réseau”, c’est la même topologie. Si je comprends bien, la machine A est un proxy HTTP transparent. Tu aurais pu en faire aussi un pont semi-transparent avec deux interfaces intercalé entre les postes et le firewall, ce qui aurait évité de modifier le plan d’adressage. Mais je reconnais que cette solution est un peu délicate à mettre en oeuvre.
Une autre solution, si le firewall le permet (c’est quoi au fait ?), consiste à laisser le firewall comme passerelle par défaut pour les postes et à rediriger (au sens NAT) ou rerouter (au sens routage) les connexions HTTP vers le proxy (sauf celles qui viennent du proxy évidemment).
Enfin, l’utilisation de VLAN si le matériel (switch, firewall, proxy) le supporte permettrait de modifier la topologie logique sans modifier les liaisons physiques.
Mais pour cela tu dois bien modifier la passerelle par défaut sur tous les postes, non ?
Ce ne serait pas plus simple de donner l’adresse IP du firewall au proxy et de déplacer le firewall derrière le proxy, dans un autre sous-réseau ?
C’est ce que je me disais en réfléchissant bien 
Oui je voudrais éviter cette topologie, que si quelque chose arrive sur le proxy, qu’on est toujours l’accès au Web en changeant juste l’adresse du firewall.
C’est exactement ce que j’essaye de faire en ce moment. mon firewall est un PIX 506e et je sais pas si je peux le faire, car rerouter de inside à inside je crois pas qu’on puisse.
Si tu as des idées sur le PIX ?, maintenant je vais bien lire l’autre topic que tu m’a donné, et je reviendrai si j’ai de sproblèmes
Si tu as peur que le proxy tombe en panne, tu peux prévoir une machine de secours prête à prendre le relais.
Si tu persistes dans ta configuration initiale, après avoir lu l’autre fil tu verras que tu as le choix entre deux possibilités :
a) La machine A fait du masquerading/SNAT
Contrainte : pour que le NAT fonctionne la machine A doit voir passer tout le trafic aller et retour.
Il faut donc désactiver l’envoi de messages ICMP redirect afin qu’ils ne dévient pas le trafic émis par les postes vers le firewall.
Avantages :
b) La machine A ne fait pas de masquerading/SNAT
Elle n’a pas besoin de voir passer le trafic dans les deux sens, pas besoin de désactiver l’envoi d’ICMP redirect.
Avantages :
Je ne connais pas du tout le PIX.
Pourrais-tu me détailler un peu + comment mettre en place la 2ème solution (qui est meilleur ?)
Merci
Il devrait suffire de supprimer la règle de masquerading. Pour tout ce qui n’est pas HTTP, la machine A doit se comporter comme un routeur absolument classique. J’insiste sur le fait qu’un routeur classique ne fait pas de NAT ni de filtrage, ce sont ces erzatz que sont les box des FAI et autres soi-disant routeurs SOHO qui en font.
EDIT
Il ne reste donc plus que
Et pour l’économie du suivi de connexion, mais c’est totalement facultatif (et en plus j’ai pas trop testé, huhu)
iptables -t raw -A PREROUTING -p tcp --dport 80 -j ACCEPT
iptables -t raw -A PREROUTING -j NOTRACK
iptables -t raw -A OUTPUT -p tcp --sport 3128 -j ACCEPT
iptables -t raw -A OUTPUT -j NOTRACKLes seuls paquets à suivre sont ceux des connexions interceptées par REDIRECT, dans les deux sens.
Ok donc je reviens au système de base avec le proxy qui écoute en 3128, la redirection du 80 en 3128 avec iptables, mais alors pour la partie routeur je la paramètre comment ?
Si le forward est déjà activé, il n’y a rien d’autre à paramétrer.
Ok merci je testerai ça demain, je te redirai :smt001
C’est bon ça fonctionne, par contre sur la machine Proxy je laisse tout passer comme elle fonctionne comme routeur ? parce que pour la sécurité de mon Proxy c’est pas génial nan ?
Pour la sécurité de la machine A en tant que serveur proxy tu peux ajouter des règles de filtrage à ta convenance dans INPUT, mais en tant que routeur je ne vois guère d’intérêt à filtrer dans FORWARD dans la mesure où il y a le PIX derrière et le trafic routé à travers la machine A pourrait aussi bien être envoyé directement au PIX. Eventuellement tu peux filtrer sur les adresses source et destination pour ne retransmettre que les paquets qui ont lieu de l’être (d’une adresse LAN vers une adresse non-LAN).
Ce que j’ai fait, c’est que j’ai tout filtrer en INPUT sauf le SSH et le port 80 qui redirige sur le port 3128 de Squid, puis j’ai tout laisser ouvert en FORWARD et OUTPUT.
Je pense que ça ira, nan ?
Comme je l’ai déjà souligné plus haut, c’est plutôt le port 3128 et non 80 qu’il faut autoriser dans INPUT car la redirection a eu lieu avant dans PREROUTING. N’oublie pas non plus d’autoriser les paquets dans l’état ESTABLISHED et RELATED pour le trafic retour des connexions sortantes.