Comment un proxy public atteint une origine privée à travers un VPN

Publier un site web à travers un tunnel et donner aux utilisateurs un accès VPN sont deux dispositions différentes qui partagent un même câble. Dans la première, un proxy inverse public accepte la requête du visiteur et la transmet par le tunnel à une origine que personne ne peut atteindre directement. Dans la seconde, l’utilisateur doit rejoindre le VPN avant que l’application ne soit accessible. Mélanger les deux descriptions, c’est ainsi qu’un backend privé finit par être exposé publiquement.

Deux modèles qui se ressemblent sur un schéma

Dessinez les flèches avant de choisir quoi que ce soit. Un modèle de publication publique va du navigateur au proxy en HTTPS, puis du proxy à l’origine par le tunnel, et l’origine n’accepte jamais de connexion depuis Internet. Un modèle VPN uniquement va du client à la passerelle, et l’application n’est accessible que depuis l’intérieur de ce chemin. L’ordinateur portable de l’utilisateur se trouve sur le même réseau que l’application, et c’est tout l’intérêt de ce modèle.

Les modèles diffèrent par qui authentifie et où. Dans le premier, le proxy est l’entrée publique et il relaie toute requête qui arrive, y compris hostile, selon la politique qui y est configurée. Dans le second, l’accessibilité elle-même est la porte, ce qui est une admission grossière mais réelle.

Où TLS s’arrête, et ce qu’il prouve réellement

TLS entre le navigateur et le proxy protège ce saut et permet au navigateur de vérifier le site qu’il comptait visiter. Si le proxy termine TLS, la requête existe sous forme lisible à l’intérieur de ce processus avant d’être transmise. Une seconde session TLS vers l’origine peut protéger le saut suivant et vérifier séparément le point de terminaison de l’application. Aucune des deux sessions ne décide quelle personne peut utiliser l’application. Un certificat générique sur le proxy ne s’étend pas non plus à ce second saut.

C’est la partie que les gens résument dans le mot chiffré. La confidentialité, l’intégrité et l’identité du serveur sont des propriétés de transport ; l’autorisation est une décision de l’application. Une adresse privée derrière un tunnel change qui peut atteindre la socket, pas qui peut se connecter une fois qu’il y est.

Ne faites confiance aux en-têtes transmis que depuis le proxy

Les applications qui journalisent ou autorisent sur l’adresse du client lisent généralement un en-tête que le proxy ajoute. Cet en-tête n’est que du texte, donc tout ce qui peut atteindre l’origine directement peut revendiquer n’importe quelle adresse. Restreignez l’origine pour que seule l’adresse de tunnel du proxy puisse se connecter, et configurez l’application pour accepter l’en-tête uniquement depuis cette adresse.

curl -s -o /dev/null -w '%{http_code}
' -H 'X-Forwarded-For: 203.0.113.9' http://172.20.5.40/

Si cette requête réussit depuis un hôte qui n’est pas le proxy, l’origine fait confiance à un en-tête qu’elle devrait ignorer. Corrigez l’écouteur avant de toucher à l’application. Un refus est un bien meilleur résultat qu’une ligne de journal portant une adresse falsifiée.

Gardez l’origine accessible depuis exactement un endroit

Liez l’écouteur de l’origine à l’adresse du tunnel ou isolez-le par un pare-feu vers le proxy, puis confirmez ce qui écoute réellement. Un service démarré avec une liaison générique accepte des connexions sur chaque interface de l’hôte, y compris une que vous aviez oubliée comme routable. La table d’écoute est la vérité de base, pas le fichier de configuration que vous comptiez appliquer. Si la liaison générique est intentionnelle, le pare-feu doit tout de même être le composant qui la restreint.

ss -ltnp | grep -E ':(80|443)'

Faites la même revue pour les interfaces d’administration, qui sont l’exposition accidentelle habituelle. Écrivez ensuite les deux modèles séparément : le site public via le proxy, et l’interface d’administration accessible uniquement par le tunnel. La phrase selon laquelle le serveur est derrière un VPN ne dit rien de tout cela.