Reverse Proxy problème
-
après vérification, c'est plutôt: net.inet.ip.portrange.first désolé :-[
-
après vérification, c'est plutôt: net.inet.ip.portrange.first désolé :-[
[/quote]Merci mais cela ne fonctionne pas.
J'ai essayé de passé à 0 ou a rien la valeur de net.inet.ip.portrange.first mais j'ai toujours le même message.
De plus, quand je force le reverse proxy avec le port 80 il m’indique le message suivant :============
The following input errors were detected:
The field 'reverse HTTP port' must contain a port number higher than net.inet.ip.portrange.reservedhigh sysctl value(1023).
To listen on low ports, change portrange.reservedhigh sysctl value to 0 on system tunable options and restart squid daemon.============
J'ai 'ajouté net.inet.ip.portrange.reservedhigh avec la valeur 0 mais toujours le même message.
Pour mes tests j'ai donc changé le port de squid avec le port 8080 dans un premier temps. Je n'ai plus l'erreur avec le bind mais les autres oui :2015/04/23 16:59:55 kid1| Starting Squid Cache version 3.4.10 for amd64-portbld-freebsd10.1…
2015/04/23 16:59:55| pinger: Initialising ICMP pinger ...
2015/04/23 16:59:55| icmp_sock: (1) Operation not permitted
2015/04/23 16:59:55| pinger: Unable to start ICMP pinger.
2015/04/23 16:59:55| icmp_sock: (1) Operation not permitted
2015/04/23 16:59:55| pinger: Unable to start ICMPv6 pinger.
2015/04/23 16:59:55| FATAL: pinger: Unable to open any ICMP sockets.=================
Mais maintenant le reverse proxy fonctionne :D :D :D
Par contre je ne comprends pas pourquoi ça ne fonctionne pas avec le port 80..
-
L'interface web du pfsense ne doit pas être sur le port de base aussi …
(Mais ça c'est évident que vous y avez déjà pensé ...) -
et tu as bien sur redémarré Squid après avoir ajouté net.inet.ip.portrange.reservedhigh ?
-
et tu as bien sur redémarré Squid après avoir ajouté net.inet.ip.portrange.reservedhigh ?
Je n'avais pas redémarré squid après avoir ajouté net.inet.ip.portrange.reservedhigh.
C'est ok maintenant avec le port 80.Un grand merci a vous tous, cela fait quelques heures que je me cassais le nez dessus.
-
un thread qui peut t'intéresser ;)
-
Maintenant que ça fonctionne (ce qui était la question initiale), il y a probablement de la place pour un réflexion plus large 8)
Compte tenu du nombre de serveur que tu décris et de leur usage (ERP), j'imagine qu'il y a des problématiques spécifiques liées à la haute disponibilité, éventuellement des aspects spécifiques de réécriture d'URL, de load balancing etc…
Le simple déploiement d'un reverse proxy sur pfSense ne répond pas à cette problématique. De plus c'est un package, avec des risque évidents de dysfonctionnement comme tu peux le lire sur le lien que j'ai mis un peu plus haut.
Compte tenu de la nature commerciale de ton environnement, selon le SLA que tu as, il est peut-être nécessaire de mettre en place une infrastructure à tolérance de panne (i.e. une paire de pfSense avec CARP).
Au lieu de faire tourner un reverse proxy directement sur pfSense, j'opterai plutôt pour le service "load balancer" de pfSense, pour conserver l'objectif de "une adresse IP externe unique" (même si c'est ici une VIP) pour rediriger les requêtes en failover vers une paire de reverse proxy installés sur une DMZ, lesquels accéderont aux serveurs en interne.
Voila pour la base de réflexion ;)
-
Le choix du reverse proxy est un vaste débat ::)
Il faut d'abord bien définir les fonctionnalités que tu veux couvrir. Il y a des solutions simples (simplistes) et des truc plus évolués et spécialisés comme le lien proposé par ccnet.
- Les aspects de charge ne posent normalement pas de problème (à ne pas négliger cependant: comme pour le serveur web, un reverse proxy Nginx est plus rapide et léger que Apache ;D mais pas avec les mêmes fonctionnalités)
- les aspects failover sont également assez bien couverts mais il peut y avoir des pièges avec les applications qui maintiennent des sessions. Il convient de bien s'assurer de ces aspects de bout en bout lors du PoC.
- attention également aux aspect d’authentification: normalement, ton application demande à l'utilisateur de s'authentifier. certains reverse proxy offrent une fonction de SSO (like) qui consiste souvent à stocker le crédential de l'utilisateur pour le rejouer ultérieurement. Tout le monde n'est pas fanatique de ce mode de fonctionnement (moi par exemple :-) )
A discuter ;) (mais est-ce que ça n'est pas largement HS par rapport à pfSense ?)
-
Pour illustrer ce propos et rester dans le cadre de pfSense, si la haute disponibilité fait partie du SLA, il conviendrait de déployer une paire de pfSense avec CARP.
pfSense contrôle l'accès à la DMZ sur laquelle sont installés 2 reverse proxy, accédés via le load balancer, en mode load balancer ou failover selon les besoins. Ces reverse proxy accèdent ensuite aux serveurs web installés sur le LAN (1)
Avec ce design, les utilisateurs venant d'internet ne pénètrent pas plus loin que la DMZ où l'appli (reverse proxy) prend le relais.
Attention: ça reste malgré tout un design que je qualifie de slideware ;D car il ne décrit que le principe. De nombreux aspects supplémentaires doivent être pris en compte avant de fournir une architecture qui pourrait être déployée:
- les aspects connectivité internet sont ignorés (edge routers, redondance des ISP, liens internet)
- redondance des serveurs web (indispensable si on fait l"effort de rendre l'infra y donnant accès elle même tolérante aux pannes)
- réseau d'administration
- et enfin, très important mais en dehors du cadre de pfSense, choix et fonctionnalités des reverse proxy
(1): "sur le LAN" est ici un raccourci. Le déploiement des serveurs dans l'infrastructure est un autre sujet, à prendre en compte dans le design cible. Ce peut être des serveurs sur un segment dont l'accès est contrôlé par un FW dédié, un segment directement attaché aux 2 pfSense décrits au dessus. Il y a plein de designs possibles dépendants de l'existant et des objectifs. C'est un autre débat et un sujet à part entière ;)
-
et je me rends compte (désolé :-[) que j'ai oublié le lien vers la fonctionnalité que j'introduis sur pfSense pour supporter ce design: le [url=https://doc.pfsense.org/index.php/Inbound_Load_Balancing]load balancer
-
Merci beaucoup pour tous ses conseils précieux chris4916.
Je vais prendre le temps d'étudier tous mes besoins et de me construire une architecture digne de ce nom.Pour l'instant il est donc fort probable que je parte sur un cluster de pfsense avec CARP.
Des reverse proxy sur une DMZ (Cluster ou loadbalancergérer par le pfsense). D'ailleurs est-ce que c'est une fonction qui est bien implémenté dans le pfsense ? Est-ce que c'est stable et bien éprouvé ?J'ai également bien pris en compte les autres aspects à prendre en compte (Lien WAN, réseau ….)
En tout cas, j'ai bien hâte de faire évoluer mon infra actuelle. ;D
-
Pas de précipitations ;D n'hésite pas à prendre d'abord d'autres avis car cette vision "high level" est juste la mienne ;)
Elle me semble correspondre à ton besoin mais il y a probablement d'autres approches possibles.Un point important, dans ce type de design ou les services sont redondants, c'est de bien s'assurer du fonctionnement de bout en bout, entre le client et le serveur lorsqu'il y a des switch d'un composant à l'autre dans les différentes couches.
- Y a t-il des pertes de session, est-ce critique ?
- comment synchroniser les configurations reverse proxy ?
- gestion des certificats (c'est un point potentiellement délicat qui requiert toute ton attention 8)) la terminaison se fait-elle au niveau des reverse proxy ? quel type de certificat utiliser ? Bref, un sujet intéressant, mais en dehors de pfSense.
-
salut salut
Réfère toi à un de nos file récent qui traite de pourquoi ne pas mettre un proxy sur pf et dans quel cadre le faire avec les restrictions qui en découle.
Les informations de chris son pertinente pour le moins mauvaise solution à développer en virtualisation, à laquelle je rajouterais un proxy du coté de ton lan et bien évidement les clients paramétrés pour passer par le proxy lan qui lui va interroger le revers.
Sauf erreur (pas mis en place pour l'instant) il faut dire à pf de ne pas laisser passer les requêtes de sortie envoyer par un client et forcer le passage par le proxy.
de tel sorte tu auras un filtrage sur les protocoles pris en charge par tes proxy qui passeront et pas le reste, sauf applications autorisées.
si un de nos grands gourous pouvaient nous le confirmer.
Cordialement.
-
…/... à laquelle je rajouterais un proxy du coté de ton lan et bien évidement les clients paramétrés pour passer par le proxy lan qui lui va interroger le revers.
j'avoue ne pas bien comprendre la finalité :-[ si tu pouvais développer un peu ;) il y a peut-être quelque chose que j'ai raté.
[quote]Sauf erreur (pas mis en place pour l'instant) il faut dire à pf de ne pas laisser passer les requêtes de sortie envoyer par un client et forcer le passage par le proxy.
Si je comprends bien la description initiale, il s'agit de clients "externes" (et donc pas sur le LAN) qui accèdent à des applications exposées par l'infrastructure de mamatov. Dans ce que je décris, l'objectif est justement de faire en sorte que ces utilisateurs n'accèdent pas au LAN mais que la requête soit faite, de manière contrôlée, par le reverse proxy.
si un de nos grands gourous pouvaient nous le confirmer.
D'autres perceptions que la mienne seraient en effet les bienvenues :)
-
Une petite précision suite à un échange privé sur un sujet en marge de celui-ci:
si il n'y a qu'un seul reverse proxy ou si celui-ci est installé sur un cluster, la fonction de load balancer de pfSense est bien sûr inutile ;) -
D'une façon plus généraliste pour la sécurité des sites web on peut consulter sur le site de l'anssi : http://www.ssi.gouv.fr/uploads/IMG/pdf/NP_Securite_Web_NoteTech.pdf
-
Dans le style, le document du CLUSIF est, à mon sens, plus didacticiel, même si un peu plus ancien.
Après, il ne faut pas rêver non plus. Il n'y a pas de solution miracle et encore moins, si c'était possible :D, de solution pas chère, à minima en ressources humaines si on vise la sécurité parfaite dans le domaine du WAF.
Je ne dis pas qu'il ne faut rien faire mais prétends que viser une solution intellectuellement idéale peut s'avérer rapidement impraticable ou hors de prix.Par exemple définir, au niveau de son WAF, une approche qui consiste à n'accepter que les requêtes autorisées rend de déploiement de toute nouvelle application fastidieux. Il en va de même avec la modification des applications existantes.
Ce qui signifie, encore plus avec de type d'infrastructure qu'avec tout autre, un contrôle précis du processus de mise en production qui maintient alignés le contenu du WAF et le code des applications.De mon point de vue, mais cela n'engage bien sûr que moi ;) , les solutions intermédiaires qui consistent à configurer, au niveau du reverse proxy, un set de règles qui regroupent les type d'attaque connus permet déjà un progrès significatif dans la protection de ses applications web.
Le marché (offres d’éditeurs) est d'ailleurs plus actif sur ce type de solution que sur les solutions qui visent la mise en place de white-lists ;)De la lecture intéressante à ce sujet. (on dérive un peu de pfSense mais le sujet le mérite bien)
-
…/... à laquelle je rajouterais un proxy du coté de ton lan et bien évidement les clients paramétrés pour passer par le proxy lan qui lui va interroger le revers.
j'avoue ne pas bien comprendre la finalité :-[ si tu pouvais développer un peu ;) il y a peut-être quelque chose que j'ai raté.[/quote]
J'espérais avoir un peu plus d'information à propos de ce design mais ce n'est pour le moment pas le cas.
Ce design est intrigant et même en y réfléchissant plus en détail, je ne vois pas quelle est la finalité si on considère que l'objectif initial est de mettre à disposition l'accès à des serveurs web hébergés localement à des utilisateurs distants accédant via internet.Un reverse proxy peut cependant servir à des utilisateurs internes si celui-ci est placé en frontal de serveurs web(1). C'est un moyen efficace de fournir de la haute disponibilité ou de la répartition de charge. Dans ce cas, le positionnement du reverse proxy en DMZ, comme je le montre sur mon schéma, n'est probablement pas le meilleur choix.
En cas d'utilisation d'un reverse proxy à usage (également) interne, si les utilisateurs locaux utilisent un proxy, le flux sur le LAN pourrait devenir:
browser => proxy => reverse proxy => web servermais le proxy n'apporte pas grand chose, si ce n'est la gestion du cache, AMHA
A noter que pour un utilisateur distant, si un proxy est déployé de son coté, le flux sera exactement le même :) sauf qu'entre le proxy et le reverse proxy, il y a le WAN ;)Tatave, n'hésite donc pas si tu as une vue différente.
(1): c'est assez courant dans les data-centre
