Skip to main content

Réseau - Le reverse proxy

image.png

Difficulté : Intermédiaire


Notions : Réseau, protocoles WEB HTTP(s)


I. Introduction

Les architectures réseaux modernes font que de nombreux services passent aujourd'hui par une WEB UI et sont donc présentées à l'utilisateur en tant que "web Apps".

Ceci est également renforcé par les besoins de mobilité des utilisateurs et d'inter-connectivité entre les différentes entités participant à un flux de marchandises ( production, acheminement, entreposage, transformation, vente ).

De plus, l'explosion des API liés à l'automatisation des échanges (traçabilité produit, EDI, commandes, facturation électronique, etc...) ou des services (authentification, SSO, etc...) et du cloud font que les services amenés à être exposés se font nombreux.

Evidemment, pour des raisons de sécurité, ces services exposés sont répartis entre plusieurs zones réseaux micro-segmentées, dans des DMZ voire même dans des cas d'architecture hybride, décentralisée en tout ou partie sur le cloud.

Cela créée quelques problématiques :

  • Multiplication des adresses et ports

  • Risques de sécurité (IP internes visibles, surfaces d’attaque élargies)

  • Gestion complexe des certificats SSL/TLS

  • Absence de centralisation des logs, politiques, limitations, etc.

C'est pour cela que l'on met en place un "Reverse Proxy".

II. Le reverse proxy

2.1 Définition

Un reverse proxy est un serveur intermédiaire qui reçoit les requêtes des clients et les redirige vers un ou plusieurs serveurs internes, redondés ou non, dans une ou plusieurs zones différentes.

Ainsi, le client ne voit jamais les serveurs internes : il ne connaît qu’un point d’entrée unique.

2.2 Principe général

Un reverse proxy assure plusieurs fonctions essentielles :

  • Point d’entrée unique pour toutes les requêtes

  • Routage vers les services internes (path-based, host-based)

  • Load balancing (répartition de charge)

  • TLS/SSL termination (décryptage au bord du réseau)

  • Caching des réponses

  • Sécurité (WAF, rate limiting, filtrage)

  • Observabilité (logs, métriques, traces)

drawing-1-1788959539.png

Info : En effet, dans reverse proxy, il y a la notion de Proxy permettant par nature de faire du cache sur le trafic.

2.3 Reverse proxy vs forward proxy

Il ne faut toutefois pas confondre le 'Reverse Proxy' et le 'Forward Proxy'

Le rôle du Forward proxy est de masquer l'identité du client, de filtrer le traffic et se positionne côté client.

  • Exemple : Proxy d'entreprise (squid, sophos proxy, etc...)

Le rôle du Reverse proxy quand à lui est de masquer les serveurs, router les requêtes et participer à la sécurisation des services.

  • Exemple : nginx, HAproxy, traefik, etc...

III. Terminologie technique

L'on retrouve dans l'ordre :

drawing-1-1789041548.png

  • Les Entrypoints : Les points d'accès publics côté externe.

Par exemple si le client veux joindre https://app.example.com , le DNS va pointer vers l'IP publique du reverse proxy. Le reverse proxy reçoit la requête sur le port 443 exposé par NGINX ou Traefik.

L’entrypoint reçoit la requête, établit la connexion TLS, inspecte les headers et choisit une route.

  • Le middleware : Composant intermédiaire appliqué Avant la redirection au backend.

Il peut s'agir de fonctions spécifiques comme :

  • Redirections HTTP → HTTPS

  • Ajout d’en-têtes de sécurité

  • Rate limiting

  • Authentification

  • Réécriture d’URL

Les middlewares sont très présents dans Traefik, Envoy, API Gateway.

  • Le routing : Décision de redirection basée sur des règles de trafic, comme par exemple :

    • Le hostname (admin.example.com)

    • Le path (/api/orders)

    • Le header (X-Client-Type)

  • Le Backend Pool : Un ensemble de backends, lorsqu'il y a plusieurs destinations possibles, par exemple dans le cas de la haute disponibilité.

  • L'endpoint : le serveur interne (VM, conteuneur, virtualhost, etc...) vers lequel la requête est redirrigée.
    • exemples :

      • frontend:3000

      • api-1:8080

      • admin:9000

IV. Le SSL Offloading / SSL Termination

Dans le cas du HTTP, les redirections sont relativement transparentes. Mais cela se corse dans le cas du HTTPS. En effet le reverse proxy va devoir gérer le SSL/TLS à la place des clients.

Il va alors :

  1. Recevoir une connexion HTTPS
  2. Déchiffrer la communication HTTPS
  3. Si backend HTTP, envoyer la requête non chiffrée au backend(s) HTTP.

drawing-1-1789042409.png

Les principaux avantages de cette méthode sont :

  • Performance : les backends n’ont plus à gérer les handshakes TLS (CPU intense)

  • Centralisation : un seul endroit pour gérer les certificats

  • Sécurité :

    • Choix des protocoles TLS

    • OCSP stapling

    • HSTS

    • Mise à jour des suites cryptographiques

  • Simplicité : les services internes peuvent rester en HTTP

Le principal inconvénient est que le trafic n'est pas chiffré de bout en bout, aussi un attaquant qui arriverait à se positionner sur un réseau interne pourrait intercepter le flux d'information et en extraire les données.

Aussi, dans les infrastructures Zero Trust, il est préférable que le backend soit aussi en HTTPS.

drawing-1-1789043334.png

Dans ce cas, le reverse proxy va :

  1. Recevoir la connexion HTTPS
  2. Déchiffrer la trame, l'analyser et appliquer les middleware
  3. La chiffrer à nouveau en sortie pour la transmettre à l'endpoint.

V. Cas d'usages typiques

5.1 Microservices

Pour les microservices et les containeurs. Un reverse proxy sert d’ingress pour un ensemble de services internes. Exemple :

  • / → frontend

  • /api → API

  • /auth → service d’authentification

5.2 Load balancing

Il peut également assumer le rôle de passerelle dans le cadre de la haute disponibilité.
Lors de l'ouverture de session, il choisira le backend disponible sur lequel transmettre la demande, puis s'assurera que la session soit renvoyée sur le même backend.

Algorithmes courants :

  • Round-robin

  • Least connections

  • Weighted

5.3 Sécurité

Il est possible sur le reverse proxy de mettre en place des ensemble de règles pour construire un WAF (Web Application Firewall).
Cela permet entre autres de :

  • Filtrer le trafic interdit

  • Appliquer des limitation d'accès sur un service

  • Filtrer les éventuels Payloads

  • Masquer les IP internes

VI. Outils courants

Voici une liste des produits les plus couramment utilisés :
Outil Type / Architecture Points forts Limites Cas d’usage idéal
NGINX Reverse proxy + serveur web Ultra performant, très mature, énorme écosystème, support HTTP/2, modules, WAF (ModSecurity) Configuration parfois complexe, pas de découverte dynamique native Sites web, API, microservices simples, offloading TLS
HAProxy Reverse proxy + load balancer L4/L7 Performance exceptionnelle, load balancing avancé, observabilité riche, très stable Moins orienté “développeur”, configuration technique Haute disponibilité, load balancing critique, trafic massif
Traefik Reverse proxy moderne orienté microservices Découverte dynamique (Docker, Kubernetes), middlewares puissants, dashboard intégré, ACME auto Moins performant que HAProxy sur très gros volumes Microservices, conteneurs, Kubernetes, devops
Envoy Proxy Proxy L7 moderne (C++), utilisé dans Istio Filtres avancés, HTTP/2 & gRPC, observabilité, resilience, hot reload Courbe d’apprentissage élevée, configuration complexe Service mesh, architectures distribuées, cloud natif
Caddy Reverse proxy + serveur web HTTPS automatique, configuration simple, très bon pour dev Moins configurable que NGINX/Envoy Petits projets, déploiements rapides, dev web

VII. Notions complémentaires

    7.1 Proxy TCP vs Proxy WEB

    Le proxy TCP agit sur la couche 4 du modèle OSI, il se contente de prendre la trame et de la router au bon service endpoint.
    Même si cela permet de masquer les IP en interne et disposer d'un entrypoint unique pour rediriger du trafic vers différents backends TCP, il n'est pas forcément possible d'examiner le contenu de la trame et donc d'agir au niveau applicatif.
    Là où le proxy HTTP agit sur la couche 7 et a donc un accès à l'intégralité du flux applicatif.
    Cela le rends donc capable d'agir sur les données (headers, cookies, mime types, etc...)

    7.2 Persistance et observabilité

    Avec la possibilité de lire les données applicatives, il est dès lors possible de rendre une session persistante en utilisant un jeton de session. Ainsi, dans le cas du load balancing, si une session est redirigée vers un backend, l'on s'assure que cette session utilisera ce même backend jusqu'à sa clôture.

    Concernant l'observabilité, ces sessions peuvent être logguées de manière centralisée en utilisant des métriques prometheus et des traces distribuées (openTelemetry) rendant l'analyse beaucoup plus simple et permettant d'accélérer le diagnostic d'un dysfonctionnement ou la détection d'une attaque.

    7.3 Failover

    Comme évoqué plus haut, il est possible à travers un pool de gérer la haute disponibilité d'un service en multipliant les endpoints.

    Mais il est également possible de redonder les reverse proxy en eux-même. Vu que ceux-ci sont capables de s'échanger les jetons de sessions afin de les persister, la perte d'un noeud deviens transparente pour l'utilisateur du service.

    • Proxy en cluster

    • Keepalived / VRRP

    • Load balancer devant le reverse proxy


    VIII. Conclusion

    Le reverse proxy est un composant indispensable dans toute architecture moderne. Il permet :

    • De sécuriser les services internes

    • De centraliser le chiffrement TLS

    • De router intelligemment les requêtes

    • De répartir la charge

    • D’ajouter des politiques de sécurité sans toucher au code

    • De simplifier la gestion opérationnelle

    Il constitue la porte d’entrée de l’infrastructure, le point où se concentrent les décisions critiques de sécurité, de performance et d’observabilité.

    Back to top