Squid et squidguard plantent.

chris4916

La position défendue par les perfectionnistes du pare-feu est que un pare-feu est un pare-feu et ne devrait rien faire d'autre.
La raison étant qu'une faille de sécurité dans un des composants ajouté pourrait être utilisée pour prendre la main sur le pare-feu et de là créer une brèche…

Ceci étant dit, ça signifie également qu'il n'y a pas de mise en œuvre simple de proxy HTTP en mode transparent (sur ce point, ça tombe bien, le mode transparent présente peu d'avantages et pleins de problèmes >:() mais il en va de même pour le portail captif.
Pour faire simple, dès lors que tu as accepté l'idée que le FW ne rempli que ce rôle, il faut construire ton infrastructure avec des services internes et des services en DMZ sur des machines dédiées.

Une fois l'architecture définie et validée, il peut y avoir une phase d'optimisation à grands coups de VM mais c'est une autre histoire ;)

Mon point de vue personnel est que cette position de principe est parfaitement correcte si l'objectif premier est "la sécurité à n'importe quel prix". Dans ce cas, il n'y a pas de compromis et le surcout en terme de machine, taches administratives, monitoring etc ne doivent pas impacter le design de l'infrastructure.

Dans la vraie vie, pour la plupart des TPE, quelques PME et la plupart des utilisation SoHo, ce n'est juste pas réaliste.
La solution n'est alors peut-être pas pfSense, qui est par ailleurs excellent en tant que pare-feu, mais une solution de type "all-in-one". Le point étant de bien comprendre que le niveau de sécurité offert est moindre 8)

chris4916

@crashoux:

Je me demander si je pourrais pas mettre ds serveurs en série? un pfsense pour le portail captif précéder d'un ipfire pour l'url filter? est-ce que ca peu fonctionner?

Peut-être mais bof… quel intérêt ?
Qui a déployer 2 serveurs, pourquoi ne pas laisser pfSense et mettre un portail captif sur un serveur dédié à cet usage ?
Ce n'est pas aussi simple pour le proxy en mode transparent à cause des aspects "route par défaut" et le fait que le proxy soit justement transparent, ce qui interdit de le mettre sur le LAN sauf à gérer des routes très spécifiques sur l'équipent qui fait office de route par défaut (très souvent le FW) mais en mettant le proxy en mode transparent derrière la solution qui fait office de portail captif, ça doit le faire...

Florian22

@chris4916:

La position défendue par les perfectionnistes du pare-feu est que un pare-feu est un pare-feu et ne devrait rien faire d'autre.

la position est défendue par les gens qui respectent les rêgles de l'art, et qui cloisonnent les services

Un routeur n'est pas un serveur d'authentification (radius)
Un routeur n'est pas un mandataire

@chris4916:

Ceci étant dit, ça signifie également qu'il n'y a pas de mise en œuvre simple de proxy HTTP en mode transparent (sur ce point, ça tombe bien, le mode transparent présente peu d'avantages et pleins de problèmes

ah oui? développez svp. je ne suis pas d'accord avec vous

@chris4916:

mais il en va de même pour le portail captif.

ah oui? développez svp, je ne suis pas d'accord avec vous - encore -

@chris4916:

Pour faire simple, dès lors que tu as accepté l'idée que le FW ne rempli que ce rôle, il faut construire ton infrastructure avec des services internes et des services en DMZ sur des machines dédiées.

des services en DMZ sur une machine dédiée au proxying inverse : EXEMPLE / NGINX

@chris4916:

Une fois l'architecture définie et validée, il peut y avoir une phase d'optimisation à grands coups de VM mais c'est une autre histoire ;)

Tout va dépendre de ce que vous mettrez sur vos VM. le procésus de routage et de répartition de charge est a éxclure.
a part du mail / du web / du sql => je ne vois rien d'autre a y mettre

=> Nous passons trop notre temps a voir des gens qui passent leur vie a bricoler un pfsense sur des ESXI ou des proxmox
ces gens généralement ne comprennent pas que ce n'est pas concu pour, et qu'il y a beaucoup de bricolage a la main a faire pour avoir un
résultat probant, qui peut a tout moment (en fonction de l'hôte de virtualisation) re-lacher

@chris4916:

Dans la vraie vie, pour la plupart des TPE, quelques PME et la plupart des utilisation SoHo, ce n'est juste pas réaliste.

si c'est tres realiste, il faut juste que ces interlocuteurs (TPE/PME, cabinets, etc) AIENT un interlocuteur pragmatique et compétant

=> Je vous renvoie vers la page qui décrit le sizing de Pfsense
=> La plus part de ces structures ont des besoins de routage inferieurs a un demi giga (et surtout en exterieur)

=> Vous pouvez envisager que des vieux nanards de PC qui ont eu MS VISTA (celeron, ou dual AMD) peuvent avoir une deuxieme vie
dans une chambre technique, ou ils pourront aisaiement, servir de :

Proxy mail
Pfsense
Serveur de partage SMB
Intranet / sous intranet
iPBX (asterisk)
Serveur d'impréssion
Serveur de BDD SQL

etc etc etc

–> On ne le dira jamais assez : Mieux vaut cloisonner, éclater, diviser, "grapper", que tout mutualiser, faire cohabiter
--> Et je ne parle même pas du "syndrôme de la panne générale" (si typique, du all in one)

--> Mais juste d'une affaire de performance globale. et d'isolation des ressources et des services. => de tolérance de panne ! => de disponibilité métier...

Votre point de vue personnel ne fait état que d'une affaire de "sécurité"
je pense que vous simplifiez la position des "perfectionnistes"

=> Ce n'est pas une affaire de sécurité absolument

J'ai déja vu des structures, ou le PC de la secretaire était connecté au NET, (PC Windows)
et que les autres PC etaient en réseau, avec pour passerelle le PC de la secretaire

autrement dit routeur
(avec démons windows a la con, de serveur DHCP, et tout le tralala)

sur ce PC, tournait un démon mail windows

tous les autres PC avaient leur outlook en smtp sur le PC de la secretaire.

dans le log du démon sur le PC de la secretaire, on pouvait lire les mails en QUEUE.
au niveau réseau, tout le trafic ethernet passait par ce poste

-> Tout marchait niquel

---> Il n'en reste pas moins que c'est de la merde. et que celui qui a fait ca, meriterait une pendaison haut et court immédiatement

bien cordialmeent

Florian22

le fait que le proxy soit justement transparent, ce qui interdit de le mettre sur le LAN sauf à gérer des routes très spécifiques sur l'équipent qui fait office de route par défaut (très souvent le FW) mais en mettant le proxy en mode transparent derrière la solution qui fait office de portail captif, ça doit le faire…

Pouvez vous svp arrêter de dire des anneries,
danke

1/ il est acceptable de laisser PF gerer le portail captif
=> donc stop pas de conseils en externalisation

2/ il est possible de mettre sur la meme interf que le portail (LAN) squid en transparent

==> donc merci de stopper le moulin a conneries

3/ "Serveur en série" ca veut rien dire (on est pas en electricité)
=> Ne répondez pas a une question malformée, sous peine de produire une réponse malformée

crashoux

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

Florian22

envoyez moi svp la capture ecran des packages installés

envoyez la ici
on reprend tout depuis le début

a 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

crashoux

j'ai un rdv ce matin je vous transmet tout dans l’après-midi.

Merci de votre aide d'avance ^^

Florian22

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 prod

je reste a dispo

chris4916

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

Florian22

@chris4916:

:) 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 sur

@chris4916:

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

on est synchrone

@chris4916:

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

@chris4916:

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

@chris4916:

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 parler

@chris4916:

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.

[/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 local

il 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

@chris4916:

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

jdh

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.

chris4916

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

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

chris4916

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

jdh

@chris4916 :

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

ccnet

Je souscris pleinement. Organisation, méthode et architecture sont des composants indissociables pour être efficace.

chris4916

@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 :-[

crashoux

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

chris4916

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

Un 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 ?

Florian22

@chris4916:

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

chris4916

@Florian22:

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.