Politique de restriction d'Applocker vs logiciel

L'objectif est d'empêcher les utilisateurs d'exécuter des programmes indésirables sur un serveur Terminal Server.

J'ai lu de nombreux articles de Microsoft et d'autres disant que la nouvelle fonctionnalité Applocker est 100% meilleure que l'ancienne politique de restriction logicielle et est recommandée en remplacement de cette dernière.

Je ne suis pas sûr de comprendre les vrais avantages d'Applocker en dehors de l'exécution en mode noyau. La plupart de ses fonctionnalités peuvent être reproduites avec la politique de restriction logicielle.

En même temps, il a un GRAND inconvénient qui le rend assez inutile: il n'est pas extensible et vous ne pouvez pas ajouter d'extensions de fichier personnalisées que vous souhaitez restreindre.

Quels sont les avantages d'Applocker par rapport à SRP et que recommanderiez-vous pour le contrôle logiciel?

La stratégie de restriction logicielle est déconseillée par Microsoft ( technet affirmant que SRP n'est pas pris en charge ), car Windows 7 Enterprise / Ultimate a introduit AppLocker.

Dans la pratique, SRP présente certains écueils, tant pour les faux négatifs que pour les faux positifs. AppLocker a l'avantage d'être toujours activement maintenu et pris en charge. Si AppLocker est une option, elle pourrait être la moins chère - après avoir pris en compte votre temps et les risques pris. Il est également possible qu'il existe une alternative tierce appropriée (mais cette question n'inclut pas cette option :).

J'espère que vous comprendrez parfaitement les pièges de SRP avant de tomber dans l'un d'eux </sarcasm>. Certains d'entre eux sont décrits dans un bel article sur la sécurité de Vadims Podāns .

Pièges connus

1. Par défaut, l'exécution à partir du \Windowsdossier est autorisée. Certains sous-dossiers peuvent être écrits par les utilisateurs. Applocker est le même, mais au moins la documentation officielle mentionne cette limitation .

   EDIT: "Pour énumérer tous les dossiers avec un accès en écriture des utilisateurs, vous pouvez utiliser, par exemple, l'utilitaire AccessEnum du pack Sysinternals." (ou AccessChk ).

   Techniquement, la documentation vous prévient également de ne pas remplacer les règles par défaut . EDIT: Un document NSA donne 16 exemples de dossiers à mettre sur liste noire avec SRP , bien que les règles de chemin de registre utilisent des barres obliques inverses de manière incorrecte, donc doivent être corrigées (voir le point sur les chemins de registre ci-dessous) et met en garde contre une entrée de liste noire trop large commune.

   La question évidente est de savoir pourquoi nous ne faisons pas de liste blanche des chemins individuels sous \Windows. (Y compris l' \Windows\*.exehéritage System32\*.exe, etc.). Je n'ai remarqué aucune réponse à cela nulle part :(.

2. En utilisant des variables d'environnement comme %systemroot%, SRP peut être contourné par les utilisateurs en effaçant la variable d'environnement. EDIT: Ceux-ci ne sont pas utilisés dans les valeurs par défaut suggérées. Cependant, ils peuvent être tentants d'utiliser. Ce pistolet est corrigé dans AppLocker, car il ne regarde jamais les variables d'environnement.

3. Les valeurs par défaut suggérées ne tiennent pas compte des deux types différents \Program Filesutilisés dans les installations 64 bits modernes. Lors de la résolution de ce problème en utilisant les "chemins de registre" plus sécurisés, il y a des rapports de faux refus dans des situations aléatoires, qui pourraient facilement être manqués lors des tests. par exemple, voir les commentaires sur le guide pratique de SpiceWorks SRP . EDIT: Cela concerne les applications 32 bits qui lisent les chemins d'accès pertinents à partir du noeud WOW6432 du registre: la résolution consiste à ajouter ces deux chemins d'accès à SRP pour permettre à tous les programmes de fonctionner sur des machines 32 bits et 64 bits comme sans restriction, qu'ils soient démarrés à partir de un processus hôte x64 ou x86:%HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramFilesDir (x86)% %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramW6432Dir%
4. Les extensions par défaut négligent d'interdire les scripts PowerShell (* .PS1) pris en charge par Windows . (Voir vidéo ). Et APPX aussi ... également selon le tableau de comparaison de Microsoft, SRP ne peut pas gérer les "applications packagées" dans Windows 8, je n'ai aucune idée de ce que cela signifie.
5. Règles de chemin du registre ne doit pas avoir des barres obliques immédiatement après le dernier signe pour cent ( en dépit d' être compris dans ses propres règles intégré dans Microsoft pour XP / Server 2003) et les antislashs doivent être remplacées par forwardslashes afin de la règle au travail ( 1 / 2 / 3 ).
6. Parmi les sources que j'ai trouvées pour SRP, aucune n'a rassemblé la liste complète ci-dessus pour vous. Et je n'ai découvert l'article de Vadims Podāns que par accident. Qu'est-ce qui se cache ailleurs?
7. De nombreuses sources recommandent simplement de supprimer les fichiers LNK de la liste. (Et les raccourcis Web pour éviter de casser les favoris?!). De manière troublante, aucune source ne semble discuter des vulnérabilités de LNK ... ou obtenir des interprètes de script pour exécuter des fichiers avec une extension inattendue, par exemplewscript /e ... ou peut-être bourrer suffisamment de shellcode dans un paramètre de script en ligne ... etc.
8. Si vous essayez de faire des compromis en autorisant les fichiers LNK sur le bureau et que vous laissez aux utilisateurs un accès en écriture au bureau, ils peuvent désormais contourner entièrement votre stratégie. Belle astuce de Vadims Podāns à nouveau. Notez que l'explication s'applique à l'utilisation de n'importe quelle extension dans une règle de chemin d'accès. Microsoft en présente plusieurs exemples *.Extension, sans avertissement. Donc , vous ne pouvez pas faire confiance à la documentation officielle , et il semble peu probable que se fixe maintenant.
9. [Inconvénient potentiel d'AppLocker]. Vadims Podāns signale que les entrées SRP utilisant des lecteurs mappés ne fonctionnent pas. Le chemin UNC doit être utilisé à la place. Peut-être qu'ils demanderaient alors l'accès via un lecteur mappé? ce n'est pas clair à 100%. Apparemment AppLocker était différent: il ne fonctionnait pas non plus avec :(. "Pour une raison inconnue, les chemins UNC ne fonctionnent pas dans Applocker! Cela signifie que si votre application est installée en réseau, vous devez créer des règles de hachage ou d'éditeur . "

Approche pragmatique

La liste blanche des logiciels est potentiellement une défense très puissante. Si nous devenons cyniques: c'est exactement pourquoi Microsoft déconseille les versions moins chères et en invente des plus complexes.

Peut-être qu'aucune autre option n'est disponible (y compris les solutions tierces). Une approche pragmatique serait alors d'essayer de configurer SRP aussi simplement que possible. Traitez-le comme une couche de défense supplémentaire, avec des trous connus. Faire correspondre les pièges ci-dessus:

1. Commencez par les règles par défaut (de l'ère pré-Win7 :).
2. Préfère ne pas utiliser de variables d'environnement, par exemple %systemroot%.
3. Ajoutez des règles pour vous assurer que les deux \Program Files\répertoires sont autorisés sur les machines 64 bits modernes. Les "chemins de registre" supplémentaires que vous devrez ajouter \Program Files\sur les ordinateurs 64 bits sont %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramFilesDir (x86)%et %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramW6432Dir%.
4. Lors de l' ajout de règles de chemin de registre, quitter immédiatement toute barre oblique inverse après le signe pour cent, et de remplacer les antislashs autres \avec forwardslashes /(par exemple %HKEY_LOCAL_MACHINE\Software\CompanyName\CustomApps%App/Bin/start.exe)
5. Ajoutez PS1 à la liste des extensions contrôlées.
6. Comprenez qu'une configuration SRP gérable n'est pas sécurisée contre un utilisateur déterminé à la vaincre. Le but est d'aider / encourager les utilisateurs à travailler dans le cadre de la politique, à les protéger contre les attaques telles que les «téléchargements en voiture».
7. Autorisez les fichiers LNK. (De préférence en le supprimant de la liste des extensions, et non via une règle de chemin d'accès).
8. Voir au dessus :).
9. Assurez-vous que votre dossier de script d'ouverture de session est autorisé. Le document de la NSA suggère d'ajouter \\%USERDNSDOMAIN%\Sysvol\. (Voir point # 2, soupir, puis voir point # 6).

Je suis d'accord que SRP a quelques fonctionnalités supplémentaires dont AppLocker pourrait vraiment bénéficier.

Cela étant dit, je vois les grands avantages d'AppLocker (comme le montre cette comparaison ):

• Les règles AppLocker peuvent être ciblées sur un utilisateur spécifique ou un groupe d'utilisateurs, tandis que SRP est appliqué sur l'ensemble de l'ordinateur.
• AppLocker prend en charge le mode audit afin que les règles puissent être testées en production avant d'être appliquées. SRP n'a pas de mode journal uniquement équivalent.

Le plus grand avantage pour moi est la possibilité de mettre en liste blanche les exécutables signés par l'éditeur. Jetez un œil à cette http://technet.microsoft.com/en-us/library/ee460943(v=ws.10).aspx

AppLocker ne présente aucun avantage, Microsoft a publié des mensonges flagrants: 1. Les objets de stratégie de groupe avec des règles plus sûres peuvent être attachés aux utilisateurs et aux groupes d'utilisateurs; 2. Windows Vista a introduit plusieurs GPO locaux qui permettent d'obtenir le même résultat sans contrôleur de domaine; 3. Le mode audit est disponible via la fonction de journalisation étendue sans application.

J'utilise Applocker au sein de mon entreprise. La stratégie que nous utilisons est la suivante: tout refuser comme référence (en fait: les valeurs par défaut d'Applocker), puis faire ce qui a été suggéré: créer une règle qui autorise uniquement les applications signées (office, adobe, wintools, ax, etc.). La plupart, peut-être que tous les logiciels malveillants ne sont pas des logiciels signés, ils ne s'exécuteront donc pas. Ce n'est pratiquement pas d'entretien. Je n'avais qu'à autoriser 3 applications héritées supplémentaires.

De plus, je ne peux pas confirmer que l'on ne peut pas utiliser les chemins UNC. Dans certaines règles de refus de sécurité supplémentaires, j'utilise avec succès le chemin UNC. Le piège réside dans l'utilisation des variables d'environnement: elles ne fonctionnent pas pour Applocker. Utilisez * des caractères génériques. Je l'utilise sur Windows 2008 R2 et Windows 2012 R2.

Je l'aime beaucoup: il n'y a pratiquement aucune baisse de performances. Comme le dit la documentation: Applocker s'appuie sur le service d'identité d'application (assurez-vous qu'il démarre automatiquement).