Windows Server - alguma maneira de evitar a criptografia de arquivos?

6

Não estou falando sobre o EFS ou o Bitlocker aqui.

Estou perguntando se existe uma maneira de impedir que os arquivos sejam criptografados. Estou me referindo, de certa forma, ao ransomware, mas especificamente quero o seguinte cenário:

  • Servidor de arquivos do Windows com compartilhamentos (na unidade E:)

Eu quero uma maneira de dizer ao servidor acima "não permitir que arquivos na unidade E: sejam criptografados por ninguém ou por qualquer software / processo."

Não consigo encontrar uma maneira de fazer isso no nível do NTFS, com exceção do acesso "read". Modificar o acesso permite que os arquivos sejam criptografados.

Pesquisei on-line, mas recebi vários links EFS / bitlocker / ransomware que não têm nada a ver com a minha dúvida.

Então, colegas especialistas. Qualquer maneira de fazer o acima em negrito? Eu não estou perguntando sobre formas de prevenir ransomware, etc. A área em negrito é especificamente o que eu estou procurando.

    
por TheCleaner 08.03.2016 / 18:26

7 respostas

14

Em suma: não.

Como você disse, se permitir que os usuários tenham acesso de gravação, eles poderão criptografar os dados. Eu não poderia conceber uma maneira que um sistema operacional ou sistema de arquivos pudesse possivelmente iniciar para detectar e prevenir os muitos tipos de criptografia que estão por aí.

É um problema difícil, no entanto, e espero que os fornecedores de sistemas operacionais estejam dedicando esforços significativos para a renderização do Cryptolocker et. al. menos destrutivos do que são atualmente.

Até lá, manter o maior número possível de backups possíveis e garantir que esses backups possam ser restaurados de forma confiável e rápida será a melhor proteção.

    
por 08.03.2016 / 18:29
4

Sim, mas também não

Este é um daqueles casos estranhos em que é literalmente impossível evitar qualquer forma de fazer algo.

Você pode impedir que processos como o Bitlocker, o Truecrypt e outros programas de criptografia legítimos acessem o compartilhamento. Na maioria das vezes, isso é feito por meio de Diretivas de Grupo (o Bitlocker vem à mente aqui) ou pacotes de software específicos "tudo em um" (consulte a Kaseya, Labtech ou NAble).

É fácil?

Senhor não. Você teria que rotear um procedimento de resposta para cada programa de criptografia separado. E você teria que fazer isso para cada novo programa que chega no mercado. Seria tempo intensivo e doloroso e ainda cobriria apenas 50% das situações. Escrevi com o Labtech e o N-Able, e não, não é rápido e fácil de fazer.

Espere, você também disse que não?

Isso mesmo, também não. Não, porque a maioria dos programas de resgate não está usando um programa de criptografia. Eles estão apenas abrindo arquivos específicos em algo semelhante a um editor de texto e alterando os valores de acordo com um hash que eles geraram. Você expressamente não pode parar esse tipo de comportamento, a menos que negue o acesso de modificação ao compartilhamento.

Então, vale a pena?

Não. Provavelmente você pode bloquear os criptografadores legítimos e úteis, mas os perigosos provavelmente ainda conseguirão passar.

Uma edição notável

Enquanto a pergunta atual é tratada acima, o que eu acredito que a intenção da pergunta é pode ser resumida um pouco melhor. Tendo acabado de ter outra corrida com um bom armário de criptografia hoje, eu tenho uma atualização para a minha perspectiva sobre o assunto.

Embora tenhamos medo dos armários de criptografia como o fim de tudo, sejam todas as infecções perigosas, às vezes as estimamos demais. Este dispositivo de criptografia específico foi capturado pelo nosso software antivírus corporativo em menos de dois minutos. No total, ele conseguiu criptografar um total de 7 pastas em um compartilhamento de rede antes de ser detectado e excluído. Estranhamente, foi realmente inteligente o suficiente para ir para os compartilhamentos de rede primeiro, um comportamento que eu não tinha visto em armários de criptografia anteriores.

Embora alguns dados muito importantes possam muito bem estar nas sete pastas criptografadas (não foi no nosso caso), o efeito total ainda é mínimo. Com uma solução de backup adequada, nosso tempo de recuperação total provavelmente será de < 4 horas e só será alto porque estou usando a oportunidade de reimplantar a estação de trabalho que estava infectada.

Se você está gastando mais de 4 horas tentando desenvolver uma defesa contra armários de criptografia, provavelmente não vale o custo de desenvolvê-la.

    
por 08.03.2016 / 21:04
3

Os arquivos são apenas bytes.

Não há status "criptografado" especial nesse contexto. Ou você tem acesso de gravação ao arquivo ou não. Quando você tiver acesso de gravação a um arquivo, todas as apostas serão desativadas. Não há nada diferente sobre bytes criptografados versus outros bytes que você pode proteger. Você pode argumentar que os bytes criptografados são de alguma forma "mais aleatórios", mas os algoritmos de compactação têm praticamente o mesmo efeito ... qualquer coisa que tente detectar a gravação de bytes criptografados também é acionada sempre que alguém edita ou salva uma imagem, vídeo ou arquivo de áudio.

Se você quiser proteger-se contra o ransom-ware em um servidor de arquivos, tenha uma boa proteção antivírus nos clientes, em seu gateway e no servidor. Siga o princípio de menor privilégio na máquina local para limitar a possibilidade de infecção e nos níveis de compartilhamento de arquivo / servidor de arquivos para limitar o acesso de gravação e, portanto, o escopo do dano se / quando ocorrerem infecções. Faça bons backups (com restaurações testadas) que estejam fisicamente separados da fonte para que você possa recuperar arquivos se / quando algo acontecer.

Pode ser interessante ver uma plataforma de compartilhamento de arquivos que permite apenas certos tipos de arquivos conhecidos, escrever buffers de E / S e verificar os cabeçalhos dos arquivos para garantir que os dados de cabeçalho correspondam às extensões de arquivo (jpgs têm cabeçalhos legíveis, txt arquivos só permitem ascii, etc). Mas isso definitivamente não faz parte do seu compartilhamento comum SMB / DFS / CIFS, e esse tipo de coisa é fácil de ser derrotado sempre escrevendo cabeçalhos válidos.

    
por 14.03.2016 / 22:27
1

Não, você não pode impedir que arquivos sejam criptografados. Como o sistema operacional supostamente saberia se um arquivo é criptografado versus ser de algum formato que ele não "conhece"?

Você pode desabilitar a criptografia no nível do sistema operacional e talvez alguns programas sejam executados via GPO, mas isso não pode parar todos os programas, nem os usuários carregam arquivos criptografados .

O que você quer fazer é garantir que os usuários só coloquem arquivos onde deveriam - e em nenhum outro lugar.

    
por 14.03.2016 / 21:11
-1

Se você tiver o Active Directory, você pode tentar um GPO SRP (Políticas de Restrição de Software) para bloquear executáveis nesses caminhos:

%AppData%\
%AppData%\*\
%localappdata%\
%localappdata%\*\
%localappdata%\Microsoft\Windows\Temporary Internet Files\
%localappdata%\Microsoft\Windows\Temporary Internet Files\Content.Outlook\
%localappdata%\Microsoft\Windows\Temporary Internet Files\Content.Outlook\*\
%localappdata%\Microsoft\Windows\Temporary Internet Files\Content.Outlook\*\*\
%Temp%\
%Temp%\$*\
%Temp%\*.zip\
%userprofile%\

Extraído de: link

    
por 01.04.2016 / 13:05
-1

Existe [potencialmente] uma solução SIMPLES para isso. Crie (talvez através de ACL) a capacidade do sistema operacional exigir uma aprovação do usuário quando uma modificação é feita em um determinado tipo de arquivo (por exemplo, .mdb, .docx, etc.). Como os processos crytpo fazem essas coisas rapidamente, sem intervenção do usuário, a criptografia é bem-sucedida. Mas se clicar em um botão "OK" permitirá a gravação, também irá impedir uma gravação em um arquivo.

Provavelmente não é uma solução perfeita, mas é um começo na prevenção de modificações rápidas de arquivos de sistemas clientes em unidades compartilhadas.

Apenas meus 2 ¢ EUA (ou US $ 7,54 canadenses)

    
por 16.03.2018 / 16:36
-2

Estamos com problemas semelhantes. Os usuários estão copiando arquivos criptografados para o nosso servidor de arquivos principal do Windows 2012 R2 e, é claro, outros usuários não podem ler os arquivos. Algumas coisas estranhas são: ele costumava avisar o usuário quando copiava os arquivos criptografados para dar-lhes uma opção de descodificação primeiro, ele não faz mais isso e copia os arquivos criptografados diretamente. A outra coisa estranha é que no meu servidor Windows 2012 R2 de teste, ele não permite arquivos criptografados, em vez disso, leva muito tempo para copiar o arquivo e, quando isso é feito, os arquivos não são criptografados. Estou executando o Windows Update para ver se "quebra" então.

Aqui está a sugestão da nossa equipe de suporte de software de criptografia. Ainda estou para aplicá-lo, pois não posso duplicar o problema em nosso servidor de produção em nosso ambiente de teste.

Ao definir a opção EFS como "Não permitir", isso fará com que os prompts reapareçam. O comportamento que você está descrevendo é provavelmente uma configuração nesse servidor de arquivos. Quando a Microsoft conclui a configuração de um novo servidor, independentemente da função desse servidor, a configuração do EFS no servidor (não no domínio) será definida como "Não definido". Dependendo do cenário, "Não definido" pode significar "ativado" ou "desativado". No servidor de arquivos, abra “gpedit.msc” e navegue até Configuração do computador > > Configurações do Windows > > Configurações de segurança > > Políticas de chave pública > > Sistema de arquivos com criptografia. Clique com o botão direito do mouse na pasta EFS e selecione Propriedades. Altere a opção para "Criptografia de arquivos usando EFS (Sistema de arquivos com criptografia)" para "Não permitir" ou "Desativar". *** Nota: Antes de desligar o EFS no servidor de arquivos, você deve fazer com que os usuários movam os dados de volta para sua máquina original. Depois de desabilitar o EFS, o usuário pode copiar os dados de volta para o compartilhamento de arquivos. Também recomendamos que o EFS seja desativado em todos os servidores de arquivos que você possa ter em seu ambiente.

    
por 26.01.2017 / 17:36