Redirection nom de domaine WAN vers ip local
-
Bonjour,
Je suis en train de mettre en place une architecture pour plusieurs sites web.
ma question est la suivante: est ce que le PFS est en mesure de transmettre un nom de domaine vers un serveurs reverse Proxy pour que le reverse proxy puisse traiter la demande par le nom de domaine et non pas l'adresse ip?
Pour être plus précis (car j'ai lu sur le forum que plusieurs personnes doivent se faire tirer les vers...):
Je souhaiterai pouvoir faire une règle du type :
SRC: monsite.mondomaine.fr port SRC: 80 ou 443 vers DST: 192.168.1.12 DST port: 80 ou 443
pourquoi faire comme ca?
pour que le reverse proxy puisse traiter la demande par le nom de domaine demandé.ca me permettrai :
- de protéger mon Reverse proxy par un pfs
- de pouvoir mettre en place plusieurs sites derriere mon reverse proxy
J'ai lu que le pfs n'utilisait que les couches 2 et 3 et ne monte pas jusque 7 (http = couche 5)
Est ce que dans le langage PFS/ Netgate ca n'est pas simplement du DNS forwarder (mais toujours avec un nom de domaine public vers un serveur sur le Lan?
Merci pour votre réponse.
-
Bonjour,
Nativement, bien évidemment NON car PF est avant tout un firewall !!!
Il te reste donc 2 solutions :
1/ Router les flux entrant vers un reverse proxy derrière ton PF (VM ou autre)(Bonne méthode)
2/ Ajouter via les add-on un reverse proxy sur ton PF (Pas idéal)Cdt
P.S : Apache nativement est aussi capable de faire le job ...
-
@baalserv Merci pour ta réponse.
Ce que je souhaite faire est en effet la méthode 1: router les flux entrant vers un RP derrière le PFS (vm nginx). C'est la ou ça ne fonctionne pas. Le RP ne reçoit pas les requêtes ou alors il ne sait pas les traiter (et ne recoit donc pas l'url)
Est ce qu'il faut la traiter comme un flux ip (source vers destination) ou alors il faut utiliser une autre méthode que je ne connais pas? -
Tout cela manque de connaissance.
Héberger plusieurs sites (http ou https) derrière un firewall dirigent naturellement vers un 'reverse proxy'.
Si on a installé un reverse proxy, on fait du NAT Port Forward des flux http et https vers le reverse proxy. Point barre.
(règles sur no de ports pas sur noms de domaine !)Un firewall réalise un filtre de paquets IP : il n'y a aucune notion de nom de domaine la dedans !!
Si plusieurs noms de domaines pointent vers la même ip, comment est fait le tri (entre paquets ayant la même ip de destination) ? Le tri peut se faire car 'à l'intérieur des paquets http(s)' il y a des instructions du genre 'GET www.nom.com/', donc le reverse proxy analyse le contenu et tri.
Une petite différence entre http et https : le flux https est crypté entre client et serveur depuis le premier paquet, donc le reverse proxy doit décoder le début en https !
Cela n'est pas une problématique pfSense (ni aucun firewall) !
-
@jdh merci pour ta réponse (et désolé pour le temps de réponse). Je vais voir ce que le pfs est capable de faire en ce sens.
Nous sommes bien d'accord sur le sujet, mais après plusieurs tests non concluants, je préférais poser la question à des experts de cette solution.
Pour info, je ne pense pas que je manque de connaissance, car j'ai déjà mis en place de telles solutions pour un éditeur de logiciels mais avec d'autres types de firewall (dont certains avec des licences).
Merci de ton aide.
Xavier -
Le schéma de base dans une infrastructure un peu étoffée est le suivant :
Internet -> (FW1 / périmétrie) -> Reverse Proxy -> (FW2 / segmentation interne) -> Serveur Web2 étant des produits différents, de technologies différentes dans l'absolu.
Le reverse proxy est placé en coupure du flux et constitue le point de terminaison des sessions SSL/TLS. Ce qui permet le travail d'un WAF sur un flux en clair, voir d'un IPS en tête de chaque segment (derrière FW2).avec d'autres types de firewall (dont certains avec des licences).
De nombreux produits du marché concentre les fonctionnalité de firwall, niveaux 3 et 4, avec des fonctionnalités de traitement niveau 7. C'est séduisant sur le papier, cà l'est aussi pour les financiers, çà ne l'est pas pour la sécurité car on met tous ces œufs dans le même panier et c'est contraire aux principex de la défense en profondeur. Si vous avez un problème avec cet équipement, vous êtes en tongues sur la banquise. Cela vaut pour tous les composants. Et c'est beaucoup plus fréquent que vous pouvez le penser. Avec ou sans licence.
-
Le titre 'Redirection nom de domaine WAN vers ip local' n'est pas cohérent avec 'mettre en place une architecture pour [héberger] plusieurs sites web'.
'le PFS est en mesure de transmettre un nom de domaine vers un serveurs reverse Proxy pour que le reverse proxy puisse traiter la demande par le nom de domaine et non pas l'adresse ip' montre bien que les fonctions de firewall et reverse proxy ne sont pas bien maitrisées.
Le schéma est simple :
Internet <-> Firewall <-> Reverse Proxy <-> Serveurs web interne
avec un NAT Port Forward sur les protocoles HTTP=80/tcp et HTTPS=443/tcpL'ensemble des flux est ainsi envoyé au Reverse proxy qui fera le tri selon le nom de domaine (et les certificats).
NB la protection apportée par le firewall consiste juste à transférer juste le trafic prévu. La sécurité réelle résidera dans la capacité du reverse proxy à traiter correctement et uniquement ce qui est prévu. L'IPS d'un firewall commercial assure lui-aussi l'analyse protocolaire, ni plus ni moins ...
Côté Firewall la config vous a été donnée. (N'attendez rien de plus !)
Côté Reverse Proxy, qu'avez vous prévu ?
-
Il faut bien comprendre, et c'est le sens des messages précédents, que la protection de sites web requiert de mettre en place des outils que vont assurer des différentes tâches.
On peut citer le filtrage des flux aux niveaux 3 et 4 donc firewall.
Analyser les flux applicatifs lors des accès a priori légitime : Waf.
Analyser les flux, pas forcément applicatif, (ex : exploitation d'une CVE sur un serveur apache) mais légitime d'un point de vue purement réseau, c'est le trvail d'un IPS.
A minima on se trouve avec 3 outils remplissant chacun une activité de protection distincte. -
Mais je pense que la solution initialement envisagée est correcte, à savoir FW en frontal qui redirige toutes les requêtes vers un reverse proxy.
On peut bien sûr discuter de design plus évolués avec du WAF et/ou un IPS mais dans le principe, @Xavier2410 ne décrit rien de différent de ce que vous lui proposez.
Effectivement, un FW ce n'est pas dans la couche 7 et effectivement ça implique de la translation d'adresse et/ou de port.Ce qui n'est pas clair, c'est la manière dont tu configures la redirection vers ton reverse proxy ni d'ailleurs la formulation de ta question puisque le FW ne va s'occuper, comme le dit jdh, que d'IP et de port.
-
Ce qui est exposé dans le post initial n'est qu'incompréhension :
- on n'écrit pas de règles avec un 'nom de domaine'.
C'est surprenant de faire ce genre de confusion, alors que le mot 'reverse proxy' est connu. Mais cela signifie que le sens ou la fonction n'est pas comprise, d'une, et que l'écriture de règles firewall n'est pas totalement bien acquis.
Ce qui compte maintenant, c'est de
- comprendre le fonctionnement d'un reverse proxy
- pour chaque protocole HTTP et HTTPS : pour cela bien comprendre HTTP puis comprendre qu'est que HTTPS par rapport à HTTP
- choisir un outil et commencer à le configurer avec les noms de domaines définis et les serveurs web préparés.
Perso, je passerai aussi un peu de temps à comprendre la mutualisation de serveurs web : comment un seul serveur web peut héberger des sites multiples (sous des noms dns distincts).
-
Dans l'absolu, tu as raison, le FW ne connait pas le DNS. Il se trouve que j'utilise quand même beaucoup cette fonction avec pfSense parce que c'est un moyen simple d'avoir des règles de FW pour des sources/destinations qui ont des IP dynamiques. Mais bon, c'est juste pour clarifier les choses.
La question initial n'était pas en effet EXACTEMENT précise mais suffisamment quand même pour que chacun comprenne que ce que veut faire @Xavier2410 c'est rediriger des flux entrants vers un reverse proxy. En tous cas, c'est ma compréhension.Pour ce qui est des multiples serveurs Web sur une même machine avec des fqdn multiples, effectivement c'est possible et même courant, même avec le même port d'ailleurs. SNI ? ou alternativement, grâce aux alternate names du certificat, si j'ose dire
-
NON ! Il ne faut pas écrire cela !
'Dans l'absolu, tu as raison, le FW ne connait pas le DNS. Il se trouve que j'utilise quand même beaucoup cette fonction avec pfSense parce que c'est un moyen simple d'avoir des règles de FW pour des sources/destinations qui ont des IP dynamiques. Mais bon, c'est juste pour clarifier les choses.'
On peut écrire des règles avec un 'nom dns' c'est à dire un hôte défini par 'nom dns' plutôt que son 'adresse ip'.
Les débutants ou peu expérimenté font alors la confusion : je peux écrire une règle 'avec un nom de domaine', croyant que le flux HTTP(S) destiné à ce domaine est définie par cela.
-
Bonjour à tous,
Tout d'abord, MERCI pour vos réponses et votre passion pour aider les autres.
Comme convenu, je reviens vers vous pour vous informer du résultat attendu sur un serveur de tests.
En effet, la fonction port forwarding fonctionne correctement (ce que je ne doutais pas). j'arrive donc bien à rediriger mes ports 80 et 443 sur mon serveur Web. Mon nginx me fait la partie RP. Pour le moment, je n'ai essayé qu'avec un seul site web, mais je pense que pour plusieurs ca sera identique dans la mesure ou mon nginx prend la charge et la redirection.Merci pour votre aide sur ce sujet.