Squid Reverse Proxy - Filtrer IP publiques source

Watchix

Bonjour,

Depuis un petit moment je cherche à améliorer la sécurité d'une architecture de test située sur la même IP publique que la production.

Contexte : Pro / Admin confirmé / Age de la solution : 2ans
Besoin :
J'ai actuellement une architecture de prod avec un reverse proxy qui effectue le mapping vers mes différentes url (https://www.domain.org)
Cependant pour des besoins de tests avant mise en prod, j'aimerais limiter l'accès à des mapping de test : https://testing.domain.org

www.domain.org et testing.domain.org correspondent à la même IP publique.
www.domain.org => doit-être joignable par tout Internet (OK)
testing.domain.org => doit-être joignable uniquement par certaines IP publiques ou GeoIP (Not OK)

Je ne peux pas non plus filtrer via IPtable de mon serveur de test car celui-ci ne voit en source que l'IP du PFsense et non la réelle IP distante.

PFsense : 2.5.2
Squid : 0.4.45_5

Ci-joint un schéma :
alt text

J'ai déjà posté dans la section "Package" / "proxy" mais sans réponses depuis

jdh

(J'ai une config proche ...)

Bravo pour fournir un schéma. Néanmoins vous utilisez un package pfSense ...

Mon schéma perso est le suivant :

Internet <-> box <-> (WAN) pfsense (LAN + DMZ)
et
sur DMZ, j'ai une VM dédiée Reverse Proxy : Debian + NGinx

Sur pfSense, j'ai un Port Forward pour les trafics http=80/tcp et https=443/tcp vers ma VM Reverse Proxy.

Dans cette VM Reverse Proxy, j'ai installé un NGinx et je définie des VirtualHost qui utilisent des certificats Let'S Encrypt (puisque il existe un certbot adapté).

Au niveau de ces VirtualHost, il est aisé de limiter l'accès avec 'allow' et 'deny' dans des sections 'location'.

En définitive, pfSense transfère la totalité du trafic 80 et 443 vers le NGinx de la VM dédié, lequel serveur web et reverse peoxy analyse par les url et permet un filtrage d'ip source VirtualHost par VirtualHost, ce qui est impossible pour pfSense (puisque c'est couche 4 = application, et que pfSense travaille couche 2 = ip).

C'est assez aisé, car j'ai une VM dédié à cet usage et j'ai la main directe dans les fichiers de conf (et accessoirement c'est mon métier).

En utilisant un package pfSense, vous vous limiter à l'usage prévu et la personnalisation nécessaire n'est (peut-être) pas disponible : c'est la raison pour laquelle, je milite pour utiliser les produits sur une machine dédiée et non les packages dès qu'on a des besoins précis.

Je ne crois pas possible de résoudre cela avec seulement pfSense ...
De toute façon, le Reverse Proxy dédié est votre avenir : un puis deux puis trois domaines ou sous-domaines, ...

NB : en fait votre premier serveur web peut être proxy : Apache ou NGinx peuvent être à la fois serveur Web et Reverse Proxy ...

Watchix

@jdh Merci pour ce retour
Hélas je ne peux pas mettre l'un de mes serveurs en tant que serveur proxy car là il s'agit d'un schéma pour illustrer ce que je souhaite faire, mais l'infrastructure derrière est plus conséquente.

J'ai essayé de voir avec Squid guard mais je n'ai pas réussi à faire ce que je souhaites pour ce qui vient de l'extérieur.
Squid Gard semble être principalement dédié aux flux sortants.

Je vais essayer de me renseigner directement auprès des Dévs du packages PFsense de Squid.

jdh

Il est nécessaire de comprendre ce qui se passe

le filtrage (d'ip source) selon l'url est une fonctionnalité de la couche applicative ou couche 4 (ou 7/ISO),
pfSense réalise un filtrage de paquets ip ou couche 2
DONC le filtrage ne peut être réalisé QUE par un reverse proxy

Il existe le package 'HA-Proxy' qui est défini par
HAProxy is a free, very fast and reliable solution offering high availability, load balancing, and proxying for TCP, HTTP and HTTPS-based applications. (cf https://docs.netgate.com/pfsense/en/latest/packages/haproxy.html)

Néanmoins, il ne va pas jusqu'à l'analyse complète de l'url comme le réalise un Reverse Proxy / Serveur Web. Et en particulier, ne peut suppléer pfSense pour le filtrage d'ip source pour des URL spécifiques ...

Edit: il y a aussi le package Squid, dont l'interface web prévoit le Reverse Proxy. Mais là aussi, je suspecte que l'analyse de l'URL n'est pas aussi complète que peut l'être un serveur Web classique. (Avec NGinx ou Apache, on fait fonctionner un reverse proxy comme un site web : un virtualhost, des limitations d'url = Location ou Alias + Directory avec Allow/Deny, et la redirection avec ProxyPass.)

Si vous avez derrière pfSense une infra qui ne se résume pas à 2 serveurs web, vous avez nécessairement les moyens de mettre un Reverse Proxy dédié.

A défaut, votre principal serveur web, utilisant Apache ou NGinx, peut faire aussi Reverse Proxy, ce qui atténue la contrainte d'un serveur dédié.

Watchix

@jdh Oui je comprend, on est tout à fait capable de pallier l'absence de cette fonctionnalité avec un "vrai" Squid derrière que je saurais configurer.
Cependant pour l'ensemble des collègues et par praticité aussi, ça aurait été bien de pouvoir gérer ça directement avec le PFsense (via les Alias par exemple), car on y fait déjà du filtrage GeoIP et via IPréputation au niveau d'autres règles de flux.

Je vais proposer cette fonctionnalité aux Dev de ce package si je parviens à les contacter

jdh

Les phrases importantes :

je ne suis pas certain que Squid, en reverse proxy, analyse les url aussi finement qu'un serveur web, (mais je n'ai installé que Squid en proxy direct),
le 'premier' serveur web (de type Apache ou Nginx) peut faire office de Reverse proxy

De mon point de vue personnel, pfSense doit rester sur le niveau couche 2 qu'il sait parfaitement gérer, et non lui greffer des packages de niveau couche 4. Mais vous faites ce que vous voulez ...

Watchix

@jdh Effectivement chacun a son point de vue
Par contre l'ensemble des firewalls du marché sont jusque niveau 7 depuis plusieurs années déjà.
Ce que fait aussi PFsense mais via des packages annexes (Snort par exemple), ce qui est plutôt une bonne chose je trouve en permettant de rester "dans la course" des solutions alternatives et ouvertes.

jdh

Le système ISO distingue 7 couches, alors que la pile IP en distingue 4. Donc 7 (ISO) = 4 (IP) = Applications = on est 'dans le protocole', et non juste le type de protocole IP et le n° de port.

Mon avis perso c'est de ne pas utiliser de modules niveau 4 (ou 7, donc) au niveau du firewall.

Concernant Snort (ou autre IPS), ce n'est pas, bien sûr, la bonne place d'être placé sur le firewall !

Un firewall, c'est une machine qui fait un boulot précis, qui doit être rapide, réguliere. Le proverbe qui convient, selon moi : qui trop embrasse, mal étreint !

Mais bon chacun fait comme il veut ... (moi j'ai mes habitudes construites après des années, après des observations, ...)