Третий уровень бэкапа: офлайн-копия против шифровальщиков

Где-то с начала этого года разговор про бэкапы у клиентов перестал быть скучным. Раньше он шёл примерно так: «бэкапы есть?» - «есть» - «хорошо». Теперь добавился вопрос, который раньше не звучал: а если всё зашифруется - восстановитесь?

Вопрос не риторический. За последние несколько месяцев трое клиентов столкнулись с тем, что файловый сервер оказался зашифрован. CryptoLocker и его клоны попадают через вложения в письмах, через заражённые флешки, иногда через RDP с простым паролем - и шифруют всё, до чего дотянутся сетевые диски включительно. То есть ровно то, что смонтировано как сетевой ресурс и куда Windows-пользователь имеет доступ на запись.

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

Почему стандартная схема не спасает

Типичная схема, которую мы использовали, выглядит так: ночной бэкап на отдельный сервер (или NAS), плюс ещё одна копия на удалённый объект или в облако. Два уровня, всё по-взрослому.

Беда в том, что оба уровня - сетевые. Если вредоносная программа запускается с правами пользователя, у которого есть доступ к обоим - оба под угрозой. И доступ к бэкапам нередко есть именно с файлового сервера: там настроен агент резервного копирования, там смонтированы шары для записи. С точки зрения шифровальщика - это просто ещё одна папка с файлами.

Облачный бэкап спасает лучше - там нет прямого сетевого диска, доступ через API или специализированного агента. Но и здесь бывают варианты: агент работает от учётки с правами на запись в облако, а значит теоретически может быть скомпрометирован.

Единственная надёжная защита - копия, которую шифровальщик физически не может затронуть. Офлайн.

Что добавили

Решение простое до неловкости, и именно поэтому мы не додумались до него сами раньше.

На каждый файловый сервер под управлением managed-сопровождения добавили третий уровень: USB-диск с расписанием подключения. Схема выглядит так:

• Внешний USB-диск ёмкостью, достаточной для нескольких актуальных копий, физически подключён к серверу или к выделенному NAS рядом.
• По расписанию - раз в сутки в нерабочее время - диск монтируется скриптом, на него пишется копия (rsync или штатный бэкап-агент), после чего диск размонтируется.
• В остальное время диск не виден операционной системе как устройство хранения - только как физически подключённое USB-устройство. Монтировать его заново скрипту или шифровальщику без явного вызова - нечем.

Реализация на Linux-хосте несложная. Udev-правило по vendor/product ID диска, скрипт с mount/umount по systemd.timer или через cron, плюс логирование результата. Сам диск форматируем в ext4 с подходящими правами - только root может монтировать и писать.

На Windows-серверах немного сложнее, там нет такого же простого механизма монтирования по расписанию. Используем mountvol для подключения/отключения тома через планировщик задач с учётной записью, у которой нет сетевого доступа к файловому серверу.

Нюансы, которые вылезли при внедрении

Физическая надёжность USB-дисков. Портативные диски формата 2.5'' не рассчитаны на постоянное подключение и ежедневный цикл нагрузки. После пары недель обсуждений остановились на полноразмерных 3.5'' дисках с отдельным питанием - они дешевле в пересчёте на объём и более вынослые.

Ротация. Один диск - одна точка отказа. Ввели два диска с чередованием по дням недели: по чётным пишем на один, по нечётным на другой. Второй диск в нерабочий день можно унести с собой или убрать в сейф. Не идеально, но лучше чем ничего.

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

Неудобство для клиента. Один клиент сразу спросил: а что если диск сломается. Ответ: заменить. Это ручная работа раз в год или реже - вполне терпимо за гарантию, что шифровальщик до этой копии не доберётся.

Что это не решает

Офлайн-бэкап не решает задачу быстрого восстановления. Максимальная глубина - сутки, потому что копия пишется раз в день. Если нужно восстановить файл, который был удалён три дня назад - смотрим на сетевой бэкап. Если весь сервер зашифрован и сетевой бэкап тоже - поднимаем с USB.

Для большинства клиентов RPO в сутки при атаке шифровальщиком - приемлемо. Потерять сутки работы неприятно, но лучше, чем потерять всё.

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

Несложно заметить, что решение прямо скажем не высокотехнологичное. Но именно поэтому оно работает: у него нет сетевого стека, нет API, нет учётных данных, которые можно украсть. Диск просто не подключён.