Veeam v11: Linux-репозиторий с immutable backup без WORM-железа

В феврале мы писали про правило 3-2-1-1-0 и про то, что immutable-копия - обязательный элемент защиты от ransomware. Концептуально всё понятно. Практически всегда упиралось в деньги: нормальный WORM-массив стоит как небольшой автомобиль, S3 с Object Lock у российских провайдеров есть не у всех и с задержками, а chattr +i через Veeam до десятой версии работал криво и без официальной поддержки.

Veeam v11, вышедший в конце февраля, поменял расклад. В нём появился Linux Hardened Repository - официальный механизм неизменяемых бэкапов на обычном Linux-сервере с XFS. Без дополнительного железа, без дорогих лицензий сверх стандартной Enterprise Plus.

Как это работает изнутри

Механизм опирается на два инструмента Linux, которые никуда не исчезнут: XFS с reflink и системный вызов FS_IOC_SETFLAGS с флагом FS_IMMUTABLE_FL. Когда Veeam завершает задание резервного копирования, он выставляет этот флаг на файлы бэкапа через непривилегированный сервисный аккаунт. После этого файл нельзя изменить или удалить даже из-под root - только ядро может снять флаг, и только через тот же системный вызов.

Хитрость в том, что Veeam запускает сервис veeamtransport от имени пользователя без sudo-прав на снятие флага. То есть даже если атакующий скомпрометировал учётку Veeam, он не сможет трогать завершённые бэкапы - нет прав. Флаг снимается автоматически только когда истекает retention и только через privileged-процесс самого Veeam, который при этом работает с ограниченными правами на уровне Linux capabilities.

XFS нужен из-за reflink - это механизм copy-on-write, который позволяет Veeam эффективно хранить инкрементальные цепочки без дублирования блоков. На ext4 hardened repository тоже технически работает, но Veeam официально поддерживает только XFS.

Разворачиваем на Ubuntu 20.04

Мы собрали стенд на Ubuntu 20.04 LTS - надёжный выбор с пятилетним LTS и нормальным ядром 5.4, где всё необходимое для reflink уже есть.

Первое - диск под репозиторий форматируем в XFS с включённым reflink:

mkfs.xfs -b size=4096 -m reflink=1,crc=1 /dev/sdb

Параметр reflink=1 обязателен. Если форматировать без него, hardened repository всё равно заработает, но без copy-on-write - то есть каждый инкремент будет занимать полное место вместо дельты.

Второе - создаём сервисного пользователя без sudo и без возможности войти интерактивно:

useradd -m -s /bin/bash veeamrepo
passwd veeamrepo  # пароль задаём, но не с правами sudo

Этот пользователь получает права только на каталог репозитория. Никаких sudoers, никакого wheel. В этом весь смысл: Veeam подключается по SSH с этим аккаунтом, и даже при его компрометации атакующий не может снять immutability-флаг с файлов.

Третье - в консоли Veeam добавляем сервер через "Add Linux Server" и затем создаём репозиторий типа "Hardened Repository". Мастер спросит про каталог и immutability period - это срок, в течение которого файлы будут заблокированы. Мы поставили 14 дней при retention 7 дней: это даёт запас, если retention обновится позже планового.

Проверяем, что это действительно работает

После первого полного бэкапа зашли на Linux-сервер под тем самым сервисным пользователем veeamrepo и попробовали удалить файл бэкапа:

rm /backup/repo/Job1/2021-03-10T020000/VeeamBackup_Job1.vbk
rm: cannot remove '...': Operation not permitted

Попробовали из-под root:

sudo rm /backup/repo/Job1/2021-03-10T020000/VeeamBackup_Job1.vbk
rm: cannot remove '...': Operation not permitted

Тот же результат. lsattr показывает флаг i на файле - всё как ожидалось. Атакующий с правами root на Linux-сервере резервных копий всё равно не может удалить или изменить файл до истечения периода immutability. Единственный способ - загрузиться с внешнего носителя в recovery mode и уже там снимать флаги, что требует физического или KVM-доступа к серверу.

Для полноты картины в рамках managed-сопровождения мы делаем ещё один шаг: сервер репозитория не состоит в домене, SSH открыт только с IP Veeam-сервера через firewall, а root-логин по SSH отключён. Это не делает систему абсолютно неуязвимой, но существенно поднимает планку для атакующего.

Что не стоит забывать

Immutability защищает файлы, но не репозиторий целиком. Несколько важных оговорок:

• Метаданные репозитория - файлы .vbm (метаданные заданий) immutable не становятся. Если атакующий их удалит, Veeam не найдёт бэкапы в репозитории, хотя физически файлы *.vbk на диске останутся нетронутыми. Восстановить можно через сканирование, но это нештатная ситуация.
• Сам Veeam-сервер - если он скомпрометирован, атакующий может изменить настройки retention и дождаться, пока Veeam сам не снимет флаги. Поэтому Veeam-сервер тоже должен быть защищён.
• Период immutability должен перекрывать реальный retention с запасом. Mismatch между ними - распространённая ошибка при настройке.

В целом Linux Hardened Repository в v11 - это то, чего многие ждали. Раньше единственным путём к настоящей immutability без cloud был либо дорогой WORM-массив, либо самодельные скрипты с chattr, которые Veeam официально не поддерживал. Теперь есть нормальное, задокументированное решение на базе обычного Linux-сервера с XFS - что в нынешних условиях с ransomware-активностью закрывает важную дыру в схеме защиты.