ReverseProxy et Passerelle RDP



  • Bonjour,
    j'ai un soucis sur une config avec Squid ReverseProxy :
    J'ai une adresse publique sur Webmail.toto.fr qui route le port 443 vers un serveur Exchange sur le LAN
    La deuxième adresse publique Rdp.toto.fr  qui route le port 443 vers un serveur RDP Microsoft 2008 r2

    Tout fonctionne nickel Sauf :



  • oups : j'ai rippé sur le touche Enter !!!

    Donc, je disais Sauf :

    au bout de x minutes (ente 1et 2) , le bureau à distance se déconnecte avec notre sablier qui apparait !!!
    Je n'ai pas ce problème sur le serveur Exchange mais cela ne travaille pas de la même manière .

    Soit je relance la connexion, soit j'attends quelques minutes et cela revient tout seul !

    Le certificat SSL, installé sur le serveur RDP, ainsi que sur Pfsense, est un certificat GlobalSign en Wildcard .

    Je ne sais pas pas quel bout prendre l'analyse du problème ?  je ne trouve rien dans les logs de Squid concernant cette déconnexion qui est systématique.

    J'ai également testé le serveur en mettant un routeur Zyxel  pour tester la viabilité et tout va bien ainsi !

    Merci de vos lumières  !!!



  • Vous avez un problème avec un package et non avec Pfsense. De plus ce package est un portage de Squid. Je vous conseille de consulter les forums spécifiques à Squid en reverse. Plus généralement le design adopté n'est pas celui qui présente la meilleure valeur ajoutée en terme de securité.



  • Effectivement et désolé. Je vais voir sur le forum squid

    Et vous me conseilleriez quelle autre bonne méthode ou produit ?



  • Un meilleur schéma serait de placer un reverse proxy autonome (pas sur le firewall) dans une dmz, ceci avant d'atteindre le serveur Windows cible (dans une autre zone réseau). Ce schéma est la mise en œuvre de principes de base :cloisonnement réseau et défense en profondeur. Ce schéma comportant lui même plusieurs modalités de mise en œuvre possibles. Le plus robuste comporte deux firewalls physiques distincts sans routage entre les firewalls mais uniquement un relayage applicatif (donc deux interfaces réseau physiques sur le relai applicatif et dans des réseaux différents).



  • (Il y a un abus de langage courant à écrire 'proxy' pour 'proxy http' !)

    On peut comprendre le fonctionnement d'un reverse proxy (http) : c'est assez simple en HTTP … mais bien plus complexe en HTTPS.

    Je suis surpris de lire qu'un reverse proxy (http) serait aussi capable de dispatcher un flux RDP ...

    Autant utiliser un reverse proxy (http) devant un Exchange (pour owa et activesync) est un (très) bon conseil,
    autant pour accéder à un serveur RDP depuis Internet, un bon conseil est ... VPN (et VPN seulement) !



  • Je suis surpris de lire qu'un reverse proxy (http) serait aussi capable de dispatcher un flux RDP …

    Ce n'est peut être pas disponible chez tout le onde mais effectivement certains éditeurs le font.
    https://kemptechnologies.com/solutions/microsoft-load-balancing/remote-desktop-services/
    Ce n'est pas juste un reverse http il faut quand même le dire.

    Tout cela étant dit, en ce qui concerne RDP, le vpn est "très hautement" préférable pour accéder RDP de l'extérieur. Comme le propose aussi l'ANSSI, le meilleur moyen de sécuriser RDP est de ne pas l’utiliser. Mais les administrateurs (ou non) de systèmes Windows ne savent pas s'en passer. Ils ignorent le plus souvent l'existence de RSAT. Solution presque (couvre au moyen 90% des besoins) équivalente mais nettement plus sûre, ne serait ce que parce qu'elle évite de laisser trainer des traces de secrets d'authentification partout où passe l’utilisateur de RDP. Ensuite la problématique de mise à disposition d'applications est différente.


Log in to reply