Squid et squidguard plantent.
-
Merci a vous!
Je ne pensais pas déchaîner les passions avec ma petite question. Ca me rassure que des personnes plus spécialiser que moi ne soit pas d'accord, ca signifie que je n'ai pas rater une solutions évidente et que même des connaisseurs sont pas d'accord ;)
Je comprend bien vos réponses, mais dans les hotels alors? comment font ils? Il y a bien du portail captif et du filtre url?
Mon but serait d'avoir une solutions s'approchant de ces system car la connexion ici est partagée pour une centaine de kot etudiants et le gros problèmes est que le propriétaire de la connexion (en belgique) est responsable du surf qui passe dessus. Mon client a déjà eu une réprimande de l’opérateur pour abus.
Est-il possible de dire au portail captif de pfsense de renvoyer tout le surf qu'il capte dans un filtre proxy qui se trouverais apres lui?
En tout cas encore un grand merci à tous
-
envoyez moi svp la capture ecran des packages installés
envoyez la ici
on reprend tout depuis le débuta la fin de ce post, vous aurez, un portail captif fonctionnel, ainsi qu'un squid embarqué sur le pfsense (bien que ca se fasse pas trop)
combien d'utilisateurs sont sur le réseau?
quelle est la segmentation du réseau (nombre de VLAN)quelle est la topo
je reste en attente
-
j'ai un rdv ce matin je vous transmet tout dans l’après-midi.
Merci de votre aide d'avance ^^
-
dans ce cas, réinstallez pfsense (faites un reset)
inutile de sauvegarder votre conf qui ne va pas.
on va partir sur une conf minimaliste, que je vous laisserai étoffer
vous allez activer deux interfaces, la premiere en 192.168.1.1/24 (WAN)
la deuxieme en 192.168.2.1/24 (la LAN)
puis vous installez le package squid 3
vous n y touchez pas.
revenez quand tout ca est d'equerre.
aucun package a part squid 3 + un pf propre et neuf + vos deux interf (wan+lan)
on fera sans VLANs. vous aurez un CP sur LAN avec un squid transp qui fait du Logging
apres le reste c'est vous.
je reste également pour votre prochain message, en attente de la topo (nombre postes, nombre users, segments, boucles locales sur le LAN)
ceci afin que je vous donne mon avis sur l'infra / vis a vis du pfsense que vous vous apprettez a mettre en prodje reste a dispo
-
:) il ne me semblait pas avoir été aussi agressif. Désolé ::)
je ne vais pas répondre à chacun des points car je ne veux pas donner l'impression de démarrer une polémique, d'autant qu'il n'y en a pas, en tous cas de mon point de vue :)
Je fais clairement partie de ceux qui pensent que lorsque c'est possible, un pare-feu ne doit remplir que cette fonction. Je ne m'oppose donc pas à cette vision de cloisonnement des services, ou en tous cas d'isolation des services orientés sécurité.
A partir de là, lorsque j'écris qu'il n'y a pas de solution simple, je veux dire qu'il ne suffit pas d'installer une machine 'n’importe où sur la LAN et d'y installer un proxy pour que celui-ci fonctionne en mode transparent (sauf par exemple à déclarer son adresse en tant que route par défaut pour les machines sur le LAN qui veulent accéder au web). Avec la machine sur le LAN, il y a des solution de redirection depuis la route par défaut mais c'est ce que j'estime (peut-être à tord) sortir du cadre de la solution simple.
ça veut donc dire une DMZ, un proxy sur la DMZ, une route sur le FW qui redirige vers le proxy.
Ce n'est pas la seule solution mais la plus simple qui me vient à l'esprit en rédigeant cette réponse.
Ceci dit, je ne suis pas très fan du proxy HTTP en mode transparent car il y a pas mal d'effets de bord à ce type d'utilisation, à commencer par le fait que HTTPS ne peut pas bénéficier du proxy avec ce design (j'avoue ne pas avoir regardé de près ce que la nouvelle implémentation de man-in-the-middle" de Squid change de ce point de vue.
WPAD me semble être la bonne solution lorsqu'il s'agit de déployer un proxy et qu'un ne souhaite pas, ce qui est bien naturel, configurer le proxy sur chaque poste de travail.Pour finir sur ce point, j'ai l’impression qu'il y a une confusion, probablement due à ma réponse mal rédigée :-[, avec le portail captif associé au proxy et le proxy seul.
J'ai émis un avis lié au proxy en mode standalone et pas au fait que le proxy était associé systématiquement au potail.Je suis vraiment désolé si je dis des âneries et suis tout à fait preneur d'arguments qui expliquent pourquoi il est acceptable d'avoir un portail captif sur le FW mais pas un proxy, à condition que la réponse ne soit pas uniquement basée sur la distinction "c'est intégré vs. c'est un package" ;)
Je suis également très intéressé, mais à titre de compréhension uniquement car je ne vais pas déployer ce type de solution, par un design de proxy sur le LAN qui fonctionnerait en mode transparent sans que celui-ci soit la route par défaut de clients du LAN ;)
-
:) il ne me semblait pas avoir été aussi agressif. Désolé ::)
si j ai paru agressif je m en excuse
j ai une maniere de parler sans détours. zero agressivité soyez en surJe fais clairement partie de ceux qui pensent que lorsque c'est possible, un pare-feu ne doit remplir que cette fonction. Je ne m'oppose donc pas à cette vision de cloisonnement des services, ou en tous cas d'isolation des services orientés sécurité.
on est synchrone
A partir de là, lorsque j'écris qu'il n'y a pas de solution simple, je veux dire qu'il ne suffit pas d'installer une machine 'n’importe où sur la LAN et d'y installer un proxy pour que celui-ci fonctionne en mode transparent (sauf par exemple à déclarer son adresse en tant que route par défaut pour les machines sur le LAN qui veulent accéder au web). Avec la machine sur le LAN, il y a des solution de redirection depuis la route par défaut mais c'est ce que j'estime (peut-être à tord) sortir du cadre de la solution simple.
cette solution pue du cul.
vous ne devriez même pas imaginer cette approche. (elle ne devrait pas vous venir a l'esprit) elle est tordue
-> Pas de services Réseaux sur des IP des pools d'assignation clients point barre.
-> C'est les hommes du milieux qui font ca
-> On surveille son, réseau face a ce genre de menaces
-> On met pas des proxy, ou des dhcp ou je ne sais quoi 3 IP plus loin qu''un client POINT. je ne veux meme pas épiloguer sur votre theorie
elle pue, vous vous la sortez de la tete merci ;)ça veut donc dire une DMZ, un proxy sur la DMZ, une route sur le FW qui redirige vers le proxy.
Ce n'est pas la seule solution mais la plus simple qui me vient à l'esprit en rédigeant cette réponse.
j'ai rien compris..
Ceci dit, je ne suis pas très fan du proxy HTTP en mode transparent car il y a pas mal d'effets de bord à ce type d'utilisation, à commencer par le fait que HTTPS ne peut pas bénéficier du proxy avec ce design (j'avoue ne pas avoir regardé de près ce que la nouvelle implémentation de man-in-the-middle" de Squid change de ce point de vue.
WPAD me semble être la bonne solution lorsqu'il s'agit de déployer un proxy et qu'un ne souhaite pas, ce qui est bien naturel, configurer le proxy sur chaque poste de travail.c'est interdit de filtrer le ssl.
une connexion ssl est integre de bout en bout
les fonctions MiM d'un proxy pour le SSL vont nécéssiter l'install d'une autoritée de confiance sur chacun des postes=> Jamais personne ne vous tiendra rigueur de ne pouvoir tracer une requete SSL
=> C'est techniquement exclu
=> Personne ne vous demande de le faire=> Autant vous sortir ca de la tête sans tarder ;)
=> et ne plus en parlerPour finir sur ce point, j'ai l’impression qu'il y a une confusion, probablement due à ma réponse mal rédigée :-[, avec le portail captif associé au proxy et le proxy seul.
J'ai émis un avis lié au proxy en mode standalone et pas au fait que le proxy était associé systématiquement au potail.[/quote]
un proxy, sert a filtrer, logger, cacher du contenu
il peut renvoyer un digest d'authentification, mais c'est LA ENCORE une implémentation pour laquelle il n'est pas a la base prévu.
mieux vaut donc l'utiliser de manière transparente, en hauteur dans le réseau localil est tout a fait possible de faire tourner un portail captif pfsense (qui fait partie de pfsense)
il est tout a fait possible de ne pas utiliser de portail et de laisser un proxy transparent
il est tout a fait possible d avoir un portail, sans proxy
Je suis également très intéressé, mais à titre de compréhension uniquement car je ne vais pas déployer ce type de solution, par un design de proxy sur le LAN qui fonctionnerait en mode transparent sans que celui-ci soit la route par défaut de clients du LAN ;)
oui, si crashoux ecoute bien, et suit bien, il n'y a pas de raisons qu'il n'ait pas une interface LAN, avec un portail actif, et un squid transparent dessus
(sauf si il fait du loadbalancing, auquel cas, il devra avoir DEUX pfsense, un frontal, qui se charge du balancing, un plus pres du/des LANs/VLANS qui se charge du portail, et du proxy.ou 1 Pf qui fait du load, et un serveur proxy ISOLé, –> et pas sur le réseau client
--
concernant le wpad, IL EST A MON SENS , meilleur de déployer du transparent que d'être obligé de mettre soit des confs en dur, soit des GPO qui vont mettre des confs
ps: wpad => N'est pas utilisé en mode transparent, uniquement lorsque la brique auth du proxy est utilisée
plus d'infos ici: https://doc.pfsense.org/index.php/WPAD_Autoconfigure_for_Squid
le principe même du transparent, est que (de la vue du poste) le proxy soit haut dans le réseau, et pas visible, (le poste a une config automatique, c'est la passerelle qui va faire le boulot)
tres souvent, il n'y a rien de compliqué. quand vous vous dites "merde ca semble assez balaise comme truc la", c'est que votre approche est certainement, "compliquante" et donc mauvaise
-
Depuis très longtemps, j'écris que le proxy ne devrait pas être sur le firewall.
La raison essentielle est que les besoins mémoire/processeur/disque/process sont très différents et, partant, cela peut perturber le firewall qui agit au niveau des paquets IP et doit répondre vite.
Dans le cas précis de pfSense, il y a lieu d'être très prudent avec les packages (qui sont fournis avec AUCUNE garantie).
Et justement Squid est un package !Une bonne démarche est donc d'avoir 2 machines distinctes :
- un firewall, avec ou sans portail captif
- un proxy avec Squid/SquidGuard/LightSquid (et en option Havp) (et avec WPAD que je ne peux que recommander).
L'inconvénient (apparent) est de devoir configurer à la main Squid/SquidGuard (au lieu d'une belle interface à la pfsense).
En fait on peut observer qu'une fois la config trouvée, elle ne bouge plus (donc pas besoin d'interface web), et elle est très facile à reproduire.L'avantage est de pouvoir stocker autant de logs que nécessaire et imposé par la loi.
-
J'avais en privé écrit à Florian que je n'interviendrait plus sur ce fil pour ne pas alimenter c e qui me semblait être parti comme une polémique inutile et qui n'avait pas lieu d'être mais compte tenu de ce qui est formulé, je me dois de rétablir quelques points (en ne considérant que les aspects techniques)
concernant le wpad, IL EST A MON SENS , meilleur de déployer du transparent que d'être obligé de mettre soit des confs en dur, soit des GPO qui vont mettre des confs
ps: wpad => N'est pas utilisé en mode transparent, uniquement lorsque la brique auth du proxy est utilisée
plus d'infos ici: https://doc.pfsense.org/index.php/WPAD_Autoconfigure_for_Squid
le principe même du transparent, est que (de la vue du poste) le proxy soit haut dans le réseau, et pas visible, (le poste a une config automatique, c'est la passerelle qui va faire le boulot):o :o :o
C'est techniquement au moins partiellement inexact et je vais essayer d'expliquer pourquoi 8)
La différence, du point de vue du proxy, entre explicite (avec ou sans WPAD) et transparent n'est pas du tout celle décrite ci-dessus.
En mode transparent, le client (le navigateur) n'est pas configuré pour interroger un proxy. Il envoie des requêtes sur généralement le port 80 (on parlera de HTTPS plus loin) pou accéder directement au serveur Web. Sauf si ce serveur web est sur le réseau local ou via une route connue du poste qui fait tourner le client, cette requête arrive sur la passerelle par défaut.
C'est ici qu'intervient, d'une manière ou d'une autre le proxy en mode transparent puisqu'il s'agit d'intercepter les paquets et de les diriger, à l'insu du browser, vers un proxy pour faire du filtre, du cache, de l'anti-virus.Ce mode de fonctionnement à l'air bien pratique car, vu de l'administrateur, il n'y a rien à faire coté client, mais il présente un inconvénient majeur: les requêtes vers les serveurs en HTTPs ne peuvent pas être redirigées vers le proxy car le client ne sait pas que celui-ci intervient dans la communication entre le client et le serveur. Duc oup, effet de bord direct, il n'y a pas de filtrage possible de l'URL. Je ne parle même pas de filtrage de contenu, de cache, d’authentification (d'où sort ce point ???) . La seule solution possible pour faire du filtrage d'URL en mode HTTPS serait de mettre en place une solution de type "man-in-the-middle" (ce qui existe ;D)
Comme le proxy transparent (au sens ou je le décris) n'est pas acceptable lorsqu'il s'agit de faire du filtrage d'URL, et que d'un autre coté la configuration de chaque client pour indiquer la présence du proxy n'est pas pratique, un mécanisme a été inventé, non pas pour imiter le fonctionnement du proxy transparent mais pour configurer le proxy coté client sans que ce soit pénible pour l'administrateur. Il s'agit de WPAD.
La fonction de WPAD est de faire en sorte que le client soit informé de manière aussi automatique que possible de l'existence d'un proxy et l'utilise.La grosse différence est que dans ce cas, il est possible de faire du filtrage d'URL même en HTTPS car le client sait qu'il s'adresse au proxy et attend une réponse de celui-ci.
J'ai écrit, pour une autre plate-forme :-[ un document qui se focalise un peu sur ces aspects. Bien que ce soit pour une plate-forme différente, ça reste techniquement valide et applicable à une configuration avec pfSense [url=https://wiki.zentyal.org/wiki/Select_Right_HTTP_Proxy_Design]https://wiki.zentyal.org/wiki/Select_Right_HTTP_Proxy_Design (désolé c'est en anglais)
Pour compléter ma réponse, je vais revenir sur un aspect réseau et positionnement du proxy lorsque celui-ci est utilisé en mode transparent:
- le browser ne sait pas qu'il communique avec un proxy puisque les paquets sont "interceptés"
- le proxy transparent peut être installé, si on considère un réseau "simple" constitué d'un LAN, d'un composant intermédiaire faisant office de pare-feu et d'une DMZ, soit sur le LAN, soit sur la DMZ, soit sur le FW.
Si on regarde chacun des cas possibles, voila comment cela fonctionne (dans ce que je comprends et n'hésitez pas me signaler mes âneries ;))
- proxy HTTP sur le LAN (ce qui sous-entant que le proxy n'est pas la gateway par défaut des clients)
=> le client veut accéder un serveur web sur le LAN: la route est connue, l'accès est donc direct, il n'y a pas d'interception de paquet et donc pas d'intervention du proxy, et donc pas de cache. Mais sur le LAN, ce n'est probablement pas grave.
=> le client veut accéder un serveur sur le web: sans entrer dans les détails du DNS, les paquets vont atteindre la gateway par défaut et pour utiliser le proxy qui est sur le LAN, il faut (faudrait car ce n'est vraiment pas souhaitable) rediriger les paquets issus du LAN vers le proxy (sur le LAN) et n'accepter des paquets sortant en HTTP que si issus du proxy. Cela ne suffit cependant pas. Comme la requête HTTP vient du client mais qu'elle est en fait, du point de vue du serveur, issue du proxy, le retour va se faire du serveur vers le proxy (et non pas vers le client) lequel va répondre au client qui ne s'attend pas à cette réponse sauf à avoir mis en place du NAT sur la LAN. Bref, le proxy en mode transparent sur le LAN, c'est compliqué et à éviter à tout prix (mais il est très intéressant de comprendre vraiment, je veux dire sur les aspects techniques, comment ça marche)- proxy HTTP sur la DMZ
=> les paquets sont naturellement interceptés par la gateway par défaut qui les redirige vers le proxy. C'est plus simple qu'un proxy sur le LAN car coté FW, il n'y a pas de règle spécifique pour autoriser à faire sortir le proxy tout en interdisant les autres clients. Tout est envoyé au proxy qui est sur un autre segment. avec un peu de DNAT, ça marche
- proxy sur le FW
C'est la solution la plus simple et c'est pourquoi "tout le monde" veut le faire comme ça (ce n'est pas juste une question d'interface d'admin même si cet aspect est important).
=> les paquets sont interceptés par le FW qui les renvoie sur le port interne du proxy (par exemple 127.0.0.1), lequel fait la requête, reçoit la réponse et la renvoie au client qui voit la réponse issue de sa passerelle par défaut. Tout va bien… ;Dmais aucune de ces solutions ne sait intercepter du HTTPS pour, par exemple, interdire, via le proxy, à ses utilisateurs de faire du facebook entre 8H00 et 17H00 :P c'est pourquoi on évite le proxy en mode transparent et on lui préfère généralement WPAD.
Last but not least, tout ceci n'est vrai que si on discute uniquement de proxy HTTP. la mise en œuvre d'un portail captif mettant en œuvre d'autres mécanismes.
-
@jdh:
Dans le cas précis de pfSense, il y a lieu d'être très prudent avec les packages (qui sont fournis avec AUCUNE garantie).
Et justement Squid est un package !Ce point me semble être LE POINT important.
Je découvre en prod pfSense (que je connais comme produit depuis longtemps mais que je n'avais jamais déployé pour faire de la prod) et il est évident que la gestion des packages est en décalage avec les fonctionnalités "intégrées".La non stabilité potentielle de ces packages me semble beaucoup plus critique que les aspects de design.
Qu'en est-il des versions précédentes ? Je veux dire par là, sans prendre en considération les aspects "garantie" que tu soulèves, est-ce que les packages qui tournent sur la version 2.1 sont plus fiables parce que plus anciens et donc mieux corrigés d'éventuels défauts ? -
Vous avez exactement décrit les problématiques, et c'est bien.
Mais vous n'insistez pas assez sur les mauvais choix.- proxy sur firewall : TRES mauvais !
- mode transparent : fausse bonne idée ! et quelque soit la redirection puisque https n'est pas géré !
La seule bonne pratique (à la fois sur le respect de la législation, et sur le long terme) est :
- un proxy configuré à la main (gardez votre bonne config), dans le LAN ou dans la DMZ
- wpad
- une règle d'interdiction de traversée du firewall sauf pour le proxy
Bien évidemment cela demande un peu d'effort mais c'est le prix de l'efficacité.
-
Je souscris pleinement. Organisation, méthode et architecture sont des composants indissociables pour être efficace.
-
@jdh:
Mais vous n'insistez pas assez sur les mauvais choix.
- proxy sur firewall : TRES mauvais !
- mode transparent : fausse bonne idée ! et quelque soit la redirection puisque https n'est pas géré !
Pour le proxy en mode transparent, je lutte contre depuis des années ;D je suis donc convaincu que ce n'est jamais une bonne solution.
Pour le proxy sur le firewall, je suis également convaincu à titre personnel que, quand on a le choix, ce n'est pas le meilleur design mais j'avoue, au delà des aspects "packages de pfSense mal gérés et/ou mals suivis" que les arguments techniques pour décrire systématiquement cette solution comme le mal ;D me manquent.
S'il ne s'agit que de performance, bof… ça dépend vraiment de l'usage que l'on a de son proxy. En faisant abstraction du cas spécifique de pfSense (*) sur une machine normalement constituée, il n'y a pas de conflit de ressource entre un proxy qui va faire du cache et un FW. Selon qu'on va faire du filtrage d'URL, du filtrage de contenu, de l'anti-virus ou même juste de l’authentification à des fins de tracking, les profiles de charge sont très différents et souvent en dessous de ce qu'une machine moyenne peut fournir (dans les environnements où ce type de question "proxy sur le FW ou pas ?" pourraient se poser.
S'il s'agit de conserver du log à des fins de tracking, là encore le proxy seul ne répond pas au problème, il faut externaliser et sécuriser les log avec une vraie politique d'archivage et le fait que ça tourne sur le FW ne gêne (ni n'aide) en rien ou presque. Rsyslog par exemple est une amorce de solution.
Bref, à part l'aspect "faille de sécurité du proxy" qui permettrait à un utilisateur de l'intérieur d'attaquer le firewall, j'ai du mal à avoir un argument fort pour expliquer qu'il faut ABSOLUMENT éviter ce design quelque soit la taille de l'entreprise.
Ceci dit, je suis ouvert à toute explication technique ;)
Et comme j'essayais de l'exprimer dans un de mes tous premiers messages sur ce fil, il y a plein de déploiements où la fiabilité de l'infrastructure souffrira plus de la multiplication des machines pour avoir un design parfait que de compromis tel que "proxy et FW sur le même OS"
La seule bonne pratique (à la fois sur le respect de la législation, et sur le long terme) est :
- un proxy configuré à la main (gardez votre bonne config), dans le LAN ou dans la DMZ
- wpad
- une règle d'interdiction de traversée du firewall sauf pour le proxy
Je suis tout à fait d'accord ;D ;D
Bien évidemment cela demande un peu d'effort mais c'est le prix de l'efficacité.
Cet effort n'est pas ponctuel, et c'est mon point. Pour ceux qui peuvent se permettre d'avoir un design parfait comme décrit ci-dessus, il n'y a pas de débat. Pour la TPE qui devra ensuite gérer les mises à jour diverses, sauvegardes et administration sur les multiples serveurs que le design parfait implique, c'est moins sûr ;) même si ça vaut toujours le coup de viser le bon design.
(*) dans le cas particulier de pfSense, le partitionnement (par défaut ?) pour le moins basique :-\ présente un risque supplémentaire au déploiement du proxy sur le firewall: "system disk full" mais comme je ne sais pas encore comment fonctionne, avec pfSense, la gestion des log, rotation purge etc… le problème peut exister même sans proxy :-[
-
Waouw, je vous avoue que je n'ai pas tout lu car je devais rentrer a midi d'une reunion et comme vous pouvez le voir ca s'est fini avec un peu de retard^^, mon cerveau est déjà hs avant de commencer.
Je relirais tout demain a tête reposée :)
De ce que je vois, vous êtes a peux pres tous d'accord pour dire qu'il le proxy transparent c'est pas top. Sur un système (type hotel) ou les personnes vont et viennent avec des portable des GSM,… je voudrais surtout faire du filtrage url avec des blacklist comme shalla et bloquer les p2p, de la limitation de bande passante et identifier les utilisateurs avec un portail captif.
Comment est-il possible de mettre en place ces sécurités sans intervenir sur les pc client et sans utiliser le proxy transparent?
Le fait d'utiliser plusieurs machine physique ne me pose aucun problème.
Florian je reviens vers toi par mp ;)
-
Si l'objectif est de potentiellement interdire l'accès à des sites en HTTPS grâce au filtrage du proxy, alors celui-ci ne peut pas être transparent. C'est très clair. et donc WPAD devient obligatoire pour ne pas avoir à gérer la configuration des postes clients. Mais c'est une mise en oeuvre finalement assez simple.
Pour ce qui est du portail captif, je ne connais pas la technologie retenue par pfSense. Je ne me risquerai donc pas à un avis trop détaillé mais je suppute qu'il faut, au final, mettre en œuvre un serveur Radius pour faire l’authentification et l'accounting des utilisateurs.
Quant à savoir si le package FreeRadius convient pour cet usage… joker ;DUn autre point à analyser: où vont être géré les comptes utilisateurs ? Est-ce qu'un serveur LDAP a ici son utilisé ?
A moins que le but soit d'utiliser des vouchers ?
-
Si l'objectif est de potentiellement interdire l'accès à des sites en HTTPS grâce au filtrage du proxy, alors celui-ci ne peut pas être transparent. C'est très clair. et donc WPAD devient obligatoire pour ne pas avoir à gérer la configuration des postes clients. Mais c'est une mise en oeuvre finalement assez simple.
pas forcément.
tu peux tres bien faire du filtrage autrement que par proxy, et donc filtrer a un niveau plus bas (que le surf)en conséquence, il n 'y a pas grand interret a journaliser des flux sécurisés.
puisque : soit ils passent, et restent integres (leur finalité)
soit ils donnent lieu a un blocage. (qui pourra lui a son tour faire l'objet d'un autre type de journalisation)qqun peut il me dire quelle est l'utilité d'avoir dans un fichier access.log, les requêtes commencant par "https://" ?
(a part connaitre les mots clés de toutes les recherches google des gens sur le réseau) (si ca ce n'est pas moralement limite déja..)
-
pas forcément.
tu peux tres bien faire du filtrage autrement que par proxy, et donc filtrer a un niveau plus bas (que le surf)
…/...
qqun peut il me dire quelle est l'utilité d'avoir dans un fichier access.log, les requêtes commencant par "https://" ?Effectivement c'est là question qu'il faut se poser au départ: "quels sont mes besoins ?" car la solution est parfois dictée par ceux-ci.
En fonction de règlementation locale, nationale ou autre, tu peux être par exemple contraint, si tu fournis un accès internet publique, de pouvoir dire qui a accédé à quel site et quand. C'est un sujet très sensible, surtout en ce moment 8)
Et il peut t'être demandé cette information plusieurs mois (années) en arrière.Si tel est l'objectif (pure supputation de ma part), alors il est préférable de:
-
identifier les utilisateurs, individuellement, au niveau proxy
-
filtrer les URL au niveau proxy
-
conserver les logs du proxy
En cas d'utilisation d'un portail captif, il est alors souhaitable, pour le confort de l'utilisateur, de passer son identifiant "portail" vers le proxy.
Mais c'est juste un exemple basé sur une supposition.
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. -
-
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 DNSdans 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
-
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"
-
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.
-> 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 :Pet 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 surfdonc 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…
-
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
-
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.
-
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 rechercheset 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)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 rejouableelle contient les parametres en clair, et en plus elle est rejouable
donc non, la confidentialité vient clairement de sauter
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 -
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 sauterAs-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 blacklisteset 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.
-
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 -
-
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).
-
-
j'agréé
je n'avais point lu cette doc
méa maxima culpa
-
concernant le DNS, tu n'as qu 'a m'écrire
-
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.
-
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 -
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.
-
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).
-
@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
-
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....
-
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 ???
-
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. -
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 ;)
-
-
je rejoins l'avis de JDH
encore une fois, je réhitère ma position, (chris) il n' a jamais été question d'avoir une blackliste "mégapuissante"
–
je ne pointe simplement le fait que le filtrage par DNS, est (a mes yeux) LA solution idéale pour filtrer des destinations bien précises
et étoffer le tout avec les blacklistes umbrella
je prend un exemple de base : le torrent
et bien moi, j'adore prendre les sites (non bloqués) qui recencent une 60e de sites de torrents,
et tous les ouvrir un par un dans les onglets de mon navigateur, pour voir que oui, sur les 60 j'en ai deux ou 3 a bloquer à la mainet que les autres sont pré-inclus dans la BL, sans que j'aie quoi que ce soit a faire
c'est un reel plaisir de faire tomber les trackers torrent, chose pas forcement gérable sur un proxy
par ailleurs, j'attire l'attention sur le fait que les pages de blocages Opendns, peuvent elle aussi dans pfsense, faire l'objet d'un empoisonnement
a leur tour, qui peut être géré sur un serveur web par un virtualhost adapatéen conséquence la solution est brandée, gratuite, performante et DEPORTEE
par ailleurs sa gestion est CENTRALISEE, en cas de loadbalancing, il suffit d'ouvrir un compte par ligne..
et le service fournit par ailleurs de bonnes stats DNS.
donc compte tenu que tout est contournable, je me permet de comparer les solutions avec des + et des -
et pour moi cette solution à des + bien interessants@chris > Oui cette solution est bien a mes yeux assimilable a un filtrage
sauf que oui, je te confirme, de la vue du réseau tu n'as que des CONNECTS
et pas de rejetspuisque quoi qqu'il arrive la requête aboutit soit sur la bonne IP, soit sur une IP frauduleuse.
--
tu me diras, qu'est ce qui empêche un mec de faire un nslookup depuis une connexion 4G et de revenir sur le réseau en accès direct sans domaine?
je te répondrais que 95% des sites, sont soit mutualisés, soit protégés, soit CDN-isés, soit autrechose-isés, et donc
oui, il y a bien toujours 2% de jusqu'au boutistes, et 5% d'adresses spécifiques
-> Ce n'est pas ce que recherche un ISP, WISP, Mini ISP
-> Ce qu''il cherche c'est mettre a terre une tendance, un mouvement-> si tu fermes la BL torrent, et que tu fermes les BL Webproxies, webVPN etc, je te garantis que cette ssolution te permet de n'avoir plus que une ou deux machines sur les 400 qui encore et toujours arrivent a te fare du torrent.
par contre je tee confirme bien qu'un domaine "filtré" lorsqu'il est SSL, (filtré DNS), te renvoie une belle erreur de certificat (puisqu'il pointe sur le serveur WEB de refus brandé), que lorsque l'utilisateur va forcer, apparaiitra la page de filtrage.
--
d'après l'entretien que j'avais eu avec le commercial umbrella, si tu distribues en DHCP directement les IP externes DNS, tu peux gérer les origines
et donc avoir des policies en fonction des hoteset donc fournir des services a plusieurs vitesses
--
par contre dans mes souvenirs c'est assez pas donné
-> Uniquement a considérer pour les PME, de l'ordre il me semble de 3 a 5€ par poste (je me rappelle plus)
-
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.les deux solutions peuvent être complémentaires ou indépendantes
cela vient du besoin de filtrage que tu as, pour un filtrage généraliste, ou basé sur quelques domaines précis, ou hyper thématique, umbrella peut tres bien faire le JOB
et comme dit plus haut, cette technique ne se contente pas du SURF, elle est multi proto
tu ne veux plus "dl.free.fr" sur tes reseaux, tu le mets dans le système, ca redescend sur tous les réseaux gérés en 20min
et en 20min tu as des blocages autant WEB, que FTP
mais OUI, une fois encore, pour un blocage plus puissant il est impératif de: soit bloquer par proxy en sus
soit bloquer le bloc IP de dl.free.fr (pool serveur) en dur dans le FW avec une reglela tu es tranquile
mais pourtant, ta solution DNS, t aura déja permis de mettre a terre les usages de 95% des usagers.
-
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.il s'agit bien du post que tu as déterré.
je peux t en parler plus si tu le veuxje t'exhorte à ouvrir ton esprit cette solution apporte de nombreux avantages
par ailleurs n'oublie pas que nous n'avons pas les mêmes prérogatives, toi tu es orienté "Entreprise, filtrage salarié, tracage légal, tracage patronal, contre attaque à oisiveté employés au travail sur un réseau homogène machine, et homogene usages/flux (usages textes / usages métiers)"
et moi
"réseau commercial usagers, tracage legal, nécéssité de rester le moins restrictif possible, obligation de faire respecter mon reglement interrieur, de proteger ma qualité de service, de traquer les abus, sur un réseau hétérogene machine, et hétérogene usages/flux"
-
et comme dit plus haut, cette technique ne se contente pas du SURF, elle est multi proto
C'est une question de lecture ;), le verre à moitié plein etc….
Ta vision est:
- cette technique ne se contente pas du surf, elle est multi protocole ;DLa mienne est:
- cette technique n'offre aucun contrôle ni aucune souplesse en terme de protocole car les adresses IP associées au FQDN ne sont plus joignables quel que soit le protocole >:(tu ne veux plus "dl.free.fr" sur tes reseaux, tu le mets dans le système, ca redescend sur tous les réseaux gérés en 20min
peut-on discuter techniquement de ce que "ça descend" veut dire ?
qui résout quoi en terme de DNS pour que ça fonctionne ?soit bloquer le bloc IP de dl.free.fr (pool serveur) en dur dans le FW avec une regle
:o la seule raison pour laquelle je m'autorise à introduire temporairement ce genre de règle au niveau d'un firewall, c'est lorsque je mets en œuvre fail2ban :-\
je ne pointe simplement le fait que le filtrage par DNS, est (a mes yeux) LA solution idéale pour filtrer des destinations bien précises
Soit mais la préconisation forte, telle que tu la fais, de ce genre de solution devrait s'accompagner à minima de beaucoup plus de précautions sur ce que ça fait vraiment et quels en sont les effets de bord.
Ecrire comme tu le fais dans ce post
Je vous déconseille squidguard.
gerer une blackliste, ce n 'est pas votre metier.
infliger a votre proxy de lire une blackliste a chaque requete, c'est dommage
par ailleurs, ce n'est pas tres scalable, et plus la lliste grossit plus le surf devient lent
seul un bloquage DNS, vous permettra de bloquer par thematiques.avec en plus des arguments très discutables, si on regarde les aspects techniques de près, me semble un peu biaisé (j'avoue ne pas trop savoir quoi écrire là pour exprimer mon avis sans froisser personne :-[)
D'une manière générale, l'action qui est d'exposer publiquement un DNS dont le contenu ne reflète pas la réalité de l'internet me semble être juste une idée étrange.
Ce n'est pas le principe de RPZ que je remets en cause ici mais le principe de "RPZ as a service" tel que exposé par OpenDNS.
Si tu penses que le "filtrage par DNS" est une bonne solution (ce qui est potentiellement le cas dans certaines situations) alors n'hésite pas une seconde à mettre en œuvre ce mécanisme sur ton propre DNS local avec BIND comme le propose fprigent. Tu peux t'appuyer sur les blacklists de [url=http://www.spamhaus.org/news/article/669/spamhaus-dbl-as-a-response-policy-zone-rpz]Spamhaus par exemple mais au moins ton DNS fonctionne localement et TU contrôles ce qui s'y passe plutôt que de tout envoyer à OpenDNS qui fait bien ce qu'il veut, y compris garder la trace des requêtes que tu fais.Last but not least, si on arrive à discuter du détail technique de l’implémentation de ce truc (quels DNS sont configurés, où, et comment l’utilisateur final bénéficie t-il de ce service (d'un point de vue DNS) ?) , j'ai l'impression que les fonctionnalités qui t'ont été présentées par le commercial de OpenDNS vont se rétrécir, sauf à accepter que tous les clients de ton LAN fassent des requêtes en direct les serveur OpenDNS et dans ce cas, je me demande comment tu résouts les noms "locaux" ???
Je fais cette remarque car comme tu es en parallèle défenseur du proxy en mode transparent, tu comprends bien que la résolution d'URL ne fonctionne pas de la même manière selon le mode de proxy utilisé. Si l’implémentation s'appuie sur l'utilisation du DNS local configuré avec un forwader vers OpenDNS, alors le requeteur aura toujours l'adresse publique de ton DNS, i.e. pas de "filtrage à 2 vitesses" ;) et si DHCP pousse en direct les DNS de OpenDNS coté client, tu pourrais imaginer avoir quelque chose de personnalisé par poste (et non pas pas utilisateur ;)) en espérant que le poste en question ne change pas trop souvent d'adresse (réservation de lease par MAC ?) mais en revanche tu ne sais plus résoudre les noms locaux.Je parle bien sûr ici de la version free de OpenDNS. Umbrella est sensiblement différent.
Bref, je ne partage pas ton engouement pour cette solution qui s'appuie sur un business model qui ne me plait pas beaucoup. Ce doit être mon coté paranoïaque qui rejette systématiquement les FaceBook et autre Google+ et tout ce qui vise à alimenter le BigData de Big Brother ;D ;D ;D