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

В Сети очень много информации о том, как максимально защитить свою инфраструктуру от подобных атак. Но все в конечном итоге сводится к последнему рубежу обороны – резервным копиям. Если первоначально целью шифровальщиков были пользовательские данные на локальном устройстве и в сетевых папках, то сейчас помимо них злоумышленников интересуют также и хранилища с бэкапами. Ведь именно зашифровав точки восстановления можно буквально поставить жертву на колени. Поэтому сохранность резервных копий – это, пожалуй, одна из главных задач по противодействию вымогателям. Разумеется, бэкапы важны еще и по многим другим причинам, но сегодня мы поговорим именно о защите от Ransomware.

Речь в данной статье пойдет о том, как при помощи штатного функционала Unified систем QSAN XCubeNAS построить простую, но при этом весьма эффективную систему по защите резервных копий от воздействия вирусов-шифровальщиков, а также случайного или преднамеренного удаления данных со стороны обслуживающего персонала. В данном случае мы говорим о применении механизма WORM (Write Once Read Many), который изначально присутствовал только в ленточных накопителях, а сейчас доступен, в том числе, и на дисковых устройствах.

В системах QSAN XCubeNAS функционал WORM обеспечивается за счет использования внутренней файловой системы ZFS. В ней предусмотрена установка флага locked на определенный срок, во время которого файл нельзя модифицировать никакими средствами. Даже обладая правами root во внутренней ОС XCubeNAS и имея доступ администратора в консоль управления устройством, не получится удалить файлы из папки WORM, а также удалить саму папку или сбросить файлы конфигурации системы. Стоит также отметить, что невозможно обойти и срок действия защиты WORM за счет изменения hardware clock или подделки NTP сервера, так как счетчик в WORM базируется на значении uptime.

Есть и обратная сторона медали. Если устройство по какой-либо причине было выключено в течение некоторого периода, то срок защиты WORM не уменьшится на соответствующий промежуток времени. Но раз мы строим защиту IT инфраструктуры компании и собираемся использовать NAS для складирования резервных копий, то подобное устройство должно работать 24/7. Так что это не должно создать проблему.

Прямое сохранения резервных копий в папку с активированным WORM не подходит, так как любой софт бэкапа во время работы создает множество вспомогательных файлов и осуществляет их пост-обработку. Поэтому алгоритм механизма защиты будет таким:

  1. Софт бэкапа выполняет свое задание и сохраняет результат в выделенную сетевую папку.

  2. По окончании задания средствами XCubeNAS создается снапшот этой папки и копируется в папку с защитой WORM.

  3. Одновременно проверяется, истек ли срок защиты для одного из ранее сохраненных снапшотов. Если такие снапшоты имеются, то они удаляются как устаревшие.

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


Рассмотрим, как это настраивается на примере Veeam как одного из самых популярных ПО резервного копирования.

Создаем сетевую папку (назовем ее Veeam) для хранения резервных копий и публикуем ее с использованием CIFS. Рекомендуется назначить права Read/Write на папку только для созданной для этой цели учетной записи (локальной или доменной).

Создаем еще одну папку (назовем ее Worm), для которой активируем функционал WORM с установкой срока защиты для каждого файла в отдельности Set Retention Period on Each File of This Folder. Срок защиты должен быть дольше, чем период создания резервных копий. Например, если бэкап делается ежедневно, то срок защиты WORM должен быть хотя бы 2 дня. Соотношение 1:2 как раз и является рекомендуемым. Но по желанию может быть изменено в сторону удлинения срока защиты.

Со стороны XCubeNAS все необходимые приготовления сделаны. Теперь необходимо произвести настройку сервера Veeam, начав с добавления ранее созданной сетевой папки Veeam в качестве нового репозитория Backup Repositories → Add Backup Repository → Network Attached Storage → SMB Share.

Указываем сетевой путь к папке и учетную запись, которая имеет права Read/Write для нее.

По окончании работы мастера получаем новый репозиторий Veeam для хранения резервных копий. Далее можно приступать к созданию задания на резервное копирование на вкладе Backup Jobs. В зависимости от объектов бэкапа выбирается соответствующий мастер. В любом случае на этапе выбора репозитория необходимо указать сетевую папку Veeam, расположенную на XCubeNAS, и добавить опцию для выполнения скрипта Advanced → Scripts.

Скрипт сделан инженерами QSAN и представляет собой последовательность команд, которые необходимо выполнить по окончании задания резервного копирования. За счет взаимодействия сервера Veeam и хранилища XCubeNAS через программный интерфейс RESTful API имеется возможность управлять рядом задач в пакетном режиме. В частности, реализуется ранее описанный алгоритм. То есть происходит создание снапшота папки Veeam, его копирование в папку Worm, а также удаление снапшотов с истекшим временем защиты. Администратору всего лишь необходимо единожды отредактировать скрипт, чтобы указать свои значения IP устройства, учетные данные, а также папки-аналоги приведенным в примере Veeam и Worm.

Вместо Veeam можно использовать любое другое ПО резервного копирования, которое поддерживает запуск скриптов по окончании процесса создания копии, поскольку RESTful API является универсальным интерфейсом управления. В любом случае идея построения схемы защиты данных точно такая же.

Компания Skilline является официальным дистрибутором и авторизованным сервисным центром QSAN на территории РФ. Будем рады ответить на все интересующие вопросы и поделиться накопленным опытом.

Комментарии (13)


  1. alexs963
    16.11.2021 11:05

    Любая ФС которая умеет CoW (btrfs, zfs) легко решает туже задачу.


    1. qw1
      17.11.2021 13:10

      Так в статье это и написано:

      В системах QSAN XCubeNAS функционал WORM обеспечивается за счет использования внутренней файловой системы ZFS
      Тут просто интеграция с виндой, простое администрирование мышкой в формочках. За это и берут деньги.


  1. Sergey-S-Kovalev
    16.11.2021 15:15

    в Dell EMC DataDomain достаточно откорректировать дату создания файла на где то в будущем и система не даст его удалить пока этот день не настанет


  1. RStarun
    16.11.2021 20:06
    +1

    Защита средствами файловой системы это конечно хорошо, но разве нельзя просто форматнуть диски (раздел, lun, ну вы поняли)


    1. Skilline Автор
      17.11.2021 09:57

      Если на разделе есть папки/файлы с активным WORM, то ОС не даст выполнить форматирование даже если у вас права superuser


  1. VXP
    17.11.2021 11:22

    Вопрос от неэксперта: а может ли шифровальщик изменить время шифрования WORM уже зашифрованного файла/папки в бОльшую сторону?


    1. Skilline Автор
      17.11.2021 12:57

      Метка со сроком действия ставится однократно и не может быть изменена, пока установленный срок не истечет.


  1. Daniilchen
    17.11.2021 12:56
    +1

    Будет здорово, если криптомайнер так зальют и защитят флагом locked. Пока машина не отработает срок (набирая аптайм до удаления) будет стоять и в идеале майнить. Неплохой вариант.


    1. Skilline Автор
      17.11.2021 12:58

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


      1. qw1
        17.11.2021 13:08

        Динамические там только логи, а скрытому майнеру они не нужны. Майнер получает из сети новый хеш раз в 5 минут (* в зависимости от протокола валюты) и начинает его брутфорсить. Как только нашёл матч — отправляет результат в пул, не нашёл — получает следующий хеш. Локальное хранение не требуется вообще.


        1. Skilline Автор
          17.11.2021 13:37

          Тогда нужно либо проникнуть во внутреннюю ОС NAS и по сути майнить на процессоре этого NAS (ну, так себе результат будет), либо запускать процесс с некоего компьютера, имеющего доступ к шаре с WORM (но тут такая папка как раз не имеет общего доступа).


          1. Daniilchen
            17.11.2021 21:11

            Chia для NAS, наверное, в самый раз :)

            Майнер был как пример, может быть что-то для ботнета, например. В любом случае дополнительные сложности для удаления это интересно, хоть и узкоспециализированно


            1. Skilline Автор
              18.11.2021 09:52

              Для Chia как раз нужно пространство хранения, чему WORM будет только преградой