← На главную

Атака вируса-шифровальщика — одна из самых стрессовых ситуаций для системного администратора и разработчика 1С. В случае с платформой 1С:Предприятие 7.7, работающей на MS SQL Server, часто возникает уникальная ситуация: вредоносная программа успешно зашифровывает все файлы в общих сетевых папках, включая конфигурационный файл 1cv7.md, файл словаря данных 1cv7.dds и все доступные резервные копии. При этом сами файлы базы данных СУБД (.mdf и .ldf) остаются абсолютно нетронутыми, поскольку на момент атаки они были заблокированы процессами MS SQL Server.

В этой статье мы подробно разберем, как восстановить работоспособность информационной базы 1С 7.7, имея на руках только «живые» файлы СУБД. Мы рассмотрим методы поиска резервных копий метаданных, декомпиляцию внешних файлов и сложную процедуру ручной «подгонки» структуры конфигурации под таблицы SQL.

Шаг 1. Безопасность прежде всего — создание «холодного» бэкапа

Перед тем как приступать к любым восстановительным работам, необходимо полностью исключить риск окончательной потери данных SQL. Запомните: любые эксперименты по подключению незавершенных конфигураций могут инициировать автоматическую реструктуризацию таблиц платформой 1С, что приведет к мгновенной очистке или удалению данных.

Выполним следующие действия:

1. Остановим службу MS SQL Server через консоль управления службами или SQL Server Configuration Manager. Это освободит файлы базы данных от блокировки.
2. Физически скопируем файлы .mdf и .ldf вашей рабочей базы данных в надежное, изолированное место (например, на внешний жесткий диск или другое облачное хранилище, не связанное с пострадавшей сетью).
3. Запустим службу MS SQL Server обратно.

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

Шаг 2. Глубокий поиск оригинального файла конфигурации 1cv7.md

Восстановление «с нуля» — трудоемкий процесс, поэтому сначала проанализируем неочевидные места, где могла сохраниться копия конфигурации:

• Временные файлы ОС (папка TEMP): При запуске Конфигуратора, сохранении метаданных или обновлении платформы 1С 7.7 активно использует временные каталоги Windows. Проверим папки по путям %TEMP% на сервере и локальных компьютерах программистов. Нам нужны временные файлы с маской имени ~md*.tmp (например, ~mdB4.tmp). Переименовав такой файл в 1cv7.md, мы можем получить полностью готовую конфигурацию.
• Теневые копии тома (VSS): Проверим, была ли включена служба теневого копирования на сервере под управлением Windows Server. Даже если администратор утверждает, что ничего не осталось, имеет смысл проверить свойства папки с базой данных на вкладке «Предыдущие версии» (Previous Versions) — шифровальщики старых типов часто пропускали системные теневые копии.
• Анализ удаленных файлов: Поскольку платформа 1С 7.7 при сохранении изменений сначала удаляет старый MD-файл, а затем записывает новый, утилиты для восстановления удаленных данных (такие как Recuva, R-Studio или GetDataBack) могут обнаружить старые версии 1cv7.md в свободном пространстве диска.
• Каталог NEW_STRU: Если атака произошла во время или сразу после обновления конфигурации, в каталоге базы данных могла остаться папка NEW_STRU. В ней содержатся промежуточные файлы структуры, которые вирус мог проигнорировать.

Шаг 3. Извлечение структуры метаданных из внешних отчетов (ERT)

Если найти оригинальный файл 1cv7.md стандартными средствами поиска не удалось, рассмотрим продвинутый технический метод. Файлы конфигурации 1cv7.md и внешних обработок/отчетов *.ert являются структурированными файлами формата Microsoft Compound Document (составной документ OLE).

Малоизвестный факт: при сохранении любого внешнего отчета или обработки 1С 7.7 автоматически упаковывает внутрь него полный поток метаданных текущей конфигурации в виде бинарного потока Main Metadata Stream (MainMetadataStream).

Если у вас сохранились внешние обработки (например, в папке ExtForms), мы можем восстановить конфигурацию по следующей схеме:

1. Скачаем специализированную утилиту для работы с файлами 1С 7.7 — GComp (или аналогичный плагин к Total Commander для работы с составными документами).
2. Используя утилиту, извлечем поток метаданных из наиболее «свежего» уцелевшего файла .ert.
3. Сформируем на основе извлеченного потока полноценный файл 1cv7.md. Полученная конфигурация будет полностью соответствовать той структуре, которая была в базе на момент последнего сохранения этой внешней обработки.

Шаг 4. Регенерация файла словаря данных 1cv7.dds

Даже если мы нашли или восстановили файл 1cv7.md, запуск базы данных в режиме SQL невозможен без файла словаря данных 1cv7.dds. Этот файл содержит сопоставление объектов метаданных (справочников, документов) физическим таблицам СУБД.

Выясним, как автоматически сгенерировать корректный 1cv7.dds:

1. Создадим новую пустую папку на диске компьютера.
2. Поместим туда наш восстановленный файл 1cv7.md.
3. Запустим Конфигуратор 1С 7.7 и укажем эту новую пустую папку в качестве пути к базе.
4. В меню Конфигуратора перейдем в «Администрирование» -> «Установка параметров базы данных» и выберем формат «Для SQL».
5. Укажем параметры подключения к любой *тестовой, пустой* базе данных на вашем MS SQL Server (ни в коем случае не подключайтесь на этом этапе к живой базе!).
6. Нажмем кнопку сохранения конфигурации. Платформа произведет первичную инициализацию структуры и автоматически сгенерирует в каталоге новый текстовый файл 1cv7.dds.
7. Теперь скопируем файлы 1cv7.md и свежесозданный 1cv7.dds в каталог к нашей оригинальной («живой») базе данных SQL.

Шаг 5. Синхронизация старой конфигурации с живой базой SQL

Рассмотрим наиболее сложную ситуацию: найденный файл конфигурации 1cv7.md устарел (например, он был взят из бэкапа полугодовой давности), а за это время программист вносил изменения в структуру данных (добавлял реквизиты, новые документы или регистры). Прямое подключение такого MD-файла приведет к критическим ошибкам СУБД из-за несовпадения колонок в таблицах.

Проанализируем алгоритм ручной синхронизации структуры:

1. Откроем MS SQL Server Management Studio (SSMS) и подключимся к нашей оригинальной уцелевшей базе данных.
2. Изучим физические таблицы базы. Таблицы справочников имеют префикс SC..., шапки документов — DH..., табличные части документов — DT..., таблицы регистров накопления — RA... и RG....
3. Откроем сгенерированный нами на Шаге 4 тестовый файл 1cv7.dds в любом текстовом редакторе. Это текстовый файл структуры метаданных.
4. Найдем в файле 1cv7.dds описание интересующего нас объекта. Например, справочник «Контрагенты» описан как таблица SC145, а его реквизиты — как поля SP146, SP147 и так далее.
5. Сравним структуру полей таблицы в SSMS и в файле 1cv7.dds. Если в СУБД в таблице SC145 присутствует колонка SP150, а в нашем файле .dds последнее поле — это SP148, значит, в конфигурацию позже были добавлены новые реквизиты.
6. Откроем Конфигуратор с нашим MD-файлом и начнем последовательно добавлять новые реквизиты в соответствующие объекты.

   Важно: Платформа 1С 7.7 присваивает идентификаторы (ID) полям строго по порядку их создания. Нам необходимо добавлять реквизиты до тех пор, пока вновь генерируемый файл 1cv7.dds по именам колонок и типам данных полностью не совпадет с реальной физической структурой таблиц в СУБД MS SQL.

7. После того как все расхождения устранены, мы сможем запустить систему в режиме «Предприятие» без потери накопленных данных.

Резюме и рекомендации по безопасности

Мы убедились, что даже в случае полной потери конфигурационных файлов 1С 7.7 на SQL-версии, данные можно восстановить благодаря защищенности файлов .mdf и .ldf от перезаписи в процессе работы СУБД.

Чтобы избежать подобных инцидентов в будущем, настоятельно рекомендуем настроить регулярное резервное копирование по схеме «3-2-1» (3 копии, на 2 разных типах носителей, 1 копия — вне офиса), ограничить доступ к серверу по протоколу RDP без использования VPN и настроить права доступа к каталогам баз данных на уровне операционной системы.