← На главную

Заражение терминального сервера 1С вирусом-шифровальщиком (Ransomware) — критическая ситуация, способная полностью парализовать работу компании. Даже если сервер предназначен исключительно для работы в 1С, существует множество скрытых векторов атак, позволяющих вредоносному ПО проникнуть в систему и зашифровать базы данных и сетевые ресурсы. Разберем подробно, какими путями шифровальщики попадают на серверы, и выстроим эшелонированную систему защиты инфраструктуры 1С.

Основные векторы проникновения вредоносного ПО на терминальный сервер

Проанализируем типичные уязвимости и сценарии, которые приводят к заражению:

1. Сетевые общие папки (SMB-шары) и проброс дисков: Если пользователь открыл зараженное вложение на своем локальном компьютере, вирус сканирует все доступные по сети ресурсы. Если у пользователя есть права на запись в сетевую папку или проброшен локальный диск через RDP-сессию (Drive Redirection), шифровальщик получает доступ к файловой системе сервера и начинает шифровать файлы баз 1Cv8.1CD и архивы.
2. Незащищенный RDP и слабые пароли: Прямая публикация порта RDP (по умолчанию 3389) в сеть Интернет делает сервер уязвимым для атак методом подбора паролей (Brute Force) и эксплуатации уязвимостей в протоколе RDP.
3. Почтовые клиенты, мессенджеры и браузеры внутри терминальной сессии: Наличие установленных почтовых программ, браузеров со свободным доступом в сеть и мессенджеров на самом терминальном сервере позволяет пользователям напрямую скачивать и запускать исполняемые вредоносные вложения (например, файлы со скриптами *.wsf, *.js, *.vbs, *.exe).
4. Избыточные привилегии учетных записей: Работа пользователей под учетными записями с правами локального или доменного администратора снимает любые барьеры на пути выполнения кода и модификации системных каталогов.
5. Непроверенные внешние обработки и расширения: Запуск внешних файлов *.epf или *.erf из ненадежных источников может привести к выполнению деструктивного кода от имени пользователя или сервера приложений.

Шаг 1. Разграничение прав доступа и изоляция пользовательских сессий

Рассмотрим первоочередные меры по ужесточению прав в операционной системе:

1. Лишение пользователей прав администратора: Обычные пользователи терминала должны обладать исключительно правами стандартного пользователя. Никаких привилегий из группы Администраторы (Administrators) им предоставляться не должно.
2. Сложные пароли и защита встроенных учетных записей: Установите сложный пароль для учетной записи локального администратора, переименуйте встроенную учетную запись Administrator и отключите неиспользуемые гостевые учетные записи.
3. Очистка временных файлов: Настройте автоматическую ночную очистку пользовательских каталогов Temp и Tmp по расписанию через скрипты, чтобы предотвратить накопление и случайный запуск временных исполняемых файлов.

Шаг 2. Защита сетевого контура и подключений по RDP

Проанализируем правила безопасной организации удаленного доступа к 1С:

1. Запрет прямого доступа к RDP из Интернета: Терминальный сервер никогда не должен публиковаться напрямую наружу. Подключение удаленных пользователей должно осуществляться строго через VPN-туннель (с обязательной двухфакторной аутентификацией) либо через шлюз удаленных рабочих столов (RD Gateway).
2. Включение NLA: Обязательно включите проверку подлинности на уровне сети (Network Level Authentication — NLA) в свойствах RDP.
3. Блокировка проброса локальных дисков и буфера обмена: В групповых политиках (GPO) терминального сервера запретите перенаправление дисков клиентов в сеанс RDP. Это исключит ситуацию, когда вирус с домашнего или локального ПК пользователя получает доступ к дискам сервера через терминальный канал.
4. Ограничение исходящего сетевого трафика (Egress Filtering): Большинству шифровальщиков для старта процесса шифрования требуется связаться со своими командными серверами (C&C) для получения ключа. Заблокируйте брандмауэром весь исходящий трафик с терминального сервера, разрешив только доверенные IP-адреса и порты (например, почтовый сервер для рассылки счетов или банковские шлюзы).

Шаг 3. Контроль запуска приложений (AppLocker и SRP)

Выясним, как полностью запретить запуск вредоносных программ в пользовательских сессиях:

1. Настройка политик AppLocker или SRP: Создайте правила белого списка, разрешающие запуск исполняемых файлов только из системных каталогов C:\Program Files и C:\Windows.
2. Запрет запуска из каталогов профилей пользователей: Категорически заблокируйте запуск любых исполняемых и скриптовых файлов из папок AppData, Temp, Downloads и каталогов общих сетевых ресурсов.
3. Блокировка скриптовых интерпретаторов: Для обычных пользователей заблокируйте доступ к powershell.exe, wscript.exe, cscript.exe, mshta.exe и certutil.exe.

Шаг 4. Архитектурная защита 1С: переход на клиент-серверный режим

Разберем, почему файловый режим 1С уязвим и как решить проблему архитектурно:

1. Отказ от файловых баз (1Cv8.1CD): В файловом варианте пользователи обязаны иметь полные права на изменение файлов в каталоге базы. В случае заражения одного рабочего места база данных будет зашифрована мгновенно.
2. Использование клиент-серверного варианта (SQL): В режиме MS SQL Server или PostgreSQL файлы базы данных хранятся в изолированном хранилище СУБД, к которому у пользователей нет доступа через файловую систему.
3. Изоляция служб 1С и СУБД: Службы кластера серверов ragent, rmngr, rphost и служба СУБД должны запускаться под отдельными сервисными учетными записями без прав администратора.
4. Применение тонкого клиента: Вместо терминального доступа пользователей на сервер предпочтительно использовать тонкий клиент, подключающийся к серверу приложений 1С по протоколу TCP или HTTPS. Это полностью исключает присутствие пользователя в операционной системе сервера.

Шаг 5. Организация надежного и неизменяемого резервного копирования

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

1. Модель Pull-бэкапа: Сервер резервного копирования должен самостоятельно забирать данные с рабочего сервера 1С. Сервер 1С не должен иметь прав доступа и сохраненных учетных данных к хранилищу резервных копий.
2. Неизменяемые хранилища (Immutable Backups): Используйте автономные Linux-серверы, ленточные накопители или S3-хранилища с поддержкой режима Object Lock / WORM, где созданную резервную копию технически невозможно перезаписать или удалить в течение заданного срока даже с учетной записью администратора.
3. Не храните бэкапы на подключенных сетевых дисках: Локальные диски, сетевые папки (SMB) и локальные теневые копии Windows (VSS) шифровальщики удаляют и шифруют в первую очередь.
4. Регулярная проверка восстановления: Регулярно проводите тестовое разворачивание резервных копий на тестовом сервере для проверки их целостности и актуальности.