Как можно бороться с шифровальщиками шары на сервере средствами Debian?

Pinkbyte

клиентов у базы около 5, эти файловые системы в продакшене то использовать уже можно, а то на 10 год (свежее на русском не нашел) написано что только для тестирования, т.к. файлы могут «пропадать».

и в чем еще принципиальная разница по функционалу для моей проблемы между обычным инкрементным бэкапированием (видимо раз в час придется что ли делать) и btrfs/zfs ??? т.е. шара условно 100 Гб на софтовом раиде в 1 Тб, объективно получается под хранение бэкапов на том же разделе хватает только на неделю, а косяк всплыл через 2 дня только (пока пользователи не обнаружили сами)

А как реализована технология NAC/NAP? просто сервер опрашивает агента/ось на клиенте про установленный софт/апдейты/антивирус и в зависимости от этого пускает или не пускает?

Плюсую подсчет энтропии. Если выше порога — бэкапить файл, и отправлять на почту письмо в стиле «блабла не храните зашифрованные файлы, если срабатывание ложно, нажмите на ссылку». Если ошибка, то руками проверить и подправить проверку.

belkabelka

теоретически да не пускать в рабочую подсеть, только на шару, с которой можно антивирь поставить

подсчет энтропии

хорошо, чем ее считать?

ТС тебе надо суточное резервирование. если будет жопец - раскатываешь с бекапа. а выяснить кто нашифровал тебе поможет подробный лог самбы. там можно включить аудит каждого движения с файлами. вплоть до того кто в какие каталоги просто read делал. не осилишь - стучи на почту. проконсультирую.

MikeDM

ререзвирование не проблема, тем более суточная, проблема в том, что через 2 дня всплывает, что всю шару похерили, соответственно работы потеряно не с утра до обеда, а за двое суток, тут уж без логов понятно кто виноват. нужно именно оперативно блокировать, а лучше вообще предотвращать.

мое дело предложить.

чем ее считать?

А у тебя есть зашифрованный файл? Посмотри что на нем выдаст такое:

$ hexdump -v -e '/1 "%02X\n"' FILE.CRYPTED | sort | uniq -c

FILE.CRYPTED - твой файл.

Это подсчет количества символов в файле. Если цифры близко друг к другу, значит можно попробовать считать по энтропии

ну тогда что же «не поддерживается»? такие костыли довольно просто собрать, кмк

а то на 10 год
файлы могут «пропадать».

В BTRFS и ZFS(под Linux портирование только начинали, в Solaris она уже была вполне себе stable) на 2010 год это заявление вполне себе справедливо. Но за 5 лет многое изменилось.

и в чем еще принципиальная разница по функционалу для моей проблемы между обычным инкрементным бэкапированием (видимо раз в час придется что ли делать) и btrfs/zfs ???

Тем что снапшот делается практически мгновенно. А инкрементальный бэкап с расчётом измений и копированием - нет.

Высокая энтропия может быть не только у зашифрованного файла, но и просто у хорошо сжатого. Так что срабатывать будет на архивах и установщиках.

Высокая энтропия может быть не только у зашифрованного файла, но и просто у хорошо сжатого. Так что срабатывать будет на архивах и установщиках.

Архивы и установщики можно отличать и по заголовкам.