Politique de restriction Applocker vs Software

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

J'ai lu de nombreux articles de Microsoft et d'autres personnes disant que la nouvelle fonctionnalité Applocker est 100% meilleure que l'ancienne Stratégie de restriction du logiciel et est recommandée en remplacement de celle-ci.

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

Dans le même cas, il présente un inconvénient majeur qui le rend très inutile: il n'est pas extensible et vous ne pouvez pas ajouter des extensions de fichiers personnalisées que vous souhaitez restreindre.

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

4 Solutions collect form web for “Politique de restriction Applocker vs Software”

La Stratégie de restriction du logiciel est obsolète par Microsoft ( technet réclamant efficacement que SRP n'est pas pris en charge ), puisque Windows 7 Enterprise / Ultimate a introduit AppLocker.

En pratique, SRP a certains pièges, tant pour les faux négatifs que pour les faux positifs. AppLocker a l'avantage qu'il est encore activement maintenu et pris en charge. Si AppLocker est une option, il pourrait être moins cher – après avoir pris en compte votre temps et vos risques. Il est également possible qu'il y ait une alternative tierce appropriée (mais cette question n'a pas inclus cette option :).

J'espère que vous obtiendrez une compréhension parfaite des pièges de SRP avant de tomber dans l'un d'entre eux </sarcasm> . Certains d'entre eux sont décrits dans un article de sécurité de Vadims Podāns .

Troubles connus

  1. Par défaut, l'exécution à partir du dossier \Windows 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 l'accès d'écriture des utilisateurs, vous pouvez utiliser, par exemple, l'utilitaire AccessEnum du pack Sysinternals." (Ou AccessChk ).

    Techniquement, la documentation vous met également en garde contre l'annulation des règles par défaut . EDIT: un document NSA donne 16 exemples de dossiers à la liste noire avec SRP , et met en garde contre une entrée de liste noire trop large commune.

    La question évidente est pourquoi ne sommes-nous pas soigneusement listes individuelles de chemins individuels sous \Windows place. (Y compris l'héritage \Windows\*.exe , System32\*.exe , etc.). Je n'ai remarqué aucune réponse à cela n'importe où :(.

  2. En utilisant des variables d'environnement comme %systemroot% , SRP peut être contourné par les utilisateurs en effaçant la variable d'environnement. EDIT: Ce n'est pas utilisé dans les valeurs par défaut suggérées. Cependant, ils peuvent être tentants à utiliser. Ce pied de foot est fixé dans AppLocker, car il ne regarde jamais les variables d'environnement.

  3. En utilisant les «chemins de registre» plus sécurisés, il existe des rapports de déni faux dans des situations aléatoires, qui peuvent facilement être manqués dans les tests. Et donc vous finissez par des lettres de lecteur à codage dur – apparemment comme ajout à la liste blanche d'origine. Par exemple, voir les commentaires sur SpiceWorks SRP howto . Je n'ai aucune explication sur la façon dont cela interagit avec # 1; Pour tout ce que je sais, vous aurez besoin de 2 fois autant de règles pour une sécurité totale.
  4. Les défauts suggérés négligent de permettre les deux différents \Program Files utilisés sur les installations modernes de 64 bits.
  5. Les extensions par défaut négligent d'interdire les scripts PowerShell (* .PS1) pris en charge par Windows . (Voir la vidéo ). Et APPX aussi … également selon le tableau de comparaison de Microsoft, SRP ne peut pas gérer "Packaged apps" dans Windows 8, je n'ai aucune idée de ce que cela signifie.
  6. Parmi les sources que j'ai trouvées pour SRP, aucune liste de liste complète ci-dessus ne vous intéresse. Et je n'ai découvert que l'article de Vadims Podāns par accident. Qu'est-ce qui se cache là-bas?
  7. De nombreuses sources recommandent simplement de supprimer les fichiers LNK de la liste. (Et les raccourcis Web pour éviter de casser des favoris ?!). Par inquiétant, 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 exemple wscript /e … ou peut-être remplacer suffisamment de shellcode dans un paramètre de script en ligne … etc.
  8. Si vous essayez de compromettre en autorisant les fichiers LNK sur le bureau et que vous laissez les utilisateurs avec un accès en écriture au bureau, ils peuvent maintenant contourner entièrement votre politique. Astuce magnifique 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 présente plusieurs exemples de ceci incluant *.Extension , sans avertissement. Donc, vous ne pouvez pas faire confiance à la documentation officielle , et il semble peu probable de le réparer maintenant.
  9. [Désavantage potentiel d'AppLocker]. Vadims Podāns rapporte 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 seraient alors autorisés à accéder via un lecteur mappé? Ce n'est pas à 100% clair. Apparemment, AppLocker était différent: il ne fonctionnait pas non plus :(. "En raison de raison inconnue, les chemins UNC ne fonctionnent pas dans Applocker! Cela signifie que si votre application est installée dans le réseau, vous devez créer des règles de hash ou d'éditeur . "

Approche pragmatique

La liste blanche de logiciels est potentiellement une défense très puissante. Si nous devenons cyniques: c'est exactement pourquoi Microsoft déprécie les versions moins coûteuses et invente les plus complexes.

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

  1. Commencez par les règles par défaut (de l'ère avant Win7 :).
  2. Préférer de ne pas utiliser de variables d'environnement, p.ex. %systemroot% .
  3. Ajoutez une deuxième copie de chaque règle, de sorte que 1 utilise les "chemins de registre" pour représenter \Program Files\ etc, et 1 utilise des chemins codés.
  4. Ajoutez des règles pour vous assurer que les deux \Program Files\ sont autorisés sur les machines 64-bit modernes. Le "chemin de registre" supplémentaire que vous devrez ajouter pour \Program Files\ sur les ordinateurs 64 bits est %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramFilesDir (x86)% .
  5. Ajouter 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. L'objectif est d'aider / encourager les utilisateurs à travailler dans la politique, à les protéger contre les attaques, comme les "téléchargements de lecteur".
  7. Autoriser les fichiers LNK. (De préférence, en le supprimant de la liste des extensions, non pas dans une règle de chemin).
  8. Voir au dessus :).
  9. Assurez-vous que votre dossier de script d'ouverture de session est autorisé. Le document NSA suggère d'ajouter \\%USERDNSDOMAIN%\Sysvol\ . (Voir le point n ° 2, soupirer, voir le point n ° 6).

Je reconnais que SRP possède des fonctionnalités supplémentaires dont AppLocker pourrait vraiment bénéficier.

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

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

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

Il n'y a aucun avantage d'AppLocker, Microsoft a publié des mensonges flagrants: 1. Les objets de stratégie de groupe avec des règles SAFER peuvent être attachés aux utilisateurs et aux groupes d'utilisateurs; 2. Windows Vista a introduit plusieurs GPO locaux qui atteignent le même résultat sans un contrôleur de domaine; 3. Le mode d'audit est disponible via la fonctionnalité de journalisation étendue sans contrôle.

  • Problème de directory virtuel FTP IIS
  • J'utilise Windows Server 2008 R2. Je veux installer le operating system dans les machines virtuelles à l'aide du code C #. Y a-t-il une solution pour cela?
  • Délégation de mot de passe avec Windows 2008 Server Trusts?
  • Comparer Shared SQL Server vs VPS SQL Server
  • Utilisation d'IIS avec le file hôte Windows 7
  • Script de création Powershell AD Group
  • Quel est le risque de l'exécution d'un controller de domaine afin qu'il soit accessible depuis Internet?
  • Commande Sleep dans le server Windows 2008
  • Windows 2008 Active Directory - Comment get la list des users connectés dans le domaine?
  • Créez un nouveau salon d'events dans Windows Server 2008
  • Windows n'a pas pu mettre à jour la configuration d'amorçage de l'ordinateur
  • Les astuces du serveur de linux et windows, tels que ubuntu, centos, apache, nginx, debian et des sujets de rĂ©seau.