Estou tentando colocar algumas medidas de prevenção de malware adicionais, limitando a execução de * .exe em vários locais - em particular, as pastas temporárias às quais várias ferramentas de compactação são descompactadas, quando um usuário pode escolher para abrir um executável diretamente de um arquivo Zip.
No artigo do TechNet, link :
You can use environment variables in a path rule. Since path rules are evaluated in the client environment, the ability to use environment variables (for example, %Windir%) allows a rule to adapt to a particular user’s environment.
...
A path rule can incorporate the ? and * wildcards, allowing rules such as "*.vbs" to match all Visual Basic Script files. The following examples illustrate the use of wildcards:
- “\DC-??\login$” matches \DC-01\login$, \DC-02\login$
- “*\Windows” matches C:\Windows, D:\Windows, E:\Windows
- “c:\win*” matches c:\winnt, c:\windows, c:\windir
Eu tenho essas regras de caminho (que apliquei individualmente e em várias combinações):
%APPDATA%\*.exe %APPDATA%\*\*.exe %LOCALAPPDATA%\*.exe %LOCALAPPDATA%\*\*.exe %TEMP%\*.exe %TEMP%z*\*.exe %TEMP%\wz*\*.exe %TEMP%\Rar*\*.exe ... que teoricamente deve representar executáveis diretamente na pasta temporária do usuário, e executáveis em pastas temporárias nomeadas da maneira que o Winzip, WinRAR e 7-zip podem nomear suas pastas temporárias (por exemplo, %TEMP%zSF20.tmp\the_file.exe ).
Os trabalhos %APPDATA% e %LOCALAPPDATA% funcionam; os %TEMP% não. Os executáveis aparecem para serem bloqueados em% TEMP%, mas isso ocorre apenas porque, em uma configuração padrão, eles também correspondem à regra %LOCALAPPDATA%\*\*.exe (Por padrão, Temp está em AppData \ Local).
Eu tinha pensado originalmente que isso era um problema com curingas em nomes de pastas parciais, mas parece que isso é específico para o uso da variável% TEMP% (daí a reescrita).
As duas soluções que confirmei (e por que prefiro não usá-las) são:
usando %LOCALAPPDATA%\Temp no lugar de %TEMP%
%TEMP% pode ser definida para diferir de %LOCALAPPDATA%\Temp . usando %HKEY_CURRENT_USER\Environment\TEMP%
%HKEY_CURRENT_USER\Environment\TEMP%z*\*.exe será fechado (o %HKEY_CURRENT_USER\Environment\TEMP%7z* entre a variável e a subpasta não deve ser especificado, e você não pode especificar uma máscara de nome de arquivo posteriormente) \ e executou o programa a partir do prompt). (Para o que vale a pena, tentei configurar o SRP nas seções Computador e Usuário do GPO, de forma independente e simultânea, caso um substitua o outro ou SET TEMP=C:\ foi resolvido de maneira diferente no Computador e no Usuário nível.)
O que há de tão especial sobre a variável %TEMP% que ela não aplicaria aqui, enquanto algo como %TEMP% seria?
Parece que a limitação é especificamente com a variável de ambiente %LOCALAPPDATA%\Temp\wz*\*.exe . Eu editei a questão como tal.
O programa pode ver um conteúdo diferente de% TEMP% do que você, quando você o verifica em cmd.exe ou command.com. Às vezes eles não são os mesmos.
Mas usar Variáveis de Ambiente na Política de Restrição de Software é uma má ideia, porque um malware pode alterar a variável.
Eu uso isso para bloquear arquivos exe de% TMP% e% TMP% * \, parece estranho, mas funciona aqui no Win7 pro clients, habilitado para o UAC, sem permissões administrativas no usuário atual.
%HKEY_CURRENT_USER\Environment\TEMP%*exe
%TEMP%\*\*.exe
Eu tentei usar %TEMP%\Rar*\*.exe e bloqueie com sucesso a execução de %TEMP%\Rar15\putty.exe e de %TEMP%\Rar14.tmp\putty.exe
Eu não acho que% TEMP% possa ter algo especial. Eu verifiquei novamente, o caminho da chave do registro que eu uso não afeta %TEMP%\Rar*\*.exe
Por favor, tente isto:
%HKEY_CURRENT_USER\Environment\TEMP%7z*/*.exe
Onde você omite a barra invertida (\) após fechar% e, em seguida, usar barra (/) para subdiretórios
Eu encontrei esta referência: link
Tags windows security group-policy