Quels sont les avantages / inconvénients de bloquer l'exécution d'un programme dans% appdata%,% temp%, etc.?

En recherchant des moyens d'empêcher CryptoLocker , j'ai vu un message sur un forum qui recommandait d'utiliser des objets de stratégie de groupe (GPO) et / ou un logiciel antivirus pour bloquer l'accès à l'exécution dans les emplacements suivants:

1. %données d'application%
2. % localappdata%
3. % temp%
4. %Profil de l'utilisateur%
5. Archives compressées

Évidemment, tout ce qui est écrit dans un forum doit être pris avec prudence. Cependant, je vois des avantages à le faire, principalement parce que les logiciels malveillants aiment s'exécuter à partir de ces emplacements. Bien sûr, cela pourrait également avoir un impact sur les programmes légitimes.

Quels sont les inconvénients du blocage de l'accès à ces emplacements?

Quels sont les avantages?

La raison pour laquelle les logiciels malveillants aiment s'exécuter à partir de ces emplacements est que les logiciels légitimes aiment s'exécuter à partir de ces emplacements. Ce sont des domaines auxquels le compte de l'utilisateur doit s'attendre à avoir un certain niveau d'accès.

Sur la base d'une grep rapide de mon propre système et d'un compte d'utilisateur final aléatoire sur notre réseau:

%appdata%

En ce moment, j'ai Dropbox , le programme d'installation d' Adobe AIR et quelques cotes et terminaisons Microsoft Office dans ce dossier.

%localappdata%

join.me et SkyDrive semblent vivre ici, ou du moins avoir traversé récemment.

%temp%

De nombreux programmes, légitimes ou non, voudront s'exécuter à partir de ce dossier. Les installateurs se décompressent généralement dans un sous-dossier de cela lorsque vous exécutez setup.exesur une archive d'installation compressée.

%Profil de l'utilisateur%

Il sera généralement sûr à moins que l'utilisateur n'ait des exigences particulières, mais notez qu'au moins certains des dossiers ci-dessus pourraient être des sous-ensembles de cela sur un réseau avec des profils itinérants.

Archives compressées

N'exécutez pas le code directement, mais extrayez-le plutôt à %temp%partir de là.

Quant à savoir si vous devez ou non bloquer ces zones, cela dépend de ce que font généralement vos utilisateurs. S'il leur suffit de modifier des documents Office, de jouer au démineur pendant le déjeuner et peut-être d'accéder à une application LOB via un navigateur, etc., vous n'aurez peut-être pas trop de mal à bloquer les exécutables dans au moins certains de ces dossiers.

De toute évidence, la même approche ne fonctionnera pas pour les personnes dont la charge de travail est moins bien définie.

Avantages:

Les logiciels malveillants tentant de s'exécuter à partir de ces emplacements ne pourront pas s'exécuter.

Les inconvénients:

Les programmes légitimes tentant de s'exécuter à partir de ces emplacements ne pourront pas s'exécuter.

Quant aux programmes légitimes que vous avez dans votre environnement qui ont besoin de droits d'exécution dans ces répertoires, vous seul pouvez le dire, mais je vois que RobM vient de publier une réponse avec une vue d'ensemble de haut niveau . Le blocage de l'exécution à partir de ces répertoires vous posera des problèmes, vous devez donc d'abord effectuer des tests pour déterminer les problèmes que vous rencontrerez et comment les contourner.

Ces recommandations fonctionneraient parfaitement dans mon environnement. AUCUN utilisateur n'est autorisé à installer le logiciel et AUCUN des logiciels approuvés ne s'exécute à partir des emplacements mentionnés. Les postes de travail ont le logiciel approuvé préinstallé dans l'image du poste de travail et mis à jour par script.

Dropbox, Chrome, Skype, etc. peuvent tous être déplacés pendant l'installation vers un emplacement d'installation "Program Files" plus acceptable.

Tant que vous disposez d'une allocation pour l'administrateur ou les administrateurs de domaine (et peut-être un compte "Installer" spécifique) pour pouvoir exécuter des mises à jour et ajouter des logiciels approuvés, je suis d'accord avec les recommandations.

Je suppose que vous voulez refuser le droit d'exécution non seulement à ces dossiers mais à toute l'arborescence à partir d'eux (sinon, il est inutile de faire ce que vous voulez faire).

La conséquence - évidente - sera que tout exécutable situé dans ceux-ci ne fonctionnera pas.

Malheureusement, cela comprendra un assez grand nombre d'applications légitimes.

% localappdata% et% appdata% sont les plus problématiques: Dropbox, Chrome, SkyDrive, par exemple, ne fonctionneront pas. La plupart des téléverseurs automatiques et de nombreux installateurs ne fonctionneront pas non plus.

% UserProfile% est encore pire car il comprend à la fois% localappdata% et% appdata% ainsi qu'un certain nombre d'autres dossiers.

En bref: si vous empêchez les applications de s'exécuter à partir de ces dossiers, votre système peut devenir à peu près inutilisable.

% temp% est différent. Bien que vous puissiez parfois avoir des programmes légitimes à partir de là, c'est assez rare et généralement facile à contourner. Malheureusement,% temp% se développe dans différents dossiers en fonction du contexte utilisateur à partir duquel vous le développez: il peut se retrouver dans% localappdata% \ temp (dans le contexte d'un utilisateur) ou% SystemRoot% \ temp (dans le contexte de système), vous devrez donc sécuriser chaque emplacement individuellement.

% temp% est également un bon candidat car c'est là que la plupart des programmes de messagerie enregistreront les pièces jointes avant de les ouvrir: cela aidera dans de nombreux cas les logiciels malveillants basés sur la messagerie.

Une bonne astuce consiste à modifier les prémisses sur les dossiers C: \ Users \ Default \ AppData \ Local \ temp et C: \ Users \ DefaultAppPool \ AppData \ Local \ Temp lorsque vous configurez le système (et, bien sûr,% SystemRoot% \ temp). Windows copiera ces dossiers lors de la création de nouveaux profils et les nouveaux utilisateurs disposeront donc d'un environnement sécurisé.

Vous voudrez peut-être ajouter% UserProfile% \ Downloads à votre liste: c'est là que la plupart des navigateurs reprendront les fichiers téléchargés de l'utilisateur et refuser l'exécution à partir de là augmentera également la sécurité.

Au cours des trois derniers mois, je cours avec une configuration similaire sur mon poste de travail principal. Mon utilisateur principal dispose de droits d'exécution sur un répertoire ou d'écriture mais jamais des deux.

Cela signifie qu'aucun nouveau fichier exécutable ne peut être introduit par ce compte. C'est le pro, je peux exécuter des programmes déjà sur le système ou installés par d'autres comptes, mais je ne peux pas télécharger de nouveau programme et l'exécuter, cela signifie que tout logiciel malveillant qui arrive via un navigateur ou d'autres moyens a beaucoup plus de mal à s'exécuter sur mon système, l'injection de DLL simple ne fonctionne pas non plus.

Comme d'autres l'ont souligné, le principal problème est que certains logiciels légitimes utilisent les emplacements que j'ai bloqués. Dans mon cas:

• Google Chrome - J'ai installé la version msi
• n'importe quelle application Portable Apps - que j'exécute maintenant sous un autre utilisateur
• Process Explorer - J'utilise directement la version 64 bits extraite
• dism.exe - exécutez en tant qu'administrateur, ce que je dois faire la plupart du temps de toute façon.

Donc, fondamentalement, j'utilise trois comptes, un avec lequel je suis connecté, un autre compte utilisateur normal pour exécuter certains programmes validés et un compte administrateur pour installer de nouveaux logiciels pour les deux autres.

J'aime le fait que cela m'oblige à tester tout logiciel nouvellement téléchargé dans une machine virtuelle.

Je démarre la plupart de mes programmes via PowerShell et ayant trois shells, un pour chaque compte me convient. Que cela fonctionne pour vous dépend vraiment de la quantité de logiciels que vous utilisez qui doit être traitée différemment.

Sur une machine de développeur, cela ne fonctionne pas vraiment car je dois compiler mon code puis l'exécuter. J'ai donc fait une exception pour mon répertoire de code sur un lecteur de données, les logiciels malveillants pourraient analyser tous les lecteurs et trouver cela.

J'utilise des listes de contrôle d'accès NTFS plutôt que des politiques pour appliquer cela. Cela empêche l'exécution de tout programme, mais je peux toujours créer un script PowerShell, puis l'exécuter et cela peut causer suffisamment de dégâts.

Donc, même si cela rend les choses plus difficiles, il n'est pas sûr à 100% mais vous protégerait toujours contre la plupart des logiciels malveillants actuels.

Vous pouvez regarder dans ces dossiers, mais la plupart sont des données, exactement le nom du dossier. Par exemple, vous verrez Chrome, mais l'exécutable réel se trouve dans le dossier c: \ programmes.

J'empêche tous les exécutables de s'exécuter n'importe où sur l'ordinateur à l'exception des dossiers de programme. Autorisé temporairement uniquement lorsque j'ai besoin d'installer quelque chose, et je n'ai jamais eu de problème.

Je recommanderais une recherche rapide dans les répertoires pour voir ce que vous avez actuellement dans chacun d'eux. Si rien ne s'exécute d'eux, suivez maintenant les instructions du forum. Si vous rencontrez un problème à l'avenir, évaluez simplement vos options. La plupart d'entre eux ne devraient de toute façon pas contenir d'exécutables.