Cet article a pour but de voir comment sécuriser un serveur Remote DeskTop Service (RDS / TSE).
Objectifs :
- Sécuriser les serveurs Remote Desktop Service sous Windows 2008 R2.
- Empêcher les utilisateurs de copier des fichiers, exécuter des commandes systèmes.
- Ne pas perturber le fonctionnement du système.
- Permettre aux administrateurs d’administrer le système sans restrictions.
- Permettre aux utilisateurs d’exécuter les programmes de la suite Office 2007.
Sécurisation du serveur remote desktop service (WINDOWS 2008 R2)
Pour cela, on va :
- Désactiver de nombreuses fonctionnalités de l’interface graphique via les stratégies de groupe.
- Bloquer l’exécution de toutes les applications sauf celles qui sont autorisées via Applocker.
Déplacer le serveur remote desktop host service dans l’OU REMOTEDESKTOPSERVER
La première étape consiste à créer une unité d’organisation et de déplacer les comptes ordinateurs des serveurs Remote DeskTop Services dans cette unité d’organisation.
Créer et lier un objet de stratégie de groupe au niveau de l’unité d’organisation « RemoteDeskTopServers » appelé « Secure Remote Desktop Servers » :
Configuration des GPO pour restreindre les fonctionnalités de l’interface graphique
Pour sécuriser le serveur Remote DeskTop Service, il faut :
- Désactiver le presse papier et le mappage de lecteur réseau au niveau de la console MMC « Terminal Services Configuration ».
- Bloquer l’accès à CMD par GPO
- Bloquer l’accès à certains programmes depuis l’aide : « Configuration ordinateur | Modèles d’administration | Systèmes | Restreindre l’exécution de ces programmes depuis l’aide en ligne».
- Bloquer l’accès à l’invite de commande : Configuration Utilisateurs | Modèles d’administration | Système | Désactiver l’accès à l’invite de commande.
- Définir la liste des applications autorisées : Configuration Utilisateurs | Modèles d’administration | Système | Exécuter seulement les applications Windows autorisées.
- Activer l’interface de l’utilisateur personnalisée : Configuration Utilisateurs | Modèles d’administration | Système | Interface Utilisateur personnalisée.
- Empêcher l’accès aux outils de modification du registre : Configuration Utilisateurs | Modèles d’administration | Système | Empêche l’accès aux outils de modification du registre.
- Configurer la GPO pour que les GPO de type « Configuration Utilisateur » s’applique à un compte ordinateur.
- Restreindre l’accès à certaines fonctionnalités / menu dans les programmes Office via GPO (utilisation ADM Office).
- Activer le pare feu de Windows 2008 R2 pour bloquer tous les accès sauf aux contrôleurs de domaine.
- Appliquer les préconisations des articles suivants :
Remarque :
Il n’y a plus de visionneuse des fichiers d’aide par défaut sous Windows 2008 R2 :
http://support.microsoft.com/kb/917607/en-us
Bloquer l’application des GPO aux administrateurs du serveur
Afin que les administrateurs puissent gérer le serveur, interdire l’application de la GPO aux groupes correspondant aux administrateurs du serveur (administrateurs du domaine dans l’exemple ci-dessous).
Pour cela, il faut refuser la permission « Appliquer la stratégie de groupe » au niveau des permissions de l’objet stratégie de groupe.
Voir article Microsoft ci dessous pour plus d’informations :
http://technet.microsoft.com/en-us/library/bb742376.aspx
« Figure 11 belows shows an example of the security settings that allow everyone to be affected by this GPO except the members of the Management group, who were explicitly denied permission to the GPO by setting the Apply Group Policy ACE to Deny. Note that if a member of the Management group were also a member of a group that had an explicit Allow setting for the Apply Group Policy ACE, the Deny would take precedence and the GPO would not affect the user« .
À savoir sur APPLOCKER
- Le mode de fonctionnement d’AppLocker est « Tout interdire sauf ». Lorsque l’on crée la première règle AppLocker, on crée indirectement la règle par défaut (non configurable), tout interdire.
- AppLocker ne gère pas les application posix ou le sous système 16 bits. Il faut donc bloquer ces deux sous systèmes. Voir stratégie Computerconfiguration/Administrative Templates/Windows-Components/Applicationcompatibility et activer le paramètre « Deny access to 16bit applications ».
- Il y a un journal de sécurité dédié pour Applocker dans Windows 2008 R2. Cela peut être pratique pour déterminer les exécutables qui sont nécessaires aux bons fonctionnement de vos applications.
- Il est possible de configurer Applocker en mode Audit uniquement. Attention la configuration par défaut est en mode appliqué.
- Surveiller la présence des erreurs Microsoft-Windows-AppLocker 8004. Elles permettent de savoir quels sont les applications qui sont interdites. Il faut ensuite identifier si c’est normal que cette soit interdite ou non.
Log Name: Microsoft-Windows-AppLocker/EXE and DLL
Source: Microsoft-Windows-AppLocker
Date: 19/04/2011 19:21:15
Event ID: 8004
Task Category: None
Level: Error
Keywords:
User: SYSTEM
Computer: fr92sv0004.newlife.lan
Description: %SYSTEM32%TASKHOST.EXE was prevented from running.- AppLocker gère les formats de fichiers suivants : Les formats pris en charge :
Exe : via règles « Executables Rules »
Com : via règles « Executables Rules »
Msi : via règles « Windows Installer »
Msp : via règles « Windows Installer »
ps1 : via règles « Script Rules »
bat : via règles « Script Rules »
cmd : via règles « Script Rules »
vbs : via règles « Script Rules »
js: via règles « Script Rules »
dll : si la case « Enable the dll rule collection » est coché. Attention au performance. Il sera aussi nécessaire de savoir quels sont les DLL utilisés par les applications (très dangereux).- Si un Applocker ne peut pas vérifier le certificat d’une application autorisée à l’aide d’une règle « Publisher », l’application est interdite.
- “If the application’s certificate expires while the rule is enforced, the binary file will be blocked from running. A binary file is considered signed as long as the timestamp happened during the validity period of both the signing of the certificate and the time stamping of the certificates in the certificate chain.”
Pour plus d’informations sur Applocker :
- http://windowsteamblog.com/windows/b/springboard/archive/ 2009/08/18/understanding-windows-7-applocker.aspx
- http://technet.microsoft.com/en-us/library/dd723678(WS.10).aspx
- http://technet.microsoft.com/en-us/library/ee844118(WS.10).aspx
- http://technet.microsoft.com/en-us/library/ee619725(WS.10).aspx
- http://technet.microsoft.com/fr-fr/library/dd723686(WS.10).aspx
- http://www.windowsnetworking.com/articles_tutorials/Introduction-AppLocker-Part1.html
- http://www.windowsnetworking.com/articles_tutorials/Introduction-AppLocker-Part2.html
- http://www.windowsnetworking.com/articles_tutorials/Introduction-AppLocker-Part3.html
- http://www.windowsnetworking.com/articles_tutorials/Introduction-AppLocker-Part4.html
- http://technet.microsoft.com/en-us/windows/dd320283.aspx
- http://microsoftplatform.blogspot.com/2011_01_01_archive.html
- http://technet.microsoft.com/en-us/library/ee460956(WS.10).aspx
- http://technet.microsoft.com/en-us/library/ee460957(WS.10).aspx
- http://technet.microsoft.com/en-us/library/dd723678(WS.10).aspx
- http://microsoftplatform.blogspot.com/2011_01_01_archive.html
- http://64.4.11.252/en-us/library/ee619725(WS.10).aspx#BKMK_CertRevocation
Mise en œuvre d’APPLOCKER
Etape 1 : créer et personnaliser les règles par défaut Applocker :
- Editer l’objet de stratégie de groupe.
- Créer les règles par défaut. Ce sont ces règles qui vont nous permettre aux systèmes de continuer à fonctionner correctement. Pour cela, cliquer sur « Create Default rules » dans les sections « Executables Rules », « Windows Installer » et « Script Rules ». On obtient à chaque fois trois règles autoriser.
- Laisser uniquement la règle avec le groupe BUILTINAdministrateurs (comprendre les comptes membres du groupe Administrators de la base SAM locale). En effet les règles pour les utilisateurs non administrateur sont trop permissives.
- Créer une règle Autoriser tous les fichiers pour les comptes suivants (même règle que pour le groupe BUILTINAdministrateurs) :
- NT AUTHORITYSYSTEM
- NT AUTHORITYLOCAL SERVICE
- NT AUTHORITYNETWORK SERVICE
- NT AUTHORITYNETWORK SERVICE
- NT AUTHORITYSERVICE.Remarque :
- Il peut être nécessaire d’autoriser d’autre entité de sécurité prédéfini comme IUSR
- Le log ci-dessous semble indiquer que par défaut le compte SYSTEM n’a plus accès à tout.
Log Name: Microsoft-Windows-AppLocker/EXE and DLL
Source: Microsoft-Windows-AppLocker
Date: 20/04/2011 16:06:47
Event ID: 8004
Task Category: None
Level: Error
Keywords:
User: SYSTEM
Computer: fr92sv0004.newlife.lan
Description: %SYSTEM32%CONHOST.EXE was prevented from running.Etape 2 : Les exécutables systèmes à autoriser :
A cette étape, seuls les membres du groupe administrateurs et les comptes SYSTEM peuvent ouvrir une session sur le serveur. Si un utilisateur essaie d’ouvrir une session, cela échoue. La session se ferme car le processus userinit.exe ne peut pas s’exécuter correctement.
Le tableau ci-dessous liste les exécutables à autoriser pour le groupe « Authenticated users » :
Processus à autoriser pour « Authenticated Users » :
- c:windowssystem32DLLHOST.exe : permet de gérer les librairies virtuelles DLL :
- c:windowsexplorer.exe : Explorateur Windows
- c:windowssystem32Userinit.exe : processus qui initie la session de l’utilisateur. Charge l’explorateur Windows.
- c:windowssystem32Dwm.exe :
- c:windowssystem32gpupdate.exe : permet d’actualiser les stratégies de groupe.
- c:windowssystem32CONHOST.EXE : ce processus est obligatoire si l’on veut que l’utilisateur puisse exécuter un utilitaire en invite de commande comme GPUPDATE.
- c:windowssystem32rdpclip.exe : permet copier / coller entre le client RDS et le serveur RDS : http://support.microsoft.com/kb/309825/en-us
- c:windowssystem32Rdpinit.exe : dans le cadre d’une session RemoteApp, lance le processus RDPSHELL.EXE (une version mineur d’explorer.exe) :
- c:windowssystem32Rdpshell.exe : s’exécute à la place d’explorer.exe dans le cadre d’une session RemoteApp.
- c:windowssystem32RUNDLL32.EXE : permet de charger des DLL comme un programme classique WIN32 :
- c:windowssystem32RUNONCE.EXE : permet d’exécuter les programmes au démarrage de la session.
- c:windowssystem32SETHC.EXE : permet les fonctionnalités d’accessibilité (touches rémanentes…).
- c:windowssystem32SLUI.exe : activation Windows
- c:windowsSPLWOW64.exe : si Windows 2008 R2 64 bits, permet l’exécution des programmes 32bit avec la couche driver 64 bit :
- c:windowssystem32TSTHEME.EXE :
- c:windowssystem32TASKHOST.EXE: permet de lancer des DLL en tant que processus.
- c:windowssystem32WERMGR.EXE : Windows Erreur Manager.
- c:windowssystem32ctfmon.exe: ctfmon.exe active le TIP (Text Input Processor) des modes d’entrée complémentaires ainsi que la barre de langue Microsoft Office.
- c:windowssystem32usrlogon.cmd : script de login par défaut.
- c:windowsapplication Compatibility Scripts : Script de login par défaut.
- c:windowsystem32logon.scr : penser à autoriser les écrans de veille.
- \nom_dns_domainenetlogon : permet d’exécuter les scripts de login.
- \nom_dns_domainesysvol : permet d’exécuter les scripts de login
- \nom_netbios_domainenetlogon : permet d’exécuter les scripts de login
- \nom_netbios_domainesysvol : permet d’exécuter les scripts de login
- %logonserver%netlogon : permet d’exécuter les scripts de login.
- %logonserver%sysvol : permet d’exécuter les scripts de login.
- c:Program FilesCitrix : excétables Citrix XenApp (chemin par défaut).
- c:Temp*getpaths.cmd :
Pour plus d’informations, voir articles Microsoft :
- http://microsoftplatform.blogspot.com/2011/01/remote-control-rds-session-in-mixed_26.html
- http://blogs.technet.com/b/askperf/archive/2008/02/22/ws2008-terminal-services-remoteapps.aspx
Applocker dispose d’un journal de sécurité qui permet de savoir quels exécutables ont été autorisés ou bloqués. Le plus simple est d’exécuter les applications avec Applocker d’activer pour déterminer les applications à autoriser.
Etape 3 : Création des règles Applocker pour les « Authenticated users » :
Avec AppLocker, on peut maintenant :
- Créer une règle qui s’applique à un utilisateurs ou à un groupe d’utilisateur.
- Créer des règles qui se basent sur les signatures numériques des programmes. La majorité des programmes sont maintenant signés par les éditeurs (à l’aide de certificat) afin de valider que le programme n’a pas été modifiés par un tiers et prouvé l’identité de l’éditeur (programme provenant d’un éditeur de confiance). Dans l’exemple ci-dessous j’autorise toutes les versions d’Explorer.exe qui sont supérieur à la version 6.0.
- Générer automatiquement des règles à l’aide de la fonctionnalité « Generate Rules » en scannant un répertoire.
On va maintenant créer les règles pour permettre aux utilisateurs non administrateurs d’utiliser les programmes de la suite Office 2007.
Pour cela, on va utiliser la nouvelle fonction de création automatique des règles en cliquant sur « Automatically Generate Rules ».
On va demander à cet assistant de créer automatiquement des règles « Publisher » et de générer des règles de chemin d’accès pour les exécutables non signées.
On va éventuellement supprimer tous les exécutables Office que l’on ne souhaite pas autoriser.
Etape 4 : Configurer le service « Application Identity » :
Il faut maintenant configurer le service « Application Identity » pour démarrer automatiquement. Sans ce service AppLocker ne fonctionne pas.
On peut faire cela manuellement ou mieux par GPO (interface grisée dans la console services.msc).
