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

Ao pesquisar maneiras de impedir o CryptoLocker , vi uma postagem no fórum que recomendava o uso de GPO ( Objetos de Diretiva de Grupo ) e / ou software antivírus para bloquear o acesso à execução nos seguintes locais:

1. %dados do aplicativo%
2. % localappdata%
3. % temp%
4. %Perfil de usuário%
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 ser executado fora desses locais. Obviamente, isso também poderia impactar programas legítimos.

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

Quais são as vantagens?

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 às quais a conta do usuário deve ter algum nível de acesso.

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

%appdata%

No momento, tenho o Dropbox , o instalador do Adobe AIR e algumas chances do Microsoft Office e termina nesta pasta.

%localappdata%

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

%temp%

Muitos programas, legítimos ou não, desejam executar a partir desta pasta. Os instaladores geralmente descompactam-se em uma subpasta disso quando você executa setup.exeem um arquivo compactado do instalador.

%Perfil de usuário%

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

Arquivos compactados

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

Se você deve ou não bloquear essas áreas, depende do que seus usuários normalmente estão fazendo. Se tudo o que eles precisam fazer é editar documentos do Office, tocar o Campo Minado durante o almoço e talvez acessar um aplicativo LOB por meio de um navegador etc., talvez você não tenha muito problema para bloquear executáveis ​​em pelo menos algumas dessas pastas.

Claramente, a mesma abordagem não funcionará para pessoas com cargas de trabalho menos bem definidas.

Prós:

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

Contras:

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

Quanto aos programas legítimos em seu ambiente que precisam de direitos de execução nesses diretórios, apenas você pode dizer, mas vejo que o RobM acabou de publicar uma resposta com uma visão geral de alto nível . O bloqueio da execução a partir desses diretórios causará problemas, portanto, é necessário fazer alguns testes primeiro para determinar quais problemas você terá e como solucionar esses problemas.

Essas recomendações funcionariam perfeitamente no meu ambiente. NENHUM usuário tem permissão para instalar 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 reposicionados durante a instalação em um local de instalação "Arquivos de Programas" mais aceitável.

Contanto que você tenha uma permissão para Administradores ou Administradores de Domínio (e talvez uma conta "Instaladora" específica) para poder executar atualizações e adicionar software aprovado, eu concordo com as recomendações.

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

A conseqüência - óbvia - será que qualquer executável localizado neles falhará na execução.

Infelizmente, isso incluirá um número bastante grande 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 carregadores automáticos e muitos instaladores também falharão no trabalho.

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

Em resumo: 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 em execução a partir daí, é pouco frequente e geralmente fácil de solucionar. Infelizmente,% temp% se expande para pastas diferentes, dependendo do contexto do usuário do qual você está expandindo: pode acabar em% localappdata% \ temp (no contexto de um usuário) ou% SystemRoot% \ temp (no contexto de sistema), assim você terá que proteger cada local individualmente.

% temp% também é um bom candidato, porque é aí que a maioria dos programas de email salva anexos antes de abri-los: isso ajudará em muitos casos de malware baseado em email.

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

Você pode adicionar% UserProfile% \ Downloads à sua lista: é aqui que a maioria dos navegadores igualará os arquivos baixados pelo usuário e negar a execução a partir daí também aumentará a segurança.

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

Isso significa que nenhum novo executável pode ser introduzido por esta conta. Esse é o profissional, eu posso executar programas já instalados 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 no navegador ou outros meios tem muito mais dificuldade em executar no meu sistema, a injeção simples de DLL também não funciona.

Como outros já apontaram, o principal problema é que algum software legítimo usa os locais que eu bloqueei. No meu caso:

• Google Chrome - instalei a versão msi
• qualquer aplicativo de aplicativos portáteis - que agora corro sob um usuário diferente
• Process Explorer - Eu uso a versão extraída de 64 bits diretamente
• dism.exe - execute como admin, o que eu sempre faço na maioria das vezes.

Então, basicamente, estou usando três contas, uma com a qual estou logado, outra conta de usuário normal para executar certos programas validados e uma conta de administrador para instalar um novo software para as outras duas.

Gosto do fato de que ele me força a testar qualquer software recém-baixado em uma VM.

Inicio a maioria dos meus programas via PowerShell e, com três shells, um para cada conta é bom para mim. Se isso realmente funciona para você depende de quanto software você usa e que deve 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 executá-lo. Então, fiz uma exceção para o meu diretório de código em uma unidade de dados, pois o malware pode verificar todas as unidades e encontrar isso.

Estou usando ACLs NTFS em vez de políticas para impor isso. Isso impede a execução de qualquer programa, mas ainda posso criar um script do PowerShell e, em seguida, executá-lo, causando danos suficientes.

Portanto, embora isso torne as coisas mais difíceis, não é 100% seguro, mas ainda o protegeria da maioria dos malwares atuais.

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

Bloqueio a execução de todos os executáveis ​​em qualquer lugar do computador, exceto nas pastas do programa. Permitido apenas temporariamente quando preciso instalar algo e nunca tive problemas.

Eu recomendo 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 no fórum. Se você se deparar com um problema no futuro, basta avaliar suas opções. A maioria deles não deveria ter executáveis.