Squid et squidguard plantent.

Florian22

1/ comme je te l ai dit : Tu ne peux pas etre tenu pour responsable d'assurer aucun tracage (en france) sur une destination SSL

(C'est a dire une requête sécurisée de A a Z IP à IP)

2/ Le délai c'est 1 AN

3/ Si tu utilises radius, tu as la concordance IP Radius / Squid Log qui te permet de remonter à un utilisateur

donc:

-> A mon avis la brique auth d'un proxy ne devrait pas être utilisée (hors env de type AD)

-> Tu devrais confier les taches d'auth, a un système par ports 802.x ou à un portail captif

-> je persiste et signe a dire que c'est mal avisé d'avoir dans ses logs des requetes SSL, (qui peuvent parfois en GET contenir des données hyper confidentielles) et aucune instance te tiendra rigueur de dire : "non mais voila, c'est du SSL, nous on a pas de vues la dessus"

et pour le filtrage, (vis a vis du ssl) comme dit, tu as des manière de faire qui ne se cantonnent pas au http (niveau haut)
mais a un niveau plus bas,

-> le blocage en dur dans le firewall (pour un nb réstreint de destinations)
-> le blocage par empoisonnement du DNS

dans le dernier cas, tu opères un blocage a tout type de flux, et pas que le surf

donc a mon sens (hors avis qu'on viendrait m'apporter pour un point qui me serait sauté du cerveau par mégarde)

=> faire passer le ssl par un proxy… ca sert a rien si ce n'est a fourrer son nez dans une requête qui devrait rester intacte de bout en bout

cdlt

Florian22

@chris4916:

Dans le cas d'une école qui ne permet l'accès que à quelques sites limités, une white-liste dans un portail captif peut suffire.
Et il y a probablement bine d'autres solutions.

un portail ne sert pas a filtrer, il sert a donner accès a une ressource LAN

donc non

pour ce type de setup, un deny-all et un allow-separate pour chaque entrée

ou une solution d'empoisonnement du dns, avec blocage dns-autres, et avec des regles de "deny-all" et "allow-separate"

chris4916

Florian,

je ne voudrais pas donner l'impression d'être systématiquement "pas d'accord" mais il est certain que sur quelques aspects, nous ne partageons pas le même point de vue, probablement parce que nous avons des expériences différentes.

@Florian22:

-> A mon avis la brique auth d'un proxy ne devrait pas être utilisée (hors env de type AD)

Sans authentification(*) dans Squid (ou en dehors de Squid mais avec l'identification poussée vers Squid) il n'est pas possible de faire du profiling qui consiste, par exemple, à autoriser les membres d'un groupe à accéder à certains sites web et l'interdire à d'autres.

Je ne comprends pas la référence à AD: pour moi la solution devrait être fonctionnellement "OS agnostique".

-> Tu devrais confier les taches d'auth, a un système par ports 802.x ou à un portail captif

oui pourquoi pas, c'est souvent le cas, encore que, en entreprise, l'usage du portail captif pour les liaison filaires, ce n'est pas trop développé.

-> je persiste et signe a dire que c'est mal avisé d'avoir dans ses logs des requetes SSL, (qui peuvent parfois en GET contenir des données hyper confidentielles) et aucune instance te tiendra rigueur de dire : "non mais voila, c'est du SSL, nous on a pas de vues la dessus"

C'est parce que tu persistes à associer "proxy" à contenu, cache etc… Ce qui est encrypté, avec HTTPS, c'est le contenu de la communication. L'URL que tu accèdes via ce protocole est elle parfaitement claire et il n'y a rien de plus confidentiel avec ça qu'avec du HTTP simple.
L’utilisation de HTTPS ne vise d'ailleurs pas uniquement à encrypter (au sens de tunnel) la communication mais également à vérifier que le serveur auquel tu accèdes est bien celui qu'il prétend être. Ce pour, pa rexemple, éviter les petits malins qui joueraient avec le contenu de fake DNS :P

et pour le filtrage, (vis a vis du ssl) comme dit, tu as des manière de faire qui ne se cantonnent pas au http (niveau haut)
mais a un niveau plus bas,
-> le blocage en dur dans le firewall (pour un nb réstreint de destinations)
-> le blocage par empoisonnement du DNS
dans le dernier cas, tu opères un blocage a tout type de flux, et pas que le surf

donc a mon sens (hors avis qu'on viendrait m'apporter pour un point qui me serait sauté du cerveau par mégarde)

ce que je te propose, c'est d'essayer de concevoir une solution (administrable ;D) qui permettrait, par exemple, aux membres de l'équipe RH d'une entreprise d'accéder à quelques réseaux sociaux pendant les heures de travail tout en l'interdisant aux autres employés.
HINT: interdire le flux dans le proxy pour HTTP uniquement ne marche pas car la plupart de ces serveurs s'accèdent également en HTTPS.

=> faire passer le ssl par un proxy… ca sert a rien si ce n'est a fourrer son nez dans une requête qui devrait rester intacte de bout en bout

faire "passer" HTTPS par le proxy ne modifie en rien le contenu de la requête, sauf en cas d'utilisation, très controversée, de solution d’interception, telle que le permettent Squid, BlueCoat et d'autres. En revanche, cela permet du filtrage sur l'adresse cible. une fois cette étape de filtrage passée, (et c'est généralement SquidGuard qui est utilisé ici derrière Squid), la communication est directe entre le client et le serveur.

(*) ce qui importe au niveau du proxy, ce n'est pas tant l'authentification que l'identification. Le proxy lui-même ne prend pas en charge l’authentification. Celle-ci est déléguée à un composant externe, Radius, LDAP Kerberos etc…

Florian22

j'agrée.

et qu 'en est il des parametres confidentiels placés en GET qui peuvent éventuellement se retrouver dans le log ?

exemple:

https://www.google.fr/search?q=j%27ai+envie+de+me+faire+fouetter+par+une+naine+a+forte+poitrine&ie=utf-8&oe=utf-8&gws_rd=cr&ei=QsoCVZPWMIG0UKzVgLAC

pour moi c'est un peu limite que dans un log, tu aies cette ligne + une IP, et donc une concordance radius par exemple, et donc un nom, un prenom, une date une heure

tu sais donc que Florian, a recherché ce contenu, telle date, telle heure

ssur un réseau d'entreprise whynot (d'ailleurs ton souci de filtrage se cale bien sur cette problematique)

sur un réseau … commercial => a exclure

--

sinon avec l'empoisonnement dns, tu peux differencier les origines

je sais que opendns le fait

--

il te suffit donc de déclarer tes origines, en fonction de tes besoins de filtrages

(ne me demande pas comment ils gerent les origines, j avais lu ca qquelque part il y a longtemps

chris4916

Je ne vais pas commenter le contenu de la requête, chacun sont truc, ;D ;D ;D mais elle n'a rien de confidentiel. A la limite de résultat de la recherche peut-il l'être mais celui-ci restera dans le tunnel et donc personne ne saura si tu as trouvé ton bonheur. D'ailleurs ce qui intéresse l'investigateur éventuel, ce n'est pas la réponse mais le fait que tu sois allé visiter ce site.
De plus, pour autant que je sache, et c'est le point qui devrait te rassurer, Squid ne va pas conserver de trace du contenu de ta requête.

Facile à mettre en oeuvre: active un proxy + squidguard sur une plateforme de test, configuré en mode explicite.
Ajoute quelques règles de filtrage pour interdire l'accès à quelques sites en HTTP et HTTPS et regarde le contenu des logs ;)
Tu peux par exemple autoriser google en HTTPS et chercher des personnes de petite taille susceptibles de te faire du mal (ou du bien ;)) et ensuite chercher ça dans tes logs.

Tu devrais normalement y trouver, pour les sites autorisés, des TCP_MISS suivis d'un CONNECT vers l'adresse IP du site.

Comme tu le soulignes, la solution dépend du besoin et de l'environnement et une même solution technique (ici Squid + SquidGuard) peut être utilisée dans différents environnement pour différents besoins.

D'où la nécessité, pour crashoux, maintenant que le débat évolue par rapport à sa question initiale relative au plantage de Squid, de reprendre à zéro en commençant par clarifier le besoin et le contexte de celui-ci avant de se focaliser sur la solution.

La fonction de cache du proxy est de moins en moins intéressante compte tenu du contenu de plus en plus dynamique du web mais en contrepartie, le besoin de savoir si un quidam est allé visiter un site jugé inapproprié est perçu comme de plus en plus important, même sur un réseau commercial. Nos ISP le savent bien.

Les solutions basées sur le DNS visent plutôt, dans ma compréhension, lorsqu'il ne s'agit pas soit de hacker soit de censurer, à offrir à l'utilisateur un accès au service proche (du point de vue réseau) du demandeur.

Florian22

@chris4916:

Je ne vais pas commenter le contenu de la requête, chacun sont truc, ;D ;D ;D mais elle n'a rien de confidentiel. A la limite de résultat de la recherche peut-il l'être mais celui-ci restera dans le tunnel et donc personne ne saura si tu as trouvé ton bonheur. D'ailleurs ce qui intéresse l'investigateur éventuel, ce n'est pas la réponse mais le fait que tu sois allé visiter ce site.

le site en l'occurence est google
qui fournit un contenu de recherches

et pour moi, la requête exprimée dans l'url est confidentielle a mes yeux

a moins que tu trouves normal que l'on puisse savoir ce qu'un utilisateur cherche dans google?
(je ne te parle pas d'un poste pro nécéssairement)

@chris4916:

De plus, pour autant que je sache, et c'est le point qui devrait te rassurer, Squid ne va pas conserver de trace du contenu de ta requête.

squid conservera l'url
or elle contient tous les parametres pour être rejouable

elle contient les parametres en clair, et en plus elle est rejouable

donc non, la confidentialité vient clairement de sauter

@chris4916:

Les solutions basées sur le DNS visent plutôt, dans ma compréhension, lorsqu'il ne s'agit pas soit de hacker soit de censurer, à offrir à l'utilisateur un accès au service proche (du point de vue réseau) du demandeur.

ce que tu dis est vrai sur l'angle Geo-DNS
toutefois c'est hors du sujet "filtrage"

donc c'est faux

les solutions de filtrage par DNS, sont tout aussi performantes que par proxy
par ailleurs, elles ne nécéssitent aucun travail du proxy, ni aucune gestion de l'admin réseau des blacklistes

chris4916

@Florian22:

@chris4916:

De plus, pour autant que je sache, et c'est le point qui devrait te rassurer, Squid ne va pas conserver de trace du contenu de ta requête.

squid conservera l'url
or elle contient tous les parametres pour être rejouable
elle contient les parametres en clair, et en plus elle est rejouable
donc non, la confidentialité vient clairement de sauter

As-tu seulement fait le test que je te suggère avant d'affirmer ça ? visiblement pas ::)
D'où vient cette histoire de "rejouabilité" ?

les solutions de filtrage par DNS, sont tout aussi performantes que par proxy
par ailleurs, elles ne nécéssitent aucun travail du proxy, ni aucune gestion de l'admin réseau des blacklistes

et as-tu déjà opéré des solutions de filtrage, de contrôle ou de sécurisation de flux HTTP dans un environnement de taille significative pour penser que l'administration du DNS permet de mettre en œuvre du filtrage "aussi performant que du proxy" ? Si c'est le cas, ce doit être dans un environnement bien particulier, à moins que ce soit mon expérience personnelle qui me donne une vision biaisée, ce qui est possible même si j'en doute fortement ;)

Pour bien comprendre ce que raconte le log de Squid.

Florian22

j'expérimente la solution actuellement sur un réseau d'environ 300 à 400 machines (de toute nature, de tous os,)

j'en suis très satisfait, autant par l'aspect "mise a terre à 99%" des flux néphastes (c'est a dire hors du reglement du réseau)

autant que par la gestion au quotidien de la solution, tres centralisée, et totalement transverse sur le réseau (multi protocolaire) et totalement détachée du réseau

il ne me suffit que de cocher "pornography" pour mettre un terme (avec un délai de propagation de 10à 20 min) a des magistrales sessions de branlettes quotidiennes (ces etudiants…)

evidemment ce n'est pas le cas

ces blacklistes sont là pour une autre finalité.

mais il serait sans problème possible de faire le salaud jusqu'au bout, et de proposer a ce parc machine de l'internet a plusieurs vitesses

avec des policies orientées "web de base" (texte) et des policies permettant le "web gourmand" (youtube vod.. etc)

il n'est pas bien sur question de s'en servir de cette manière.

par ailleurs, toutes solutions sont contournables, moi ce que je regarde c'est le ratio de ceux qui font rien, + ceux qui lachent l'affaire, rapportés aux 2% de jusqu'au boutistes

pour qui tu ne peux rien

concernant le reste :

la facon de voir comment squid journalise les requetes HTTP, me suffit pour imaginer comment il va journaliser les HTTPS
et oui, les urls qui contiennent des parametres en GET, sans système de token, sont rejouables

=> tu peux rejouer mes liens google de ton coté , et tu les verras de la même manière s'afficher chez toi que si tu avais tapé les mots clés

-> donc si la requete est présente en entier dans le log de squid, et bien moi je dis c'est une atteinte à la vie privée
car les mots clés sont en clair, et le lien est rejouable
-> donc le contenu de la requête (a la base cryptée) ne l'est plus, vu que tu peux rejouer la requête a ton tour de ton coté ultérieurement, et indéfiniment

chris4916

@Florian22:

j'expérimente la solution actuellement sur un réseau d'environ 300 à 400 machines (de toute nature, de tous os,)

Je suis très intéressé par une descriptions technique de comment est-ce que cela fonctionne

mais il serait sans problème possible de faire le salaud jusqu'au bout, et de proposer a ce parc machine de l'internet a plusieurs vitesses
avec des policies orientées "web de base" (texte) et des policies permettant le "web gourmand" (youtube vod.. etc)

tout ça basé sur le DNS :o n'hésite surtout pas à en dire un peu plus sur comment ça se met en œuvre.

la facon de voir comment squid journalise les requetes HTTP, me suffit pour imaginer comment il va journaliser les HTTPS

et oui, les urls qui contiennent des parametres en GET, sans système de token, sont rejouables

Ton imagination te joue des tours ! Il n'y a pas, jusqu'à preuve du contraire, dans le log de Squid, de "GET https://….." ce qui voudrait dire que Squid exécute la requête HTTPS à ta place, ce qui, sauf si tu met en place de l'interception (et donc man-in-the-middle :-X), n'existe pas.
Mais même sans interception, et c'est tout le débat depuis le début, tu peux grace au proxy explicite et contrairement au proxy transparent, bénéficier de Squid et SquidGuard (ou Dansguardian) pour faire du filtrage, du contrôle d'accès et du profiling sur les URL en HTTP et en HTTPS.

Pour mettre fin à ce débat qui perd un peu de son utilité dans le cadre de la question initiale de crashoux (mais je reste très intéressé par une description de ton implémentation de contrôle de l'internet basée sur le DNS), je te suggère de lire la doc de Squid sur la partie HTTPS.

-> donc si la requete est présente en entier dans le log de squid, …/...

Tous les mots sont importants :)

un petit extrait de la doc de Squid pour illustrer mon propos et conclure, de mon coté (là aussi tous les mots sont utiles):

When a browser establishes a CONNECT tunnel through Squid, Access Controls are able to control CONNECT requests, but only limited information is available. For example, many common parts of the request URL do not exist in a CONNECT request:

the URL scheme or protocol (e.g., http://, https://, ftp://, voip://, itunes://, or telnet://),

the URL path (e.g., /index.html or /secure/images/),

and query string (e.g. ?a=b&c=d)

With HTTPS, the above parts are present in encapsulated HTTP requests that flow through the tunnel, but Squid does not have access to those encrypted messages. Other tunnelled protocols may not even use HTTP messages and URLs (e.g., telnet).

Florian22

j'agréé

je n'avais point lu cette doc

méa maxima culpa

Florian22

concernant le DNS, tu n'as qu 'a m'écrire

Tatave

Salut salut

Juste la pour suivre sans pour autant vouloir interférer.

Je suis curieux de voir la suite sur l'information traitant des dns.

Cordialement.

Florian22

@Tatave:

Salut salut

Juste la pour suivre sans pour autant vouloir interférer.

Je suis curieux de voir la suite sur l'information traitant des dns.

Cordialement.

bah dis donc tatave, t abuses, tu la connais la methode ^^
l autre jour j en ai parlé t etais la

chris4916

J'espère que "la" méthode n'est pas celle-ci ;)
Ce n'est pas vraiment du filtrage ni du contrôle mais juste une solution de contournement partielle.

Ce n'est pas que je n'aime pas OpenDNS (je j'ai largement utilisé) mais Umbrella + Investigate … bof :-\ A la limite en complément d'une infrastructure dédiée au filtrage mais encore, je ne vois pas bien ce que ça apporte, si ce n'est une autre vision de la catégorisation des fournisseurs de service et de site.

jdh

Filtrage par dns ?

La liste 'adult' de la blacklist de Toulouse comporte plus d'1 million de lignes soit autant de domaine dns.
Il me parait totalement impossible (et fantaisiste) qu'un serveur dns avec une telle liste de domaines (associé à 127.0.0.1) réponde aussi vite que SquidGuard pour traiter cette même liste !

Lire la page de http://dsi.ut-capitole.fr/documentations/cache/squidguard.html sur le comparatif entre SquidGuard et ses concurrents.
Notamment la liste 'adult' est augmentée pour limiter l'utilisation de regex qui, elle, est très consommatrice.

Le filtrage par dns est tout à fait possible et efficace pour de petites listes de domaines.
Par exemple, si un fournisseur FAI français est obligé, par décision de justice, d'interdire à ses clients l'accès à un site pirate, il utilisera cette méthode.
Et chacun peut le vérifier …

Je salue la précision de chris4916 : sans regarder la doc, il suffit de regarder un 'access.log' pour vérifier que

les paramètres après le ? n'y sont pas,
les 'CONNECT xxxx:443' pour le trafic https (=443/tcp).

chris4916

@jdh:

Filtrage par dns ?

Nous sommes d'accord 8)
Je viens de lire quelques sujets (dans ce forum que je découvre) relatifs à cette solution préconisée ici et là (en commençant par le lien ci-dessus). ça m’interpelle quand même pas mal ce truc lorsque c'est déployé avec cette idée en tête de remplacer un proxy HTTP.

il y a des aspects performance mais également des aspects "niveau de service", granularité, profiling, anti-virus… bref, ce n'est simplement pas la même chose.

Par contre, c'est une solution qui me semble acceptable pour un device mobile isolé dans la nature qui voudrait avoir une protection de base pour ne pas être redirigé vers des sites malveillants. Je vais essayer d'améliorer ma compréhension de ce truc en attendant les explications de Florian

fprigent

La solution filtrage dns fonctionne bien, avec du DNS RPZ (bind). Le problème est plutôt d'arriver à installer un Bind 9.10 qui est le seul à même de faire fonctionner cela "correctement"..

En plus cela fonctionne pour tout : HTTP, HTTPS, ftp, etc… et sans configuration des postes.. Pratique.

Mais bon, il faut arriver à le faire "tomber en marche".... ;-)

Bien sûr, cela ne dispense nullement d'un filtrage par proxy....

chris4916

@fprigent:

Bien sûr, cela ne dispense nullement d'un filtrage par proxy….

Mais quel est l'intérêt dans ce cas ?

avec un proxy, la résolution de l'URL est faite par l'URL, donc moins de chance que cette couche soit bricolée par l'utilisateur mais je ne comprends la finalité si on superpose les 2 solutions ???

fprigent

Tu ne traite pas les mêmes cas :
- proxy "simple" (configuration standard)
- pour les postes contrôlés pour lesquels tu as positionné le proxy
- filtrage complet
- proxy avec wpad
- pour les postes qui sont configurés correctement après information (style affiche pour du public étudiant, ou autre)
- filtrage complet
- proxy transparent
- pour les postes qui ne respectent pas le wpad
- filtrage complet pour le port 80
- pour les autres ports => filtrage DNS.

chris4916

@fprigent:

Tu ne traite pas les mêmes cas : …/...

J'avoue ne pas vraiment comprend, même si je saisi je pense une partie de l'idée.
D'un point de vue DNS, selon que le proxy est transparent ou pas, la différence se situe au niveau de "qui" demande la résolution.

Dans le cas d'un proxy transparent, c'est le poste de l'utilisateur qui se charge de demander au DNS de résoudre le nom et qui fait ensuite la requête sur l'adresse IP, laquelle est interceptée par le proxy de manière transparente ::)
dans le cas d'un proxy explicite ou WPAD (c'est à quelques détails près la même chose), le client sait qu'il parle à un proxy, il ne demande pas de résolution de nom au DNS mais délègue ça au proxy qui s'en charge (avec les avantages que ça présente en terme de cache au niveau DNS)
pour mémoire: sans proxy, c'est, comme en proxy transparent, le client qui gère le DNS

donc soit il y a une différence entre les DNS utilisés par les clients vs. ceux utilisés par le proxy et effectivement on ne traite pas la même chose (mais ça devient compliqué de savoir quoi est filtré par quoi) soit les DNS sont les mêmes et la différence que tu évoques ne me saute pas aux yeux.

Je ne prétends pas que ce que tu énonces est faux, erroné ou quoique ce soit de ce genre. Je n’ai de plus pas utilisé OpenDNS en dehors d'un DNS classique (donc sans filtrage) et ma compréhension est celle liée à la lecture de leur publication mais cette notion de filtrage DNS me laisse perplexe. Le seul intérêt que j'y vois, éventuellement, est de fournir aux clients qui n'ont pas de proxy configuré ou configurable (en direct ou via WPAD) une sorte de protection basée sur le blocage de l'adresse IP correspondant au FQDN, ce qui dans certains cas, j'en conviens, est mieux que rien.
Mais avec quelques effets de bord et des points pas pris en compte.
Du coup, si il n'y a pas de proxy, pourquoi pas, ça peut dépanner… provisoirement ou en fonction des environnements
Si un proxy est disponible, en mode explicite (je ne considère jamais le proxy transparent comme une solution fiable si il s'agit de fournir du filtrage ou de la sécurité) alors je ne comprends pas l’intérêt de superposer les 2 solutions, ce qui crée des zones de flou en terme d'administration et contrôle, avec les effets de bord déjà évoqués.

Mais je suis complètement ouvert à changer d'avis si ma compréhension de "comment ça marche" évolue ;)