proxy http

R12y a wroté :

Bonjour

Bonsoir,

Toujurs à la découverte des proxies, je me demandait un truc à leur sujet.
J'explique d'abord le contexte.
J'ai les logiciels Gaim (pour du instant messenging), Thunderbird et le
client ssh de OpenSSH, le tout sous Linux.
Je dois passer par un proxy http transparent pour acceder à ces services.

IPtables ou squid ?

Si j'ai bien compris comment fonctionne le réseau, pour "laisser passer"
quoi que ce soit, le proxy doit d'abord croire que c'est du traffic http.
C'est ça?

Un proxy 'basique' n'analyse pas au niveau tcp les trames qu'il reçoit.
Basiquement, s'il écoute sur le port 8080 et qu'il relaie ce qu'il y
reçoit, il le fait, et c'est tout, sans faire la distinction entre du http,
du https ou ... du ssh.

Après, il existe des choses plus fines, pour filtrer les flux en streaming
par exemple, ce qui est déjà pas mal (et arrêtera sans doute Gaim ;), ou
carrément pour analyser ce qui passe aux niveaux 5 à 7 OSI, mais là, il
faut une machine qui encaisse la charge, et un patron qui encaisse la
facture :).

Si je tente une connexion directe avec Gaim, par exemple, je me fais
filtrer. Par contre, si je specifie un proxy http (et le port) dans les
réglages de Gaim, j'arrive à me connecter aux serveur de mesagerie que
j'utilise. Est ce que ça veut dire qu'il "encapsule" les paquets dans du
http pour leur permettre de passer le proxy?

Bah non, ton proxy relaie ton flux puisqu'il le voit arriver par le bon
port, et voilà.

/me n'utilise pas Gaim ... quels ports écoutent sur les serveurs Gaim ?
80 ? 443 ?

--
Guillaume

Toujurs à la découverte des proxies, je me demandait un truc à leur
sujet. J'explique d'abord le contexte. J'ai les logiciels Gaim (pour du
instant messenging), Thunderbird et le client ssh de OpenSSH, le tout
sous Linux. Je dois passer par un proxy http transparent pour acceder à
ces services.

IPtables ou squid ?

Le Proxy est un Squid.
Mais sur la patte LAN de la machine qui fait proxy, il y a un iptables qui
redirige toutes les requetes à destination du port 80 vers le 3128 du
Squid (sur la même machine).

Si j'ai bien compris comment fonctionne le réseau, pour "laisser
passer" quoi que ce soit, le proxy doit d'abord croire que c'est du
traffic http. C'est ça?

Un proxy 'basique' n'analyse pas au niveau tcp les trames qu'il reçoit.
Basiquement, s'il écoute sur le port 8080 et qu'il relaie ce qu'il y
reçoit, il le fait, et c'est tout, sans faire la distinction entre du
http, du https ou ... du ssh.

Ok. Mais donc, je viens de comprendre une chose:

En réseau, j'ai toujours cru que quand une machine (appellons-la
"client") voulait "dialoguer" avec une autre (serveur), le paquet utilisé
pour dialoguer contenait (en gros) l'adresse et le port de la machine
emettrice, et l'adresse et le port du destinataire. Manifestement, on peut
rajouter, sans encapsuler quoi que ce soit, l'adresse et le port d'une
machine "intermédiaire".

C'est ça?

Ce petit bout rajouté n'est pas manipulé par le proxy, il est juste lu.
Ce petit bout parvient donc à la machine destinataire ou pas?

/me n'utilise pas Gaim ... quels ports écoutent sur les serveurs Gaim ?
80 ? 443 ?

Gaim est un client multi réseau que j'utilise sous Linux pour chatter avec
des correspondants sur MSN && Yahoo && Jabber.
Les serveur auxquels il se connecte sont ceux qui gèrent ces différents
réseaux de chat...

--
SPIP, phpNuke, Plone, opengroupware... c'est bien
CPS c'est mieux: http://www.cps-project.org/
Hébergement de sites CPS: http://www.objectis.org/

R12y a wroté :

IPtables ou squid ?

Le Proxy est un Squid.
Mais sur la patte LAN de la machine qui fait proxy, il y a un iptables qui
redirige toutes les requetes à destination du port 80 vers le 3128 du
Squid (sur la même machine).

OK, donc c'est un squid, mais il écoute sur deux ports (80 + 3128).
Il me semble donc qu'avec squid (ou est-ce squid + squidguard ?), tu peux
mettre en oeuvre un filtrage par type de flux plus fin que si tu te
contentais de faire du NAT avec Iptables. Notamment en bloquant tous les
flux en streaming, tu devrais empêcher la diffusion de vidéos, de flux
audio, les messageries instantanées et les petits malins qui feraient
passer une session ssh par les ports autorisés.

Ok. Mais donc, je viens de comprendre une chose:

En réseau, j'ai toujours cru que quand une machine (appellons-la
"client") voulait "dialoguer" avec une autre (serveur), le paquet utilisé
pour dialoguer contenait (en gros) l'adresse et le port de la machine
emettrice, et l'adresse et le port du destinataire.

Oui (quoique le port d'origine ne soit pas souvent pertinent).

Manifestement, on peut
rajouter, sans encapsuler quoi que ce soit, l'adresse et le port d'une
machine "intermédiaire".

Euh... oui et non :).
Si l'on parle d'un élément intermédiaire, tu peux rajouter
- une passerelle par défaut, vers laquelle ira tout le trafic qui ne
correspond plus au couple adresse / masque de la machine.
- des routes statiques dont tu viens enrichir ta table de routage.
- des passerelles logiques, tels qu'un relais proxy ou un firewall qui
ferait du NAT, vers lequel tu vas envoyer un trfic spécifique (web + https
pour un proxy classique) après l'avoir renseigné dans l'appli kivabien.

Dans ce dernier cas, si le proxy fait du pur NAT, la machine d'origine est
invisible depuis le réseau de destination, on ne voit ... que le proxy.
Sauf si le proxy est paramétré pour laisser dans les entêtes http le champ
x-originating-ip : on voit alors l'adresse de la machine d'origine derrière
le proxy, ce qui révèle l'existence de ce dernier et du réseau derrière lui
(c'est donc rarement une bonne idée).

Ce petit bout rajouté n'est pas manipulé par le proxy, il est juste lu.
Ce petit bout parvient donc à la machine destinataire ou pas?

Dans le cas d'une translation IP (NAT) pure et simple, non. On ne voit que
la patte externe du proxy, et c'est tout.
Pour un proxy logiciel, ça dépend de sa config' (cf. çi-dessus).

/me n'utilise pas Gaim ... quels ports écoutent sur les serveurs Gaim ?
80 ? 443 ?

Gaim est un client multi réseau que j'utilise sous Linux pour chatter avec
des correspondants sur MSN && Yahoo && Jabber.
Les serveur auxquels il se connecte sont ceux qui gèrent ces différents
réseaux de chat...

Ca je le sais, je connais l'utilité du produit, c'est juste que je conchie
les messageries instantanées (désolé hein ;)).
Ce qui m'intéresse, c'est le port d'écoute sur les serveurs, pour savoir si
une telle messagerie instantanée peut se fondre de bout en bout dans du
trafic web.


--
Guillaume

En réseau, j'ai toujours cru que quand une machine (appellons-la
"client") voulait "dialoguer" avec une autre (serveur), le paquet utilisé
pour dialoguer contenait (en gros) l'adresse et le port de la machine
emettrice, et l'adresse et le port du destinataire. Manifestement, on peut
rajouter, sans encapsuler quoi que ce soit, l'adresse et le port d'une
machine "intermédiaire".

C'est ça?

Non.
Quand un client utilise un proxy pour contacter un serveur, le
destinataire de l'information envoyée par le client est le proxy, qui lui
fait une nouvelle connexion dont l'émetteur est le proxy et le
destinataire le serveur.

Sauf en présence d'un proxy transparent (mais c'est mal en général),
qui récupère tout le trafic quel que soit l'adresse de destinataire
spécifiée par le client.

Ce petit bout rajouté n'est pas manipulé par le proxy, il est juste lu.
Ce petit bout parvient donc à la machine destinataire ou pas?

Je pense qu'il faudrait se replonger dans la pile TCP/IP et comprendre que
des informations différentes se trouvent dans des couches différentes et
ont des rôles différents.

Dans le cas de HTTP, qui est le plus simple, au niveau IP/TCP l'échange
est entre le client et le proxy, et au niveau HTTP (au-dessus d'IP donc),
le client indique l'URL finale (celle sur le serveur) au proxy.

--
Patrick Mevzek . . . . . . Dot and Co (Paris, France)
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>

Bonjour.

Je réponds à Patrick Mevzek <pm-N200509@nospam.dotandco.com>

En réseau, j'ai toujours cru que quand une machine (appellons-la
"client") voulait "dialoguer" avec une autre (serveur), le paquet
utilisé pour dialoguer contenait (en gros) l'adresse et le port de
la machine emettrice, et l'adresse et le port du destinataire.
Manifestement, on peut rajouter, sans encapsuler quoi que ce soit,
l'adresse et le port d'une machine "intermédiaire".

C'est ça?

Non.
Quand un client utilise un proxy pour contacter un serveur, le
destinataire de l'information envoyée par le client est le proxy, qui
lui fait une nouvelle connexion dont l'émetteur est le proxy et le
destinataire le serveur.

Sauf en présence d'un proxy transparent (mais c'est mal en général),
qui récupère tout le trafic quel que soit l'adresse de destinataire
spécifiée par le client.

Ce petit bout rajouté n'est pas manipulé par le proxy, il est juste
lu. Ce petit bout parvient donc à la machine destinataire ou pas?

Je pense qu'il faudrait se replonger dans la pile TCP/IP et
comprendre que des informations différentes se trouvent dans des
couches différentes et ont des rôles différents.

Dans le cas de HTTP, qui est le plus simple, au niveau IP/TCP
l'échange est entre le client et le proxy, et au niveau HTTP
(au-dessus d'IP donc), le client indique l'URL finale (celle sur le
serveur) au proxy.

Vous êtes peut-être le sauveur de mes neurones qui crament depuis des jours
à essayer de trouver une solution pratique pour un tel routage.

Pourriez-vous SVP jeter un petit coup d'oeil à mon post du 23/09
4333c809$1$24527$636a15ce@news.free.fr intitulé
"Résolution alternative de noms de serveurs" ?

En fait je cherche soit une solution en "routage par défaut", soit un tel
proxy local transparent et générique, ceci pour Windows 2000/XP. Je suis
sidéré d'avoir fouillé tout le Web sans rien trouver, à part des gens qui
semblaient avoir les boules pour le même problème !

Merci de tout conseil.
Cordialement,

--
/***************************************
* Patrick BRUNET
* E-mail: lien sur http://zener131.free.fr/ContactMe
***************************************/

On Sun, 25 Sep 2005 11:55:26 +0200, Patrick Mevzek wrote:

Sauf en présence d'un proxy transparent (mais c'est mal en général),

Ok. Mais dans le cas présent, je ne suis pas l'dministrateur du proxy,
plutot une "victime"... :-)


--
SPIP, phpNuke, Plone, opengroupware... c'est bien
CPS c'est mieux: http://www.cps-project.org/
Hébergement de sites CPS: http://www.objectis.org/

Le 26-09-2005, R12y <mihamina.rakotomandimby@etu.univ-orleans.fr> a écrit :

On Sun, 25 Sep 2005 11:55:26 +0200, Patrick Mevzek wrote:

Sauf en présence d'un proxy transparent (mais c'est mal en général),

Ok. Mais dans le cas présent, je ne suis pas l'dministrateur du proxy,
plutot une "victime"... :-)

Dans ce cas, la bonne question à se poser est "Pourquoi un tel cache ?"
et c'est principalement ton admin qui pourra te répondre. Et si la
demande est justifiée, il préfèrera mille fois ouvrir le port qui va
bien plutôt que te forcer à camoufler un flux.

Je comprends qu'il soit dans la nature humaine de vouloir toujours
contourner les mécanismes de sécurité, mais ça devient un vrai
casse-tête de monter une protection efficace sans être trop restrictif.
En tout cas, s'il y a une chose dont je suis sur c'est que l'admin de ta
fac n'a pas mis ce serveur mandataire _juste_ pour te faire suer.

Pour répondre à ta question, oui il faut que les requêtes soient en HTTP
valides s'il s'agit effectivement d'un cache. Sinon, il s'agit juste
d'un pare-feu. Enfin, c'est vrai pour le moment, parce que il commence à
y avoir tellement de chose qui circule encapsulé dans du HTTP qu'il
arrivera bien un jour un moment ou on y mettra un sacré coup de frein.
Et quand bien même cela passe pour le moment, rien ne dit que les
serveurs ne sont pas blacklistés (c'est le cas de msn chez nous en tout
cas...)

Croco

On Sun, 25 Sep 2005 11:55:26 +0200, Patrick Mevzek wrote:

Sauf en présence d'un proxy transparent (mais c'est mal en général),

Ok. Mais dans le cas présent, je ne suis pas l'dministrateur du proxy,
plutot une "victime"... :-)

Tenter de passer outre peut être contraire à la charte d'utilisation
qui a probablement été signée, d'où éventuels déboires légaux...

--
Patrick Mevzek . . . . . . Dot and Co (Paris, France)
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>

Tenter de passer outre peut être contraire à la charte d'utilisation
qui a probablement été signée, d'où éventuels déboires légaux...

Mon premier post soulève ce point. Je reformule ce que j'y ai déjà écrit.
L'administrateur dudit réseau m'a autorisé à passer outre, mais m'a
officieusement demandé de garder la "technique" pour moi. Tout simplement
parceque si il remarque que ça se généralise, il rendra le proxy moins
"transparent".
Cela dit, il n'a pas vraiment le temps de m'expliquer dans les détails le
fonctionnement des proxies, c'est pour cela que je me suis dit que ça
serait une bonne idée d'en parler ici :-)

--
SPIP, phpNuke, Plone, opengroupware... c'est bien
CPS c'est mieux: http://www.cps-project.org/
Hébergement de sites CPS: http://www.objectis.org/

On Mon, 26 Sep 2005 22:38:22 +0000, Croco wrote:

Dans ce cas, la bonne question à se poser est "Pourquoi un tel cache ?"

Parceque légalement il est strictement interdit par la loi de directement
connecter un étudiant à internet.

La Fac ou je suis n'étant pas non plus une Fac réputée pour
couver/fabriquer des apprentis crackers, le compromis a été trouvé de
faire un proxy transparent. L'association dont je fais partie du bureau
font partie de ceux qui ont activement négocié cette "liberté".

J'ai d'ailleurs justifié ce besoin.

Je comprends qu'il soit dans la nature humaine de vouloir toujours
contourner les mécanismes de sécurité, mais ça devient un vrai
casse-tête de monter une protection efficace sans être trop restrictif.
En tout cas, s'il y a une chose dont je suis sur c'est que l'admin de ta
fac n'a pas mis ce serveur mandataire _juste_ pour te faire suer.

Moi personnellement, non. Je lui ai dit que pour des activités très
sérieuses j'ai besoin de SSH, des News, du mail en IMAP,...

Pour répondre à ta question, oui il faut que les requêtes soient en HTTP
valides s'il s'agit effectivement d'un cache. Sinon, il s'agit juste
d'un pare-feu. Enfin, c'est vrai pour le moment, parce que il commence à
y avoir tellement de chose qui circule encapsulé dans du HTTP qu'il
arrivera bien un jour un moment ou on y mettra un sacré coup de frein.
Et quand bien même cela passe pour le moment, rien ne dit que les
serveurs ne sont pas blacklistés (c'est le cas de msn chez nous en tout
cas...)

Merci beaucoup pour ces précisions.
J'ai trouvé un semblant de solution pour les applications GNOME (car
j'utilise GNOME comme environement):

Manifestement on peut indiquer d'une manière "pseudo system-wide" un proxy
aux aplications GNOME. Il suffit d'aller dans gconf et puis "system" ->
http_proxy. C'est local à la session GNOME en cours. Ca n'est valable que
pour l'user en cours.
J'ai découvert ça juste au moment de quiter la BU hier soir et j'ai pas
testé, je vous donne des nouvelles.


--
SPIP, phpNuke, Plone, opengroupware... c'est bien
CPS c'est mieux: http://www.cps-project.org/
Hébergement de sites CPS: http://www.objectis.org/