Política de restrição Applocker vs Software

O objetivo é impedir que os usuários executem programas indesejados em um servidor de terminal.

Eu li muitos artigos da Microsoft e de outros dizendo que o novo recurso Applocker é 100% melhor que a antiga Política de Restrição de Software e é recomendado como uma substituição desta.

Não tenho certeza de entender as vantagens reais do Applocker além da execução no modo kernel. A maioria de suas funcionalidades pode ser reproduzida com a Política de Restrição de Software.

Ao mesmo tempo, ele tem uma GRANDE desvantagem que o torna bastante inútil: não é extensível e você não pode adicionar extensões de arquivo personalizadas que deseja restringir.

Quais são as vantagens do Applocker sobre o SRP e o que você recomendaria para o controle de software?

A Política de Restrição de Software foi descontinuada pela Microsoft (tecnologia que afirma efetivamente que o SRP não é suportado ), desde que o Windows 7 Enterprise / Ultimate introduziu o AppLocker.

Na prática, o SRP tem certas armadilhas, tanto para falsos negativos quanto para falsos positivos. O AppLocker tem a vantagem de ainda estar sendo mantido e suportado ativamente. Se o AppLocker for uma opção, poderá ser a mais barata - depois de contabilizar o tempo e os riscos assumidos. Também é possível que exista uma alternativa de terceiros adequada (mas essa pergunta não incluiu essa opção :).

Espero que você tenha uma compreensão perfeita das armadilhas do SRP antes de cair em qualquer uma delas </sarcasm>. Alguns deles são descritos em um bom artigo de segurança da Vadims Podāns .

Armadilhas conhecidas

1. Por padrão, a execução da \Windowspasta é permitida. Algumas subpastas podem ser gravadas pelos usuários. Applocker é o mesmo, mas pelo menos a documentação oficial menciona essa limitação .

   Edição: "Para enumerar todas as pastas com acesso de gravação de usuários, você pode usar, por exemplo, o utilitário AccessEnum do pacote Sysinternals." (ou AccessChk ).

   Tecnicamente, a documentação também evita a substituição das regras padrão . EDIT: Um documento da NSA fornece 16 exemplos de pastas para a lista negra com SRP , embora as regras do caminho do registro usem barras invertidas incorretamente, portanto, devem ser corrigidas (consulte o ponto nos caminhos do registro abaixo) e avisa sobre uma entrada comum na lista negra excessiva.

   A pergunta óbvia é por que não estamos colocando na lista branca cuidadosamente os caminhos individuais abaixo \Windows. (Incluindo o \Windows\*.exelegado System32\*.exe, etc). Não notei respostas para isso em nenhum lugar :(.

2. Usando variáveis ​​de ambiente como %systemroot%, o SRP pode ser ignorado pelos usuários limpando a variável de ambiente. EDIT: Estes não são usados ​​nos padrões sugeridos. No entanto, eles podem ser tentadores de usar. Essa espingarda é corrigida no AppLocker, porque nunca analisa variáveis ​​de ambiente.

3. Os padrões sugeridos são negligenciados para permitir os dois diferentes \Program Filesusados ​​nas instalações modernas de 64 bits. Ao resolver isso usando os "caminhos do registro" mais seguros, há relatos de negações falsas em situações aleatórias, que podem ser facilmente perdidas nos testes. por exemplo, veja comentários sobre o SpiceWorks SRP howto . EDIT: isso é para aplicativos de 32 bits que leem caminhos relevantes do WOW6432Node do registro: a resolução é adicionar esses dois caminhos ao SRP para permitir que todos os programas funcionem em máquinas de 32 bits e de 64 bits como irrestrito, se iniciado a partir de um processo host x64 ou x86:%HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramFilesDir (x86)% %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramW6432Dir%
4. As extensões padrão negligenciam a proibição de scripts do PowerShell (* .PS1) suportados pelo Windows . (Veja o vídeo ). E o APPX também ... também de acordo com a tabela de comparação da Microsoft, o SRP não pode gerenciar "Aplicativos empacotados" no Windows 8, não tenho idéia do que isso significa.
5. Regras de caminho de registro não deve ter barras imediatamente após o último sinal de porcentagem (apesar de ser incluído no da Microsoft própria base de regras para XP / Server 2003) e quaisquer barras invertidas devem ser substituídos com forwardslashes em ordem para a regra para o trabalho ( 1 / 2 / 3 )
6. Das fontes que encontrei para o SRP, nenhuma colocou a lista completa acima para você. E só descobri o artigo de Vadims Podāns por acidente. O que mais está à espreita por aí?
7. Muitas fontes recomendam simplesmente remover arquivos LNK da lista. (E atalhos da Web para evitar a quebra de favoritos ?!). De maneira perturbadora, nenhuma fonte parece discutir as vulnerabilidades do LNK ... ou fazer com que os intérpretes de script executem arquivos com uma extensão inesperada, por exemplowscript /e ... ou talvez com um código de shell suficiente em um parâmetro de script embutido ... etc.
8. Se você tentar se comprometer ao permitir arquivos LNK na área de trabalho e deixar usuários com acesso de gravação à área de trabalho, agora eles poderão ignorar completamente sua política. Dica adorável de Vadims Podāns novamente. Observe que a explicação se aplica ao uso de qualquer extensão em uma regra de caminho. A Microsoft apresenta vários exemplos disso *.Extension, incluindo , sem aviso prévio. Portanto, você não pode confiar na documentação oficial e parece improvável que seja corrigido agora.
9. [Potencial desvantagem do AppLocker]. Vadims Podāns relata que as entradas SRP usando unidades mapeadas não funcionam. O caminho UNC deve ser usado. Talvez eles se candidatassem ao acesso através de uma unidade mapeada? não é 100% claro. Aparentemente, o AppLocker era diferente: não funcionava com :(. "Por motivos desconhecidos, os caminhos UNC não funcionam no Applocker! Isso significa que, se o aplicativo estiver instalado na rede, você deverá criar regras de hash ou de editor . "

Abordagem pragmática

A lista de permissões de software é potencialmente uma defesa muito poderosa. Se ficarmos cínicos: é exatamente por isso que a Microsoft reprova as versões de preço mais baixo e inventa versões mais complexas.

Talvez nenhuma outra opção esteja disponível (inclua soluções de terceiros). Então, uma abordagem pragmática seria tentar configurar o SRP da maneira mais simples possível. Trate-o como uma camada extra de defesa, com furos conhecidos. Combinando as armadilhas acima:

1. Comece pelas regras padrão (da era anterior ao Win7 :).
2. Prefira não usar variáveis ​​de ambiente, por exemplo %systemroot%.
3. Adicione regras para garantir que ambos os \Program Files\diretórios sejam permitidos em máquinas modernas de 64 bits. Os "caminhos de registro" extras que você precisará adicionar \Program Files\nos computadores de 64 bits são %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramFilesDir (x86)%e %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramW6432Dir%.
4. Ao adicionar às regras do caminho do registro, deixe de fora a barra invertida imediatamente após o sinal de porcentagem e substitua outras barras invertidas \por barras invertidas /(por exemplo %HKEY_LOCAL_MACHINE\Software\CompanyName\CustomApps%App/Bin/start.exe)
5. Adicione o PS1 à lista de extensões controladas.
6. Entenda que uma configuração gerenciável de SRP não é segura contra um usuário determinado a derrotá-la. O objetivo é ajudar / incentivar os usuários a trabalharem dentro da política, para protegê-los contra ataques como "downloads drive-by".
7. Permitir arquivos LNK. (De preferência, removendo-o da lista de extensões, não através de alguma regra de caminho).
8. Veja acima :).
9. Verifique se a pasta do script de logon é permitida. O documento da NSA sugere adicionar \\%USERDNSDOMAIN%\Sysvol\. (Veja o ponto 2, suspiro e depois o ponto 6).

Concordo que o SRP possui alguns recursos adicionais dos quais o AppLocker poderia realmente se beneficiar.

Dito isto, vejo os grandes benefícios do AppLocker (conforme documentado nesta comparação ) como:

• As regras do AppLocker podem ser direcionadas a um usuário específico ou a um grupo de usuários, enquanto o SRP é aplicado em todo o computador.
• O AppLocker suporta o modo de auditoria para que as regras possam ser testadas na produção antes de serem aplicadas. O SRP não possui um modo somente de log equivalente.

A maior vantagem para mim é a capacidade de colocar na lista branca os executáveis ​​assinados pelo editor. Dê uma olhada neste http://technet.microsoft.com/en-us/library/ee460943(v=ws.10).aspx

Não há benefícios do AppLocker, a Microsoft publicou mentiras flagrantes: 1. GPOs com regras SAFER podem ser anexados a usuários e grupos de usuários; 2. O Windows Vista introduziu vários GPOs locais que alcançam o mesmo resultado sem um controlador de domínio; 3. o modo de auditoria está disponível através do recurso de registro estendido sem aplicação.

Eu uso o Applocker dentro da minha empresa. A estratégia que usamos é: Negar tudo como linha de base (na verdade: o Applocker é o padrão) e, em seguida, faça o que foi sugerido: faça uma regra que permita apenas aplicativos assinados (escritório, adobe, ferramentas de win, axe etc.). A maioria, talvez todo malware seja um software não assinado, portanto não será executado. Quase não existe manutenção. Eu só tinha que permitir três aplicativos herdados extras.

Além disso, não posso confirmar que não se pode usar caminhos UNC. Em algumas regras de negação de segurança extras, uso o caminho UNC com sucesso. A armadilha está no uso de variáveis ​​do ambiente: elas não funcionam para o Applocker. Use * curingas. Eu o uso no Windows 2008 R2 e no Windows 2012 R2.

Gosto muito: quase não há queda de desempenho. Como diz a documentação: O Applocker conta com o Serviço de identidade de aplicativos (verifique se ele é iniciado automaticamente).