Proxy transparent ou non sur 1.3.0

[pkaer]

Bonjour, <BR> <BR>J'ai un fonctionnement bizarre du Proxy sur la 1.3.0. <BR> <BR>Si le proxy est activé , ainsi que le mode transparent, mon filtrage d'URL via "Petit Poulpe" fonctionne bien mais <!-- BBCode Start --><B>aucune règles sur le firewall n'est prise en compte</B><!-- BBCode End -->, que cela soit celles ajoutées à la main dans rc.firewall (doc Antolien) ou celle définies dans "blockoutgoing". <BR> <BR>Si le Proxy est activé, mais pas le mode transparent, le filtrage d'URL ne fonctionne plus alors que les règles de firewall deviennent opérationnelles. <BR> <BR>Le même test fait sur une 1.4.0b2 montre une différence dans le sens ou aussi bien le filtrage d'URL que les règles de firewall fonctionnent quand le Proxy est activé ainsi que le mode transparent. <BR> <BR>Si quelqu'un a une idée, elle sera la bienvenue car c'est un site en prod sur lequel je ne peux pas mettre de version beta d'IPCop <BR> <BR>Merci <BR>@+ <BR>PK

[poudre]

Bonsoir, <BR> <BR> <BR>Il faudrait, je pense, comparer le cheminement des trames entre un systeme avec et sans proxy. Les règles de filtrages, si elles ont été positionnées sur la chaine forward par exemple ont peu de chance d'être utilisées dans le cas d'un proxy. <BR>Je peux me tromper, mais pour moi, dans le cas d'un firewall avec Nat on passe pour une trame qui doit sortir par la chaine forward puis output et postrouting mais dans le cas d'un proxy on va passe par le filtre input ( vu que c'est le firewall qui va faire la requette) puis output et peut être postrouting mais cela n'est pas certain.. <BR>A contrôler... <BR> <BR>Il serait vraiment intéressant que le test soit fait puis documenté ensuite. <BR> <BR>Cdlt Pascal.

[tomtom]

Hum.. <BR> <BR>le cheminement normal d'une tramme au travers d'une passerelle est : <BR> <BR>PREROUTING - FORWARD - POSTROUTING <BR> <BR>Si on ajoute un proxy transparent, les paquets à destination d'un port 80 (et/ou 443, etc) sont modifiés au PREROUTING pour aller vers l'adresse du proxy (adresse locale generalement). <BR>On aura donc un schema ainsi : <BR> <BR>PREROUTING (modif du paquet -> destination = localhost) - INPUT - Traitement du paquet par le proxy - <BR> <BR>Puis une requete de proxy vers la vraie destination : <BR>OUTPUT - POSTROUTING <BR> <BR>Paquet retour : PREROUTING - INPUT - Traitement par le proxy <BR> <BR>Puis renvoi de la reponse au client : OUTPUT - POSTROUTING et renvoi vers le client... <BR> <BR>Donc effectivement, le comportement est modifié. <BR> <BR>Mais, seulement les paquets à destination du port 80 (et autres ports gérés par le proxy). <BR> <BR>Donc si le comportement pour les autres paquets est modifié, c'ets une erreur de config et/ou un bug de ipcop ! <BR> <BR>t.

[olivier_morin]

Effectivement si le cache est activé, les règles iptables pour le port 80 ne fonctionnent plus. Et comme petit-pouple utilise squid...
Mais cela n'est pas grave car :
- toutes les règles fonctionnent sauf port http et https
- mais... squidguard (ou squid) permettent de faire des règles pour thhp et https.

Donc aucun problème, juste la réécriture des règles iptables de ces 2 ports en règles squidguard (dans squidGuard.conf).

[ShonGail]

Hum..
<BR>
<BR>le cheminement normal d'une tramme au travers d'une passerelle est :
<BR>
<BR>PREROUTING - FORWARD - POSTROUTING
<BR>
<BR>Si on ajoute un proxy transparent, les paquets à destination d'un port 80 (et/ou 443, etc) sont modifiés au PREROUTING pour aller vers l'adresse du proxy (adresse locale generalement).
<BR>On aura donc un schema ainsi :
<BR>
<BR>PREROUTING (modif du paquet -> destination = localhost) - INPUT - Traitement du paquet par le proxy -
<BR>
<BR>Puis une requete de proxy vers la vraie destination :
<BR>OUTPUT - POSTROUTING
<BR>
<BR>Paquet retour : PREROUTING - INPUT - Traitement par le proxy
<BR>
<BR>Puis renvoi de la reponse au client : OUTPUT - POSTROUTING et renvoi vers le client...
<BR>
<BR>Donc effectivement, le comportement est modifié.
<BR>
<BR>Mais, seulement les paquets à destination du port 80 (et autres ports gérés par le proxy).
<BR>
<BR>Donc si le comportement pour les autres paquets est modifié, c'ets une erreur de config et/ou un bug de ipcop !
<BR>
<BR>t.

C'est donc selon ce principe que même si je bloque la totalité des ports de LAN->WAN selon les règles d'Antolien, mes postes accèdent encore au surf (ipcop 1.3+dansguardian) ?

En bloquant aussi la totalité des ports, les logs de p2p ne peuvent plus se connecter, notamment Kazaa. Est-ce parce que les connections initiées par kazaa sur le port 80 sont traitées et rejetées par dansguardian (bien que cela ne soit pas du http) ?

Du coup, à quoi servent les addons devellopés spécifiquement pour bloquer kazaa&co quand un proxy filtrant suffit ?

[tomtom]

C'est donc selon ce principe que même si je bloque la totalité des ports de LAN->WAN selon les règles d'Antolien, mes postes accèdent encore au surf (ipcop 1.3+dansguardian) ?

En bloquant aussi la totalité des ports, les logs de p2p ne peuvent plus se connecter, notamment Kazaa. Est-ce parce que les connections initiées par kazaa sur le port 80 sont traitées et rejetées par dansguardian (bien que cela ne soit pas du http) ?

Du coup, à quoi servent les addons devellopés spécifiquement pour bloquer kazaa&co quand un proxy filtrant suffit ?

Souvent, les softs de p2p sont capables de se connecter via des proxys.
C'est assez etonnant que ca bloque chez toi ... Es-tu sur que tu as regardé toutes les options de ton soft ?

Sinon, je n'en sais pas assez sur ces logiciels, mais j'en ai vu se connecter a partir de site drolement securisés pourtant! (proxy avec auth NTLM...)

t.

[pkaer]

Salut,

Merci de toutes ces réponses. Elle confirme ce que je supposais; à savoir qu'il y a un problème sur la 1.4.0bx (pour les 1.4.0ax je n'ai pas vérifié).

En effet même si le tansparent du proxy est activé, il ne fonctionne pas. Ceci est confirmé par le fait que les graphes du Proxy restent désèpérement vides.

Est-ce que je suis le seul à l'avoir remarqué ou quelqu'un peut-il confirmer ce problème

Merci
@+
PK

PS : Coup de chapeau à l'équipe d'IXUS pour le travail réalisé pour que nous ayons un beau Forum tout neuf

[ShonGail]

C'est donc selon ce principe que même si je bloque la totalité des ports de LAN->WAN selon les règles d'Antolien, mes postes accèdent encore au surf (ipcop 1.3+dansguardian) ?

En bloquant aussi la totalité des ports, les logs de p2p ne peuvent plus se connecter, notamment Kazaa. Est-ce parce que les connections initiées par kazaa sur le port 80 sont traitées et rejetées par dansguardian (bien que cela ne soit pas du http) ?

Du coup, à quoi servent les addons devellopés spécifiquement pour bloquer kazaa&co quand un proxy filtrant suffit ?

Souvent, les softs de p2p sont capables de se connecter via des proxys.
C'est assez etonnant que ca bloque chez toi ... Es-tu sur que tu as regardé toutes les options de ton soft ?

Sinon, je n'en sais pas assez sur ces logiciels, mais j'en ai vu se connecter a partir de site drolement securisés pourtant! (proxy avec auth NTLM...)

t.

Pourtant, même en modifiant les options de Kazaa (qui est je crois connu pour être des plus $%#&! à stopper au niveau des passerelles), impossible pour lui de se connecter.

Si je fait un netstat -a sur la machine où j'ai installé kazaa, je m'apercois que celui-ci initie des connexions vers des tas d'adresses sur des ports >1024

Si ces ports sont bloqués au niveau du firewall, n'est-ce pas normal qu'il ne puisse pas se connecter ?

Mais cela me semble un peu facile vu que des progs sont spécifiquement dévellopés pour contrer les logiciels de p2p

[tomtom]

Ben en général; Kazaa et autres sont capables d'utiliser le port 80 et justement le proxy pour se connecter..

Mais bon, je ne suis pas expert, peut-etre que squid allié à un filtrage d'adresse adéquat permet de le bloquer simplement.

Cela me surprend un peu tout de même, mais je n'ai vraiment pas de quoi tester ce genre de choses

t.