Quais são os prós e contras de bloquear a execução de um programa em% appdata%,% temp%, etc.?

13

Enquanto pesquisava maneiras de evitar CryptoLocker , vi uma postagem no fórum que aconselhava usar Group Policy Objects (GPO) e / ou software antivírus para bloquear o acesso de execução nos seguintes locais:

  1. % appdata%
  2. % localappdata%
  3. % temp%
  4. % UserProfile%
  5. Arquivos compactados

Obviamente, qualquer coisa escrita em um fórum deve ser tomada com cautela. No entanto, vejo vantagens em fazer isso, principalmente porque o malware gosta de executar esses locais. É claro que isso também pode afetar os programas legítimos.

Quais são as desvantagens de bloquear o acesso de execução a esses locais?

Quais são as vantagens?

    
por poke 11.02.2014 / 15:37

7 respostas

12

A razão pela qual o malware gosta de executar a partir desses locais é porque o software legítimo gosta de executar a partir desses locais. São áreas nas quais a conta do usuário deve ter algum nível de acesso.

Com base em um rápido grep do meu próprio sistema e uma conta de usuário final aleatória em nossa rede:

%appdata%

Neste momento, tenho o Dropbox , o instalador de Adobe AIR e algumas probabilidades do Microsoft Office e termina nesta pasta.

%localappdata%

O join.me e o SkyDrive parecem morar aqui, ou pelo menos ter passado por aqui recentemente.

%temp%

Muitos programas, legítimos ou não, vão querer executar a partir desta pasta. Os instaladores normalmente descompactam a si mesmos em uma subpasta disso quando você executa setup.exe em um archive compactado do instalador.

%UserProfile%

Normalmente, ele será seguro, a menos que o usuário tenha requisitos específicos, mas observe que pelo menos algumas das pastas acima podem ser subconjuntos disso em uma rede com perfis de roaming.

Compressed archives

Não execute código diretamente, em vez disso, extraia para %temp% e execute a partir daí.

Quanto a se você deve ou não bloquear essas áreas, isso depende do que seus usuários normalmente estão fazendo. Se tudo o que eles precisam fazer é editar documentos do Office, jogar Campo Minado durante o almoço e talvez acessar um LOB app através de um navegador, etc., então você pode não ter muita dificuldade em bloquear executáveis em pelo menos algumas dessas pastas.

É evidente que a mesma abordagem não funcionará para pessoas com cargas de trabalho menos bem definidas.

    
por 11.02.2014 / 16:15
6

Prós:

O malware que tentar executar a partir desses locais não poderá ser executado.

Contras:

Os programas legítimos que tentam executar a partir desses locais não poderão ser executados.

Quanto aos programas legítimos que você tem em seu ambiente que precisam de direitos de execução nesses diretórios, só você pode dizer, mas eu vejo RobM Acabou de postar uma resposta com uma visão geral de alto nível . Bloquear a execução desses diretórios causará problemas, então você precisa fazer alguns testes primeiro para determinar quais problemas você terá, e como você precisa contorná-los.

    
por 11.02.2014 / 16:18
3

Essas recomendações funcionariam perfeitamente no meu ambiente. Nenhum usuário tem permissão para instalar o software e NENHUM do software aprovado é executado a partir dos locais mencionados. As estações de trabalho têm o software aprovado pré-instalado na imagem da estação de trabalho e atualizado por script.

O Dropbox, o Chrome, o Skype, etc., podem ser reimplantados durante a instalação em um local de instalação "Arquivos de Programas" mais aceitável.

Desde que você tenha um subsídio para administrador ou administradores de domínio (e talvez uma conta "Instalador" específica) para poder executar atualizações e adicionar software aprovado, eu concordaria com as recomendações.

    
por 11.02.2014 / 20:45
2

Suponho que você queira negar o direito de execução não apenas a essas pastas, mas à árvore inteira a partir delas (caso contrário, não faz sentido fazer o que você deseja fazer).

A conseqüência óbvia é que qualquer executável localizado nesses arquivos falhará na execução.

Infelizmente, isso incluirá um grande número de aplicativos legítimos.

% localappdata% e% appdata% são os mais problemáticos: Dropbox, Chrome, SkyDrive, por exemplo, não funcionarão. A maioria dos uploaders automáticos e muitos instaladores também não funcionam.

% UserProfile% é ainda pior, pois inclui% localappdata% e% appdata%, além de várias outras pastas.

Resumindo: se você impedir que aplicativos sejam executados nessas pastas, seu sistema poderá ficar praticamente inutilizável.

% temp% é diferente. Embora você possa, ocasionalmente, ter programas legítimos sendo executados a partir de lá, é bastante raro e geralmente fácil de contornar. Infelizmente,% temp% se expande para pastas diferentes, dependendo do contexto de usuário do qual você está expandindo: ele pode acabar em% localappdata% \ temp (no contexto de um usuário) ou% SystemRoot% \ temp (no contexto de o sistema) para que você tenha que proteger cada local individualmente.

% temp% também é um bom candidato, porque é onde a maioria dos programas de e-mail salvará os anexos antes de abri-los: isso ajudará em muitos casos de malwares baseados em e-mail.

Um bom truque é alterar as premissas nas pastas C: \ Users \ Default \ AppData \ Local \ temp e C: \ Users \ DefaultAppPool \ AppData \ Local \ Temp ao configurar o sistema (e, é claro, % SystemRoot% \ temp). O Windows copiará essas pastas quando criar novos perfis e, assim, os novos usuários terão um ambiente seguro.

Você pode querer adicionar% UserProfile% \ Downloads à sua lista: é nesse ponto que a maioria dos navegadores farão o mesmo com os arquivos baixados do usuário, e a negação da execução também aumentará a segurança.

    
por 11.02.2014 / 16:28
2

Nos últimos três meses, estou executando uma configuração semelhante na minha estação de trabalho principal. Meu usuário principal tem permissões de execução para um diretório ou permissões de gravação, mas nunca as duas.

Isso significa que nenhum novo executável pode ser introduzido por essa conta. Esse é o profissional, eu posso executar programas já no sistema ou instalados por outras contas, mas não consigo baixar nenhum programa novo e executá-lo, isso significa que qualquer malware que entra por um navegador ou outro meio tem muito mais dificuldade para executar no meu sistema, a injeção de DLL simples também não funciona.

Como outros apontaram, o principal problema é que alguns softwares legítimos usam os locais que eu bloqueei. No meu caso:

  • Google Chrome - instalei a versão do msi
  • qualquer aplicativo Portable Apps - que agora executo com um usuário diferente
  • Process Explorer - Eu uso diretamente a versão de 64 bits extraída
  • dism.exe - execute como administrador, o que eu tenho que fazer na maior parte do tempo de qualquer maneira.

Então, basicamente, estou usando três contas, uma com a qual estou logado, outra conta de usuário normal para executar determinados programas validados como e uma conta de administrador para instalar um novo software para os outros dois.

Eu gosto do fato de que isso me força a testar qualquer software baixado recentemente em uma VM.

Eu inicio a maioria dos meus programas via PowerShell e tenho três shells, um para cada conta é bom para mim. Se isso funciona para você, realmente depende de quanto software você usa que precisa ser tratado de maneira diferente.

Em uma máquina de desenvolvedor, isso realmente não funciona porque eu tenho que compilar meu código e depois executá-lo. Então eu fiz uma exceção para o meu diretório de código em uma unidade de dados, o malware poderia varrer todas as unidades e encontrar isso.

Estou usando as ACLs do NTFS em vez de políticas para impor isso. Isso impede que qualquer programa seja executado, mas ainda posso criar um script do PowerShell e executá-lo, o que pode causar danos suficientes.

Então, enquanto isso dificulta as coisas, ele não é 100% seguro, mas ainda protege você do malware mais atual.

    
por 11.02.2014 / 20:02
0

Você pode procurar nessas pastas, mas a maioria são dados, exatamente para o nome da pasta. Por exemplo, você verá o chrome, mas o executável real está na pasta c: \ programs.

Eu bloqueio todos os executáveis de execução em qualquer lugar no computador, exceto as pastas do programa. Permitido apenas temporariamente quando preciso instalar algo, e nunca tive problemas.

    
por 21.08.2014 / 04:07
-1

Eu recomendaria uma pesquisa rápida dos diretórios para ver o que você tem em cada um deles atualmente. Se nada estiver sendo executado a partir deles, siga as orientações do fórum. Se você se deparar com um problema no futuro, simplesmente avalie suas opções. A maioria deles não deve ter executáveis neles.

    
por 11.02.2014 / 16:02