Pourquoi pas de proxy sur le firewall

chris4916

Excellente initiative 8)

Au moins ça permettra de discuter ici de ce sujet qui me semble important sans polluer d'autres posts.

Sur l'aspect sécurité et point d'attaque potentiel du FW dès lors que celui-ci embarque un service "ouvert", je suis tout à fait convaincu.
Squid fait partie de ces services qui écoutent, même si uniquement (normalement) sur le LAN ou les DMZ, et donc présente un risque potentiel. Il en va de même pour le portail captif d'ailleurs ;-)

C'est LE point que je mettais en avant ici.
Ceci étant, l'impact de FREAK sur Squid… ??? mais je suis totalement d'accord qu'il ne s'agit que d'un exemple parmi d'autres. Dès lors qu'il y a un service exposé au niveau de FW, il y a un risque.

Ce qui me fait réagir (peut-être de manière excessive :-[ ), c'est la systématisation de la réponse "pas de proxy sur pfSense !" avec des arguments différents (performance, package, sécurité) alors que je ne vois pas de message qui dit fortement et systématiquement "pas de portail captif", "pas de DNS"

L'aspect [b]espace disque est parfaitement valide, surtout si l’installation a été faite avec le partitionnement par défaut ::) et qu'il n'y a pas de rsyslog (petit point qui à l'air stupide mais à cause de clog, l'absence de rsyslog rend pfsense incapable de remonter dans des log un peu anciens si il faut investiguer). Quand aux composants qui n'utilisent pas clog… :-X

ccnet

Ce qui me fait réagir (peut-être de manière excessive :-[ ), c'est la systématisation de la réponse "pas de proxy sur pfSense !" avec des arguments différents (performance, package, sécurité) alors que je ne vois pas de message qui dit fortement et systématiquement "pas de portail captif", "pas de DNS"[/quote]
Dans un premier temps j'ai étendu le point de vue à l'ensemble des packages (Squid et tous les autres) que j'ai séparé des services natifs de Pfsense. Ceci parce les fonctions natives sont développées par l'équipe Pfsense.
Néanmoins on pourrait aussi avoir une réflexion sur les services qui ne devraient pas être fournis par le firewall, mais par un système distinct, même si les éditeurs les proposent.

chris4916

Je pense que nous sommes tout à fait en phase en ce qui concerne le "principe": le pare-feu doit assurer une fonction de pare-feu uniquement si on vise un système aussi stable et sécurisé que possible.

Je suis également d'accord que le fait que lorsqu'on évoque un package et non pas une fonctionnalité "intégrée", le risque est encore plus grand car les équipes de développement ne sont pas les mêmes et donc les cycles de développement/validation différents.

Mais dans ce cas, il faut systématiquement ne déployer que les fonctionnalités minimum. Et ça devient compliqué pour l'entreprise qui veut déployer pfSense comme son interface avec internet car cette interface ne fait rien d'autre que du pare-feu (ce qui est déjà bien) et les autres fonctionnalités sont difficiles à mettre en œuvre si il n'y a pas de ressource IT compétente (oui, je suis d'accord, il faut encore plus de compétence pour déployer un package "proprement" en comprenant bien les impacts éventuels :P)

Mais du coup, pour tenir cette position, il faut un disclaimer bien visible qui explique tous ces add-ons (et pas seulement le proxy) sont risqués, affaiblissent le système et ne sont pas destinés à ceux qui n'ont pas une compréhension fine du fonctionnement de la machine. Et même dans ce cas c'est limite.

Bref, un truc qui dit: "comme pfSense vise l'excellence du pare-feu, tout ce qui n'est pas strictement du ressort du filtrage de paquet doit être exclu"

ça le fait mais ça commence à devenir compliqué car il va y en avoir des questions sur la route par défaut à pousser depuis le serveur DHCP externe à pfSense qui va distribuer une route par défaut qui elle-même ne peut pas être pfSense si on s'en tient au principe de base évoqué ci-dessus.

Je suppose que c'est même pour cette raison que les développeurs de pfSense acceptent un compromis à la règle stricte du "pare-feu sinon rien" en ajoutant des services supplémentaires. Mais où est la limite et quel niveau de risque cela fait-il courir ?

J'en reviens à la question que je soulevais il y a quelques jours: pourquoi le portail captif serait acceptable et pas le proxy ? tous les deux écoutent sur un port (le portail captif s'appuie même sur un service HTTP qui peut bien sûr présenter des faiblesses) et la problématique du profil de charge n'en n'est pas une. Il s'agit bien là de sécurité et de stabilité du code.

Ou alors il faut proposer une vision de pfSense avec différents niveaux de service (joke):
1 - le pare-feu qui vise l'excellence dans cette fonction: c'est une paire de pfSense en filtrage de paquet uniquement et CARP
2 - le pare-feu un peu moins stable car il fourni des services annexes mais ça reste acceptable parce développé par la même équipe et validé
3 - le pare-feu qui va un jour se planter car des packages (bien que proposés par l'interface de pfSense) ont été installés et ça affaibli le système.

et je ne parle même pas du niveau 4 qui consiste à installer un pare-feu et des composants hors pfSense sur le système ;D ;D ;D

jdh

(étonnant de lire ici des choses dont le contraire est écrit ailleurs !)

Doit être inclus dans le firewall

tout ce qui est nécessaire,
rien que ce qui est nécéessaire.

Ce qui est package n'est nullement nécessaire et même contraire à une utilisation raisonnée.
ccnet ne souligne pas la 'dangerosité' de Squid qui monopolise des ressources au risque que le firewall fonctionne incorrectement : mémoire, charge proc, charge disque.

Mais pfSense peut fournir le service dhcp car cela occupe très peu un firewall !
et ainsi de suite.

chris4916

@jdh:

Doit être inclus dans le firewall

tout ce qui est nécessaire,

rien que ce qui est nécéessaire.

Si c'est pour faire du firewalling, alors c'est du filtrage de packet uniquement ;) ou alors il faut discuter un peu de ce que nécessaire couvre en terme de foncitonnalité.

Ce qui est package n'est nullement nécessaire et même contraire à une utilisation raisonnée.
ccnet ne souligne pas la 'dangerosité' de Squid qui monopolise des ressources au risque que le firewall fonctionne incorrectement : mémoire, charge proc, charge disque.

parce que ce n'est pas en soit un vrai problème.
Ce point n'est valide que dans le cas d'une machine mal dimensionnée:

la fonction de filtrage de paquet ne fait pratiquement pas d'accès disque donc pas de risque de conflit avec par exemple un proxy qui écrit/lit du cache
la consommation mémoire est assez faible pour la fonction de filtrage de paquet.
l’utilisation du processeur dépend de la bande passante sur l'interface la moins rapide

En terme de ressource, un firewall qui ne fait que du firewall, ça pourrait presque (c'est limite une taquinerie :-X ) tourner sur un Raspberry Pi.
De ce fait, agiter le drapeau rouge de "pas de proxy car le profil de charge n'est pas compatible" est une vision un peu biaisée que je ne partage pas car avec n'importe quelle machine assez basique, on est généralement à l'abri de ces problématiques. Il y en a plein d'autres cependant :)
Je ne dis pas qu'il faut ignorer les aspects hardware mais ce n'est souvent pas un problème.

Mais pfSense peut fournir le service dhcp car cela occupe très peu un firewall !
et ainsi de suite.

donc ton point de vue est uniquement relatif à la charge…

Je me rends bien compte qu'il y a quelques membres dans cette section du forum un peu irrités par ma position mais je ne peux pas m'empêcher de réagir à des propos (pas nécessairement les tiens) qui ne sont pas étayés.
Pas étonnant que comme le dit ccnet, "le message ne passe pas" si l'argumentaire n'est pas clair et soutenable.

De mon point de vue et à défaut d’information différente, il n'y a que les aspects:

sécurité (à cause de services qui écouteraient sur des ports réseau)
stabilité (en cas de déploiement de package, non développés par le core-team)
complexité d'administration

qui justifieraient de cantonner le boîtier à la frontière entre le LAN et le WAN à la fonction de filtrage de paquet.

Avec cette vision, je suis donc en désaccord, en quelque sorte, avec les voix qui disent "surtout pas de proxy sur le firewall" mais qui ne s'offusquent pas qu'il y a un portail captif ou un VPN. Et je ne pense pas avoir jamais écrit autre chose ;)

Pour aller plus loin, mon avis est que rien n'est systématiquement à prohiber dès lors que c'est fait en connaissance ce cause.
Pour décrire ma perception des les 2 extrêmes:

un débutant devrait vraiment se cantonner à ne faire que du filtrage de paquet
le guru qui maîtrise bien tous les composants peu sans trop de risques déployer sur sa gateway par défaut les composants qui y ont naturellement leur place si on accepte des compromis en terme de sécurité.

La vraie difficulté que vous ne percevez pas tout le temps me semble t-il pas, c'est que la gars qui se pointe sur ce forum en disant "je n'arrive pas à accéder à internet au travers de pfSense" n'a aucune idée ou alors qu'un idée très vague de ce qu'est une route par défaut, DHCP et autres services réseau.

Avec une position jusqu’au-boutiste qui dit "le firewall ne fait QUE du firewall" (point que je partage), l'architecture résultante est compliquée pour le commun des mortels.

Il faut customiser tout un tas de services, à commencer par DHCP
tous les services tournés vers l’extérieur doivent se trouver sur une ou plusieurs DMZ
il y a potentiellement des problèmes de DNS si ces services doivent accéder à la fois des serveurs sur le LAN et à l'extérieur.

Rien d'insurmontable pour un technicien IT mais la plupart des personnes qui viennent demander de l'aide ici n'ont pas ce profil et du coup ne comprennent pas la remarque (que je trouve lapidaire): "pas de proxy sur le firewall".

Pour conclure ce long post, cette remarque est d'autant moins bien comprise et assimilée par les newbies que partout dans le forum de pfSense (dans la section anglaise ;) ) il y a des posts, y compris de la part des sponsors de pfSense qui discutent de packages, y compris Squid.
Il suffit de lire la section hardware pour voir que beaucoup de sujets relatifs au dimensionnement incluent Squid dans les profils de charge.
Ou alors il faut aller voir chez NetGate.

Tout ça pour essayer d'expliquer que juste dire "le proxy sur le FW c'est le mal" sans autre information, c'est un peu limite, AMHA.

Fort heureusement, ccnet a créé un fil pour discuter de ce sujet plus en détail ;-)

jackos

Bonjour,
je suis pas un expert, cela pourra vous paraître simple :

utiliser les service dhcp, dns forwarder et ntp qui sont inclus par défaut, est ce raisonnable? (jdh a en partie répondu sur le dhcp)
et ce qui est des roadwarrior OpenVpn?

jdh

Evidemment que le problème de charge est l'élément clé !!!
Parce que le filtrage de paquet suppose de réagir dans les temps : on parle en ms.

Le passage par un proxy peut se mesurer en secondes : entre l'analyse de l'url, voire d'une regexp, entre l'authentification, entre la recherche dans le cache (généralement configuré trop gros), la charge cpu et mémoire peut avoir un impact sur le temps de filtrage paquet !

Cet argument est clair et facile à entendre.
Alors pour moi, ça suffit : pas de proxy sur le firewall.
J'en ai un peu marre de devoir toujours rappeler ce basic qu'il n'est pas nécessaire d'allonger.
Je regrette que, régulièrement, le sujet soit remis sur le tapis, y compris par des gens sérieux !

Donc les packages sont intéressants … mais seulement culturellement parlant !
Ils sont à éviter fortement.

ccnet

Mon idée est de faire, une fois pour toute, un sort à cette (mauvaise) idée qui consiste à mettre un proxy sur le firewall. Et d'une façon générale de traiter la dangerosité des packages. Ils sont des curiosités intéressantes (culturelles convient bien aussi) mais incompatibles avec un usage sérieux (par là j’entends sûr) du firewall d'entreprise. Pour cela répertorier les raisons objectives, techniques et rationnelles pour lesquelles ces pratiques ne sont pas recommandables me semble utile.
Ceci afin de ne plus y revenir à longueur de post sur le forum.

chris4916

@ccnet:

…Et d'une façon générale de traiter la dangerosité des packages. .../....
Pour cela répertorier les raisons objectives, techniques et rationnelles pour lesquelles ces pratiques ne sont pas recommandables me semble utile.
Ceci afin de ne plus y revenir à longueur de post sur le forum.

Je partage exactement cet objectif, à savoir répertorier les raisons objectives pour lesquelles un package présente plus de risque qu'une fonctionnalité "intégrée".

Et pour le moment, la seule raison objective que je vois (et je ne prétends pas qu'elle n'est pas suffisante), c'est que le développement n'est pas assuré par le core-team, avec donc un risque que le mode de fonctionnement, à un instant donné, du package ne soit pas compatible avec celui de pfSense.

Si nous sommes d'accord sur la différenciation package vs. intégré en terme de risque du point de vue fiabilité du code, penchons nous sur les autres points évoqués et essayons de présenter des arguments pour expliquer pourquoi c'est acceptable ou pas de le(s) faire tourner sur pfSense.

j'avoue ne pas comprendre l'argumentaire de jdh

Evidemment que le problème de charge est l'élément clé !!!
Parce que le filtrage de paquet suppose de réagir dans les temps : on parle en ms.

Le passage par un proxy peut se mesurer en secondes : entre l'analyse de l'url, voire d'une regexp, entre l'authentification, entre la recherche dans le cache (généralement configuré trop gros), la charge cpu et mémoire peut avoir un impact sur le temps de filtrage paquet !

Il faut m'expliquer car ça me laisse perplexe.

je suis d'accord qu'un cache trop gros, en plus d'être inefficace, consomme beaucoup trop de mémoire
je suis d'accord que le temps de cycle du service proxy n'est pas le même

mais en quoi une authentification qui peut prendre quelques millisecondes ou le parcours de l'index du cache va impacter d'un point de vue performance le filtrage de packet sous prétexte que c'est un proxy. Est-ce que le proxy va générer, plus que certains autres programmes susceptibles de tourner sur ce type de machine plus de swap et d'I/O wait et du swap (ce qui est vraiment pénalisant en terme de performance)

La charge d'un serveur VPN, si il y a beaucoup de clients, peut être aussi pénalisante que celle d'un proxy (l’encryption consomme beaucoup de ressources) mais, sauf cas particulier d'un couple CPU/mémoire mal dimensionné, il n'y a pas de risque dans la grande majorité des cas. (je ne parle ici bien sûr que des aspects purement performance)

J'invite ceux qui sont persuadés du contraire à lire attentivement le document de sizing publié par pfSense. Bien sur qu'il faut s'assurer que le hardware utilisé convient mais la config minimum est quand même très basique et la plate-forme full-featured (laquelle est livrée avec pfSense préinstallé, y compris le proxy HTTP :o) est basée sur un Atom (8 cœurs certes mais ça reste une assez petite machine).

Dans le lien de sizing, vous noterez avec j'en suis certain beaucoup d'intérêt la mise en garde à propos du service VPN (pour les fonctionnalités intégrées) et à propos de Snort pour les packages. Pas de point particulier lié à la charge du proxy HTTP.

Je quote ici ce lien, pour ceux qui ont la flemme de tout lire ;)

Feature Considerations

Most features do not factor into hardware sizing, although a few will have a significant impact on hardware utilization:

VPN - Heavy use of any of the VPN services included in the pfSense software will increase CPU requirements. Encrypting and decrypting traffic is CPU intensive. The number of connections is much less of a concern than the throughput required. AES-NI acceleration of IPsec significantly reduces CPU requirements on platforms that support it.

Captive Portal - While the primary concern is typically throughput, environments with hundreds of simultaneous captive portal users (of which there are many) will require slightly more CPU power than recommended above.

Large State Tables - State table entries require about 1 KB of RAM each. The default state table size is calculated based on 10% of the available RAM in the firewall. For example, a firewall with 1 GB of RAM will default to 100,000 states which when full would use about 100 MB of RAM. For large environments requiring state tables with several hundred thousand connections, or millions of connections, ensure adequate RAM is available.

Packages - Some of the packages increase RAM requirements significantly. Snort and ntop are two that should not be installed on a system with less than 1GB RAM.

et ce n'est pas moi qui le dit mais M. pfSense lui même :P

Attention: ne me faites pas dire que je prétends que la charge engendrée par le proxy doit être négligée :-X
Je dis que celle-ci doit être prise en compte (spécialement et avec attention en ce qui concerne les aspects I/O disque) mais qu'une fois de sizing effectué, ce n'est pas la charge du proxy qui va perturber le fonctionnement du firewall, lequel dans sa fonction de base, est très peu consommateur.

jdh

Je regrette d'avoir encore à y revenir parce qu'il suffit d'avoir simplement lu les docs, d'avoir installé une fois un pack complet 'Squid/SquidGuard/Blacklist de Toulouse/LightSquid' sur un modeste serveur Debian pour voir l'évidence.

Il est parfaitement clair que

les ressources mémoire demandées par Squid/SquidGuard/la blacklist de Toulouse sont très importantes : pour un cache de 5 G, avec 100 utilisateurs (20 simultanés), entre 1 G et 2G sont nécessaires
les IO disques fonctionnent pour chercher les objets dans le cache (même si la répartition en 256 répertoires limite le parcours de répertoires)
le cpu est sollicité pour rechercher dans le million de lignes (le fichier compilé domains.db de adult fait 44 Mo et plus d'1 million de lignes)

Il me semble parfaitement évident que cette 'charge' qui permet une réponse acceptable en 1 à 2 secondes peut avoir un impact si, dans le même temps, la machine qui fait firewall doit répondre en moins de 10 ms pour un simple icmp retour (j'observe depuis mon LAN 0,2 ms), et encore plus pour les protocoles TCP (avec ACK) et autres ESP, AH, …

Il est clair qu'il faut privilégier le filtrage à ce qui peut, très largement, être fait par une autre machine, et dans le LAN (ou la DMZ).

Et encore, le job d'ingénieur réseau est de choisir le hardware qui va tenir à la variation de charges et dans le temps.
Pour le VPN, il faudra réfléchir à l'utilisation de carte de cryptage/décryptage hardware qui allège la charge processeur.

(Vous noterez, au passage, que les vendeurs de boitier dit 'UTM' se gardent bien de préciser les processeurs qu'ils utilisent !)

Par ailleurs, et c'est une très bonne raison, la config générée par les interfaces des packages N'EST PAS en accord avec MES besoins.

Mais, surtout, le fond du problème est que ceux qui soutiennent le proxy sur le firewall le font parce qu'ils ne se sentent pas capables de faire autrement, persuadés qu'ils ne seront pas à la hauteur de l'interface web pour configurer les 2 fichiers de conf (squid.conf et squidGuard.conf), et surtout faute d'essais. On y touche qu'une seule fois à l'interface web !

Sur le site d'Ixus, j'ai cotoyé (l'excellent) Franck78 qui a créé pour Ipcop l'interface de sélection dans la blacklist de Toulouse. Il pourrait confirmer que la création directe de squidGuard.conf n'est quand même pas très difficile. La lecture du fichier montre la simplicité de la config.

Pour moi, ca suffit, je n'écrirais plus une ligne.
Et je regrette cette prose d'un membre qui tient par ailleurs des raisonnements assez justes, car les ignorants pourraient croire cette hésitation pour vraie.

chris4916

afin de ne pas polluer ce fil, je vais réagir ici aux propos de jdh
@jdh:

@chris4916 : le fil (justement) cité avance LES arguments techniques pour lesquels il ne faut pas mettre un proxy sur un firewall. Il est très regrettable que tu t'obstines à insérer partout TES doutes (et ton incompréhension) et notamment sur des fils de non spécialistes. Il faut arrêter ce point de vue : tu prends une Debian, tu installes Squid + SquidGuard, et tu observes le besoin mémoire en fonction de la taille de cache !

Il y a un incohérence entre un petit matériel qui fait firewall (simplement et efficacement) et un firewall avec proxy qui exigerait d'importantes ressources mémoire pour faire les 2 boulots correctement.

Je critique ces petites distributions qui prétendent que l'on peut tout faire sans rien dire sur les ressources hardware nécessaires ! Marre !

Oui je reviens une fois de plus sur ce sujet dans le cadre d'un éventuel déploiement avec une solution autre que pfSense car le seul argument valide, auquel je souscris pleinement, est celui de ccnet qui dit:
@ccnet:

Mon idée est de faire, une fois pour toute, un sort à cette (mauvaise) idée qui consiste à mettre un proxy sur le firewall. Et d'une façon générale de traiter la dangerosité des packages. Ils sont des curiosités intéressantes (culturelles convient bien aussi) mais incompatibles avec un usage sérieux (par là j’entends sûr) du firewall d'entreprise.

Nous sommes d'accord, les packages de pfSense sont mal gérés. Le proxy est un package => pas de proxy sur pfSense.

Le deuxième point auquel je souscris, c'est que le déploiement d'un firewall d'entreprise doit se faire sur un environnement dédié et n'exécuter que la fonction de firewall. Ce qui à mon sens signifie qu'il faut prendre soin de ne pas activer, dans le cas d'un déploiement de pfSense, les fonctions de CA, VPN, account managment etc… et pour être très clair à ce sujet, je trouve beaucoup plus étrange de gérer un CA ou des comptes sur pfSense que d'y faire tourner un proxy HTTP 8)

Ceci étant dit, ce que tu vois comme une obstination de ma part (ce que je déplore) est le résultat de mon expérience dans le domaine. La recherche de la solution idéale qui consiste à ne déployer que les designs intellectuellement parfaits trouve rapidement sa limite dans la vraie vie, et ce même en entreprise si la complexité d'opération du design parfait introduit un risque plus important que ce que le design vise à couvrir(1).
Pour une PME, un SOHO ou, dans le cas du fil en question, un déploiement d'une infrastructure familiale, une solution "all-in-one", même si intellectuellement pas parfaite, et donc avec quelques risques, est parfois préférable au design théorique parfait car plus facile à exploiter pour des non-spécialistes.
Au lieu de uniquement critiquer ce que tu appelles "les petites distributions" qui construisent du "all-in-one", pose toi la question de savoir pourquoi et de quel est le marché pour ces distributions.
Essaie également de décrire factuellement quel est le niveau de risque.

Tu sembles également te focaliser sur l'aspect hardware:
@jdh:

Je suis étonné qu'avec cette question, ne soit pas mentionné le hardware prévu !

Il y a un incohérence entre un petit matériel qui fait firewall (simplement et efficacement) et un firewall avec proxy qui exigerait d'importantes ressources mémoire pour faire les 2 boulots correctement.

L'approche de christophefrotignan me semble ici être la bonne: définissons les besoins et le design avant de se poser la question du hardware qui viendra en réponse adaptée à la solution retenue.
Je ne dis pas que le choix du hardware n'est pas important, ni même que la charge d'un proxy est négligeable mais avec la configurations à notre disposition à faible coût, ce n'est jamais un point de blocage mais uniquement une question d'adéquation.

Un proxy HTTP sur une machine dimensionnée pour faire du FW, ça ne marchera pas. Nous sommes d'accord :D mais c'est une manière biaisée de voir le problème 8)
Relis donc mon post ci-dessous à propos du sizing hardware à la suite duquel tu devrais, si tu es cohérent, combattre aussi farouchement ceux qui prétendent déployer un serveur VPN avec pfSense que ceux qui prétendent déployer un proxy…. si le hardware les LE point qui te dérange le plus 8)

(1): pour avoir eu la chance de travailler sur des designs et déploiements d'architectures assez complexes, je peux affirmer qu'une trop grande complexité introduit parfois des process d'opérations qui sont mal appréhendés et qui génèrent au final des problèmes bine plus importants que ceux que le design visait à gérer. Et la notion de complexité est ici toute relative : un cluster qui sera perçu comme simple dans un environnement parce que les opérateurs sont formés et comprennent son fonctionnement pourra être, dans d'autres cas, mal appréhendé et générer des pertes de service et/ou de données.

jdh

C'est très intriguant : quelqu'un qui comprend beaucoup de choses et pourtant tient un discours incohérent !

Dans pfSense, il faut : le fitrage (alias, rules, nat, virtual ip), le routage, les vpn (forcément : où pourrait on mettre cela ailleurs ?), le portail captif, des services basic (dhcp, dns, ntp)
Mais il ne devrait pas y avoir dans pfSense : la gestion de CA, la gestion d'utilisateurs ! Nous somme d'accord ici

Bien évidemment avec une machine survitaminée (proc, mémoire et disque) on peut ajouter le proxy.
Mais est ce qu'il faut faire ? Puisque le travail n'est pas le même (temps de réponse p.e.) et les contraintes (proc, mémoire, disque).

Il est cité le sizing. (quelle histoire)
Le sizing (ful featured) cite 4 appliance : VK-T40E, SG-2440, SG-4860, C2758
La boutique pfSense indique les tarifs : VK-T40E = 449€, SG-2440 = 499€, SG-4860 = 699€, SG-8860 = 999€, et pas de prix pour C2758
Si on regarde les caractéristiques techniques, seule la C2758 est à même de gérer et le firewall et un proxy, mais le prix n'est pas indiqué et je pourrais parier qu'il est supérieur à 1500€ voire 2000€.

Donc, en pratique, on écrit "pas de proxy sur le firewall".
Parce que, en milieu pro, il est bien préférable d'acquérir 2 machines moins puissantes et en faire un cluster de firewall et créer une VM Proxy sur sa plateforme de virtualisation interne, que d'acquérir un 'monstre' qui sera mal utilisé par 2 taches très différentes !
En l'occurence, un firewall dédié et peu puissant est toujours meilleur à un firewall sur gros hardware

Ce qui m'épate, c'est que tu peux comprendre que 'ma' règle n'est pas une vérité absolue mais une vérité pratique, et que tu es juste au boutiste d'une vérité.
Tu n'écrirais pas que l'on peut placer aussi sur le firewall, un serveur mail (et son antispam/antivirus), un serveur de fichier (cifs/smb et/ou ftp), pourtant c'est possible … en thérorie.

Comme disait l'autre, la différence entre la théorie et la pratique ? en théorie, il n'y en a pas, en pratique, si !

J'attends toujours, le résultat d'une expérimentation (que, moi, j'ai fait) sur une Debian + Squid + SquidGuard + Havp. Tu verras que c'est très loin d'être simple à mettre au point, que les besoins sous charge ne sont pas de ceux qu'on laissent sur un firewall !

chris4916

Je ne comprends pas ce qui est incohérent dans mon discours.
Peut-être que le problème se situe à ce niveau ??? N'hésite pas à pointer ce qui ne va pas dans ma formulation ou réflexion, je ne vais pas m'en offusquer.

@jdh:

J'attends toujours, le résultat d'une expérimentation (que, moi, j'ai fait) sur une Debian + Squid + SquidGuard + Havp.

;D Mon proxy ne tourne pas sur pfSense mais sur un serveur Ubuntu. J'ai une assez bonne idée de ce que ça donne en terme de charge. Et pour avoir déployé des proxy dans des infrastructures que je qualifierai de "grande taille" (plusieurs centaines / milliers d'utilisateurs dans des architectures de proxy hiérarchisés) , j'ai également une très bonne idée de ce que ça représente en terme de profil de charge et de besoin hardware lorsque les besoins augmentent 8) (ce que je veux dire par là, c'est que mon proxy actuel n'est probablement pas représentatif)

Mon serveur pfSense n'est pas non plus une machine de la boutique pfSense (c'est trop cher :-X)

Et donc je ne fais pas la promotion du proxy sur le firewall (sans quoi je me l'appliquerai à ma propre installation) mais je comprends tout à fait que pour certains utilisateurs, l'approche UTM et pour aller plus loin, du all-in-one, ait du sens.

En milieu pro, pour une entreprise qui dispose des ressources compétentes ou qui est prête à acheter du service, nous sommes d'accord que la solution consiste à séparer les services est confortable. Et ce n'est PAS pour une raison de charge (la charge du FW est tellement faible (1) que le résultat ne serait d'ailleurs pas le monstre que tu décris).

Sauf que dans la pratique, il n'y a pas que des déploiements en milieu pro. Comme tu le décris, faire une installation from scratch d'un proxy n'est pas forcément simple, d’où l'attrait du all-in-one.

Ce à quoi je réagit, c'est la position inflexible qui consiste à uniquement dire "pas de proxy avec le firewall".

sur pfSense, et sur la base de l'argumentaire de ccnet relatif aux packages, je suis d'accord. :D n'en parlons plus (mais lorsqu'un utilisateur potentiel se pointe sur le forum avec cette question pour un déploiement pfSense, il suffit juste de lui expliquer que les packages pfSense… bof, y compris le proxy :-)
lorsque mon propos est de renvoyer l'utilisateur qui vise un design all-in-one vers une autre solution et que tu reviens sur le sujet en disant "pas de proxy sur le FW", je m'interroge sur l'argumentaire car ton point sur le hardware (et maintenant sur le coût associé) ne tient pas alors nous ne parlons plus de pfSense.

La seule vraie raison, dans l'absolu, pour ne pas faire tourner d'autres services que le firewall sur la plate-forme qui rend ce service, serait l'absolue nécessité de stabilité et sécurité pour ce composant critique.
L'aspect hardware n'entre pas en ligne de compte dans le cahier des charges mais est uniquement le résultat d'une évaluation des besoins.

De plus, car nous avons visiblement une perception différente de ce point de vue, bien sûr qu'il est possible (et souhaitable dans un déploiement "pro") de ne faire tourner que le firewall sur la machine qui fourni ce service.
DNS, portail captif, VPN, DHCP peuvent très bien tourner ailleurs, contrairement à ce que tu sembles penser(2) ;)

En espérant ne pas semer le doute dans ton esprit, ni rendre mon propos encore plus incohérent qu'il l'est peut-être déjà, je te suggère d'aller faire un tour chez des constructeurs comme CheckPoint ou Juniper. Tu verras par exemple chez CheckPoint des solutions NGTP qui mélangent sur la même plate-forme tous ces services, y compris le proxy, anti-virus etc… Faut-il en conclure qu'ils ne connaissent pas leur métier ou qu'il y a un marché pour ce type de solution ?

(1) Attention de ne pas se tromper ici: on parle de firewall "edge", en bordure d'internet. cette charge là, pour le strict besoin de pare-feu, est généralement relativement faible et se mesure en terme de débit réseau. Il n'en va pas de même pour un firewall "interne" entre 2 LAN, ou un firewall en bordure d'un datacentre qui risquent de devoir supporter des débits bien plus importants, avec de nombreux VLAN et interfaces.

(2) Je n'utilise pas de portail captif dans mon infrastructure actuelle mais les autres services (DHCP, VPN, DNS) fonctionnent très bien "hors" pfSense.

jdh

Dans pfSense, il faut : le fitrage (alias, rules, nat, virtual ip), le routage, les vpn (forcément : où pourrait on mettre cela ailleurs ?), le portail captif, des services basic (dhcp, dns, ntp)
Mais il ne devrait pas y avoir dans pfSense : la gestion de CA, la gestion d'utilisateurs ! Nous somme d'accord ici

Les services basic comme DNS, DHCP, NTP peuvent bien évidemment fonctionner ailleurs. Mais pas le VPN et le portail captif !

Pour le VPN, si on veut le placer sur une autre machine, il faut que le protocole VPN puisse être routé (p.e. pour Ipsec, NAT traversal requis) et il faut des routes qui passent par le serveur VPN. Bilan, il est préférable de le positionner sur le firewall sauf très gros besoins.

Pour le portail captif, si on le place dans le LAN, il y a possibilité de passer outre, ce qui n'est pas le but. De plus la charge est probablement faible, donc, il est sans doute plus efficace de le placer sur le firewall.

Concernant du cache, compte tenu de ton expérience/example, je serais TRES étonné de placer cette charge sur un firewall. Pourtant un fichier de conf est un fichier de conf.
Tu vois bien que l'élément clé est la charge hardware.

Il y a aussi une évidence : si le firewall comporte plusieurs LAN, faut-il que le proxy cache pour tous les LAN ? Cela ne diffuse pas une info si on sait qu'un autre LAN fait telle requête ?

Bref la règle "pas de proxy sur le firewall" est correcte

en milieu pro
sous charge (disons à partir de 10-15 utilisateurs, et à fortiori, 100, ou des milliers).
On peut la contourner
pour un milieu perso
avec 3-5 utilisateurs
et avec un hardware un peu sérieux (et surtout de la mémoire).
En fait la règle "pas de proxy sur le firewall" est la bonne à presque tous les coups.

Aussi ceux qui, par pur esprit pointilleux, vienne à alimenter le doute de ceux débutants ne vont pas du tout dans le bon sens !
Et c'est ce que tu ne veux pas comprendre ! Une réponse trop exacte n'est pas, loin s'en faut, la meilleure réponse ! Elle peut gêner même !

Tatave

salut salut

je me permet juste d'intervenir sans prendre partie pour un ou l 'autre solution.

il y a des cas ou la théorie n'a pas de place et ou les bonnes pratiques non plus (budget ou DAF trop serré et ou pingre qui ne comprendra que quant il l'aura dans le dos et profond et encore pas si sûr que cela lui serve de leçon)

il y a des cas la théorie comme les bonnes pratiques ne doivent pas être contournés, il en va de certaines obligations légales (et autre considérations plus pointues) et là il faut les appliquer là aussi le budget et le DAF on leur mots a dire mais avec messieurs avocats et tout se qui s'en suit aux "luc" pour leur serrer les trois pièces cuisines dans le cas où s'il ne suivent pas les recommandation c'est eux qui iront aux frais pour leur fautes voir dans le meilleur des cas faire les chercheurs ailleurs…

Juste une intervention pour recadrer les points de vues sans partie pris si possible de ma part.

Cordialement.

chris4916

@jdh:

Les services basic comme DNS, DHCP, NTP peuvent bien évidemment fonctionner ailleurs. Mais pas le VPN et le portail captif !

Pourquoi ? Pourquoi, comme pour le débat initial (proxy sur le firewall) amènes-tu une conclusion aussi catégorique, d'autant que tu expliques juste après que c'est techniquement faisable ?

Il me parait bien plus intéressant pour tous de bien comprendre quelles sont les raisons de tel ou tel choix, et donc d'expliquer les vrais problèmes engendrés par tel ou tel type de design plutôt que d’asséner quelque chose de manière dogmatique, afin que chacun puisse faire son choix en connaissance de cause.

Pour le VPN, si on veut le placer sur une autre machine, il faut que le protocole VPN puisse être routé (p.e. pour Ipsec, NAT traversal requis) et il faut des routes qui passent par le serveur VPN. Bilan, il est préférable de le positionner sur le firewall sauf très gros besoins.

Pour le portail captif, si on le place dans le LAN, il y a possibilité de passer outre, ce qui n'est pas le but. De plus la charge est probablement faible, donc, il est sans doute plus efficace de le placer sur le firewall.

une DMZ répond en partie aux points (au demeurant tout à fait justes) que tu évoques.

Concernant du cache, compte tenu de ton expérience/example, je serais TRES étonné de placer cette charge sur un firewall. Pourtant un fichier de conf est un fichier de conf. Tu vois bien que l'élément clé est la charge hardware.

Correct. Je ne me serais pas risqué à un tel déploiement sur des machines "firewall". Et je ne dis pas qu'il faut le faire ;)
Je dis, encore et encore, que la position dogmatique "le proxy sur le firewall c'est hérétique" n'a pas de sens si elle n'est pas argumentée et que le seul argument de la charge hardware n'en n'est pas un, dans la très grande majorité des cas.

Bref la règle "pas de proxy sur le firewall" est correcte

en milieu pro

sous charge (disons à partir de 10-15 utilisateurs, et à fortiori, 100, ou des milliers).
On peut la contourner

pour un milieu perso

avec 3-5 utilisateurs

et avec un hardware un peu sérieux (et surtout de la mémoire).

Voila enfin quelques chiffres :)
Pour te donner un ordre de comparaison, un proxy d'entré de gamme chez BlueCoat, mettons le SG200-10, donné pour 400 utilisateurs, c'est 500 Go de disque (hors système) et 6 GB de mémoire. avec 8 GB de mémoire, BLueCoat couvre des config pour 2500 utilisateurs.
Ce n'est pas si énorme que ça n'est-ce pas ;D

En fait la règle "pas de proxy sur le firewall" est la bonne à presque tous les coups.

Je suis tout à fait d'accord, y compris le presque

Aussi ceux qui, par pur esprit pointilleux, vienne à alimenter le doute de ceux débutants ne vont pas du tout dans le bon sens !
Et c'est ce que tu ne veux pas comprendre ! Une réponse trop exacte n'est pas, loin s'en faut, la meilleure réponse ! Elle peut gêner même !

Du coup, ce long échange est bénéfique car tu as mis le doigt précisément sur ce qui différencie nos points de vue:

tu es partisan d’énoncer des axiomes (des dogmes pour reprendre la connotation religieuse de ta remarque sur l'hérésie du design) en demandant à tous de les accepter aveuglément et de ne surtout pas les discuter.
je prône plutôt d'expliquer avec un niveau raisonnable de détail les principaux impacts des différents designs afin que celui qui déploie choisisse en connaissance de cause.

Je comprends maintenant beaucoup mieux ta position, même si je ne la partage.
Celle-ci me semble acceptable dans le cadre d'une prestation chez un client où tu aurais une obligation de résultat mais dans un forum de ce type, je suis perplexe. 8)

Lolight

Hello,
Je passe mettre mon grain de sel. Ce que je vais dire n'a rien a voir avec le débat je vais donc rester bref.
Un sujet comme celui ci est génial il permet de comprendre le pourquoi du comment autour d'un débat, j'ai pas votre niveau et aujourd'hui je me couche moins con, sans ce topic et juste en ayant lu "pas de proxy sur un FW" je me serais couché encore plus con parce que j'aurais lus un truc dont je suis pas sûr et sans en comprendre la raison. A votre bon cœur :P

Merci pour ce débat très instructif en tout cas ;D

chris4916

@Tatave:

il y a des cas ou la théorie n'a pas de place et ou les bonnes pratiques non plus (budget ou DAF trop serré et ou pingre qui ne comprendra que quant il l'aura dans le dos et profond et encore pas si sûr que cela lui serve de leçon)

C'est également un aspect important du débat, qui rejoint, d'une certaine manière, mon propos sur la faisabilité en terme d'opérations qui doit être adaptée aux ressources disponibles.

Le travail de l'architecte doit prendre en compte ces paramètres (coût, cahier des charges, aspects légaux) afin de proposer la solution la mieux adaptée. Et c'est, au final, presque tout le temps une affaire de compromis :-\ (ce que je trouve, puisque c'est mon métier, souvent frustrant :-X)

jdh

@chris4196 : Tu indiques ta config personnelle dans un fil : je constate que le proxy n'est pas sur le firewall !

J'affirme qu'il ne faut "pas de proxy sur le firewall" (et je le répète).
C'est LA BONNE règle dans 99% des cas ! (99,9% ?) : en entreprise, sous charges, c'est LA BONNE config, celle qu'il FAUT mettre en place.
Le cas où on peut passer outre est assez simple et rare : utilisation perso, avec 3-5 utilisateurs, et avec une machine qui a de la ressource (2 Go de mémoire, un cpu qui avance).
En fait, on peut mettre le proxy sur le firewall quand on a une machine trop grosse comme firewall !

Donc, il est TRES souhaitable de diffuser l'affirmation que de multiplier partout "ce n'est pas exact" : un débutant n'a pas les compétences pour savoir ce qui est vrai, et c'est mal !
C'est ce dernier point que je voudrais VRAIMENT que tu changes !

chris4916

@jdh:

@chris4196 : Tu indiques ta config personnelle dans un fil : je constate que le proxy n'est pas sur le firewall !

Effectivement car je ne pense pas que ce soit LA bonne solution systématique.

Ce contre quoi je m'insurge, ce n'est pas le choix technique en lui même mais le dictat qui consiste à :

ne répondre que de manière lapidaire et manichéenne aux personnes qui posent la question "pas de proxy sur le FW, c'est hérétique !" sans autre explication factuelle.
faire croire qu'il n'y a qu'une seule bonne solution sans compromis sans prendre le temps de comprendre le contexte

Ce que j'essaie d'expliquer à longueur de message, c'est que, dans certains cas, mais pas le mien car j'ai la prétention d'assez bien maîtriser ces aspects techniques, l'approche "all-in-one" est un compromis, parfois meilleur que la solution intellectuellement parfaite qui consisterait à multiplier les serveurs.
Le type qui veut faire un proxy transparent (et pourtant je lutte contre cette approche, va voir mes messages dans la section anglaise) n'a pas beaucoup d'autre choix si il ne veut / peut pas faire une DMZ.

En fait, on peut mettre le proxy sur le firewall quand on a une machine trop grosse comme firewall !

Ce n'est pas un problème de hardware ;) le hardware, c'est un choix, qui a des impacts certes, mais ce n'est jamais, dans les cas qui nous intéressent, une contrainte.

Donc, il est TRES souhaitable de diffuser l'affirmation que de multiplier partout "ce n'est pas exact" : un débutant n'a pas les compétences pour savoir ce qui est vrai, et c'est mal !
C'est ce dernier point que je voudrais VRAIMENT que tu changes !

Indeed, c'est notre point de désaccord, car sur le reste, nous sommes à peu près en ligne, hormis les besoins hardware nécessaire pour faire tourner un proxy :)
Deux visiosn s'opposent:

D'un coté : "le débutant n'a pas les compétences pour comprendre, balançons lui LA vérité"
D'un autre : "essayons d'expliquer l'impact des choix et les raisons qui poussent à certains designs afin que le débutant puisse faire son choix"

Tu sais, l'histoire du gars à qui tu apprends à pécher ;)

mais visiblement, nous n'allons pas converger vers cette vision :( Ce n'est pas grave mais c'est pourtant bien plus enrichissant pour la progression de tous de discuter de ces aspects plutôt que de prétendre venir avec la vérité absolue, surtout qu'en grattant un peu, je ne partage pas ton argumentaire technique et surtout la manière, à mon sens un peu biaisée dont tu le présentes

En fait, on peut mettre le proxy sur le firewall quand on a une machine trop grosse comme firewall !