j’ai un vps dont j’ai envie de faire un serveur proxy http simple en utilisant seulement iptables. Ce que je veux pour l’instant, c’est qu’il relaye les requêtes http des clients, et les réponses http des serveurs web distant.
Par exemple, depuis un navigateur de mon ordinateur personnel, je tapes http://www.foo.com, du coup la requête va au serveur proxy, et celui-ci va la transmettre
au serveur web de foo.com pour recevoir la réponse http (càd la page web).
Puis une fois qu’il a reçu la réponse http, il la renvoie au client.
Voici ce que j’ai mis comme règles iptables à la machine proxy :
#À la sortie de l'interface réseau de la machine proxy, on modifie l'adresse ip source du paquet sortant contenant la requête HTTP du client :
iptables -t nat -A POSTROUTING -p tcp --dport 80 -o eth0 -j SNAT --to ip_proxy
iptables -t nat -A POSTROUTING -p tcp --dport 443 -o eth0 -j SNAT --to ip_proxy
, j’ai fais aussi un :
echo 1 > /proc/sys/net/ipv4/ip_forward
Mais ça marche pas. J’ai l’impression que la manipulation n’est pas suffisante pour faire le relai.
Pour qu’une machine intermédiaire sert de proxy http, il faut qu’il se comporte comme un « client » http pour aller chercher la ressource auprès d’un serveur web distant.
Donc le proxy est un « logiciel », qui se situe donc à la couche application du modele osi, et non à la couche réseau.
Firefox par exemple, se connecte au serveur proxy comme si celui-ci était un navigateur.
En fait un proxy en français le terme serait mediateur.
Le client lui demande de faire la requête pour lui et de lui restituer le résultat.
Un relai SMTP c’est encore autre chose. Comme son nom l’indique, tu lui confie ton message et lui le passe au suivant etc.
D’où ma différence des noms proxy et relay
Ton truc ne fait que du routage, pour que çamarche il suffit pour la machine client de router les paquets sur cesports vers ton «proxy» mais ça n’a effectivement rien à voir avec le proxy qui est situé sur un niveau au dessus (en terme de couche OSI). Entre autres pas de caches, pas de filtrage eventuel, bref ça ne sert à rien ou presque
Ton truc ne fait que du routage, pour que çamarche il suffit pour la machine client de router les paquets sur cesports vers ton «proxy» mais ça n’a effectivement rien à voir avec le proxy qui est situé sur un niveau au dessus (en terme de couche OSI). Entre autres pas de caches, pas de filtrage eventuel, bref ça ne sert à rien ou presque
Du coup, il faudrait 2 interfaces réseaux et faire du nat sur mon vps, et comme ça, le vps qui agit en tant que « routeur » pourra restituer au client la page web demandée qu’il a récupéré à un serveur web distant.
Pourquoi utiliser ton VPS externe à ton réseau local pour faire un proxy?
Fait ton proxy en interne.
Si c’est pour des raisons d’anonymat, ben en fait ce ne sera pas le cas, ton hébergeur VPS aura les informations. Les protocoles de communication avec un proxy sont reconnaissables.
Le NAT ne sert à rien (si on considère ton proxy sur le VPS.
Un autre cas d’architecture serait d’avoir un tunnel VPN entre ton LAN et le VPS et ensuite le VPS sort sur internet. Cependant ça veut dire que soit ton interface unique de ton vps sert pour les deux (attention à la bande passante et à la capacité de traitement pour éviter la latence induite); soit tu as deux adresses publiques sur ton vps, une pour le VPN pour l’accès internet du proxy.
Le proxy est un serveur qui reçoit une demande de connexion de la part d’une machine A vers un serveur web B, cette requête est traitée, éventuellement filtrée, on regarde si elle figure dans le cache et elle est envoyée vers le serveur. Il gère les certificats et les DNS
le routage. (voir plus haut).
On peut lier les 2 en faisant un proxy transparent qui envoit comme tu le fais toutes les requêtes destinée au port 80 vers le proxy. Cependant ça ne marche pas pour le port 443. Le paquet est chiffrée et le proxy est incapable de la déchiffrer, de plus il ne peut donner à A le certificat. Il faut donc explicitement donner l’adresse du proxy au navigateur à cet instant.
Le proxy peut être détecté automatiquement via l’envoi d’une page wpad.dat lors d’une requête sur le port 80 de la passerelle, page indiquant l’IP du proxy.
Non, le proxy web c’est un système qui permet à un client de faire une requete HTTP vers une URL qui sera prise en charge par le proxy.
Tu ne cherche pas à accéder à une machine mais à une URL.
le proxy ne gère pas le DNS, c’est un serveur DNS qui le fait que le proxy va interroger. Il ne gère absolument pas non plus les certificat.
La notion de proxy transparent est juste que le parefeu (pas le routeur) intercepte les paquets liés à des requêtes HTTP (quelques soit les ports qu’il faudra lui indiquer) pour les envoyer sur une IP et un port particulier.
Ca marche pour HTTP et HTTPS, le proxy n’a pas à déchiffrer le contenu. On peut le faire mais la configuration est plus spécialisée, et nécessite d’avoir mis en place des certificats au niveau du client. C’est une configuration compliquée, qui est en plus soumise à pas mal de réglementation législative.
Le proxy répercute la requête envoyée par le client vers l’URL distante, et il répercute la réponse du serveur fournissant la réponse au client.
Quand au routage, c’est une fonctionnalité sous jacente aux conmmunications réseau, qui basiquement ne concerne que les couches OSI jusqu’à l’IP et/ou TCP/UDP.
Un proxy fonctionne au niveau applicatif du modèle OSI.
Tu ne connais pas très bien le fonctionnement d’un proxy ni l’objectif d’un parefeu (qui filtre) et d’un routeur (qui dirige - au sens routier du terme-, non?
Je crois qu’en premier lieu, et pour mieux comprendre ce que tu veux faire, c’est de nous définir le besoin réel derrière la solution que tu veux mettre en place.
Car ça ressemble furieusement (et de plus en plus) à du problème XY.
Je me suis mal exprimé, je veux dire que la requête DNS est faite du proxy et non de la machine A, cela peut être important si le DNS est interne et a une «view» différente de celle du la machine A.
Idem pour le certificat, il va utiliser ses références et non celles de la machine A (je crois bien, dis moi si je me trompe), c’est ça que je voulais dire. Pour les certificats, comme c’est le proxy qui gère la connexion avec le site distant, je me disais que c’est lui qui vérifiait la validité de ce site, mais peut être que je me trompe et qu’il se contente de relayer les certificats, ce serait plus judicieux.
Non, lorsque j’ai mis en place un proxy squd avec squidguard dans le lycée où je travaillais, je bloquais le port 443 et je redirigeais tous les paquets à destination de l’extérieur vers le port 80 vers le proxy squid qui les prenait en charge. Je crois qu’il faut juste rajouter dans le fichier de configuration de squid la ligne
http_port 3128 intercept
Cela évite de déclarer le proxy aux navigateurs des machines A
En revanche, cela ne peut pas marcher pour les requêtes https, du coup actuellement ça n’apporte plus grand chose, le http étant de moins en moins utilisé.
Squid allié à squidguard et dnsguardian permet de faire de filtrage (obligatoire dans les lycées), filtrage qui nécessite a minima une connaissance de l’URL et demanderait une analyse des requêtes pour être efficace. [j’ai toujours trouvé cela crétin, un élève met une minute à remarquer que demander la traduction de la page interdite à un site comme google trad te la donne immédiatement, par ailleurs la liste des URLs interdites, disponibles sur un ftp de l’EN à Bordeaux, leur permettait de savoir immédiatement les sites intéressants pour tricher]. Si tu as raison (ce qui me parait de plus en plus logique sur ce point à savoir que sur le https, le proxy ne se contente que de vérifier l’URL), à ce moment là rien n’est mis en cache sur tout ce qui concerne le trafic https. Ça enlève une partie de l’intérêt des proxys dans ce cas. Par ailleurs, ça signifie que le filtrage sur du https ne peut se faire que sur l’URL et même que sur le domaine, pas sur l’URL complète, ça en limite la portée.
Pour le proxy, j’avais installé ça au début des années 2000 et ça concernait surtout le http, puis j’ai mis en place à minima sur le https (j’avais testé ssl_bump mais c’est très intrusif), étant en désaccord sur l’enregistrement de l’activité des élèves du secondaire, j’ai claqué la porte sur la gestion des élèves mineurs et me suis limité aux prépas (majeurs). À partir de ce moment là, le https n’était plus filtré. En revanche, au niveau d’iptables et des tables de routage, sans être un Pascal_Hambourg, j’arrive à faire des choses
Visiblement, tu gères mieuxque moi cette histoire de proxy, je te laisse
Filtrage sur les destinations. IL n’y a pas d’analyse du contenu et heureusement car ça violerait la RGPD.
En fait, les proxy utilisent des listes de classifications. Mais il n’y aucun traitement sur le contenu des paquets (la partie data, il ne gère que le header).
Pour la mise en cache, les sites étant majoritairement dynamique, il y 'a finalement peu de mise en cache par le proxy lui meme, ou alors il faut mettre en place des solution plus efficace, comme varnish par exemple.
J’ai eu à mettre en place un proxy dan sle groupe Gefrco qui est depuis devenu un groupe russe.
La difficulté était de gérer le faire qu els utilisateurs ne travaillaient pas sur le même fudseau horaire.
Au départ fait un squid, la solution a ensuite migré vers un ironport.
En fait c’est illégal. La traçabilité n’est réalisé que pour des raison judiciaire. Ces trace ne peuvent pas être librement consulté par qui que ce soit ministre compris car c’est une violation de la loi pénale.
Des protocoles peuvent être mis en place au niveau interne 5RH ou autre suivant le périmètre) pour pouvoir faire des analyses en cas de doutes justifié. Seul un juge est habilité à le faire.
j’ai d’ailleurs, à plusieurs reprise dans ma carrière, refusé de données les informations, y compris sous la menace, en faisant appel à la loi le cas échéant, notamment l’article 40 que j’ai menacé d’utiliser en cas de refus de se conformer à la loi.
D’ailleurs, toute tentative de vouloir sanctionner un fonctionnaire (même vacataire ou contractuel) serait aussi sanctionné, harcèlement compris.
J’ai eu à le faire 5 fois en 25 ans, dont deux fois en tant que contractuel de l’administration territoriale, 1 fois dans le cadre d’une administration d’état en tant que prestataire externe et deux fois en tant que prestataire dans une société privée.
Du coup, le proxy web ne peut pas filtrer le contenu quand c’est crypté par le ssl, c’est logique.
Le proxy web récupére la page web demandée par le client, puis pour savoir s’il doit servir ou non cette page web au client, il doit d’abord vérifier si cette page web contient les mots « drogue », « cannabis » : mais il ne peut pas le faire car la page web provient d’un site en ssl, donc son contenu est crypté et donc non filtrable.
Et je crois que c’est pareil pour les urls quand c’est du ssl, car la requête http du client contenant l’url de la page demandée est en ssl, donc cryptée.
Le filtrage possible est d’utiliser une blacklist d’ip des sites webs.
Bien sûr que si, l’URL fait partie de la communication chiffrée par TLS/SSL.
@Zargos A un moment, il va falloir arrêter de raconter n’importe-quoi !
Par contre, le nom de domaine du serveur est recopié avant le corps de la communication chiffrée et ce nom de domaine n’est pas forcément chiffré.
Voir Wikipedia FR - Server Name Indication
Lorsque le SNI est en clair, les proxy peuvent l’utiliser pour du filtrage.
Une autre méthode de filtrage, c’est avec un résolveur DNS récursif. Ce serveur peut renvoyer une mauvaise adresse IP lorsque l’on demande un nom de domaine non approuvé.
Pas tout à fait, le domaine n’est pas chiffré, j’ai vérifié sur une connexion, il apparait bien en clair le domaine, ensuite le reste est chiffré. En clait un GET https://loin.labas.fr/page.php?donnees=secret sera tel que loin.labas.fr est en clair en revanche page.php?donnees=secret est chiffré. Je comprends mieux du coup comment apache2 se débrouille avec les virtualhosts.
[~]$ sudo tcpdump host 82.65.201.202 -w /tmp/deb.pcap
tcpdump: listening on wlan0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
^C1475 packets captured
1475 packets received by filter
0 packets dropped by kernel
[~]$ strings /tmp/deb.pcap | grep debian
www.debian-fr.org
[~]$
Effectivement, c’est au début de la connexion, tant que celle ci est utilisée, tout est chiffrée. Ainsi si je prends cette edition de message en cours de route (fait en direct), on obtient:
~]$ sudo tcpdump host 82.65.201.202 -w /tmp/deb.pcap
tcpdump: listening on wlan0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
[Là je recharge cette page suivi par un ^C]
^C1414 packets captured
1414 packets received by filter
0 packets dropped by kernel
[~]$ strings /tmp/deb.pcap | grep debian
[~]$
Hum, ça dépend du TLS. Mon serveur peut faire du TLS 1.3, je vais tester.
Hum, pourtant
TLS 1.3 et domaine en clair contrairement à ce que dit Wikipedia, l’extension ECH doit se mettre à part. Pourtant ça pourrait être actif depuis buster inclus mais aucune version d’apache ne l’intègrerait de manière systématique actuellement. Bon, à suivre
