GPO – Comment configurer AppLocker pour sécuriser vos postes Windows ?


I. Présentation

Dans ce tutoriel, nous allons voir comment configurer AppLocker par GPO pour sécuriser les postes Windows en bloquant l’exécution et l’installation de logiciels.

La solution AppLocker est la remplaçante d’une autre fonction similaire, configurable par GPO, mais moins complète : la stratégie de restriction logicielle.

AppLocker permet de créer des règles pour définir les applications autorisées à être exécutées par les utilisateurs lambdas sur les machines du domaine. Grâce à ces restrictions, vous allez pouvoir lutter contre l’installation de logiciels non approuvés par le service informatique, de logiciels crackés en version portable, des logiciels portables au sens large, mais cela va permettre aussi de limiter l’installation de malwares sur les postes de travail.

AppLocker va permettre d’agir sur quatre types d’éléments : les exécutables, les installeurs au format Windows Installer (package MSI), les scripts et les applications modernes au format APPX.

Pour en savoir plus sur les différences entre AppLocker et les stratégies de restriction logicielle, consultez la documentation Microsoft.

Qu’allons-nous mettre en place ?

Pour ce tutoriel AppLocker, nous allons apprendre à créer une politique afin de bloquer l’exécution et l’installation de tous les logiciels, à l’exception :

  • Des logiciels présents dans Program Files (car ils sont déjà installés)
  • Des logiciels présents dans le dossier d’installation de Windows (les utilitaires natifs et les composants indispensables au bon fonctionnement de Windows s’y trouvent…)
  • Des applications modernes signées
  • De l’application Microsoft Teams (pour vous montrer le principe de création d’une exception)

Cette politique sera appliquée uniquement aux membres d’un groupe de sécurité Active Directory.

Pour suivre ce tutoriel, vous avez besoin de deux machines :

  • Un contrôleur de domaine Active Directory
  • Une machine pour tester AppLocker, Windows 10 ou Windows 11, c’est très bien ! Voire même un serveur.

II. AppLocker : les systèmes d’exploitation pris en charge

La solution AppLocker existe depuis quelques années déjà puisqu’elle a été introduite dans Windows à l’occasion de la sortie de Windows 7 et Windows Server 2008 R2. Au fil des versions et des sorties de Windows, Microsoft a fait évoluer AppLocker pour ajouter des fonctionnalités.

AppLocker est pris en charge sur Windows 10 et Windows 11 : vous pouvez miser sans problème sur cette fonctionnalité. Il en va de même pour Windows Server, si vous souhaitez mettre en place une politique AppLocker sur un serveur RDS.

Néanmoins, il y a un « mais » et c’est un petit détail qui fait mal. Pour utiliser AppLocker sur les postes de travail, vous devez utiliser une édition Entreprise ou Education de Windows. Autrement dit, AppLocker ne fonctionnera pas sur Windows 10 Pro, ni Windows 11 Pro, mais il fonctionnera sur Windows 10 Enterprise et Windows 10 Education.

Pour Windows Server, cette restriction n’existe pas pour les versions à partir de Windows Server 2012.

Maintenant que vous avez pris en compte de ce détail, nous allons pouvoir commencer la configuration.

III. Création d’un groupe pour appliquer la règle AppLocker

Avant d’attaquer la GPO AppLocker, nous allons créer un groupe de sécurité sur lequel va s’appliquer notre politique AppLocker.

À partir de la console « Utilisateurs et ordinateurs Active Directory« , j’ai créé le groupe de sécurité « GG-Restrictions-Logiciels« . Vous pouvez le créer avec le Centre d’administration Active Directory ou avec PowerShell : vous avez le choix.

Au sein de ce groupe, j’ai ajouté un salarié de l’entreprise pour lui appliquer les restrictions : « guy.mauve« .

IV. Configuration d’une GPO AppLocker

À partir de la console de Gestion des stratégies de groupe, créez une nouvelle GPO et liez cette GPO à une OU qui cible vos machines. Pour ma part, je vais cibler l’OU qui contient la machine où se connecte « guy.mauve » et je vais nommer cette GPO « AppLocker« , tout simplement.

Ensuite, modifiez cette GPO à l’aide d’un clic droit sur son nom.

A. Configurer le service Identité de l’Application

Pour qu’AppLocker fonctionne, il faut que le service « Identité de l’application » (AppIDSvc) soit actif et démarré automatiquement. Ce n’est pas le cas par défaut. Nous allons configurer la GPO pour configurer ce service sur nos postes de travail.

Parcourez l’arborescence comme ceci :

Configuration ordinateur > Stratégies > Paramètres Windows > Paramètres de sécurité > Services système

Ouvrez les propriétés du service « Identité de l’application« , cochez la case « Définir ce paramètre de stratégie » et cliquez sur « Automatique« .

Validez. Première étape réussie !

B. Créer les règles AppLocker

Pour configurer AppLocker, parcourez l’arborescence de cette façon :

Configuration ordinateur > Stratégies > Paramètres Windows > Paramètres de sécurité > Stratégies de contrôle de l’application > AppLocker

Ensuite, cliquez sur le lien « Configurer la mise en application des règles » sur la partie de droite.

Pour chaque type de règles, cochez l’option « Configuré » et basculez sur « Appliquer les règles« .

Note : j’utilise le mode « Appliquer les règles » dès maintenant, mais en phase de test, c’est pertinent de commencer par une phase d’audit et d’analyse en sélectionnant « Auditer uniquement« . De cette façon, les événements AppLocker seront générés, mais il n’y aura pas de restrictions effectives sur la machine.

Validez avec « OK« .

Développez « AppLocker« , quatre catégories vont s’afficher : règles de l’exécutable (EXE), règles Windows Installer (MSI), règles de scripts et règles d’applications empaquetées (APPX).

Je vous invite à générer les règles par défaut pour les « Règles de l’exécutable« , les « Règles Windows Installer » et les « Règles d’applications empaquetées« . Pour cela, effectuez un clic droit sur la catégorie et cliquez sur le bouton « Créer des règles par défaut« .

Si l’on regarde la partie « Règles de l’exécutable« , on peut voir que cette action crée plusieurs règles pour autoriser « Tout le monde » à exécuter les programmes situés dans « Program Files » et « Windows« . En complément, les administrateurs n’auront pas de restrictions. C’est une bonne base pour la suite.

Dans le même esprit, une règle est créée pour les applications empaquetées.

Désormais, passons à la création de notre règle personnalisée. Effectuez un clic droit sur « Règles de l’exécutable » et cliquez sur « Créer une règle« . Un assistant va se lancer.

Je vous rappelle que l’objectif est de créer une règle pour empêcher le groupe « GG-Restrictions-Logiciels » d’exécuter et d’installer des logiciels, à part ceux présents dans « Program Files » et « Windows ».

Cliquez sur « Suivant » lorsque le premier écran apparaît.

Choisissez l’action « Refuser » et pour le champ « Utilisateur ou groupe« , sélectionnez le groupe « GG-Restrictions-Logiciels« . Poursuivez.

Lorsque l’on crée une règle, il y a trois types de conditions principales :

  • Editeur : règle basée sur l’éditeur de l’exécutable. Par exemple : autoriser uniquement l’exécutable d’un éditeur spécifique, avec un nom spécifique, dans une version spécifique, ou autoriser tous les exécutables de l’éditeur Microsoft.
  • Chemin d’accès : règle basée sur un chemin d’accès. Par exemple : bloquer l’exécution de tous les exécutables situés sur le Bureau de l’utilisateur.
  • Hachage du fichier : règle basée sur le hash de l’exécutable, tout en sachant qu’un hash va évoluer pour un même logiciel d’une version à l’autre.

Choisissez « Chemin d’accès » et continuez.

Pour le chemin d’accès, précisez « *.* » : cela signifie que l’on refuse tous les exécutables ! Mais, nous allons créer deux exceptions à la prochaine étape.

Sous « Ajouter une exception« , choisissez « Chemin d’accès » et cliquez sur le bouton « Ajouter« . Créez une première exception avec ce chemin :

%PROGRAMFILES%*

Répétez l’opération avec ce chemin :

%WINDIR%*

Cela va permettre d’autoriser les exécutables situés dans « Program Files » et le dossier d’installation de Windows. Cliquez sur « Suivant ».

Nommez cette règle et indiquez une précision si vous le souhaitez. Cliquez sur « Créer« .

Nous obtenons le résultat suivant :

Je vous invite à créer une règle similaire, mais dans la catégorie « Règles Windows Installer » pour bloquer les fichiers MSI.

Une fois que c’est fait, la GPO est prête, nous allons tester depuis un poste client.

V. Tester la configuration AppLocker

Sur le poste client, je me connecte avec l’utilisateur « guy.mauve » puisqu’il est membre du groupe « GG-Restrictions-Logiciels« . Ensuite, j’effectue un « gpupdate /force » et pendant ce temps je télécharge quelques logiciels : Putty, Firefox Portable, Chrome, Teams et 7-Zip.

Le problème, c’est que l’administrateur système bloque l’exécution de tous ces exécutables ! Et oui, notre stratégie AppLocker rentre en jeu et contrôle l’exécution de chaque fichier ! Comme l’exécutable n’est pas dans un dossier autorisé (Program Files ou Windows), il est bloqué !

Dans le même esprit, avec un package MSI (suite à la création de la seconde règle).

Si l’on regarde dans l’Observateur d’événements de la machine locale, on peut voir que tous les événements AppLocker sont enregistrés. Vous pouvez les retrouver dans :

Journaux des applications et des services > Microsoft > Windows > AppLocker

Ensuite, il y a un journal par catégorie de règles, ce qui est appréciable pour le debug. On peut voir que « guy.mauve » a tenté d’exécuter « Putty.exe » et que l’exécution a été empêchée. Là ce sont des exécutables sans réels dangers, mais ce serait un logiciel malveillant, ce serait bloqué également et d’autant plus appréciable !

J’en profite pour parler du module PowerShell AppLocker. Il permet de récolter des informations assez précises, comme par exemple la liste des applications refusées pour un utilisateur avec la commande « Get-AppLockerFileInformation« .

Get-AppLockerFileInformation -EventLog -EventType Denied

À l’inverse, on peut voir ce qui a été autorisé :

Get-AppLockerFileInformation –EventLog –EventType Allowed

VI. AppLocker : créer une exception pour autoriser l’installation de Teams

Pour finir, nous allons apprendre à créer une exception pour autoriser l’installation d’un logiciel spécifique, en l’occurrence Teams, malgré les restrictions mises en place. Un cas très courant puisque Teams peut s’installer sans les droits Administrateur étant donné qu’il s’installe dans le répertoire « AppData » du profil de l’utilisateur, comme d’autres applications.

Lorsque l’on télécharge Teams, on obtient le fichier suivant : Teams_windows_x64.exe

La première chose à faire, c’est ajouter une nouvelle exception sur notre règle située dans « Règles de l’exécutable« . Effectuez un clic droit sur la règle « Empêcher installation de logiciels » et cliquez sur « Propriétés« .

Au sein de l’onglet « Exceptions« , choisissez « Editeur » sous « Ajouter une exception » puis cliquez sur le bouton « Ajouter« .

Vous devez indiquer le chemin vers l’exécutable de Teams pour que l’assistant AppLocker récupère des informations sur l’exécutable, notamment l’éditeur. Ensuite, les différents champs seront complétés automatiquement : Editeur, Nom du produit, Nom du fichier et Version du fichier.

Prenez le curseur à gauche et positionnez-le sur « Editeur ». Cela va permettre d’accepter toutes les valeurs pour les autres champs et d’autoriser toutes les applications signées par l’éditeur Microsoft. En fait, on pourrait être plus restrictif et autoriser seulement le produit « MICROSOFT TEAMS », mais le problème c’est que Teams s’appuie sur plusieurs composants. Si l’on ne crée par une autorisation plus large, l’installation échouera. Validez.

La création d’une exception dans AppLocker ne suffit pas : même avec cette exception, l’installeur de Teams sera bloqué ! En fait, en plus d’ajouter une exception, il faut créer une règle pour autoriser l’éditeur Microsoft. Une petite subtilité, mais qu’il faut connaître si vous ne voulez pas vous casser les dents pendant 3 heures sur une règle AppLocker qui ne s’applique pas (ce qui devrait arriver à un moment donné malgré tout).

Toujours dans « Règles de l’exécutable« , créez une nouvelle règle… et :

  • Choisissez l’action « Autoriser » et ciblez « Tout le monde » ou le groupe « GG-Restrictions-Logiciels« 
  • Choisissez le type de condition principale « Editeur« 
  • Indiquez le fichier exécutable de Teams comme fichier de référence et positionnez le curseur sur « Editeur« 

Finalisez la création de la règle.

Vous devez obtenir ceci :

À partir de là, sur le poste client, l’utilisateur « guy.mauve » sera toujours restreint à l’exception près qu’il pourra exécuter les logiciels signés par Microsoft qui ne sont pas situés dans « Program Files » et « Windows« . Pour Teams, cela va lui permettre d’installer l’application dans sa session.

VII. AppLocker : efficace avec PowerShell et l’Invite de commande

Nous avons vu comment exécuter le logiciel depuis l’Explorateur de fichiers et nous avons pu constater que l’exécution est bien bloquée. Il faut savoir aussi que l’exécution sera bloquée si l’on tente de lancer l’exécutable depuis la console PowerShell ou l’Invite de commande. Par exemple :

Cela peut paraître normal, mais avec la méthode plus ancienne, à savoir « Stratégie de restriction logicielle« , ce n’est pas le cas. En effet, si vous ouvrez une console comme l’Invite de commande sur votre machine en tant qu’utilisateur standard (et donc restreint par la stratégie de restriction logicielle), vous allez pouvoir exécuter les fichiers bloqués. Ce qui nécessite de bloquer l’accès à l’Invite de commande et la console PowerShell, ce qui n’est pas un mal de toute façon ! Voilà, un atout de plus pour AppLocker puisqu’il est efficace contre cette méthode de contournement.

Cette introduction à AppLocker touche à sa fin ! Vous avez désormais connaissance des bases pour configurer cette fonctionnalité très intéressante afin de sécuriser vos postes de travail, mais aussi vos serveurs !

Source link

GPO – Comment configurer AppLocker pour sécuriser vos postes Windows ?


I. Présentation

Dans ce tutoriel, nous allons voir comment configurer AppLocker par GPO pour sécuriser les postes Windows en bloquant l’exécution et l’installation de logiciels.

La solution AppLocker est la remplaçante d’une autre fonction similaire, configurable par GPO, mais moins complète : la stratégie de restriction logicielle.

AppLocker permet de créer des règles pour définir les applications autorisées à être exécutées par les utilisateurs lambdas sur les machines du domaine. Grâce à ces restrictions, vous allez pouvoir lutter contre l’installation de logiciels non approuvés par le service informatique, de logiciels crackés en version portable, des logiciels portables au sens large, mais cela va permettre aussi de limiter l’installation de malwares sur les postes de travail.

AppLocker va permettre d’agir sur quatre types d’éléments : les exécutables, les installeurs au format Windows Installer (package MSI), les scripts et les applications modernes au format APPX.

Pour en savoir plus sur les différences entre AppLocker et les stratégies de restriction logicielle, consultez la documentation Microsoft.

Qu’allons-nous mettre en place ?

Pour ce tutoriel AppLocker, nous allons apprendre à créer une politique afin de bloquer l’exécution et l’installation de tous les logiciels, à l’exception :

  • Des logiciels présents dans Program Files (car ils sont déjà installés)
  • Des logiciels présents dans le dossier d’installation de Windows (les utilitaires natifs et les composants indispensables au bon fonctionnement de Windows s’y trouvent…)
  • Des applications modernes signées
  • De l’application Microsoft Teams (pour vous montrer le principe de création d’une exception)

Cette politique sera appliquée uniquement aux membres d’un groupe de sécurité Active Directory.

Pour suivre ce tutoriel, vous avez besoin de deux machines :

  • Un contrôleur de domaine Active Directory
  • Une machine pour tester AppLocker, Windows 10 ou Windows 11, c’est très bien ! Voire même un serveur.

II. AppLocker : les systèmes d’exploitation pris en charge

La solution AppLocker existe depuis quelques années déjà puisqu’elle a été introduite dans Windows à l’occasion de la sortie de Windows 7 et Windows Server 2008 R2. Au fil des versions et des sorties de Windows, Microsoft a fait évoluer AppLocker pour ajouter des fonctionnalités.

AppLocker est pris en charge sur Windows 10 et Windows 11 : vous pouvez miser sans problème sur cette fonctionnalité. Il en va de même pour Windows Server, si vous souhaitez mettre en place une politique AppLocker sur un serveur RDS.

Néanmoins, il y a un « mais » et c’est un petit détail qui fait mal. Pour utiliser AppLocker sur les postes de travail, vous devez utiliser une édition Entreprise ou Education de Windows. Autrement dit, AppLocker ne fonctionnera pas sur Windows 10 Pro, ni Windows 11 Pro, mais il fonctionnera sur Windows 10 Enterprise et Windows 10 Education.

Pour Windows Server, cette restriction n’existe pas pour les versions à partir de Windows Server 2012.

Maintenant que vous avez pris en compte de ce détail, nous allons pouvoir commencer la configuration.

III. Création d’un groupe pour appliquer la règle AppLocker

Avant d’attaquer la GPO AppLocker, nous allons créer un groupe de sécurité sur lequel va s’appliquer notre politique AppLocker.

À partir de la console « Utilisateurs et ordinateurs Active Directory« , j’ai créé le groupe de sécurité « GG-Restrictions-Logiciels« . Vous pouvez le créer avec le Centre d’administration Active Directory ou avec PowerShell : vous avez le choix.

Au sein de ce groupe, j’ai ajouté un salarié de l’entreprise pour lui appliquer les restrictions : « guy.mauve« .

IV. Configuration d’une GPO AppLocker

À partir de la console de Gestion des stratégies de groupe, créez une nouvelle GPO et liez cette GPO à une OU qui cible vos machines. Pour ma part, je vais cibler l’OU qui contient la machine où se connecte « guy.mauve » et je vais nommer cette GPO « AppLocker« , tout simplement.

Ensuite, modifiez cette GPO à l’aide d’un clic droit sur son nom.

A. Configurer le service Identité de l’Application

Pour qu’AppLocker fonctionne, il faut que le service « Identité de l’application » (AppIDSvc) soit actif et démarré automatiquement. Ce n’est pas le cas par défaut. Nous allons configurer la GPO pour configurer ce service sur nos postes de travail.

Parcourez l’arborescence comme ceci :

Configuration ordinateur > Stratégies > Paramètres Windows > Paramètres de sécurité > Services système

Ouvrez les propriétés du service « Identité de l’application« , cochez la case « Définir ce paramètre de stratégie » et cliquez sur « Automatique« .

Validez. Première étape réussie !

B. Créer les règles AppLocker

Pour configurer AppLocker, parcourez l’arborescence de cette façon :

Configuration ordinateur > Stratégies > Paramètres Windows > Paramètres de sécurité > Stratégies de contrôle de l’application > AppLocker

Ensuite, cliquez sur le lien « Configurer la mise en application des règles » sur la partie de droite.

Pour chaque type de règles, cochez l’option « Configuré » et basculez sur « Appliquer les règles« .

Note : j’utilise le mode « Appliquer les règles » dès maintenant, mais en phase de test, c’est pertinent de commencer par une phase d’audit et d’analyse en sélectionnant « Auditer uniquement« . De cette façon, les événements AppLocker seront générés, mais il n’y aura pas de restrictions effectives sur la machine.

Validez avec « OK« .

Développez « AppLocker« , quatre catégories vont s’afficher : règles de l’exécutable (EXE), règles Windows Installer (MSI), règles de scripts et règles d’applications empaquetées (APPX).

Je vous invite à générer les règles par défaut pour les « Règles de l’exécutable« , les « Règles Windows Installer » et les « Règles d’applications empaquetées« . Pour cela, effectuez un clic droit sur la catégorie et cliquez sur le bouton « Créer des règles par défaut« .

Si l’on regarde la partie « Règles de l’exécutable« , on peut voir que cette action crée plusieurs règles pour autoriser « Tout le monde » à exécuter les programmes situés dans « Program Files » et « Windows« . En complément, les administrateurs n’auront pas de restrictions. C’est une bonne base pour la suite.

Dans le même esprit, une règle est créée pour les applications empaquetées.

Désormais, passons à la création de notre règle personnalisée. Effectuez un clic droit sur « Règles de l’exécutable » et cliquez sur « Créer une règle« . Un assistant va se lancer.

Je vous rappelle que l’objectif est de créer une règle pour empêcher le groupe « GG-Restrictions-Logiciels » d’exécuter et d’installer des logiciels, à part ceux présents dans « Program Files » et « Windows ».

Cliquez sur « Suivant » lorsque le premier écran apparaît.

Choisissez l’action « Refuser » et pour le champ « Utilisateur ou groupe« , sélectionnez le groupe « GG-Restrictions-Logiciels« . Poursuivez.

Lorsque l’on crée une règle, il y a trois types de conditions principales :

  • Editeur : règle basée sur l’éditeur de l’exécutable. Par exemple : autoriser uniquement l’exécutable d’un éditeur spécifique, avec un nom spécifique, dans une version spécifique, ou autoriser tous les exécutables de l’éditeur Microsoft.
  • Chemin d’accès : règle basée sur un chemin d’accès. Par exemple : bloquer l’exécution de tous les exécutables situés sur le Bureau de l’utilisateur.
  • Hachage du fichier : règle basée sur le hash de l’exécutable, tout en sachant qu’un hash va évoluer pour un même logiciel d’une version à l’autre.

Choisissez « Chemin d’accès » et continuez.

Pour le chemin d’accès, précisez « *.* » : cela signifie que l’on refuse tous les exécutables ! Mais, nous allons créer deux exceptions à la prochaine étape.

Sous « Ajouter une exception« , choisissez « Chemin d’accès » et cliquez sur le bouton « Ajouter« . Créez une première exception avec ce chemin :

%PROGRAMFILES%*

Répétez l’opération avec ce chemin :

%WINDIR%*

Cela va permettre d’autoriser les exécutables situés dans « Program Files » et le dossier d’installation de Windows. Cliquez sur « Suivant ».

Nommez cette règle et indiquez une précision si vous le souhaitez. Cliquez sur « Créer« .

Nous obtenons le résultat suivant :

Je vous invite à créer une règle similaire, mais dans la catégorie « Règles Windows Installer » pour bloquer les fichiers MSI.

Une fois que c’est fait, la GPO est prête, nous allons tester depuis un poste client.

V. Tester la configuration AppLocker

Sur le poste client, je me connecte avec l’utilisateur « guy.mauve » puisqu’il est membre du groupe « GG-Restrictions-Logiciels« . Ensuite, j’effectue un « gpupdate /force » et pendant ce temps je télécharge quelques logiciels : Putty, Firefox Portable, Chrome, Teams et 7-Zip.

Le problème, c’est que l’administrateur système bloque l’exécution de tous ces exécutables ! Et oui, notre stratégie AppLocker rentre en jeu et contrôle l’exécution de chaque fichier ! Comme l’exécutable n’est pas dans un dossier autorisé (Program Files ou Windows), il est bloqué !

Dans le même esprit, avec un package MSI (suite à la création de la seconde règle).

Si l’on regarde dans l’Observateur d’événements de la machine locale, on peut voir que tous les événements AppLocker sont enregistrés. Vous pouvez les retrouver dans :

Journaux des applications et des services > Microsoft > Windows > AppLocker

Ensuite, il y a un journal par catégorie de règles, ce qui est appréciable pour le debug. On peut voir que « guy.mauve » a tenté d’exécuter « Putty.exe » et que l’exécution a été empêchée. Là ce sont des exécutables sans réels dangers, mais ce serait un logiciel malveillant, ce serait bloqué également et d’autant plus appréciable !

J’en profite pour parler du module PowerShell AppLocker. Il permet de récolter des informations assez précises, comme par exemple la liste des applications refusées pour un utilisateur avec la commande « Get-AppLockerFileInformation« .

Get-AppLockerFileInformation -EventLog -EventType Denied

À l’inverse, on peut voir ce qui a été autorisé :

Get-AppLockerFileInformation –EventLog –EventType Allowed

VI. AppLocker : créer une exception pour autoriser l’installation de Teams

Pour finir, nous allons apprendre à créer une exception pour autoriser l’installation d’un logiciel spécifique, en l’occurrence Teams, malgré les restrictions mises en place. Un cas très courant puisque Teams peut s’installer sans les droits Administrateur étant donné qu’il s’installe dans le répertoire « AppData » du profil de l’utilisateur, comme d’autres applications.

Lorsque l’on télécharge Teams, on obtient le fichier suivant : Teams_windows_x64.exe

La première chose à faire, c’est ajouter une nouvelle exception sur notre règle située dans « Règles de l’exécutable« . Effectuez un clic droit sur la règle « Empêcher installation de logiciels » et cliquez sur « Propriétés« .

Au sein de l’onglet « Exceptions« , choisissez « Editeur » sous « Ajouter une exception » puis cliquez sur le bouton « Ajouter« .

Vous devez indiquer le chemin vers l’exécutable de Teams pour que l’assistant AppLocker récupère des informations sur l’exécutable, notamment l’éditeur. Ensuite, les différents champs seront complétés automatiquement : Editeur, Nom du produit, Nom du fichier et Version du fichier.

Prenez le curseur à gauche et positionnez-le sur « Editeur ». Cela va permettre d’accepter toutes les valeurs pour les autres champs et d’autoriser toutes les applications signées par l’éditeur Microsoft. En fait, on pourrait être plus restrictif et autoriser seulement le produit « MICROSOFT TEAMS », mais le problème c’est que Teams s’appuie sur plusieurs composants. Si l’on ne crée par une autorisation plus large, l’installation échouera. Validez.

La création d’une exception dans AppLocker ne suffit pas : même avec cette exception, l’installeur de Teams sera bloqué ! En fait, en plus d’ajouter une exception, il faut créer une règle pour autoriser l’éditeur Microsoft. Une petite subtilité, mais qu’il faut connaître si vous ne voulez pas vous casser les dents pendant 3 heures sur une règle AppLocker qui ne s’applique pas (ce qui devrait arriver à un moment donné malgré tout).

Toujours dans « Règles de l’exécutable« , créez une nouvelle règle… et :

  • Choisissez l’action « Autoriser » et ciblez « Tout le monde » ou le groupe « GG-Restrictions-Logiciels« 
  • Choisissez le type de condition principale « Editeur« 
  • Indiquez le fichier exécutable de Teams comme fichier de référence et positionnez le curseur sur « Editeur« 

Finalisez la création de la règle.

Vous devez obtenir ceci :

À partir de là, sur le poste client, l’utilisateur « guy.mauve » sera toujours restreint à l’exception près qu’il pourra exécuter les logiciels signés par Microsoft qui ne sont pas situés dans « Program Files » et « Windows« . Pour Teams, cela va lui permettre d’installer l’application dans sa session.

VII. AppLocker : efficace avec PowerShell et l’Invite de commande

Nous avons vu comment exécuter le logiciel depuis l’Explorateur de fichiers et nous avons pu constater que l’exécution est bien bloquée. Il faut savoir aussi que l’exécution sera bloquée si l’on tente de lancer l’exécutable depuis la console PowerShell ou l’Invite de commande. Par exemple :

Cela peut paraître normal, mais avec la méthode plus ancienne, à savoir « Stratégie de restriction logicielle« , ce n’est pas le cas. En effet, si vous ouvrez une console comme l’Invite de commande sur votre machine en tant qu’utilisateur standard (et donc restreint par la stratégie de restriction logicielle), vous allez pouvoir exécuter les fichiers bloqués. Ce qui nécessite de bloquer l’accès à l’Invite de commande et la console PowerShell, ce qui n’est pas un mal de toute façon ! Voilà, un atout de plus pour AppLocker puisqu’il est efficace contre cette méthode de contournement.

Cette introduction à AppLocker touche à sa fin ! Vous avez désormais connaissance des bases pour configurer cette fonctionnalité très intéressante afin de sécuriser vos postes de travail, mais aussi vos serveurs !

Source link

GPO – Comment configurer AppLocker pour sécuriser vos postes Windows ?


I. Présentation

Dans ce tutoriel, nous allons voir comment configurer AppLocker par GPO pour sécuriser les postes Windows en bloquant l’exécution et l’installation de logiciels.

La solution AppLocker est la remplaçante d’une autre fonction similaire, configurable par GPO, mais moins complète : la stratégie de restriction logicielle.

AppLocker permet de créer des règles pour définir les applications autorisées à être exécutées par les utilisateurs lambdas sur les machines du domaine. Grâce à ces restrictions, vous allez pouvoir lutter contre l’installation de logiciels non approuvés par le service informatique, de logiciels crackés en version portable, des logiciels portables au sens large, mais cela va permettre aussi de limiter l’installation de malwares sur les postes de travail.

AppLocker va permettre d’agir sur quatre types d’éléments : les exécutables, les installeurs au format Windows Installer (package MSI), les scripts et les applications modernes au format APPX.

Pour en savoir plus sur les différences entre AppLocker et les stratégies de restriction logicielle, consultez la documentation Microsoft.

Qu’allons-nous mettre en place ?

Pour ce tutoriel AppLocker, nous allons apprendre à créer une politique afin de bloquer l’exécution et l’installation de tous les logiciels, à l’exception :

  • Des logiciels présents dans Program Files (car ils sont déjà installés)
  • Des logiciels présents dans le dossier d’installation de Windows (les utilitaires natifs et les composants indispensables au bon fonctionnement de Windows s’y trouvent…)
  • Des applications modernes signées
  • De l’application Microsoft Teams (pour vous montrer le principe de création d’une exception)

Cette politique sera appliquée uniquement aux membres d’un groupe de sécurité Active Directory.

Pour suivre ce tutoriel, vous avez besoin de deux machines :

  • Un contrôleur de domaine Active Directory
  • Une machine pour tester AppLocker, Windows 10 ou Windows 11, c’est très bien ! Voire même un serveur.

II. AppLocker : les systèmes d’exploitation pris en charge

La solution AppLocker existe depuis quelques années déjà puisqu’elle a été introduite dans Windows à l’occasion de la sortie de Windows 7 et Windows Server 2008 R2. Au fil des versions et des sorties de Windows, Microsoft a fait évoluer AppLocker pour ajouter des fonctionnalités.

AppLocker est pris en charge sur Windows 10 et Windows 11 : vous pouvez miser sans problème sur cette fonctionnalité. Il en va de même pour Windows Server, si vous souhaitez mettre en place une politique AppLocker sur un serveur RDS.

Néanmoins, il y a un « mais » et c’est un petit détail qui fait mal. Pour utiliser AppLocker sur les postes de travail, vous devez utiliser une édition Entreprise ou Education de Windows. Autrement dit, AppLocker ne fonctionnera pas sur Windows 10 Pro, ni Windows 11 Pro, mais il fonctionnera sur Windows 10 Enterprise et Windows 10 Education.

Pour Windows Server, cette restriction n’existe pas pour les versions à partir de Windows Server 2012.

Maintenant que vous avez pris en compte de ce détail, nous allons pouvoir commencer la configuration.

III. Création d’un groupe pour appliquer la règle AppLocker

Avant d’attaquer la GPO AppLocker, nous allons créer un groupe de sécurité sur lequel va s’appliquer notre politique AppLocker.

À partir de la console « Utilisateurs et ordinateurs Active Directory« , j’ai créé le groupe de sécurité « GG-Restrictions-Logiciels« . Vous pouvez le créer avec le Centre d’administration Active Directory ou avec PowerShell : vous avez le choix.

Au sein de ce groupe, j’ai ajouté un salarié de l’entreprise pour lui appliquer les restrictions : « guy.mauve« .

IV. Configuration d’une GPO AppLocker

À partir de la console de Gestion des stratégies de groupe, créez une nouvelle GPO et liez cette GPO à une OU qui cible vos machines. Pour ma part, je vais cibler l’OU qui contient la machine où se connecte « guy.mauve » et je vais nommer cette GPO « AppLocker« , tout simplement.

Ensuite, modifiez cette GPO à l’aide d’un clic droit sur son nom.

A. Configurer le service Identité de l’Application

Pour qu’AppLocker fonctionne, il faut que le service « Identité de l’application » (AppIDSvc) soit actif et démarré automatiquement. Ce n’est pas le cas par défaut. Nous allons configurer la GPO pour configurer ce service sur nos postes de travail.

Parcourez l’arborescence comme ceci :

Configuration ordinateur > Stratégies > Paramètres Windows > Paramètres de sécurité > Services système

Ouvrez les propriétés du service « Identité de l’application« , cochez la case « Définir ce paramètre de stratégie » et cliquez sur « Automatique« .

Validez. Première étape réussie !

B. Créer les règles AppLocker

Pour configurer AppLocker, parcourez l’arborescence de cette façon :

Configuration ordinateur > Stratégies > Paramètres Windows > Paramètres de sécurité > Stratégies de contrôle de l’application > AppLocker

Ensuite, cliquez sur le lien « Configurer la mise en application des règles » sur la partie de droite.

Pour chaque type de règles, cochez l’option « Configuré » et basculez sur « Appliquer les règles« .

Note : j’utilise le mode « Appliquer les règles » dès maintenant, mais en phase de test, c’est pertinent de commencer par une phase d’audit et d’analyse en sélectionnant « Auditer uniquement« . De cette façon, les événements AppLocker seront générés, mais il n’y aura pas de restrictions effectives sur la machine.

Validez avec « OK« .

Développez « AppLocker« , quatre catégories vont s’afficher : règles de l’exécutable (EXE), règles Windows Installer (MSI), règles de scripts et règles d’applications empaquetées (APPX).

Je vous invite à générer les règles par défaut pour les « Règles de l’exécutable« , les « Règles Windows Installer » et les « Règles d’applications empaquetées« . Pour cela, effectuez un clic droit sur la catégorie et cliquez sur le bouton « Créer des règles par défaut« .

Si l’on regarde la partie « Règles de l’exécutable« , on peut voir que cette action crée plusieurs règles pour autoriser « Tout le monde » à exécuter les programmes situés dans « Program Files » et « Windows« . En complément, les administrateurs n’auront pas de restrictions. C’est une bonne base pour la suite.

Dans le même esprit, une règle est créée pour les applications empaquetées.

Désormais, passons à la création de notre règle personnalisée. Effectuez un clic droit sur « Règles de l’exécutable » et cliquez sur « Créer une règle« . Un assistant va se lancer.

Je vous rappelle que l’objectif est de créer une règle pour empêcher le groupe « GG-Restrictions-Logiciels » d’exécuter et d’installer des logiciels, à part ceux présents dans « Program Files » et « Windows ».

Cliquez sur « Suivant » lorsque le premier écran apparaît.

Choisissez l’action « Refuser » et pour le champ « Utilisateur ou groupe« , sélectionnez le groupe « GG-Restrictions-Logiciels« . Poursuivez.

Lorsque l’on crée une règle, il y a trois types de conditions principales :

  • Editeur : règle basée sur l’éditeur de l’exécutable. Par exemple : autoriser uniquement l’exécutable d’un éditeur spécifique, avec un nom spécifique, dans une version spécifique, ou autoriser tous les exécutables de l’éditeur Microsoft.
  • Chemin d’accès : règle basée sur un chemin d’accès. Par exemple : bloquer l’exécution de tous les exécutables situés sur le Bureau de l’utilisateur.
  • Hachage du fichier : règle basée sur le hash de l’exécutable, tout en sachant qu’un hash va évoluer pour un même logiciel d’une version à l’autre.

Choisissez « Chemin d’accès » et continuez.

Pour le chemin d’accès, précisez « *.* » : cela signifie que l’on refuse tous les exécutables ! Mais, nous allons créer deux exceptions à la prochaine étape.

Sous « Ajouter une exception« , choisissez « Chemin d’accès » et cliquez sur le bouton « Ajouter« . Créez une première exception avec ce chemin :

%PROGRAMFILES%*

Répétez l’opération avec ce chemin :

%WINDIR%*

Cela va permettre d’autoriser les exécutables situés dans « Program Files » et le dossier d’installation de Windows. Cliquez sur « Suivant ».

Nommez cette règle et indiquez une précision si vous le souhaitez. Cliquez sur « Créer« .

Nous obtenons le résultat suivant :

Je vous invite à créer une règle similaire, mais dans la catégorie « Règles Windows Installer » pour bloquer les fichiers MSI.

Une fois que c’est fait, la GPO est prête, nous allons tester depuis un poste client.

V. Tester la configuration AppLocker

Sur le poste client, je me connecte avec l’utilisateur « guy.mauve » puisqu’il est membre du groupe « GG-Restrictions-Logiciels« . Ensuite, j’effectue un « gpupdate /force » et pendant ce temps je télécharge quelques logiciels : Putty, Firefox Portable, Chrome, Teams et 7-Zip.

Le problème, c’est que l’administrateur système bloque l’exécution de tous ces exécutables ! Et oui, notre stratégie AppLocker rentre en jeu et contrôle l’exécution de chaque fichier ! Comme l’exécutable n’est pas dans un dossier autorisé (Program Files ou Windows), il est bloqué !

Dans le même esprit, avec un package MSI (suite à la création de la seconde règle).

Si l’on regarde dans l’Observateur d’événements de la machine locale, on peut voir que tous les événements AppLocker sont enregistrés. Vous pouvez les retrouver dans :

Journaux des applications et des services > Microsoft > Windows > AppLocker

Ensuite, il y a un journal par catégorie de règles, ce qui est appréciable pour le debug. On peut voir que « guy.mauve » a tenté d’exécuter « Putty.exe » et que l’exécution a été empêchée. Là ce sont des exécutables sans réels dangers, mais ce serait un logiciel malveillant, ce serait bloqué également et d’autant plus appréciable !

J’en profite pour parler du module PowerShell AppLocker. Il permet de récolter des informations assez précises, comme par exemple la liste des applications refusées pour un utilisateur avec la commande « Get-AppLockerFileInformation« .

Get-AppLockerFileInformation -EventLog -EventType Denied

À l’inverse, on peut voir ce qui a été autorisé :

Get-AppLockerFileInformation –EventLog –EventType Allowed

VI. AppLocker : créer une exception pour autoriser l’installation de Teams

Pour finir, nous allons apprendre à créer une exception pour autoriser l’installation d’un logiciel spécifique, en l’occurrence Teams, malgré les restrictions mises en place. Un cas très courant puisque Teams peut s’installer sans les droits Administrateur étant donné qu’il s’installe dans le répertoire « AppData » du profil de l’utilisateur, comme d’autres applications.

Lorsque l’on télécharge Teams, on obtient le fichier suivant : Teams_windows_x64.exe

La première chose à faire, c’est ajouter une nouvelle exception sur notre règle située dans « Règles de l’exécutable« . Effectuez un clic droit sur la règle « Empêcher installation de logiciels » et cliquez sur « Propriétés« .

Au sein de l’onglet « Exceptions« , choisissez « Editeur » sous « Ajouter une exception » puis cliquez sur le bouton « Ajouter« .

Vous devez indiquer le chemin vers l’exécutable de Teams pour que l’assistant AppLocker récupère des informations sur l’exécutable, notamment l’éditeur. Ensuite, les différents champs seront complétés automatiquement : Editeur, Nom du produit, Nom du fichier et Version du fichier.

Prenez le curseur à gauche et positionnez-le sur « Editeur ». Cela va permettre d’accepter toutes les valeurs pour les autres champs et d’autoriser toutes les applications signées par l’éditeur Microsoft. En fait, on pourrait être plus restrictif et autoriser seulement le produit « MICROSOFT TEAMS », mais le problème c’est que Teams s’appuie sur plusieurs composants. Si l’on ne crée par une autorisation plus large, l’installation échouera. Validez.

La création d’une exception dans AppLocker ne suffit pas : même avec cette exception, l’installeur de Teams sera bloqué ! En fait, en plus d’ajouter une exception, il faut créer une règle pour autoriser l’éditeur Microsoft. Une petite subtilité, mais qu’il faut connaître si vous ne voulez pas vous casser les dents pendant 3 heures sur une règle AppLocker qui ne s’applique pas (ce qui devrait arriver à un moment donné malgré tout).

Toujours dans « Règles de l’exécutable« , créez une nouvelle règle… et :

  • Choisissez l’action « Autoriser » et ciblez « Tout le monde » ou le groupe « GG-Restrictions-Logiciels« 
  • Choisissez le type de condition principale « Editeur« 
  • Indiquez le fichier exécutable de Teams comme fichier de référence et positionnez le curseur sur « Editeur« 

Finalisez la création de la règle.

Vous devez obtenir ceci :

À partir de là, sur le poste client, l’utilisateur « guy.mauve » sera toujours restreint à l’exception près qu’il pourra exécuter les logiciels signés par Microsoft qui ne sont pas situés dans « Program Files » et « Windows« . Pour Teams, cela va lui permettre d’installer l’application dans sa session.

VII. AppLocker : efficace avec PowerShell et l’Invite de commande

Nous avons vu comment exécuter le logiciel depuis l’Explorateur de fichiers et nous avons pu constater que l’exécution est bien bloquée. Il faut savoir aussi que l’exécution sera bloquée si l’on tente de lancer l’exécutable depuis la console PowerShell ou l’Invite de commande. Par exemple :

Cela peut paraître normal, mais avec la méthode plus ancienne, à savoir « Stratégie de restriction logicielle« , ce n’est pas le cas. En effet, si vous ouvrez une console comme l’Invite de commande sur votre machine en tant qu’utilisateur standard (et donc restreint par la stratégie de restriction logicielle), vous allez pouvoir exécuter les fichiers bloqués. Ce qui nécessite de bloquer l’accès à l’Invite de commande et la console PowerShell, ce qui n’est pas un mal de toute façon ! Voilà, un atout de plus pour AppLocker puisqu’il est efficace contre cette méthode de contournement.

Cette introduction à AppLocker touche à sa fin ! Vous avez désormais connaissance des bases pour configurer cette fonctionnalité très intéressante afin de sécuriser vos postes de travail, mais aussi vos serveurs !

Source link

Mourad ELGORMA

Fondateur de summarynetworks, passionné des nouvelles technologies et des métiers de Réseautique , Master en réseaux et système de télécommunications. ,j’ai affaire à Pascal, Delphi, Java, MATLAB, php …Connaissance du protocole TCP / IP, des applications Ethernet, des WLAN …Planification, installation et dépannage de problèmes de réseau informatique……Installez, configurez et dépannez les périphériques Cisco IOS. Surveillez les performances du réseau et isolez les défaillances du réseau. VLANs, protocoles de routage (RIPv2, EIGRP, OSPF.)…..Manipuler des systèmes embarqués (matériel et logiciel ex: Beaglebone Black)…Linux (Ubuntu, kali, serveur Mandriva Fedora, …). Microsoft (Windows, Windows Server 2003). ……Paquet tracer, GNS3, VMware Workstation, Virtual Box, Filezilla (client / serveur), EasyPhp, serveur Wamp,Le système de gestion WORDPRESS………Installation des caméras de surveillance ( technologie hikvision DVR………..). ,

Laisser un commentaire