Политика 3-2-1 на практике: как клиент восстановился после Cerber за 4 часа

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

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

Как было заражение

Cerber в этот раз пришёл не через Word-макрос, как Locky месяц назад, а через уязвимость в браузере - сотрудник зашёл на скомпрометированный сайт с непропатченным IE. Payload отработал тихо, начал шифровать файлы. Два файловых сервера и один бухгалтерский терминальный сервер - всё, что было доступно с рабочей станции через сетевые шары.

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

Что спасло

На аудите в январе мы зафиксировали несколько проблем и дали рекомендации. Клиент большинство из них выполнил. Именно это и сыграло роль.

Правило 3-2-1 - не просто теория. Три копии данных, два разных носителя, одна копия вне площадки. Здесь было реализовано так: резервные копии пишутся на локальный NAS (быстрый доступ при восстановлении), оттуда реплицируются на ленту в другом физическом шкафу, и раз в неделю образ уходит на облачное хранилище. Cerber до NAS не добрался - NAS не был смонтирован как сетевой диск с правами на запись. Это принципиальный момент.

Изоляция бэкап-цели. Если резервная копия доступна с любой рабочей станции через сетевой диск - это не резервная копия, это дополнительный объём для шифратора. NAS с бэкапами был доступен только с выделенного бэкап-сервера под отдельными учётными данными. Никаких сопоставленных дисков, никакого доступа по обычным AD-учёткам.

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

Тест восстановления был проведён. И это, пожалуй, самое важное. В марте, через два месяца после аудита, мы провели тестовое восстановление - подняли один из серверов из бэкапа на изолированном стенде. Процедура была задокументирована, ответственные знали, что делать. Когда случился реальный инцидент, не было паники «а работает ли это вообще» - уже знали, что работает, и приблизительно сколько займёт.

Что пошло не по плану

Честности ради - было несколько моментов, которые усложнили ситуацию.

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

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

Бэкап базы 1С. База в момент бэкапа была открыта, снимок оказался «горячим» и при восстановлении потребовал дополнительного времени на консистентность. Решается агентом VSS или агентским бэкапом 1С - стандартная история, просто надо учитывать.

Что это значит на практике

Восстановление за 4 часа - это не везение. Это результат конкретных решений, принятых заранее:

• NAS для бэкапов не монтировать как сетевой диск с правами на запись для рабочих машин.
• Хранить несколько версий - один снимок не защищает, если заражение случилось до него.
• Проверять восстановление - не «понадеяться что работает», а реально поднять из бэкапа на тестовом стенде хотя бы раз в квартал.
• Документировать процедуру - кто звонит, кто восстанавливает, в каком порядке, куда сообщать.

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

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