CryptoWall 3.0 в офисе клиента: как правило 3-2-1 спасло данные и почему мы теперь требуем его обязательно

Звонок пришёл в начале рабочего дня. Голос на той стороне - системный администратор клиента, торгово-производственная компания - был ровным, но с той характерной тщательной ровностью, которая бывает когда человек уже прошёл стадию паники и перешёл в рабочий режим. «У нас всё зашифровано. Сетевые диски, часть рабочих станций, документы на файловом сервере. Везде текстовые файлы с требованием выкупа».

CryptoWall 3.0. Один из пользователей открыл вложение в письме, которое выглядело как счёт от контрагента. Дальнейшее - классика: шифровальщик прошёлся по всем смонтированным сетевым дискам, до которых достали права учётки пользователя.

Что было потеряно и что нет

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

Не тронуто: резервная копия файлового сервера на внешнем USB-диске, который по расписанию отключался от сервера и убирался в сейф. Это и спасло.

Время восстановления - около суток с учётом проверки, пересборки среды и тестирования. Данные потеряли примерно за трое суток до инцидента - последняя копия на внешнем диске была именно трёхдневной давности. Это больно, но терпимо. Альтернатива - платить выкуп без каких-либо гарантий, что ключи вообще пришлют.

Выкуп не платили.

Почему USB-диск в сейфе сработал

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

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

У большинства бэкап шёл либо на сетевую шару на том же сервере (или соседнем - всё равно в той же сети), либо на NAS без ротации носителей. То есть: одна копия, один носитель, всё в той же сети. Если CryptoWall добирается до такого бэкапа - а он добирается, мы это видели в других случаях - восстанавливаться не из чего.

Правило 3-2-1: не новость, но теперь обязательно

Правило 3-2-1 существует давно и все его знают. Напомним:

• 3 копии данных - оригинал плюс два независимых бэкапа.
• 2 разных носителя - например, диск на сервере и внешний диск или лента.
• 1 копия за пределами офиса - физически в другом месте или изолированное облако.

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

После инцидента с клиентом мы пересмотрели подход. Теперь 3-2-1 - не рекомендация, а требование для тех, кто на managed-сопровождении. Без этого мы не можем давать никаких обязательств по восстановлению.

Как это выглядит на практике

Для большинства клиентов схема получается такая:

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

С облаком есть нюанс: обычный смонтированный облачный диск (вроде Яндекс.Диска или Google Drive в режиме синхронизации) - это не бэкап. Это расширение локального хранилища, которое криптолокер с радостью зашифрует вместе с оригиналами. Нужен именно бэкап-сервис с версионированием, к которому у рабочих процессов нет прямого доступа на запись.

Про сетевые права и сегментацию

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

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

Одновременно с настройкой бэкапа по правилу 3-2-1 у этого клиента мы провели ревизию прав на файловом сервере. Удалили унаследованные права, оставленные при увольнении сотрудников, порезали широкие записи типа «Everyone - Full Control» на нескольких старых шарах. Скучная работа, но именно она определяет насколько плохо будет в следующий раз.

Где мы сейчас

Клиент восстановлен, работает. Настроена трёхуровневая схема бэкапа, внешние диски уходят в ротацию раз в неделю, облачная копия настроена через Veeam Cloud Connect к провайдеру с изолированным облачным репозиторием.

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

Шифровальщики никуда не делись. CryptoWall 3.0 активен, TeslaCrypt тоже работает. Каждый месяц приходят новости о новых заражениях. Иллюзий что это прекратится само по себе - нет. Поэтому единственное что реально работает, это иметь копию, до которой зловред не может дотянуться физически.