Администрирование · 12 мин
Как восстановить 1С после шифровальщика
Пошаговая инструкция по восстановлению баз 1С после атаки шифровальщика: изоляция сервера, поиск резервных копий, восстановление файловой и клиент-серверной базы, проверка целостности данных.
Шифровальщик (ransomware) шифрует файлы на дисках серверов и рабочих станций, и базы 1С — один из первых пострадавших объектов: файловые базы .1CD, архивы выгрузок .dt и бэкапы SQL оказываются недоступны, а работа учёта останавливается. Хорошая новость в том, что при наличии резервных копий восстановление 1С — вполне штатная процедура, и данные обычно удаётся вернуть без потерь или с минимальными потерями за период между последней копией и атакой.
Главные ошибки в такой ситуации — паника, поспешная переустановка системы и попытки «починить» зашифрованные файлы вручную. Эти действия уничтожают улики, затрудняют определение вектора атаки и иногда лишают последнего шанса на расшифровку. Правильный порядок: сначала изолировать заражённые машины, затем оценить ущерб, найти целые копии и только после этого восстанавливать базы на чистом окружении.
Ниже разобран практический сценарий: как оценить заражение, где искать выжившие копии, как восстановить файловую и клиент-серверную базу, как проверить целостность данных и что сделать, чтобы ситуация не повторилась.
Шаг 1. Изолируйте заражённые машины и зафиксируйте состояние
Первое действие — физически отключить пострадавшие серверы и рабочие станции от сети: выдернуть сетевой кабель или выключить Wi-Fi. Не выключайте питание сразу, если есть подозрение, что шифрование ещё идёт: снятие образа диска и анализ процессов в оперативной памяти помогут понять, какой шифровальщик сработал. Если атака продолжается, отключение питания допустимо как крайняя мера.
Отключите общие сетевые папки и примонтированные диски на остальных машинах — многие шифровальщики распространяются по сетевым ресурсам. Проверьте, не зашифрованы ли каталоги, куда писались резервные копии, и NAS-устройства, доступные по SMB.
Сфотографируйте или перепишите текст записки с требованием выкупа (файлы README, HOW_TO_DECRYPT и подобные). По ноте и расширению зашифрованных файлов можно идентифицировать семейство шифровальщика через сервисы вроде ID Ransomware — от этого зависит, существует ли бесплатный дешифратор.
Шаг 2. Оцените масштаб повреждения и идентифицируйте шифровальщик
Составьте список пострадавших объектов: файловые базы .1CD, каталоги с выгрузками .dt, бэкапы MS SQL или PostgreSQL (.bak, .dump), хранилища конфигураций, файлы лицензий. Отметьте, какие из них зашифрованы (изменённое расширение, невозможность открыть), а какие остались доступны.
Определите семейство шифровальщика: загрузите образец зашифрованного файла и текст записки на сервис идентификации (например, ID Ransomware от компании Emsisoft), сверьте расширение со списками известных семейств. На портале No More Ransom публикуются бесплатные дешифраторы для многих старых и некоторых актуальных семейств.
Параллельно установите вектор заражения: открытый RDP-порт со слабым паролем, фишинговое письмо, уязвимость VPN-шлюза. Без устранения причины восстановленная система будет заражена повторно — это самая частая причина «второй волны» атаки через несколько дней после восстановления.
Проверьте сетевые папки и сервер 1С — возможно, базы не затронуты
Проверьте, выжили ли копии на внешних носителях или в облаке
Ищите офлайн-копии: съёмные диски, ленты, облачные версии
Идентифицируйте семейство и проверьте наличие дешифратора
Шаг 3. Найдите целые резервные копии
Поиск копий — ключевой этап, от него зависит объём потерь. Проверьте все возможные источники, даже те, о которых «точно помнят, что там пусто»:
- внешние USB-диски и ленточные накопители, которые физически не были подключены в момент атаки;
- облачные хранилища с версионированием (объектные хранилища, Яндекс.Диск, Google Drive) — версии файлов до даты заражения часто доступны даже если текущая версия перезаписана зашифрованной;
- сервера репликации и вторичные площадки, если настроена георезервная копия;
- локальные папки бухгалтеров — нередко кто-то вручную делал выгрузку *.dt «на всякий случай»;
- теневые копии Windows (VSS) на заражённом сервере — команда
vssadmin list shadowsпокажет, уцелели ли они.
Учтите: многие современные шифровальщики первым делом удаляют теневые копии и шифруют сетевые бэкапы, поэтому копии, хранившиеся на том же сервере или на постоянно примонтированном диске, скорее всего потеряны. Ценность имеют только офлайн- и версионные копии.
Перед восстановлением скопируйте найденную резервную копию минимум в два независимых места и работайте только с копией копии. Если архив окажется битым, а вы начнёте его «лечить» в единственном экземпляре, второго шанса не будет.
Шаг 4. Восстановите файловую базу 1С
Если у вас файловая база (каталог с файлом 1Cv8.1CD), сценариев восстановления два: из выгрузки *.dt или из копии самого файла базы.
Восстановление из выгрузки *.dt
Это самый надёжный способ: файл *.dt содержит полный снимок базы в независимом формате. Установите платформу 1С на чистый сервер (версию платформы — не ниже той, на которой делалась выгрузка), создайте пустую информационную базу через стартер 1С и загрузите выгрузку: «Конфигуратор → Администрирование → Загрузить информационную базу».
Шаг 5. Восстановите клиент-серверную базу (SQL)
Для клиент-серверного варианта восстановление идёт на уровне СУБД. Разверните чистый экземпляр MS SQL Server или PostgreSQL, восстановите базу из бэкапа (.bak для MS SQL, дамп для PostgreSQL) и подключите её через консоль кластера серверов 1С, указав имя сервера СУБД и имя базы.
Важные нюансы: версия СУБД при восстановлении должна быть не ниже исходной (MS SQL не позволяет восстановить бэкап на более старую версию сервера); после восстановления проверьте права учётной записи, под которой сервер 1С обращается к базе; если использовались полные модели восстановления с бэкапами журнала транзакций, можно накатить логи и сократить потери до минут, а не до ночной копии.
После подключения базы к кластеру 1С откройте Конфигуратор и выполните «Администрирование → Тестирование и исправление» с проверками ссылочной целостности. Только после успешного прохождения пускайте пользователей.
Как проверить результат восстановления
Запуск без ошибок, списки документов отображаются
Ошибки формата потока, падение при открытии
Проверки завершены без критических ошибок
Ошибки ссылочной целостности, битые таблицы
Оборотно-сальдовая ведомость и складские остатки сходятся с последними распечатками или отчётами
Расхождения в суммах, пропавшие документы
Проведение документов и формирование отчётов без ошибок
Зависания, ошибки при записи объектов
Шаг 6. Что делать, если резервных копий нет
Ситуация тяжёлая, но не всегда безнадёжная. Порядок действий такой: снимите посекторный образ зашифрованного диска, идентифицируйте шифровальщик и проверьте наличие дешифратора на No More Ransom и у антивирусных вендоров. Для ряда семейств ключи публикуются после задержек правоохранительных операций — зашифрованные файлы стоит сохранить даже если дешифратора пока нет.
Проверьте теневые копии VSS и точки восстановления — иногда шифровальщик не успевает или не может их удалить. Программы восстановления удалённых файлов (типа R-Studio) иногда находят исходные версии файлов, если шифровальщик создавал зашифрованную копию, а оригинал удалял без затирания секторов — на SSD с включённым TRIM шансы заметно ниже.
Оплата выкупа не гарантирует получение рабочего ключа: дешифраторы вымогателей часто содержат ошибки и портят большие файлы (а .1CD — это как раз большой файл). Кроме того, оплата финансирует дальнейшие атаки и может нарушать требования регуляторов. Параллельно соберите остатки данных: выгрузки в Excel, печатные формы, данные банк-клиентов, копии у контрагентов — по ним можно частично восстановить учёт вручную в новой базе.
Шаг 7. Защититесь от повторной атаки
Восстановление без изменения инфраструктуры почти гарантирует рецидив. Минимальный набор мер: закройте прямой доступ RDP из интернета (только через VPN), включите сложные пароли и блокировку после подборов, обновите ОС и прикладное ПО, ограничьте права пользователей и установите антивирус с поведенческим анализом на все машины, включая серверы.
Перестройте резервное копирование по принципу «3-2-1»: минимум три копии данных, на двух разных типах носителей, одна — вне основной площадки и недоступная для записи из продуктивной сети. Критично, чтобы хотя бы одна копия была офлайн или иммутабельной (неизменяемой): объектное хранилище с блокировкой версий, лента, диск, подключаемый только на время копирования. Настройте регулярную автоматическую проверку восстановления — копия, которую ни разу не разворачивали, нельзя считать рабочей.
Что важно запомнить
Изолируйте заражённые машины, сохраните зашифрованные файлы и не устраняйте следы атаки. Восстановление идёт из резервной копии на чистом окружении с последующим тестированием базы и сверкой остатков. Без копий остаются дешифраторы, теневые копии и ручное восстановление учёта. После инцидента обязательно устраните вектор атаки и внедрите офлайн-резервное копирование.
Частые вопросы
Можно ли расшифровать базу 1С без ключа злоумышленников?
Только если для конкретного семейства шифровальщика существует публичный дешифратор — их публикуют на портале No More Ransom и у антивирусных вендоров. Для современных шифровальщиков со стойкой криптографией самостоятельная расшифровка невозможна; остаются теневые копии, восстановление удалённых оригиналов файлов и ожидание публикации ключей.
База из копии открывается, но выдаёт «Ошибка формата потока». Что делать?
Это признак частичного повреждения файла базы. Сделайте копию файла и прогоните утилиту chdbfl.exe из каталога платформы с включённым исправлением ошибок. Если не помогло — попробуйте выгрузить базу в .dt через Конфигуратор (часто выгрузка проходит даже при ошибках в отдельных таблицах) и загрузите в новую пустую базу.
За какой период потеряются данные?
Потери равны интервалу между последней целой резервной копией и моментом атаки. Если копия делалась ночью, а атака случилась днём — теряются документы за текущий день. Их частично можно восстановить по бумажным документам, данным банк-клиента, ЭДО и копиям у контрагентов.
Нужно ли сообщать об атаке в госорганы?
Если в базе обрабатывались персональные данные (а в 1С с зарплатой и кадрами они есть почти всегда), утечка подпадает под требования законодательства о персональных данных: оператор обязан уведомить Роскомнадзор об инциденте в установленные сроки. Практическую целесообразность обращения в полицию определяйте с юристом — для расследования важно сохранить улики до переустановки систем.
Можно ли работать в 1С сразу после восстановления из копии?
Нет, сначала выполните тестирование и исправление информационной базы, сверьте остатки по ключевым отчётам с последними доступными данными и убедитесь, что сервер очищен от вредоносного ПО, а вектор атаки устранён. Пропуск этих шагов приводит к работе на повреждённой базе или к повторному заражению.
Шифровальщик задел и сервер лицензий 1С. Что делать?
Программные лицензии 1С привязаны к аппаратной конфигурации. После переустановки сервера активируйте резервный пин-код из комплекта поставки. Если резервные пин-коды исчерпаны, обратитесь в центр лицензирования 1С через партнёра, у которого приобреталась программа, — при подтверждённом инциденте возможна повторная выдача кодов.