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 disant que la nouvelle fonctionnalité AppLocker est 100% meilleure que l’ancienne Stratégie de restriction logicielle et est recommandée comme 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 Stratégie de restriction logicielle.
En même temps, il a un GROS inconvénient 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 des logiciels ?
En pratique, SRP a certains pièges, tant pour les faux négatifs que pour les faux positifs. AppLocker a l’avantage d’être encore activement maintenu et supporté. Si AppLocker est une option, il pourrait être la solution la moins coûteuse – en tenant compte de votre temps et des risques pris. Il est aussi possible qu’il existe une alternative tierce appropriée (mais cette question n’incluait pas cette option :).
Espérons que vous obtiendrez une compréhension parfaite des pièges de SRP avant de tomber dans l’un d’eux </sarcasme>. Certains d’entre eux sont décrits dans un excellent article de sécurité de Vadims Podans.
« Pour énumérer tous les dossiers avec accès en écriture des utilisateurs, vous pouvez utiliser, par exemple, l’utilitaire AccessEnum du pack Sysinternals. » (ou AccessChk).
Un document de la NSA donne 16 exemples de dossiers à mettre en liste noire avec SRP (bien que les règles de chemin du registre utilisent incorrectement les barres obliques inverses et doivent être corrigées – voir le point sur les chemins du registre ci-dessous) et avertit d’une entrée de liste noire couramment trop large.
La question évidente est pourquoi ne mettons-nous pas soigneusement en liste blanche des chemins individuels sous \Windows à la place. (Y compris les anciens \Windows\*.exe, System32\*.exe, etc.). Je n’ai trouvé de réponse à cela nulle part :(.
En utilisant des variables d’environnement comme %systemroot%, SRP peut être contourné par les utilisateurs en effaçant la variable d’environnement. Celles-ci ne sont pas utilisées dans les valeurs par défaut suggérées. Cependant, elles peuvent être tentantes à utiliser. Ce piège est corrigé dans AppLocker, car il ne consulte jamais les variables d’environnement.
Les valeurs par défaut suggérées négligent de prendre en compte les deux \Program Files différents utilisés sur 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 refus erronés dans des situations aléatoires, qui pourraient facilement être manqués lors des tests. par ex. voir les commentaires sur le guide pratique SRP de SpiceWorks. Cela est dû aux applications 32 bits qui lisent les chemins pertinents depuis le WOW6432Node du registre : la résolution est d’ajouter ces deux chemins à SRP pour permettre à tous les programmes de fonctionner sur les machines 32 bits et 64 bits en tant que Non restreint, qu’ils soient démarrés depuis un processus hôte x64 ou x86 : %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramFilesDir (x86)% %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramW6432Dir%
Les extensions par défaut négligent d’interdire les scripts PowerShell (*.PS1) supportés par Windows. (Voir vidéo). Et APPX aussi. De plus, selon le tableau comparatif 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.
Les règles de chemin du registre ne doivent pas avoir de barres obliques immédiatement après le dernier signe pourcentage (bien qu’elles soient incluses dans les propres règles intégrées de Microsoft pour XP/Server 2003) et toutes les barres obliques inverses doivent être remplacées par des barres obliques pour que la règle fonctionne (1/2/3).
Parmi les sources que j’ai trouvées pour SRP, aucune ne rassemble la liste complète ci-dessus pour vous. Et je n’ai découvert l’article de Vadims Podans que par accident. Que se cache-t-il d’autre ?
Si vous essayez de faire un compromis 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 stratégie. Astuce charmante de Vadims Podans encore. Notez que l’explication s’applique à l’utilisation de toute extension dans une règle de chemin. Microsoft présente plusieurs exemples de cela incluant *.Extension, sans avertissement. Donc vous ne pouvez pas faire confiance à la documentation officielle, et il semble peu probable que ce soit corrigé maintenant.
[Inconvénient potentiel d’AppLocker]. Vadims Podans 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’elles s’appliqueraient alors à l’accès via un lecteur mappé ? ce n’est pas 100% clair. Apparemment AppLocker était différent : il ne fonctionnait avec aucun des deux :(. « 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 soit des règles de hachage, soit des règles 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 chères et en invente de plus complexes.
Peut-être qu’aucune autre option n’est disponible (y compris les solutions tierces). Alors une approche pragmatique serait d’essayer de configurer SRP aussi simplement que possible. Traitez-la comme une couche de défense supplémentaire, avec des failles connues. En correspondance avec les pièges ci-dessus :
Partez des règles par défaut (de l’ère pré-Win7 :).
Préférez ne pas utiliser de variables d’environnement, par ex. %systemroot%.
Ajoutez des règles pour vous assurer que les deux répertoires \Program Files\ 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%.
Lors de l’ajout aux règles de chemin du registre, omettez toute barre oblique inverse immédiatement après le signe pourcentage, et remplacez toutes les barres obliques inverses \ suivantes par des barres obliques / (par ex. %HKEY_LOCAL_MACHINE\Software\CompanyName\CustomApps%App/Bin/start.exe)
Ajoutez PS1 à la liste des extensions contrôlées.
Comprenez qu’une configuration SRP gérable n’est pas sécurisée contre un utilisateur déterminé à la contourner. L’objectif est d’aider/encourager les utilisateurs à travailler dans le cadre de la stratégie, pour les protéger contre les attaques comme les « téléchargements furtifs ».
Autorisez les fichiers LNK. (De préférence en les retirant de la liste des extensions, pas via une règle de chemin).
Voir le point 7 :).
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).