Dans ce troisième article, nous allons étudier les fondamentaux de notre bastion : concept de mise en œuvre, implémentation réseau et matrice de flux. L’article se conclura pas une analyse des risques sur chaque éléments.
Royal TS, Royal Server et Yubikey
Bastion avec Royal TS et Royal Server
Télécharger les cinq articles en PDF !
Bastion avec Royal TS et Royal Server
Schéma de principe
Le schéma ci-dessous représente le principe mis en œuvre d’une connexion au travers du bastion, étape par étape :
- L’utilisateur dispose d’un document Royal TS sur son poste de travail ou un partage réseau accessible – le document contient un objet de configuration Royal Server qui contient son login (si le mot de passe y est stocké, un mot de passe sera demandé)
- L’objet de configuration Royal Server est déverrouillé et sera présenté auprès du serveur Royal Serveur pour les étapes 3, 4 et 5
- L’utilisateur demande à parcourir la liste des documents présent dans le Document Store de Royal Server
- Royal Server vérifie les permissions de l’utilisateur
- L’utilisateur sélectionne un document : avant de pouvoir le lire, un code TOTP sera demandé à l’utilisateur pour le compte utilisateur
- L’utilisateur lance une connexion vers un serveur cible : pour établir le tunnel SSH avec Royal Server, un code TOTP pour le compte opérateur est demandé préalablement.
- Une fois le tunnel établi, une connexion RDP est ouverte entre Royal Server et le serveur ciblé avec le compte opérateur.
Pour plus de sécurité, l’utilisateur ne peut pas lire ou copier les mots de passe contenus dans le document Royal TS fournit par Royal Server (ces informations sont saisies et maintenues par l’administrateur).
Le fichier est également protégé par un mot de passe, connu de l’utilisateur, afin de lui permettre de modifier les connexions existantes ou d’en ajouter. Le mot de passe peut être simple, le document ne pouvant être exfiltrer de Royal Server et l’accès primaire étant conditionner à une authentification forte.
L’administrateur du bastion (par défaut un administrateur du domaine) est le seul a pouvoir gérer le document – ce dernier définie l’exigence de TOTP, configure les comptes utilisateurs et assure le pairing du téléphone.
Enfin, pour renforcer la sécurité des comptes, deux systèmes de TOTP différents sur deux périphériques différents seront nécessaires : le compte utilisateur s’appuie sur le TOTP de Yubikey et le TOTP du compte opérateur sur celui de Microsoft via le téléphone professionnel de l’utilisateur.
Intégration réseau
Flux Tier 2 vers Service SaaS
Lors de l’authentification forte, un accès au service SaaS sera nécessaire sur le port TCP/443. Ce service sera accédé par le smartphone de l’utilisateur ou une application installée sur le PC (Yubico Authenticator).
Ce flux n’est donc nécessaire que lorsque l’équipement en charge de la récupération du code TOTP est connecté au réseau de l’entreprise.
Flux Tier 2 vers Tier 0
Le poste utilisé pour la connexion n’établit de connexion que vers le serveur RS et le serveur Secure Gateway (ce peut-être le même serveur ou deux serveurs différents). Seul les flux TCP/54899 et TCP/22 sont requis ; le serveur RS est le point d’entré indispensable pour l’accès au Document Store. Le serveur Secure Gateway vous permet de fermer les flux d’administration entre les tiers
Flux interne Tier 0
En dehors des flux habituel de production, le serveur RS aura besoin de réaliser des requêtes LDAP auprès des contrôleurs de domaine (TCP/389) et le serveur Secure Gateway d’établir une connexion en RDP avec la cible (TCP/389) ou en SSH pour les serveurs Linux (TCP/22).
Considération relative à la sécurité
Puisque le point d’initialisation de l’accès est en Tier 2, ce dernier est le plus susceptible d’être compromis : il est donc essentiel de respecter les règles suivantes :
- Le compte établissant la connexion vers le bastion pour atteindre le Document Store doit appartenir au Tier 2.
- Le compte accédant au serveur RS doit être de même nature que le compte de login sur la station hébergeant Royal TS (i.e. utilisateur pour un PC bureautique, opérateur pour un PC dans un réseau d’administration Tier 2), afin d’éviter une escalade de privilège dans le Tier.
- Les mots de passe des comptes de Tier 0 ne doivent pas être accessible depuis l’environnement de Tier 2 (saisie, récupération par copier/coller ou affichage).
- L’accès au Document Store doit être protégé à deux niveaux : l’ouverture doit être conditionné par une authentification unique (MFA) et le contenu sensible du document ne doit pas pouvoir être modifié par l’utilisateur Tier 2.
- Seul un accès RDP est permis au travers de la Secure Gateway. Idéalement, cet accès devrait permettre une connexion sur un serveur d’administration central pour réaliser tout autre opération de maintenance.
- Les accès type WinRM, remoteShell, … ne sont pas permis vers les systèmes du Tier 0 (ces accès doivent être fait depuis un serveur du Tier 0 exclusivement).
Scénarios d’attaques et contre-mesures
Pour qu’un bastion soit efficace, il est nécessaire de se positionner dans un contexte de compromission pour essayer d’évaluer sa robustesse. La chaine de risque serait la suivante :
Vous trouverez ci-après les différentes analyses sur le modèle présenté et les contre-mesures misent en œuvre.
Cas A : compromission du poste de l’utilisateur
| Risque | Le poste de l’utilisateur est sous le contrôle de l’attaquant. Dans ce scénario, l’attaquant a la capacité d’installer ses outils, de maintenir sa présence dans le SI de manière persistante et de voler tout compte qui se connecte à la machine. Il peut également faire une analyse du réseau pour détecter des cibles potentielles ou capturer le flux réseau. |
| Conséquences | Le compte utilisateur est compromis et pourrait permettre un accès au serveur Royal Server (1), au Document Store (2) et au fichier Royal TS local qui contient les informations de connexion au serveur Royal Server (3). |
| Contre-mesure | (1) La mise en place du MFA rendra le compte inutilisable (2) La mise en place d’un second MFA rendra l’accès impossible (3) Le chiffrement du fichier empêchera son exploitation. Le mot de passe doit être suffisamment complexe pour éviter que ce dernier soit cassé. Note : le MFA ne doit pas être un code OTP sur le poste du client (accessible). |
Cas B : le compte utilisateur a été volé
| Risque | Le compte de l’utilisateur est sous le contrôle de l’attaquant. Dans ce scénario, l’attaquant a un accès sur le système et peut arriver à compromettre tout le poste de travail (voir cas A). Les fichiers accessibles par l’utilisateur le sont également pour l’attaquant. |
| Conséquences | Le compte utilisateur est compromis et pourrait permettre un accès au serveur Royal Server (1), au Document Store (2) et au fichier Royal TS local qui contient les informations de connexion au serveur Royal Server (3). |
| Contre-mesure | (1) La mise en place du MFA rendra l’accès impossible (2) La mise en place d’un second MFA rendra l’accès impossible (3) Le chiffrement du fichier empêchera son exploitation. Le mot de passe doit être suffisamment complexe pour éviter que ce dernier soit cassé. |
Cas C : le fichier Royal TS local est volé
| Risque | Le fichier peut être utilisé depuis un poste inconnu. |
| Conséquences | Le compte utilisateur est inclus dans le fichier et pourrait permettre un accès au serveur Royal Server (1), au Document Store (2) et aux informations de connexion au serveur Royal Server (3). |
| Contre-mesure | (1) La mise en place du MFA rendra l’accès impossible (2) La mise en place d’un second MFA rendra l’accès impossible (3) Le chiffrement du fichier empêchera son exploitation. Le mot de passe doit être suffisamment complexe pour éviter que ce dernier soit cassé. |
Cas D : la clé Yubikey a été perdue ou volée
| Risque | La clé peut être utilisée par l’attaquant. |
| Conséquences | L’accès au server Royal Server (1) devient possible ainsi que l’accès au Document Store (2). La clé peut être utilisé (3). |
| Contre-mesure | (1) Le compte doit également avoir été volé, ou le fichier local. (2) La mise en place d’un second MFA rendra l’accès impossible. (3) Utiliser un code OTP avec un smartphone en NFC ou USB. |
Cas E : la clé Yubikey a été oubliée
| Risque | Aucun. |
| Conséquences | L’administrateur ne peut plus se connecter au serveur Royal Server (1). |
| Contre-mesure | (1) L’administrateur peut reconfigurer le compte pour utiliser un autre accès MFA. |
Cas F : Le serveur Royal Server est compromis
| Risque | Compromission du Tier 0. |
| Conséquences | L’accès à la configuration de Royal Server est possible pour l’attaquant. De ce fait, ce dernier peut créer un compte et déjouer toutes les sécurités pour obtenir un accès permanent depuis l’extérieur du Tier 0 (1). D’autre part, l’attaquant peut voler des comptes (2) qui se connecteraient sur le système et réaliser des mouvements latéraux (pass-the-hash ou rejeu d’identité). Si un compte à privilège se connecte sur le serveur, l’attaquant peut compromettre le domaine en entier (3). |
| Contre-mesure | (1) Superviser régulièrement la configuration du serveur et mettre ne place une politique de contrôle de l’accès. Durcir le système avec des règles strictes. Interdire l’accès en RDP et utiliser un serveur physique. (2) Limiter les comptes ayant le droit de se connecter au serveur. Considérer le serveur comme aussi sensible qu’un contrôleur de domaine. (3) Interdire la connexion de comptes ayant des privilèges Active Directory sur le serveur. |
Cas G : le Document Store est compromis à distance
| Risque | Récupération des accès aux serveurs du Tier 0. |
| Conséquences | L’attaquant peut récupérer les comptes déclarés dans les fichiers de connexion (1). |
| Contre-mesure | (1) L’ouverture du fichier doit être protéger par un code MFA. Le cache de code doit être réduit au minimum. |
Cas H : Le Document Store est compromis localement
| Risque | Récupération des accès aux serveurs du Tier 0. |
| Conséquences | L’attaquant peut récupérer les comptes déclarés dans les fichiers de connexion (1). L’attaquant peut récupérer les fichiers modèles (2). |
| Contre-mesure | (1) L’ouverture du fichier doit être protéger par un code MFA. Le cache de code doit être réduit au minimum. Les fichiers doivent être chiffrés intégralement. (2) Les fichiers modèles ne doivent pas contenir d’information d’authentification. |
Cas I : Le smartphone est compromis
| Risque | Accès au code TOTP de l’authenticator. |
| Conséquences | L’attaquant peut s’identifier en lieu et place de l’administrateur (1). |
| Contre-mesure | (1) Ce risque est conditionné à la compromission de l’accès primaire au serveur Royal Server. |
Cas J : Le smartphone est volé ou perdu
| Risque | Accès au code TOTP de l’authenticator. |
| Conséquences | L’attaquant peut s’identifier en lieu et place de l’administrateur (1). |
| Contre-mesure | (1) Ce risque est conditionné à la compromission de l’accès primaire au serveur Royal Server. |
Cas K : Le smartphone est oublié
| Risque | Aucun. |
| Conséquences | L’administrateur ne peut plus se connecter au serveur Royal Server (1). |
| Contre-mesure | (1) L’administrateur peut reconfigurer le compte pour utiliser un autre accès MFA. |
Cas L : Le compte administrateur est volé (non-administrateur de Royal Server)
| Risque | Compromission du Tier 0. |
| Conséquences | L’attaquant peut se connecter au système du Tier 0 (1) s’il obtient un accès à ces derniers (2). |
| Contre-mesure | (1) Surveiller l’activité des comptes. (2) Interdire l’accès distance depuis un serveur autre que la Secure Gateway. |
Cas L : Le compte administrateur est volé (administrateur de Royal Server)
| Risque | Compromission du Tier 0 et du serveur Royal Server. |
| Conséquences | L’attaquant peut se connecter au système du Tier 0 (1) s’il obtient un accès à ces derniers (2). L’attaquant peut prendre le contrôleur de Royal Server (voir les cas F, G et H) (3). |
| Contre-mesure | (1) Surveiller l’activité des comptes. (2) Interdire l’accès distance depuis un serveur autre que la Secure Gateway. (3) Avoir mis en place les contre-mesures des cas F, G et H. |
Cas M : La Secure Gateway est compromise
| Risque | Compromission du Tier 0. |
| Conséquences | L’attaquant peut se connecter au système du Tier 0 (1) s’il obtient un accès valide à ces derniers (2). |
| Contre-mesure | (1) Surveiller l’activité des comptes. (2) Utiliser le Smart-Card-Logon ou une solution de MFA. |
Cas N : Un serveur du Tier 0 est compromis
| Risque | Compromission du Tier 0. |
| Conséquences | L’attaquant peut se connecter au système du Tier 0 (1) et voler les comptes qui se connecte au système compromis (2). |
| Contre-mesure | (1) Surveiller l’activité des comptes. (2) Utiliser le Smart-Card-Logon ou une solution de MFA. |
Cas O : Le contrôleur de domaine est compromis
| Risque | Compromission du domaine. |
| Conséquences | Perte de contrôle complète du SI. |
| Contre-mesure | Interdire l’administration des Contrôleurs de domaine Directement depuis Royal Server. Mettre les comptes administrateurs du domaine dans le groupe Protected Users afin de bloquer leur utilisation au travers de la Secure Gateway. Utiliser un serveur de rebond au travers de Royal Server pour se connecter aux contrôleurs de domaine. Mettre en place le Smart-Card-Logon pour les comptes d’administration du domaine. |
