“Администраторы делятся на три категории: тех, кто еще не делает бекапы, тех, кто уже делает, и тех, кто уже проверяет бекапы.”

Когда речь заходит о необходимости защиты данных сервисов и приложений, на ум в первую очередь приходит резервное копирование и репликация. Однако решения по резервному копированию и репликации данных сами по себе не гарантируют защиту от логической порчи данных: удаления содержимого внутри файлов и баз данных, шифрования или намеренного внесения ошибок. Наличие копии вселяет ложное чувство уверенности: «у нас есть копия = мы в безопасности».

Здесь кроется ловушка: резервное копирование позволяет восстановиться после сбоев, которые легко распознать, например, от физических отказов — выхода из строя диска, случайного удаления тома, сбоя узла. Однако вирус-шифровальщик, целью которого зачастую является шантаж для получения выкупа, ведет себя гораздо хитрее, он меняет содержимое на логическом уровне - внутри файлов или баз данных. Быстро обнаружить подобные изменения не всегда представляется возможным. Средства репликации и СРК просто скопируют данные, не зная, что они уже испорчены, и в худшем случае, также затрут предыдущую рабочую копию. Такая ситуация может продолжаться еще долгое время, пока поврежденные данные не повлияют на работоспособность системы, и это не заметят сами пользователи или администраторы приложения.

Какой из этого следует вывод? Копии данных надо проверять! 

Подходы к защите от логических сбоев

Независимо от того, какое решение по репликации или резервному копированию используется и как оно работает - копирует ВМ целиком, реплицирует тома на уровне СХД, или задействует специализированный агент внутри ОС или приложения, можно выделить несколько подходов к тестированию для защиты от логических сбоев:

Каждый из подходов имеет свои плюсы и минусы, и только их грамотное сочетание позволит обеспечить надежную защиту от логических сбоев. В данной статье мы подробно рассмотрим первый подход: проверку данных на источнике на примере ПО MIND Guard, а остальные подходы разберем в будущих статьях. 

Проверка данных на источнике

Рассмотрим несколько простых, но при этом наглядных способов обнаружить нарушение целостности данных на источнике. 

Способ №1: ловля на живца (honeypot)

Способ основан на использовании и контроле статуса файлов-приманок. В нескольких местах на диске защищаемой машины создаются файлы (.txt, .docx, .xlsx, .pdf, .db) и произвольным содержимым, похожим на полезные данные, и для этих файлов заранее подсчитываются контрольные суммы.

Специальный скрипт перед каждой итерацией репликации или резервного копирования рассчитывает хэш-сумму файлов приманок и сравнивает их с известным значением: если файл-приманка пропал, или его хэш не совпадает — это повод забить тревогу и прекратить репликацию для предотвращения отправки испорченных данных на приёмник. Данный вариант позволяет отловить ситуацию с массовым шифрованием/удалением файлов.

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

Плюсы: простая реализации.

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

Cпособ №2: проверка работы приложений

Перед запуском очередной итерации репликации можно проверять работу приложения с помощью тестового запроса. Если приложение выдает на запрос ожидаемый ответ, например, веб-сервер отвечает Status Code 200, или СУБД возвращает определенное значение при выполнении SELECT из БД, то проверка считается успешной, и запускается передача данных.

Плюсы: позволяет выявлять большее типов отказов.

Минусы: сложнее в реализации и требует написания более сложных скриптов, возможны ложные срабатывания, приводящие к остановке, например, в момент обслуживания и обновления ПО. 

Способ №3: интеграция с инструментами проверки ИБ

Можно запрашивать статус локального антивируса или EDR на наличие активных угроз или подозрительной активности в системе с момента последней итерации передачи данных.

Плюсы: обнаружение и автоматическая реакция на вредоносное ПО до того, как оно успеет нарушить целостность данных.

Минусы: необходимость в использовании сторонних средств ИБ, высокие требования к квалификации для настройки. 

Принцип работы MIND Guard #guest

Перед тем как перейти к описанию процедуры настройки, рассмотрим основной инструмент, который мы будем использовать для защиты и аварийного восстановления сервисов — MIND Guard #guest.

Принцип работы MIND Guard #guest заключается в периодической синхронизации данных между двумя машинами: защищаемой, на которой работают сервисы и приложения (в терминологии Guard она называется Источником) и резервной (далее — Приёмник), сохраняющей на себе копию данных, которая затем используется для восстановления в случае сбоя защищаемой машины.

Наличие подобной “теплой” копии позволяют администратору в случае какого-либо сбоя за несколько минут восстановить на приёмнике ОС, настройки, приложения и данные.

Репликация в MIND Guard #guest выполняется на блочном уровне с помощью специализированного агента (MIND Agent) и модулей репликации, запускающихся на ОС источника и приёмника. Благодаря этому поддерживается защита машин, работающих на разных платформах виртуализации и облачных средах, в том числе всевозможные гибридные сценарии, например, когда источник представляет собой виртуальную машину на платформе VMware vSphere, а приёмник - ВМ на OpenStack, поверх QEMU/KVM.

Для настройки и управления заданиями защиты и восстановления машин в MIND Guard #guest используется выделенный сервер — Контроллер. Контроллер лишь дает команды на запуск/остановку заданий, контролирует и мониторит репликацию, но напрямую не участвует в передаче трафика между источником и приёмником, поэтому его доступность не влияет на работоспособность уже запущенных заданий.

MIND Guard #guest поддерживает асинхронную репликацию с возможностью настройки времени между итерациями вплоть до нескольких секунд для минимизации RPO. Для снижения объемов передаваемых данных, MIND Guard #guest использует механизм снапшотов (мгновенных снимков) и отслеживает блоки данных, измененных с последней итерации репликации.

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

Сценарий (Pipeline) содержит перечень скриптов, которые запускаются на различных этапах задания репликации или восстановления: перед первым снимком, перед каждым снимком, после создания снимка, перед переключением на приёмник и т.д., а также условия поведения задания в случае успешного или неуспешного выполнения скрипта.

Скрипт (Script) - написанная на языках Bash или PowerShell последовательность команд, выполняемых на источнике или приёмнике. Скрипты могут запускаться на источнике перед каждой итерацией создания снапшота и передачи данных на приёмник. В нормальном режиме работы при отсутствии нарушения целостности, скрипт всегда завершается с кодом возврата 0, и источник передает данные на приёмник. В случае, если скрипт возвращает любое значение отличное от нуля, агент MIND экстренно завершает работу задания и репликация прерывается. 

Настройка защиты машины с проверкой целостности данных

Чтобы не дублировать информацию из официальной документации и руководств по продукту, рассмотрим лишь основные шаги по настройке скриптов и задания репликации.

В качестве примера рассмотрим способ контроля целостности на Linux машине с помощью файлов-приманок и хэш-сумм. Пример скрипта на Bash для проверки файлов приведен в Приложении к статье. При необходимости схожим образом можно выполнить настройку Windows машин с помощью PowerShell скрипта.

Этап 1. Разложите файлы-приманки на дисках машины источника и создайте файлы с контрольными суммами для проверки целостности:

1. На источнике (Linux) создайте несколько файлов-приманок с произвольным содержимым. Лучше называть файлы и размещать их в корневом разделе и каталогах таким образом, чтобы при листинге они отображались первыми в списке, например: /0.txt, /0/0.txt. Это повысит вероятность, что вредоносное ПО при поиске по файловой системе в первую очередь попытается повредить файлы-приманки.

2. Рассчитайте хэш-суммы и разместите файлы с ними рядом с файлами-приманками (например, /0.txt.md5, /0/0.txt.md5).

Дальнейшая настройка заданий выполняется через графический интерфейс Контроллера MIND.

Этап 2. Добавьте на контроллер скрипты и сценарии для проверки целостности:

1. В веб-интерфейсе Контроллера зайдите на страницу Скрипты → +Создать скрипт. Укажите имя, ОС (Linux) и вставьте скрипт. Сохраните.

2. Перейдите в Скрипты → Сценарии → +Создать сценарий. На вкладке Снимки добавьте шаги для запуска скриптов:

• Перед первым снимком: ваш скрипт, действие при ошибке — «Остановить миграцию с ошибкой».

• Перед каждым снимком: (при необходимости) тот же или другой скрипт с аналогичным действием.

3. Сохраните сценарий.

Этап 3. Создайте или отредактируйте существующее задание репликации источника:

1. На вкладке Дополнительно отключите функцию Автоматическое восстановление. Данная функция перезапускает задание в случае возникновения ошибки, что будет приводить к конфликту с механизмом принудительного завершения задания при срабатывании скриптов проверки целостности.

2. На вкладке Скрипты выберите созданный на предыдущем этапе сценарий. Сохраните изменения.

Этап 4. Запустите задание на репликацию. Теперь перед каждой итерации репликации будет запускаться скрипт проверки наличия файлов-приманок и подсчёт их контрольных сумм.

При сбое проверки, например, если один из файлов-приманок будет удален, либо если его контрольная сумма будет отличаться от контрольной суммы в .md5 файле, задание перейдет в статус Ошибка и репликация прервется. 

Восстановление машины после сбоя репликации

Остановка задания репликации не всегда может происходить из-за действий вредоносного ПО. Для определения причин потребуется участие системного администратора, администратора приложения и специалиста по ИБ.

Вот краткая последовательность действий в случае сбоя репликации:

1. Проверить журнал задания на Контроллере. В нем будет отображена информация о причине остановки задания, время остановки, какой скрипт привел к остановке и вывод скрипта.

2.      Определите причину ошибки:

• Действия вредоносного ПО — проверьте файлы-приманки, данные приложений и работоспособность сервисов на источнике.

• Ложное срабатывание — например, если файл был случайно удален или изменен пользователем или сторонним ПО.

• Сбой, вызванный другими причинами, не связанными с механизмами проверки целостности.

3.      Действия при ложном срабатывании:

• Восстановите файлы-приманки и обновите хэш-суммы.

• Исправьте логику скрипта для проверки.

• После этого в интерфейсе Контроллера нажмите Перезапустить для возобновления репликации.

4.      Действия при заражения источника:

• Если ОС на источнике работает в виртуальной машине, создайте копию, используя механизмы снапшотов или клонирования ВМ. Это пригодится при дальнейшем расследовании инцидента, а также спасти те данные, которые еще не были испорчены или зашифрованы.

• Отключите источник от сети или полностью выключите, чтобы избежать распространения заражения.

• Восстановите приёмник из последней работающей реплики данных. Для этого в интерфейсе Контроллера выполните Switchover (переключение).

• При переключении можно задать опцию «Остановить приёмник», чтобы резервная машина автоматически не запускалась. Сразу после этого рекомендуется сделать снапшот виртуальной машины с приёмником, отключить машину от сети и также проверить ее на наличие следов вредоносного ПО.

5.      После проверки приёмника:

• Если приёмник признан «чистым», тогда можно запустить его и восстановить работоспособность сервисов.

• Если туда уже проникло вредоносное ПО, то можно попытаться удалить его из системы, либо развернуть ОС и приложения с нуля и восстановить из реплики только те данные, которые не успели подвергнуться заражению.

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

Заключение

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

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

MIND Guard поддерживает защиту Linux и Windows машин, работающих на различных платформах виртуализации, и позволяет реализовать методы проверки целостности данных на источнике, используя механизм запуска скриптов на различных этапах выполнения репликации.

Необходимо внимательно анализировать журналы событий, а также состояние источника и приёмника перед тем, как восстанавливаться. Всегда есть вероятность, что приёмник также содержит вредоносное ПО, которое может активироваться в момент переключения. Создавайте снапшоты или клоны ВМ, чтобы иметь возможность откатиться и заново попробовать восстановить машину.

В следующих статьях мы рассмотрим другие механизмы защиты MIND Guard #guest - точки восстановления и инструменты автоматизации и тестирования восстановления. 

Приложение: примеры скриптов для проверки целостности файлов на источнике

Ниже приведены примеры скриптов на Bash и PowerShell, которые можно использовать для проверки целостности файлов на Linux и Windows машинах. В скриптах в переменных FILES (для Bash) и $files (для PowerShell) задаются пути к одному или нескольким файлам-приманкам.

Перед запуском скрипта требуется создать на защищаемой машине файлы-приманки с произвольным содержимым по указанным путям.

Рядом с файлами-приманками должны располагаться файлы с контрольными суммами с расширением .md5. Для расчета контрольных сумм можно использовать утилиту md5sum (для Linux):

echo "$(md5sum /0.txt)" > /0.txt.md5

или Get-FileHash (для Windows):

Get-FileHash -Algorithm MD5 -Path "C:\0.txt" > "C:\0.txt.md5"

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

Скрипт на Bash для запуска на Linux машинах:

#!/bin/bash

# Пути к файлам-приманкам, разделенные ;
FILES="/0.txt;/0/0.txt"

IFS=';' read -ra FILE_ARRAY <<< "$FILES"

# Проверить наличие всех файлов
for file in "${FILE_ARRAY[@]}"; do
    if [[ ! -f "$file" ]]; then
        echo "Missing file: $file"
        exit 1
    fi

    # Путь к хэш-файлу
    md5_file="${file}.md5"

    # Проверить, что файл с хэшом присутствует
    if [[ ! -f "$md5_file" ]]; then
        echo "Missing MD5 file: $md5_file"
        exit 1
    fi

    # Сравнить хэши
    expected_md5=$(awk '{print $1}' "$md5_file")
    actual_md5=$(md5sum "$file" | awk '{print $1}')
    if [[ "$expected_md5" != "$actual_md5" ]]; then
        echo "MD5 mismatch for file: $file"
        exit 1
    fi
done

Скрипт на PowerShell для запуска на Windows машинах:

# Пути к файлам-приманкам, разделенные ;
$files = "C:\0.txt;C:\0\0.txt"

$fileArray = $files -split ';'

# Подсчет MD5 хэша
function Get-MD5Hash {
    param([string]$filePath)
    $hasher = [System.Security.Cryptography.MD5]::Create()
    $stream = [System.IO.File]::OpenRead($filePath)
    $hashBytes = $hasher.ComputeHash($stream)
    $stream.Close()
    return ([BitConverter]::ToString($hashBytes) -replace "-", "").ToLower()
}

foreach ($file in $fileArray) {
    if (-Not (Test-Path $file)) {
        Write-Host "Missing file: $file"
        exit 1
    }

    $md5File = "$file.md5"

    if (-Not (Test-Path $md5File)) {
        Write-Host "Missing MD5 file: $md5File"
        exit 1
    }

    # Сравнить хэши
    $expectedHash = (Get-Content $md5File
    | Select-String -Pattern '^[a-fA-F0-9]{32}'
    | ForEach-Object { $_.Matches[0].Value }).Trim()

    if (-not $expectedHash) {
        Write-Host "Invalid or missing hash in $md5File"
        exit 1
    }

    $actualHash = Get-MD5Hash -filePath $file

    if ($expectedHash -ne $actualHash) {
        Write-Host "MD5 mismatch for file: $file"
        exit 1
    }
}

exit 0