Шифровальщик зашифровал базы 1С вместе с бэкапами: порядок действий, когда ключа нет
Иван Недомолков · Опубликовано:
Сценарий у таких утр одинаковый. Базы 1С не открываются, серверы при этом пингуются. В папках вместо файлов лежит то же самое с новым расширением, а рядом с каждым текстовый файл: ваши данные зашифрованы, сторонние программы их испортят, ключ продаём только мы. Админ идёт за бэкапами и обнаруживает, что сетевые копии зашифрованы той же ночью.
Мы прошли это сами: за одну ночь в компании на несколько тысяч человек легли больше десятка баз 1С, почта, FTP, сайт, четыре мобильных приложения и кассы. Ниже порядок действий, который мы бы хотели иметь на руках в то утро. Наш случай идёт иллюстрацией к каждому шагу.
Шаг 1. Первый час: что не трогать
Самое дорогое в первый час - лишние действия с зашифрованными файлами.
- Оригиналы не трогать. Никаких “дешифраторов” из интернета, утилит восстановления, попыток подсунуть файл SQL Server. Записка не врёт в одном: сторонний софт может испортить файл окончательно. Кроме того, это улики, и ключи от некоторых шифровальщиков со временем публикуют.
- Скопировать зашифрованное на отдельный диск, дальше работать только с копией и только на чтение.
- Отделить заражённое от сети. Пароли, учётки, VPN и порты закрывает своя команда параллельно, восстановление данных идёт на отдельном чистом сервере.
У нас в тот день работа разделилась сама: одни вытаскивали данные из бэкапов, другие поднимали серверы с нуля, третьи меняли все пароли, блокировали учётки и закрывали порты. Через сутки критичные базы работали.
Шаг 2. Понять, сколько зашифровано
Подобрать ключ нельзя, и на это не стоит тратить ни часа. У нашего шифровальщика была X25519 и XSalsa20-Poly1305 с отдельным ключом на каждый файл. Вопрос не в том, как расшифровать, а в том, весь ли файл зашифрован.
Многие шифровальщики шифруют только начало: для бэкапа на сотни гигабайт это быстрее, а испорченный заголовок и так не даст его восстановить. Наш портил первые 10 МиБ каждого файла и дописывал в конец служебный хвост с маркером GOWR3F.
Как это проверить на своём файле:
- Посмотреть статистику по блокам. Шифротекст даёт почти идеально ровное распределение байтов, у сжатых данных SQL Server оно заметно неровное. Граница между ними и есть конец зашифрованной области.
- Найти хвост. В последних сотнях байт шифровальщики обычно пишут служебные данные, часто вместе с размером зашифрованного куска.
Файлы меньше зашифрованной области потеряны целиком. Это мелкие журналы транзакций и системные базы, их восстанавливать нечего.
Шаг 3. Искать копии в правильном порядке
Пока одни разбирают файлы, другие ищут незашифрованное. Порядок по полезности:
- Свежие офлайн-копии. Диски, не подключённые к сети в ту ночь. У нас правило 3-2-1 соблюдалось не на всех базах, но где соблюдалось, оно и спасло: критичные базы подняли из копий с отдельных дисков.
- Тестовые базы и копии у разработчиков. Выгрузки
.dt, файлы.cf, ноутбуки. - Старые копии любой давности. Двухлетняя копия не вернёт свежие данные, но о ней ниже.
Цена первого пути тоже не нулевая. Офлайн-копии отставали, и мы потеряли около 10 часов данных. Для учёта товара это значит расхождение с физикой: инвентаризации, пересчёт остатков, ручное выравнивание.
Что не поможет: зашифрованные бэкапы той же базы за другие дни, у них испорчено одно и то же начало. И базы другой редакции той же типовой конфигурации: версии объектов не совпадают.
Шаг 4. Если чистой копии нет: собрать базу из страниц
Для части баз копии не нашлось вовсе. Здесь выручило то, что зашифровано только начало.
База SQL Server состоит из страниц по 8 КБ. Сжатый бэкап - это последовательность независимых блоков, каждый распаковывается сам по себе. Значит, можно найти первый целый блок сразу за зашифрованной областью, распаковать всё до конца файла и получить почти все страницы базы. SQL Server такой файл штатно не восстановит, но страницы в нём целые.
Сколько при этом теряется: 10 МиБ шифротекста в сжатом бэкапе - это примерно первые 70-100 МБ файла данных, около 9 тысяч страниц. В бухгалтерской базе на 23 ГБ это около 0,3 % страниц. Мало по объёму и много по смыслу, потому что в начале файла лежит описание таблиц и колонок, служебные страницы распределения и самые старые данные.
Работа раскладывается так:
| Этап | Что делаем | На чём легко ошибиться |
|---|---|---|
| Извлечение | распаковываем блоки, вынимаем страницы | сканировать поток с неверным шагом: в базу попадают страницы чужих баз |
| Проверка | контрольная сумма каждой страницы | без неё битые страницы уходят в данные |
| Отсев | отбрасываем чужое и устаревшее по номеру последнего изменения | старое содержимое диска стоит на “правильных” номерах страниц |
| Живость | по картам распределения отличаем живые страницы от удалённых | удалённые строки возвращаются и дают дубли |
| Структура | восстанавливаем таблицы, колонки, индексы | у 1С её надо сверить с описанием, которое платформа хранит в базе |
| Конфигурация 1С | собираем по списку версий | если собирать по найденным строкам, 1С не откроет базу |
| Сборка | новая база в исходной сортировке, загрузка, индексы | другая сортировка меняет порядок строк и даёт конфликты в 1С |
Главная находка нашего случая в пятой строке. Описание таблиц SQL Server лежало в испорченном начале. Но 1С хранит полное описание своих таблиц у себя в базе, в обычных данных, и оно уцелело. По нему восстановилась вся структура.
С конфигурацией было неприятнее. Сначала казалось, что не хватает пары десятков файлов. Посчитали по списку версий: не хватало 1 023. Копия двухлетней давности закрыла 1 006 из них. Вот почему старая копия любой давности стоит того, чтобы её искать.
Шаг 5. Самотест до работы с живой базой
До того как трогать вашу базу, вся цепочка прогоняется на синтетической: все типы данных, кириллица, большие текстовые и двоичные значения, даты на границах диапазона, удалённые строки. С неё снимается сжатый бэкап, проходит весь конвейер, результат сравнивается с исходником построчно. Норма - ноль расхождений в обе стороны.
У нас самотест окупился в первый же прогон. Таблица загрузилась без единой ошибки, а даты в ней были неверные: в декодере перепутались половины значения datetime. Ни одна проверка SQL этого бы не заметила, и в бухгалтерию уехали бы документы с чужими датами.
Шаг 6. Проверить собранную базу
Сначала техническая часть, она одинаковая для любой собранной базы:
-- 1. Целостность новой базы: ни одной ошибки
DBCC CHECKDB (N'RestoredDb') WITH NO_INFOMSGS, ALL_ERRORMSGS;
-- 2. Бэкап с контрольной суммой и его проверка
BACKUP DATABASE RestoredDb
TO DISK = N'D:\restore\RestoredDb.bak'
WITH COMPRESSION, CHECKSUM, INIT;
RESTORE VERIFYONLY
FROM DISK = N'D:\restore\RestoredDb.bak'
WITH CHECKSUM;Плюс число строк в каждой таблице сверяется с числом извлечённых. Если нашлась старая копия, её восстанавливают рядом и сравнивают неизменные данные: старые проводки и закрытые периоды должны совпасть. У нас по регистрам совпало 99,6-99,8 %, а расхождение главного регистра точно совпало с независимым подсчётом потерь по индексам.
Потом отчёт о потерях. Он строится точно, а не на глаз: на потерянные страницы ссылаются уцелевшие соседи, а каждая строка уцелевшего индекса содержит ключ строки данных. Есть в индексе и нет в данных - строка потеряна. Движения регистров, сгруппированные по регистратору, дают список документов, которые достаточно перепровести в 1С.
Шаг 7. Приёмка в 1С, и тут нужен человек
Методику мы собирали вместе с нейросетью: агент сопоставлял страницы, сравнивал наборы строк, откладывал спорные случаи и проверял результат. Но две вещи увидел только человек. Ошибку при первом запуске тонкого клиента. И то, что одна из собранных баз оказалась старой копией, а не свежей.
Поэтому порядок приёмки такой:
- Восстановить итоговый бэкап на тестовом сервере, зарегистрировать базу в кластере.
- Тестирование и исправление: реструктуризация, пересчёт итогов.
- Перепроведение по списку из отчёта о потерях.
- Ключевые отчёты за последний месяц открывает бухгалтер, который знает свои документы в лицо.
- Только после этого пользователи.
Чем кончилось у нас: бухгалтерская база собралась за 6 часов, не собрались полтора десятка документов. Service Desk вернулся почти целиком: обращения, запросы на изменение, спринты. Потеряли почтовый архив и содержимое вложений.
Что закрыть после
Вся безопасность сводится к тому, чтобы отсрочить момент взлома, а когда он наступит, обойтись дешевле. После атаки мы закрыли доступ к серверам снаружи, сменили все пароли, убрали лишние доступы, ограничили подключения по странам, обновили софт и антивирусы, ужесточили VPN и включили двухфакторную авторизацию.
Для 1С главное из этого списка - бэкапы. Копия, до которой дотягивается учётка с сервера, будет зашифрована той же ночью. Нужна хотя бы одна копия, до которой из сети не дотянуться: отключаемый диск, лента, хранилище с запретом перезаписи. И проверять её восстановлением, а не наличием файла. Как устроить бэкап, чтобы он не шёл всю ночь, разобрано в статье бэкап 1С идёт всю ночь, а что делать, если бэкап есть, но восстанавливается с ошибками, в разборе восстановления базы 1С из бэкапа SQL.
Если это случилось у вас
Пришлите один зашифрованный файл или его начало и хвост: бесплатно посмотрим, сколько зашифровано и есть ли из чего собирать. Если зашифрован весь файл, скажем сразу. Если только начало, возьмёмся за сборку по услуге восстановление базы 1С после шифровальщика, с отчётом о потерях и приёмкой в 1С.
