Proxy derrière un firewall ?

Bonjour à toutes et à tous,

Le titre du post est bien parlant.

Soit une solution proxy de filtrage du type SQUID que je veux faire
fonctionner sur un LAN public en DHCP.
Je ne peux configurer automatiquement le proxy des navigateurs web des
clients.
Est il donc possible de le placer en aval du firewall ?

Soit le croquis suivant:

@-----|proxy|-----|firewall|-------|LAN|

Dans ce cas comment cela se paramètrerait il sur le firewall ?

Ou bien quelqu'un aurait une autre idée ?

Olive
un proxy transparent peut etre

pour info
http://www.cru.fr/renater-cache/transparent_proxy_how_to.html

Le Thu, 24 Nov 2005 14:18:19 +0100, olive a écrit :

Est il donc possible de le placer en aval du firewall ?
Soit le croquis suivant:

@-----|proxy|-----|firewall|-------|LAN|

Oui, bien sûr. On peut faire un proxy transparent, dont les deux cartes
réseaux sont montées en bridge.
Ensuite avec iptables, on reroute tous les paquets à destination des
ports gérés par le proxy (http, https, ftp, etc...) vers le port local
du proxy (genre 3128 pour squid).

Dans ce cas comment cela se paramètrerait il sur le firewall ?

A priori rien, sauf à spécifier dans la règle l'ip du proxy comme
étant la provenance des paquets sensés sortir du même proxy.
En cas de panne du proxy, il faudra modifier cette règle.


--
DAPL
http://marreduspam.com/ad252602

un proxy transparent peut etre

pour info
http://www.cru.fr/renater-cache/transparent_proxy_how_to.html

Mais oui c'est bien sur !!! Pourquoi l'ais je oublié celui là :p
Merci aussi à DALP pour sa réponse !

Le truc, c'est que mon proxy est une solution clé en main ... et je me
demande si le SQUID qui est à l'intérieur possède la configuration
ad-hoc pour fonctionner en mode transparant ... en plus il semblerait
qu'il demande une authentification des clients ... pffff va falloir que
je me tourne vers le fournisseur du soft (serveur de filtrage URL avec
proxy SQUID intégré) ...

To be continued ...

olive a écrit(wrote):

Bonjour à toutes et à tous,

Bonjour,

Le titre du post est bien parlant.

Le sujet est un peu hors sujet ici, mais vu que je traine ici...

Soit une solution proxy de filtrage du type SQUID que je veux faire
fonctionner sur un LAN public en DHCP.
Je ne peux configurer automatiquement le proxy des navigateurs web des
clients.

Voir plus loin...

Est il donc possible de le placer en aval du firewall ?

Soit le croquis suivant:

@-----|proxy|-----|firewall|-------|LAN|

Il serait plus judicieux de la placer dans une zone à part ce qui ferait
un schéma du genre :

@------|firewall|-------|LAN|
|
|
|proxy|

L'intérêt est de protéger le proxy, à la fois des utilisateurs et
d'Internet.

Dans ce cas comment cela se paramètrerait il sur le firewall ?

Ou bien quelqu'un aurait une autre idée ?

Dans ce cas la configuration "propre" voudrait que entre les seuls flux
ouverts :
- entre le LAN et proxy le soit en destination de TCP/3128 (ou autre si
modifié)
- le DNS entre le proxy et les serveurs DNS.
- les protocoles web standard entre le proxy et Internet (TCP/80,443 et
d'autres si besoin 81, 8080, 8443... en accord avec le filtrage fait
sur le proxy, voir tous les ports si on fait confiance au proxy)
Cela c'est si la configuration du proxy est connue des clients...

Maintenant concernant la configuration automatique, il y a plusieurs
solutions :
- du "Policy routing" sur le firewall : on ouvre les port "web" sur le
firewall, mais on route les paquets sur le proxy. Sur le proxy, on
met en place une redirection de sorte à rerouter le traffic web sur le
proxy. Ainsi, le paquet qui est envoyé sur le proxy n'est pas modifié
(c'est essentiel pour le HTTPS et/ou des port non standard) et arrive
sur le proxy ou il est modifié localement (ce qui permet à Squid de
savoir quel est la modification et de retrouver ses petits),
- du WCCP, ceci nécessite un routeur et des modifications d'archi (en
particulier, il est déconseillé de vouloir filtrer le demi tunnel
GRE...), je le mentionne pour info :
http://www.squid-cache.org/Doc/FAQ/FAQ-17.html
- l'utilisation de WPAD, qui est une méthode assez simple :
http://www.squid-cache.org/Doc/FAQ/FAQ-5.html
On peut ainsi configurer la plus des navigateurs de sont domaine assez
rapidement, sans grosse difficulté, Il suffit juste d'avoir un serveur
web, qui peut être par exemple sur le proxy.
La FAQ est assez claire, je ne la recopie pas...

Olive

--
Julien

http://www.cru.fr/renater-cache/transparent_proxy_how_to.html

Ho purée ! c'est pas tout jeune ça :

# Le noyau (2.0.29, 2.0.31 et plus) doit être compilé avec les options
[...]
CONFIG_IP_TRANSPARENT_PROXY=y
CONFIG_IP_ALWAYS_DEFRAG=y
[...]
ipfwadm -I -a accept -W lo

Oui, bien sûr. On peut faire un proxy transparent, dont les deux cartes
réseaux sont montées en bridge.
Ensuite avec iptables, on reroute tous les paquets à destination des
ports gérés par le proxy (http, https, ftp, etc...) vers le port local
du proxy (genre 3128 pour squid).

Question naïve : on peut utiliser iptables pour manipuler les paquets
qui transitent entre les interfaces d'un bridge ?

http://www.cru.fr/renater-cache/transparent_proxy_how_to.html

Ho purée ! c'est pas tout jeune ça :

# Le noyau (2.0.29, 2.0.31 et plus) doit être compilé avec les opti ons
[...]
CONFIG_IP_TRANSPARENT_PROXY=y
CONFIG_IP_ALWAYS_DEFRAG=y
[...]
ipfwadm -I -a accept -W lo
oui mais c etait pour le schema et le principe general d un proxy transma rent.

on peut qd meme l adapter au kernel recent.

et de plus cets dans les vielles marmites qu on fait les meilleurs soupes :))

Pascal@plouf a écrit(wrote):

Oui, bien sûr. On peut faire un proxy transparent, dont les deux cartes
réseaux sont montées en bridge.
Ensuite avec iptables, on reroute tous les paquets à destination des
ports gérés par le proxy (http, https, ftp, etc...) vers le port local
du proxy (genre 3128 pour squid).

Question naïve : on peut utiliser iptables pour manipuler les paquets
qui transitent entre les interfaces d'un bridge ?

Oui et non... c'est en fonction des paramètres suivants qu'on peut
utiliser certaines tables de netfilter (copie d'une conf en utilisation) :
net.bridge.bridge-nf-filter-vlan-tagged = 1
net.bridge.bridge-nf-call-ip6tables = 0
net.bridge.bridge-nf-call-iptables = 1
net.bridge.bridge-nf-call-arptables = 1

Ensuite on peut combiner cela avec ebtables (qui apporte des
points d'entrée supplémentaires pour le niveau 2).

Pour le filtrage IP/netfilter et de niveau 2, je ne puis que conseiller
la lecture de (surtout des diagrammes) :

http://ebtables.sourceforge.net/br_fw_ia/br_fw_ia.html



--
Julien

Question naïve : on peut utiliser iptables pour manipuler les paquets
qui transitent entre les interfaces d'un bridge ?

Oui et non... c'est en fonction des paramètres suivants qu'on peut
utiliser certaines tables de netfilter (copie d'une conf en utilisation) :
net.bridge.bridge-nf-filter-vlan-tagged = 1
net.bridge.bridge-nf-call-ip6tables = 0
net.bridge.bridge-nf-call-iptables = 1
net.bridge.bridge-nf-call-arptables = 1

Ensuite on peut combiner cela avec ebtables (qui apporte des
points d'entrée supplémentaires pour le niveau 2).

Pour le filtrage IP/netfilter et de niveau 2, je ne puis que conseiller
la lecture de (surtout des diagrammes) :

http://ebtables.sourceforge.net/br_fw_ia/br_fw_ia.html

Très intéressant, merci (excepté que c'est écrit beaucoup trop gros dans
mon Firefox).

Si je comprends bien, je devrai patcher mon noyau 2.4 pour pouvoir
utiliser tout ça (comme dirait l'autre, je passerai à la série 2.6 quand
elle sera stable). Car pour l'instant mon /proc/sys/net/ ne contient pas
de sous-répertoire 'bridge', même quand un bridge est créé.

Pascal@plouf a écrit(wrote):

http://ebtables.sourceforge.net/br_fw_ia/br_fw_ia.html

Si je comprends bien, je devrai patcher mon noyau 2.4 pour pouvoir
utiliser tout ça (comme dirait l'autre, je passerai à la série 2.6 quand
elle sera stable). Car pour l'instant mon /proc/sys/net/ ne contient pas
de sous-répertoire 'bridge', même quand un bridge est créé.

L'appel aux « hooks » IP de netfilter est automatique dans la version
2.4 (pour autant que je me souvienne, car je considère le 2.6 stable
pour cette partie là:)) ). Il n'y a pas besoin de jouer avec sysctl.

--
Julien