Question Stratégie de restriction Applocker vs Software


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 affirmant que la nouvelle fonctionnalité Applocker est 100% meilleure que l'ancienne stratégie de restriction logicielle et qu'elle 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 en mode noyau. La plupart de ses fonctionnalités peuvent être reproduites avec la politique de restriction logicielle.

En même temps, il présente un inconvénient majeur qui le rend plutôt inutile: il n’est pas extensible et vous ne pouvez pas ajouter d’extensions de fichiers personnalisées que vous souhaitez restreindre.

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


11
2017-11-09 13:38


origine


Les restrictions sur les extensions de fichiers sont quelque peu inutiles, car il existe plusieurs façons de les contourner. Cela pourrait éloigner les personnes qui ne savent pas ce qu'elles font, mais si vous pensez que cela va arrêter l'espionnage des virus ou des entreprises, vous vous trompez d'arbre. Avez-vous vu d'autres inconvénients ?? - Chris S
Regardez ici: technet.microsoft.com/library/hh994614 - joeqwerty


Réponses:


La stratégie de restriction logicielle est obsolète par Microsoft (technet affirmant effectivement que SRP n'est pas supporté), depuis que Windows 7 Entreprise / Édition Intégrale a introduit AppLocker.

En pratique, SRP présente certains inconvénients, tant pour les faux négatifs que pour les faux positifs. AppLocker présente l'avantage d'être toujours maintenu et pris en charge. Si AppLocker est une option, alors ce pourrait être la solution la moins chère, après comptabilisation de votre temps et des risques pris. Il est également possible qu'il existe une alternative tierce appropriée (mais cette question n'incluait pas cette option :).

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

Pièges connus

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

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

    Techniquement, la documentation vous met également en garde contre le dépassement du règles par défaut. EDIT: Un document de la NSA donne 16 exemples de dossiers sur liste noire avec SRP, bien que les règles de chemin de registre utilisent des barres obliques inverses de manière incorrecte, elles doivent donc être corrigées (voir le point sur les chemins de registre ci-dessous) et vous avertissent d'une entrée courante dans la liste noire.

    La question évidente est de savoir pourquoi ne plaçons-nous pas soigneusement dans la liste blanche des chemins individuels? \Windows au lieu. (Incluant le \Windows\*.exe héritage, System32\*.exe, etc). Je n'ai remarqué aucune réponse à cela nulle part :(.

  2. Utilisation de variables d'environnement telles que %systemroot%, SRP peut être contourné par les utilisateurs en effaçant la variable d’environnement. EDIT: Celles-ci ne sont pas utilisées dans les valeurs par défaut suggérées. Cependant, ils peuvent être tentants d'utiliser. Ce footgun est corrigé dans AppLocker, car il ne regarde jamais les variables d'environnement.

  3. Les valeurs par défaut suggérées négligent de prendre en compte les deux \Program Files utilisé sur les installations 64 bits modernes. Lors de la résolution de ce problème à l'aide des "chemins de registre" plus sécurisés, il existe des rapports de faux refus dans des situations aléatoires, qui pourraient facilement être omis lors des tests. par exemple. voir les commentaires sur Comment faire de SpiceWorks SRP. EDIT: cela concerne les applications 32 bits qui lisent les chemins pertinents à partir du WOW6432Node du registre: la résolution consiste à ajouter tous les deux Ces chemins d'accès à SRP pour permettre à tous les programmes de fonctionner sur des ordinateurs 32 bits et 64 bits sans restriction, qu'ils soient démarrés à partir d'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. Les règles de chemin de registre ne doivent pas comporter de barres obliques juste après le dernier signe de pourcentage (bien qu'elles soient incluses dans les règles intégrées de Microsoft pour XP / Server 2003), et les barres obliques inverses doivent être remplacées par des barres obliques pour que la règle fonctionne (1/2/3).
  6. Parmi les sources que j'ai trouvées pour SRP, aucune n'a mis la liste complète ci-dessus pour vous. Et je n'ai découvert l'article de Vadims Podans que par accident. Quoi d'autre se cache là-bas?
  7. De nombreuses sources recommandent simplement de supprimer les fichiers LNK de la liste. (Et des raccourcis Web pour éviter de briser les favoris?!). Fait troublant, 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 insérer suffisamment de shellcode dans un paramètre de script intégré ... etc.
  8. Si vous essayez de compromettre 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 Podans à nouveau. Notez que l'explication s'applique à l'utilisation de n'importe quelle extension dans une règle de chemin. Microsoft présente plusieurs exemples de cela, y compris *.Extensionsans avertissement. Alors vous ne pouvez pas faire confiance à la documentation officielle, et il semble peu probable d’être corrigé 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 pourraient alors demander l'accès via un lecteur mappé? ce n'est pas clair à 100%. Apparemment, AppLocker était différent: cela ne fonctionnait pas avec l'un ou l'autre :(. "Pour des raisons inconnues, les chemins UNC ne fonctionnent pas dans Applocker! Cela signifie que si votre application est installée sur le réseau, vous devez créer des règles de hachage ou d’éditeur."

Approche pragmatique

La liste blanche de logiciels est potentiellement une très puissante défense. Si nous sommes cyniques: c’est précisément pourquoi Microsoft déconseille les versions moins chères et en invente des plus complexes.

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

  1. Commencez par les règles par défaut (de l'ère pré-Win7 :).
  2. Préférez ne pas utiliser de variables d'environnement, par exemple. %systemroot%.
  3. Ajoutez des règles pour vous assurer que les deux \Program Files\ les répertoires sont autorisés sur les machines 64 bits modernes. Les "chemins de registre" supplémentaires que vous devrez ajouter pour \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. Lorsque vous ajoutez des règles de chemin de registre, supprimez toute barre oblique inverse immédiatement après le signe de pourcentage et remplacez-la par la suite. \ avec des barres obliques / (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. L'objectif est d'aider / encourager les utilisateurs à travailler dans le cadre de la politique, de les protéger contre des attaques telles que les "téléchargements à la volée".
  7. Autoriser les fichiers LNK. (De préférence en le supprimant de la liste des extensions, et non par une règle de chemin d'accès).
  8. Voir au dessus :).
  9. Assurez-vous que votre dossier de script de connexion est autorisé. Le document de la NSA suggère d'ajouter \\%USERDNSDOMAIN%\Sysvol\. (Voir le point n ° 2, soupir, puis voir le point n ° 6).

5
2017-08-07 10:28





Je conviens que SRP offre certaines fonctionnalités supplémentaires dont AppLocker pourrait vraiment bénéficier.

Cela étant dit, je vois les grands avantages d’AppLocker (documenté par cette comparaison) comme:

  • Les règles AppLocker peuvent être ciblées sur un utilisateur spécifique ou un groupe d'utilisateurs, tandis que SRP est appliqué sur tout 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 de journal uniquement équivalent.

1
2017-11-09 13:56





Le plus gros avantage pour moi est la possibilité d’inscrire la liste blanche des exécutables signés par éditeur. Regarde ça http://technet.microsoft.com/en-us/library/ee460943(v=ws.10).aspx


0
2018-02-19 18:24



Un peu plus de détails en feraient une meilleure réponse. Un lien peut changer et rendre la réponse moins utile. Trouver des détails à partir du matériel lié aiderait - Dave M


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


0
2018-04-23 21:20



Seriez-vous en mesure de fournir ces objets de stratégie de groupe, pour aider d'autres personnes à le mettre en œuvre? - womble♦


J'utilise Applocker au sein de mon entreprise. La stratégie que nous utilisons est la suivante: refuser tout comme base (en fait: les valeurs par défaut d’Applocker), puis appliquer ce qui a été suggéré: définir une règle qui autorise uniquement les applications signées (office, adobe, wintools, ax, etc.). La plupart des logiciels malveillants sont peut-être des logiciels non signés, ils ne s'exécutent donc pas. Ce n'est presque pas d'entretien. Je devais seulement autoriser 3 applications héritées supplémentaires.

De plus, je ne peux pas confirmer que personne ne peut utiliser les chemins UNC. Dans certaines règles de refus de sécurité supplémentaires, j'utilise avec succès UNC-path. Le piège est d'utiliser les variables d'environnement: elles ne fonctionnent pas pour Applocker. Utilisez * des jokers. Je l'utilise sous Windows 2008 R2 et Windows 2012 R2.

J'aime beaucoup ça: il n'y a presque pas de chute de performance. Comme le dit la documentation: Applocker s’appuie sur le service d’identité d’application (assurez-vous qu’il démarre automatiquement).


0
2017-08-31 08:02