Squid et squidguard plantent.

chris4916

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 ;)

Florian22

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 main

et 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 rejets

puisque 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 hotes

et 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)

Florian22

@chris4916:

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 regle

la tu es tranquile

mais pourtant, ta solution DNS, t aura déja permis de mettre a terre les usages de 95% des usagers.

Florian22

@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.

il s'agit bien du post que tu as déterré.
je peux t en parler plus si tu le veux

je 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"

chris4916

@Florian22:

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 ;D

La 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

chris4916

Comme je n'aime pas éditer mes posts :-[ voici un lien vers un peu de lecture intéressante:
[url=http://www.sans.org/reading-room/whitepapers/dns/implementation-dns-rpz-malware-phishing-defence-34535]http://www.sans.org/reading-room/whitepapers/dns/implementation-dns-rpz-malware-phishing-defence-34535

Florian22

en ce qui concerne tes questions clients LAN /resolution

les clients ne voient jamais l'annuaire exterieur, lorsquils font des lookups, ils questionnent leur passerelle

qui a son tour questionnera soit ODNS directement, soit un relai local, qui le fera

par "redescendre" j'entends:

L'émission de l'ordre sur ODNS
La prise en compte par ODNS
l'expiration des relais (car ils ne font pas de lookup au niveau supérieur a chaque reprise), et la mise à jour dans les relais

-> ce délai de prise en compte sur un LAN (qui dispose donc d'un relai local de référence) est d'environ 15 à 35 minutes

voir meme l'expiration au niveau client, qui peut etre plus longue

– Encore une fois, d'un aspect "ISP" --

1/ c'est un bon mécanisme qui consomme peu de resources, s'administre centralement
2/ ca ne nécéssite pas de gestion de blacklistes, et permet les blocages individuels de destinations

3/ on s 'en fou totalement de ce que ODNS collecte, car cela reste des infos qui ont pour origine les IP des intercos Fibre/cable/ou dsl
4/ seule la passerelle sait

5/ je ne vois pas ou est le problème de restreindre et obliger un utilisateur a utiliser le DNS de l operateur (la passerelle)
99.9% des utilisateurs n'ont pas de problème avec cela

6/ oui je te confirme bien, du moins chez moi, un user = une machine, (auth basée sur la machine)
et non sur des identifiants, orientés multi-machines

7/ je suis d'accord avec toi sur le fait que distribuer les IP odns directement au client peut etre chiant (local)
encore que, a verifier si umbrella ne prend pas cela deja en compte je l ignore

8/ moi le seul traitement qque je fais sur une page de filtrage (débrandée Opendns par un serveur web fake via les relais dns)
c'est via un scripting sur la page de filtrage via le referrer (qui contient l'url en question) et va faire une journalisation avec l'IP-via, le referrer, la date l heure

apres , pour finir, dans un env de type entreprise, je ferai pas ca moi

je bloquerai tout
et je passerai par la constitution au fil de l'eau d'une WL

je le ferai sur deux axes, le premier via le proxy, (constitution WL, et deny-all par defaut)
et dans un deuxieme axe, par DNS

comme ca, je sais que le Kimsufi de toto, ne servira pas a faire du tunelling ssh parce que j'ignore sa destination

=> tu fermes tout, en proxy, et via DNS pour confirmer
=> tu ouvres tes besoins

la t'es sur d'être pepere

par ailleurs, il ne faut pas oublier que les dns du proxy peuvent etre différents et pas forcement odns

tu peux donc avoir une strategie HTTPs

et une strategie couches inferieures

chris4916

@Florian22:

6/ oui je te confirme bien, du moins chez moi, un user = une machine, (auth basée sur la machine)
et non sur des identifiants, orientés multi-machines

Ce qui explique en partie nos différence de vue ;)

Pour ce qui est de gérer des whiteliste dans le cas d'un déploiement en entreprise, ça dépend bien sur de la taille de l'entreprise mais c'est rapidement ingérable et donc irréaliste sauf cas particuliers avec un usage très limité du web.