Что делать при заражении базы 1С вирусом-шифровальщиком и как защитить систему на будущее

Системный администратор 1С v7.7 IT и автоматизация бизнеса
← На главную

Атака программ-вымогателей (ransomware) на рабочие станции и серверы с базами данных 1С — одна из самых критических аварийных ситуаций. Зловред шифрует файлы информационных баз (как таблицы DBF в версии 7.7, так и единый файл 1Cv8.1CD в платформе 8), дописывая к ним длинные расширения с контактами злоумышленников. Разберем по шагам, какие действия необходимо предпринять сразу после обнаружения инцидента, возможно ли спасти данные без выкупа и как выстроить эшелонированную защиту на будущее.

Первичные действия при обнаружении атаки

Когда вы обнаружили, что файлы меняют свои расширения или уже зашифрованы, действовать нужно незамедлительно:

  1. Немедленная изоляция хоста: отключим сетевой кабель или разорвем Wi-Fi соединение на зараженной машине, чтобы троян не продолжил сканировать и шифровать сетевые каталоги, сетевые шары и подключенные накопители.
  2. Сохранение оперативной памяти: если процесс шифрования еще идет или только завершился, не станем сразу перезагружать или выключать компьютер стандартным способом. При возможности снимем дамп оперативной памяти (или переведем систему в гибернацию) — современные алгоритмы могут оставлять временные ключи шифрования в памяти до момента перезагрузки.
  3. Поиск процесса и изоляция: завершим подозрительные процессы через диспетчер задач или командную строку, чтобы остановить перезапись оставшихся файлов.

Оценка возможности восстановления зашифрованных баз

Большинство современных шифровальщиков (семейства Cryakl, Vault и аналогичные) используют стойкое асимметричное шифрование (например, RSA с длинным ключом). Подобрать закрытый ключ математически невозможно, а выплата выкупа не гарантирует получение декриптора. Однако существуют сценарии, когда данные удается спасти:

  1. Восстановление из теневых копий: проверим состояние службы теневого копирования с помощью утилиты Shadow Explorer. Нередко при запуске скрипта из-под непривилегированной учетной записи вирусу не хватает прав выполнить команду vssadmin delete shadows, и снимки тома остаются целыми.
  2. Постраничное восстановление и ремонт заголовков файлов: многие шифровальщики в целях экономии времени шифруют не весь массив файла, а только первые несколько килобайт (заголовок и первичное дерево страниц). В базах формата DBF повреждается только начальный заголовок со структурой полей. Открыв файл в шестнадцатеричном редакторе или специализированных утилитах для работы с DBF, можно восстановить заголовочную структуру аналогичного пустого файла из дистрибутива конфигурации. В файловых базах 1Cv8.1CD при повреждении первых страниц таблицы данных внутри файла остаются нетронутыми. Специализированные парсеры структуры страниц .1CD позволяют извлечь уцелевшие записи таблиц и перенести их в чистую базу.
  3. Восстановление из резервных копий: самый надежный и правильный путь. Если бэкапы велись регулярно, поврежденная рабочая база удаляется, а система восстанавливается из последней сохраненной копии.

Технические меры защиты операционной системы

Проанализируем ключевые каналы проникновения: чаще всего вирус попадает через фишинговые письма с вложениями (архивы с расширениями .vbs, .js, .scr, .hta) либо через уязвимости протокола RDP. Настроим системные ограничения для нейтрализации этих векторов.

1. Переназначение ассоциаций опасных файлов и отключение скриптовых движков

Переопределим запуск скриптов на обычный текстовый редактор. Если пользователь случайно откроет файл со скриптом, он просто откроется в блокноте в виде текста, не выполнив вредоносный код. Для отключения wscript.exe и cscript.exe применим следующие параметры реестра:


[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\wscript.exe]
"Debugger"="ntsd -d"

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\cscript.exe]
"Debugger"="ntsd -d"

[HKEY_CLASSES_ROOT\JSFile\Shell\Open\Command]
@="C:\\Windows\\notepad.exe \"%1\" %*"

[HKEY_CLASSES_ROOT\VBSFile\Shell\Open\Command]
@="C:\\Windows\\notepad.exe \"%1\" %*"

2. Настройка политик ограничения запуска программ (SRP / AppLocker)

Запретим запуск исполняемых файлов из пользовательских каталогов (AppData, Temp, Downloads), куда почтовые клиенты и браузеры сохраняют вложения. Через оснастку gpedit.msc в разделе «Политики ограниченного использования программ» создадим правило по умолчанию, разрешающее выполнение файлов только из защищенных каталогов C:\Windows и C:\Program Files, заблокировав запуск из всех остальных мест.

3. Отказ от постоянно подключенных сетевых дисков

Шифровальщик сканирует все доступные буквы дисков (Z:, Y: и т.д.). Заменим подключенные сетевые диски на прямые сетевые пути (UNC) через ярлыки вида \\server\share\%username%. Это снижает вероятность того, что простой скрипт сможет автоматически обойти и зашифровать все корпоративные файловые ресурсы.

Защита на уровне архитектуры платформы 1С:Предприятие

Рассмотрим, как конфигурация и окружение самой платформы влияют на безопасность:

  1. Переход на клиент-серверный вариант (SQL): это кардинальное решение проблемы шифрования файлов баз. В файловом режиме (.1CD или .DBF) каждый пользовательский компьютер обязан иметь прямой доступ на чтение и запись к файлам базы. При заражении ПК вирус получает те же права. В клиент-серверном режиме (MS SQL Server, PostgreSQL) пользователи общаются только с кластером серверов 1С по портам протокола TCP/IP, а прямые права на файлы базы данных имеет исключительно служебная учетная запись СУБД.
  2. Публикация баз через веб-сервер и RemoteApp: если нет возможности перейти на СУБД, организуем подключение пользователей через веб-клиент или RemoteApp без прямого доступа к файловой системе сервера.
  3. Штатная защита от опасных действий: не отключаем в платформе 1С механизм защиты от опасных действий. Он предупреждает пользователей при попытках внешних отчетов и обработок запустить исполняемые файлы операционной системы или использовать неизвестные COM-объекты.
  4. Использование профилей безопасности: в кластере серверов 1С настроим профили безопасности, запрещающие серверному коду вызывать произвольные системные утилиты ОС и обращаться к неразрешенным каталогам файловой системы.

Организация неуязвимого резервного копирования

Резервные копии бесполезны, если шифровальщик имеет к ним доступ на запись. Разберем правила построения защищенных архивов:

  1. Принцип одностороннего доступа (Write-Only): настроим сетевую папку для бэкапов так, чтобы у рабочей учетной записи были права исключительно на создание файлов и запись данных, но полностью отсутствовали права на чтение, изменение и удаление содержимого каталога. В таком случае вирус не сможет прочитать список созданных файлов и перезаписать их.
  2. Разделение учетных записей служб: утилиты резервного копирования должны работать как системные службы под выделенным служебным пользователем. Учетные записи рядовых пользователей или операторов 1С не должны иметь никаких прав доступа (NTFS и сетевых) к диску с бэкапами.
  3. Изоляция на внешнем сервере (Linux / NAS): настроим схему, при которой сервер с резервными копиями сам забирает (pull) файлы с рабочего сервера по расписанию через защищенные протоколы (SSH/SFTP/rsync), либо рабочий сервер выгружает файлы во временный каталог, откуда скрипт на базе Linux сразу переносит их в изолированное хранилище и очищает точку входа.
  4. Хранение офлайн-копий («холодный» бэкап): выработаем регламент периодического сброса архивов на внешние съемные диски или ленточные накопители. После завершения копирования накопитель должен быть физически отключен от компьютера и локальной сети.

Комплексное сочетание системных политик ограничения, отключения опасных скриптовых интерпретаторов, перехода на клиент-серверную архитектуру 1С и изолированного резервного копирования гарантирует сохранность учетных данных даже при успешном проникновении вредоносного ПО в локальную сеть.

← На главную