[Matrice de Flux pour vos infrastructures RDS (2008 Rx, 2012 Rx, 2016) sur Azure et OnPrem] Liste des ports que vous devez connaître pour vos services RDS en DMZ

Publié: 07/02/2018 dans TSE & RDS, Windows Sever
Tags:, , , , , , ,

 

Certains clients disposant d’une zone démilitarisée (ou DMZ pour Demilitarized Zone) et désirant déployer une infrastructure RDS avec une ou plusieurs Passerelles RDS (RDG : Remote Desktop Gateway) et serveurs RDWA (Remote Desktop Web Access) se posent souvent la question suivante :

Quels sont les (ports) requis à ouvrir pour permettre à tous les services de rôles RDS de communiquer correctement ?

Cette communication concerne principalement les serveurs RDG et RDWA placés en DMZ avec les autres services de rôles RDS en back-end, placés généralement sur le réseau interne de l’entreprise et se trouvant derrière un ou plusieurs Firewalls, notamment les serveurs Hôtes de Session (RDSH : Remote Desktop Session Host) et serveurs Broker (RDCB : Remote Desktop Connection Broker).

Vu que le serveur de Passerelle RDS doit être membre du domaine AD (Workgroup non supporté !), les flux avec les Contrôleurs de domaine AD (DC : Domain Controllers) sont nécessaires, et ce pour authentifier les utilisateurs distants (externes) et les autoriser à accéder aux ressources RDS internes.

Dans ce type d’architecture (scénario de déploiement), plusieurs ports sont à ouvrir pour permettre à la Passerelle RDS de remplir les fonctions suivantes:

  • Authentifier les utilisateurs distants/externes RDS
  • Autoriser les utilisateurs distants/externes RDS à accéder aux ressources internes publiées
  • Résoudre les noms DNS des ressources RDS internes
  • Forwarder (au Broker) les packets RDP envoyés par les clients distants.
  • Obtenir la liste des Révocations de Certificats SSL
  • Envoyer des requêtes RADIOS (si vous déployez un serveur NPS central)

 

Pour simplifier la compréhension de la matrice de flux « global », j’ai décidé de créer deux catégories de Flux, à savoir :

Flux entre « External Network » et la Passerelle RDS placée en DMZ : config au niveau du Firewall Externe

Flux entre la « Passerelle RDS » et les ressources internes (RDSH, RDCB, DC…) : config au niveau du Firewall Interne

Le diagramme Visio ci-dessous représente une architecture RDS classique avec RDG/RDWA en DMZ et le reste des services de rôles en interne

Flux entre « External Network » et la Passerelle RDS placée en DMZ : Pare-feu Externe

Déployer une Passerelle RDS vous évite d’exposer directement vos ressources RDS à Internet et les protéger contre plusieurs types attaques informatique (e.g DoS/DDoS Attack !).

La Passerelle RDS a besoin du serveur Web IIS (Internet Information Services) pour fonctionner.

Le WebSite RDG hébergé sur IIS nécessite une liaison « HTTPS », par conséquent le port de communication (d’écoute) utilisé par la RDG est le 443.

Vous aurez compris, pour autoriser le trafic HTTPS entrant et permettre une communication entre les clients externes et la Passerelle RDS placée en DMZ (derrière un Firewall Externe/Public), la règle suivant doit être créée/configurée :

Nom de la règle : External_to_RDG (nom de règle donné à titre d’exemple)

Port : 443/TCP

Protocol : HTTPS

Source : Internet

Destination : @IP de la Passerelle RDS placée en DMZ

 

Flux entre la « Passerelle RDS » placée en DMZ et les ressources internes (RDSH,RDCB,DC…) : Pare-feu Interne

Le Pare-feu Interne doit être configuré pour autoriser plusieurs types de communications (trafics) entre le ou les serveurs RDG placés en DMZ et vos ressources internes tels que les Domain Controller (pour authentification/autorisation), Serveurs Broker (redirection aux ressources RDS), Serveurs RDSH (accès aux ressources publiées).

Trafic lié à l’authentification  & autorisation via la Passerelle RDS
#Kerberos

La règle à mettre en place pour autoriser le trafic (Kerberos) entre la Passerelle RDS placée en DMZ et le(s) Contrôleur(s) de domaine interne afin d’authentifier les utilisateurs distants est la suivante :

Nom de la règle : RDG_to_InternalDC (nom de règle donné à titre d’exemple)

Port : 88/TCP

Protocol : Kerberos

Source :@IP de la Passerelle RDS placée en DMZ

Destination : @IP du(es) DCs 

 

#Service RPC NT Directory Service (NTDS) 

Le serveur RDG a également besoin de communiquer avec le service RPC NTDS (NT Directory Services) lié à l’AD, ce dernier écoute généralement sur un numéro de port non utilisé et pris d’une plage de ports haute. Le serveur RDG n’ayant pas la capacité de connaitre ce numéro de port (dynamic port) utilisé par le service RPC NTDS, il contacte le Mappeur de point de terminaison RPC (RPC Endpoint Mapper) en utilisant le port 135, l’Endpoint Mapper indique ensuite au serveur RDG le port d’écoute pour le service demandé qu’est le RPC NTDS. Comme indiqué précédemment, ces numéros de ports sont attribués de manière dynamique (généralement compris entre 1024 et 65 535), notez qu’à l’aide d’une clé de Registre, vous pouvez configurer un port « Statique » pour le RPC NTDS si nécessaire. Je vous laisse consultez cet article pour en savoir plus.

Nom de la règle : RDG_to_RPCMapper (nom de règle donné à titre d’exemple)

Port : 135/TCP + Port d’écoute configuré pour le service RPC NTDS

Protocol :RPC Endpoint Mapper + RPC NTDS

Source :@IP de la Passerelle RDS placée en DMZ

Destination : @IP du(es) DCs 

 

#LDAP

La règle à mettre en place pour autoriser le trafic (LDAP) entre la Passerelle RDS placée en DMZ et le(s) Contrôleur(s) de domaine interne afin d’autoriser les utilisateurs distants est la suivante :

Nom de la règle : RDG_to_InternalDC (nom de règle donné à titre d’exemple)

Port : 389/TCP et 389/UDP

Protocol : LDAP

Source :@IP de la Passerelle RDS placée en DMZ

Destination : @IP du(es) DCs 

 

#DNS

La règle à mettre en place pour autoriser le trafic DNS entre la Passerelle RDS placée en DMZ et le(s) Contrôleur(s) de domaine interne et permettre la résoudre des noms DNS des ressources internes :

Nom de la règle : RDG_to_DNS (nom de règle donné à titre d’exemple)

Port : 53/TCP et 53/UDP

Protocol : DNS

Source :@IP de la Passerelle RDS placée en DMZ

Destination : @IP du(es) DCs_ou un des serveurs DNS du réseau

 

#RDP

La règle à mettre en place pour autoriser le trafic RDP entre la Passerelle RDS placée en DMZ et les serveurs RDS internes pour forwarder les packets RDP reçus par les clients distants :

Nom de la règle : RDG_to_RDSHCB (nom de règle donné à titre d’exemple)

Port : 3389/TCP

Protocol : RDP

Source :@IP de la Passerelle RDS placée en DMZ

Destination : @IP des serveurs RDSH ainsi que RDCB

 

Note importante : si le port RDP par défaut, a été personnalisé/changé sur le déploiement RDS (e.g 33381 au lieu de 3389), le port 33381 doit être spécifié dans la règle ci-dessus.

Trafic entre le serveur RD Web Access et les serveurs RDSH internes

Si vous avez décidé de placer votre ou vos serveurs RD Web Access en DMZ (chose que je vous recommande d’ailleurs :)), notez qu’un seul flux est à ouvrir :

Nom de la règle : RDWA_to_RDCB (nom de règle donné à titre d’exemple)

Port : 5504/TCP

Protocol : RPC

Source :@IP du ou des serveurs RDWA placés en DMZ

Destination : @IP du(es) serveurs RDCB

 

J’espère que cet article pourra vous être utile lors du Design de votre infra RDS et/ou rédaction de votre document d’architecture technique/DAT/TAD (RDS Network Considerations Section).

Notez que des ports supplémentaires peuvent être requis si vous disposez d’une plateforme RADIUS, ou utilisez par exemple des solutions « Third-party » pour l’authentification/autorisation (dans ce cas, referez-vous à la documentation technique fournie par l’éditeur de solution pour en savoir plus).

Keep in touch,

A bientôt

#HK

Publicités
commentaires
  1. Nabil dit :

    Bonjour Hicham,

    Merci pour ce magnifique post qui explique dans les détails tous les prérequis sur les ouvertures de ports à faire!!
    Nickel 🙂

    Cordialement,
    Nabil

  2. David P dit :

    Salut Hicham,
    Est ce que le port 3391 en udp est encore nécessaire ? 🙂

    • Hicham KADIRI dit :

      RDP s’appuie sur le TCP et non UDP. C’est un protocol Stateful et non pas Stateless. Donc pas de port RDP UDP à ouvrir, simplement en TCP :).

      A+
      #HK

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion /  Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion /  Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion /  Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion /  Changer )

Connexion à %s