Я не говорю здесь о EFS или Bitlocker.
Я спрашиваю, есть ли способ предотвратить шифрование файлов. Я имею в виду в некоторой степени программы-вымогатели, но конкретно мне нужен следующий сценарий:
Мне нужен способ сказать указанному выше серверу: «Не позволяйте никому или любому программному обеспечению / процессу шифровать файлы на диске E:».
Я не могу найти никакого способа сделать это на уровне NTFS, кроме доступа для чтения. Изменить доступ позволяет шифровать файлы.
Я искал в Интернете, но получил кучу ссылок на EFS / bitlocker / ransomware, которые не имеют ничего общего с моим вопросом.
Так что коллеги-эксперты. Есть ли способ выделить выше жирным шрифтом? Я не спрашиваю о способах защиты от программ-вымогателей и т. Д. Полужирный шрифт - это именно то, что мне нужно.
Короче: нет.
Как вы сказали, если вы разрешите пользователям иметь доступ для записи, они смогут шифровать данные. Я не мог представить себе, как операционная система или файловая система могла даже Начало для обнаружения и предотвращения множества существующих типов шифрования.
Однако это сложная проблема, и я ожидаю, что поставщики ОС прилагают значительные усилия для рендеринга Cryptolocker et. al. менее разрушительны, чем сейчас.
До тех пор наилучшей защитой будет поддержание как можно большего числа различных типов резервных копий и обеспечение надежного и быстрого восстановления этих резервных копий.
Да, но тоже нет
Это один из тех странных случаев, когда буквально невозможно предотвратить каждый способ действия.
Вы можете запретить таким процессам, как Bitlocker, Truecrypt и другим законным программам шифрования доступ к общему ресурсу. В большинстве случаев это делается с помощью групповых политик (здесь на ум приходит Bitlocker) или конкретных программных пакетов «все в одном» (посмотрите на Kaseya, Labtech или NAble).
Это просто?
Господа нет. Вам нужно будет создать сценарий процедуры ответа для каждой отдельной программы шифрования. И вам придется делать это для каждой новой программы, которая появляется на рынке. Это будет трудоемко и болезненно, и все же охватит только 50% ситуаций. Я писал сценарии как с Labtech, так и с N-Able, и нет, это не так быстро и легко сделать.
Подожди, ты тоже сказал нет?
Правильно, тоже нет. Нет, потому что большинство программ-вымогателей не используют программу шифрования. Они просто открывают определенные файлы в чем-то вроде текстового редактора и меняют значения в соответствии с сгенерированным ими хешем. Вы явно не можете остановить этот тип поведения, если не запретите изменять доступ к общему ресурсу.
Итак, оно того стоит?
Нет. Вы, вероятно, можете заблокировать законные и полезные шифровальщики, но опасные, вероятно, все равно пройдут.
Примечательное редактирование
Хотя сам вопрос уже рассмотрен выше, я считаю, что смысл вопроса можно сформулировать немного лучше. Только что проверив сегодня хороший крипто-шкафчик, я напомнил себе мою точку зрения на этот вопрос.
Хотя мы опасаемся, что крипто-шкафчики - это всего лишь конец опасным инфекциям, иногда мы переоцениваем их. Этот конкретный крипто-шкафчик был обнаружен нашим корпоративным антивирусным ПО менее чем за две минуты. Всего ему удалось зашифровать в общей сложности 7 папок на сетевом ресурсе перед обнаружением и удалением. Как ни странно, на самом деле он был достаточно умен, чтобы сначала использовать сетевые ресурсы, чего я не видел в предыдущих криптоблоках.
Хотя некоторые очень важные данные вполне могли находиться в семи зашифрованных папках (в нашем случае этого не было), общий эффект все же минимален. При наличии подходящего решения для резервного копирования общее время восстановления, скорее всего, составит <4 часов, и только потому, что я использую возможность повторно развернуть зараженную рабочую станцию.
Если вы тратите более 4 часов, пытаясь разработать защиту от крипто-шкафчиков, вероятно, это не стоит затрат на ее разработку.
Файлы - это просто байты.
В этом контексте нет особого статуса «зашифрованный». Либо у вас есть доступ на запись к файлу, либо его нет. Если у вас есть доступ для записи в файл, все ставки отключены. Нет ничего особенного в зашифрованных байтах и других байтах, от которых вы можете защититься. Вы можете возразить, что зашифрованные байты каким-то образом «более случайны», но алгоритмы сжатия имеют почти такой же эффект ... все, что может попытаться обнаружить запись зашифрованных байтов, вероятно, также сработает всякий раз, когда кто-либо редактирует или сохраняет изображение, видео или аудио файл.
Если вы хотите защититься от программ-вымогателей на файловом сервере, установите хорошую антивирусную защиту на клиентах, на вашем шлюзе и на сервере. Следуйте принципу минимальных привилегий на локальном компьютере, чтобы ограничить возможность заражения, и на уровнях файлового сервера / общего файлового ресурса, чтобы ограничить доступ для записи и, следовательно, масштаб ущерба, если / когда происходит заражение. Создавайте хорошие резервные копии (с проверенными операциями восстановления), которые физически отделены от источника, чтобы вы могли восстановить файлы, если / когда что-то произойдет.
Было бы интересно увидеть платформу совместного использования файлов, которая разрешает только определенные известные типы файлов, буферы записывают ввод-вывод и сканируют заголовки файлов, чтобы убедиться, что данные заголовка соответствуют расширениям файлов (jpgs имеют читаемые заголовки, txt файлы разрешают только ascii и т. д.). Но это определенно не часть вашего общего ресурса SMB / DFS / CIFS, и такого рода вещи легко решить, просто всегда записывая действительные заголовки.
Нет, вы не можете предотвратить шифрование файлов. Как ОС должна знать, зашифрован ли файл или имеет какой-то формат, о котором она не «знает»?
Вы можете отключить шифрование на уровне ОС и, возможно, некоторые программы не запускаются через GPO, но это не может остановить каждый программа, ни пользователи, загружающие уже зашифрованные файлы.
Что вы хотите сделать, так это убедиться, что пользователи размещают файлы только там, где им положено, а не куда-либо еще.
Если у вас есть Active Directory, вы можете попробовать GPO SRP (Software Restriction Policies), чтобы заблокировать исполняемые файлы по этим путям:
%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%\
Извлечен из: http://www.sysadmit.com/2015/04/windows-gpo-para-prevenir-cryptolocker.html
Есть [потенциально] ПРОСТОЕ решение этой проблемы. Создайте (возможно, через ACL) возможность для ОС запрашивать одобрение пользователя при внесении изменений в определенный тип файла (например, .mdb, .docx и т. Д.). Поскольку процессы crytpo делают это быстро, без вмешательства пользователя, шифрование проходит успешно. Но если нажатие на кнопку «ОК» разрешает запись, это также ПРЕДОТВРАЩАЕТ запись в файл.
Вероятно, это не идеальное решение, но это начало предотвращения быстрой модификации файлов клиентскими системами на общих дисках.
Только мои 2 доллара США (или 7,54 канадских доллара)
У нас похожие проблемы. Пользователи копируют зашифрованный файл на наш основной файловый сервер Windows 2012 R2, и, конечно же, другие пользователи не могут читать файлы. Вот пара странных вещей: когда он копировал зашифрованные файлы, он предлагал пользователю сначала выбрать способ расшифровки, он больше этого не делает и копирует зашифрованные файлы напрямую. Другая странность заключается в том, что на моем тестовом сервере Windows 2012 R2 он не позволяет использовать зашифрованные файлы, вместо этого требуется много времени, чтобы скопировать файл, и когда это будет сделано, файлы не зашифрованы. Я запускаю Центр обновления Windows, чтобы проверить, не "ломается" ли тогда.
Вот предложение от нашей службы поддержки программного обеспечения для шифрования. Мне еще предстоит применить его, поскольку я не могу воспроизвести проблему на нашем производственном сервере в нашей тестовой среде.
Если для параметра EFS установлено значение «Не разрешать», запросы будут появляться снова. Описываемое вами поведение, скорее всего, является настройкой на этом файловом сервере. Когда Microsoft завершит настройку нового сервера, независимо от роли этого сервера, для параметра EFS на сервере (а не в домене) будет установлено значение «Не определено». В зависимости от сценария «Не определено» может означать «включено» или «отключено». На файловом сервере откройте «gpedit.msc» и перейдите к Конфигурация компьютера >> Параметры Windows >> Параметры безопасности >> Политики открытого ключа >> Шифрованная файловая система. Щелкните правой кнопкой мыши папку EFS и выберите «Свойства». Измените параметр «Шифрование файлов с использованием шифрованной файловой системы (EFS)» на «Не разрешать» или «Отключить». *** Примечание. Прежде чем отключать EFS на файловом сервере, вы должны попросить пользователей переместить данные обратно на его / ее исходный компьютер. После отключения EFS пользователь может скопировать данные обратно в общую папку. Мы также рекомендуем отключить EFS на всех файловых серверах, которые могут быть в вашей среде.