Заразили один сервер из тысячи: что происходит с остальными 999
Если заражён один сервер из тысячи, судьба остальных 999 зависит не от антивируса, а от архитектуры сети. В сегментированной инфраструктуре с раздельными правами доступа шифровальщик останавливается на одном узле. В плоской сети с общей учётной записью администратора он расходится по всем серверам за несколько часов через ту же учётку.
Почему заражение одного сервера ставит под удар всю сеть 1С
В пятницу в 18:40 бухгалтер розничной сети с 30 филиалами и тысячей виртуальных серверов открывает акт сверки в 1С — вместо файла .xlsx система показывает .locked37. IT поднимает логи: заражён один терминальный сервер в московском офисе, куда утром заходил администратор под учёткой с правами на весь домен для ежедневного бэкапа.
Сама по себе эта учётка не опасна. Но она же прописана в задании резервного копирования на всех 999 остальных серверах — так настроили три года назад, когда бэкап делали вручную и было проще дать одному логину доступ везде. Поэтому шифровальщик, получив дамп паролей с заражённого сервера, за два-три часа проходит по сети через ту же учётку и добирается до баз 1С в каждом филиале.
Почему именно сервер 1С часто становится точкой входа
1С-инфраструктура — удобная мишень не потому, что платформа уязвима сама по себе, а потому что вокруг неё годами накапливается самая свободная конфигурация сети. Терминальный сервер, на который заходят разом 40 бухгалтеров, публикуют наружу ради удалённой работы. Пароль администратора хранят в текстовом файле на этом же сервере — «так быстрее чинить». RDP-порт остаётся открытым в интернет, потому что когда-то его настроили для подрядчика и с тех пор не закрыли. Каждая такая мелочь сама по себе не критична, но вместе они превращают один сервер в трамплин на всю сеть.
Ставка здесь не абстрактная. Закрытие месяца в 1С:ERP срывается для всего холдинга, а не для одного магазина. Склад не отгружает машины, которые уже стоят под погрузкой. Если среди зашифрованных баз были персональные данные сотрудников или клиентов, компания обязана разбираться, произошла ли утечка, и в ряде случаев уведомлять регулятора — того требует 152-ФЗ.
Что происходит с остальными 999 серверами: сеть держит удар или падает целиком
Ответ зависит от того, как построена сеть, а не от того, сколько в ней серверов. В плоской архитектуре, где один администратор имеет доступ ко всем машинам, а сегменты сети не разделены, заражение одного узла — вопрос времени до заражения остальных. В сегментированной сети, где филиалы и отделы изолированы по VLAN, а права выданы по ролям, а не по принципу «на всякий случай», шифровальщик физически не может дотянуться до соседнего сегмента.
Ориентировочная разница между двумя сценариями показана в таблице ниже — как правило, именно архитектура, а не марка антивируса, решает, останется ли инцидент локальным.
| Параметр | Плоская сеть, общие права | Сегментированная сеть, права по ролям |
|---|---|---|
| Скорость перехода на соседний сервер | обычно 1-3 часа | заражение не выходит за пределы сегмента |
| Доля серверов под ударом через сутки | чаще всего большинство инфраструктуры | единицы серверов в одном сегменте |
| Состояние резервных копий | бэкап часто в той же сети и тоже зашифрован | бэкап в отдельном сегменте без общих учёток |
| Срок восстановления 1С | от нескольких суток на весь холдинг | часы на один сервер |
| Обязанность уведомлять по 152-ФЗ | почти всегда, если задеты ПДн | только если инцидент коснулся сегмента с ПДн |
На практике большинство инцидентов у малого и среднего бизнеса — это не таргетированная атака, а именно плоская сеть, доставшаяся в наследство от роста: сначала было пять серверов и один айтишник, потом стало тысяча, а модель доступа осталась той же. Разница между строками таблицы — это не теория, а разница между «потеряли один сервер на день» и «встали всем холдингом на неделю».
Почему бэкап нередко шифруется вместе с базой
Резервная копия обычно живёт в той же сети, что и рабочие серверы, и монтируется под той же учётной записью, что и сама 1С. Шифровальщик, дойдя до сервера с бэкапами, шифрует их точно так же, как рабочие базы — просто потому что видит их как обычную сетевую папку. Восстановление после этого возможно только из копии, которая физически или логически изолирована: на отдельном сегменте, под отдельной учёткой, желательно ещё и с версионированием за несколько дней назад, а не только за последнюю ночь.
Как исправить ситуацию, если вирус уже проник в 1С-инфраструктуру
Первые тридцать минут решают, останется инцидент в границах одного сервера или расползётся дальше. Заражённую машину отключают от сети физически, не через выключение — шифровальщик может доработать при завершении процесса, а форензику потом всё равно проводить по образу диска. Пароли всех учёток, у которых был доступ к заражённому серверу, меняют сразу, а не после разбора причин.
Базу 1С поднимают из бэкапа, который хранится вне заражённого сегмента — если бэкап лежал в той же сети под той же учёткой, придётся проверять его на целостность отдельно. Платформу 1С на восстановленном сервере стоит сразу вывести на актуальный релиз: часть шифровальщиков заходит через уязвимости в старых версиях веб-сервисов 1С, которые давно закрыты в свежих обновлениях 1С. Если своей команды на такой разбор не хватает, аварийные работы сисадмина и специалиста по 1С обычно тарифицируют почасово — у нас это 3800 руб/час, и в инцидент обычно укладываются в рабочий день.
Каких действий лучше избежать в первые часы
Три ошибки повторяются в большинстве инцидентов. Перезагрузка заражённого сервера до снятия образа диска уничтожает следы, по которым можно понять, как шифровальщик попал внутрь и куда успел зайти. Восстановление базы в ту же сеть под теми же учётками гарантирует повторное заражение в течение недель. А оплата выкупа без консультации с юристом и специалистом по инцидентам не даёт гарантии расшифровки и создаёт отдельные вопросы к комплаенсу компании.
Что делать, если заражение повторяется на других серверах
Если вирус возвращается через месяц-два уже на другом сервере, значит, в первый раз вылечили симптом, а не причину. Чаще всего это один и тот же локальный админ-пароль, скопированный на все серверы при разворачивании, старый веб-модуль 1С с открытым портом наружу без ограничений по IP, или права доступа, которые выдавались «с запасом» — бухгалтеру с правами системного администратора, потому что так было быстрее один раз настроить.
В такой ситуации точечные заплатки не помогают: нужно пересматривать саму модель прав в 1С — кто и к каким объектам обращается, какие роли реально нужны, а какие остались с момента первого внедрения и никто их не сокращал. Такую доработку прав и разграничение доступа делают в рамках доработки 1С — обычно это разовая работа, после которой повторное заражение через ту же лазейку перестаёт быть возможным в принципе, а не просто менее вероятным.
Как предотвратить распространение вируса на всю сеть 1С
Предотвратить — значит убрать саму возможность одной учётке или одному серверу дотянуться до всех остальных. На практике это несколько конкретных вещей, а не общая рекомендация «повысить безопасность»:
- ✓раздельные сегменты сети для филиалов, серверов 1С и рабочих станций бухгалтерии
- ✓бэкап в отдельном сегменте без доступа с рабочих станций и без общей с 1С учётной записи
- ✓роли доступа в 1С по фактическим задачам сотрудника, без прав «на всякий случай»
- ✓закрытые наружу порты RDP и веб-публикации 1С, доступ только через VPN
Для компаний с несколькими филиалами и разрозненными серверами, которые копились годами, проще пересобрать IT-архитектуру во время следующего крупного проекта — например, при переходе на 1С:ERP для холдинга или при внедрении 1С с нуля: сегментация закладывается сразу в проект, а не добавляется потом поверх готовой сети. Отдельный вопрос — сам сервер, на котором крутится 1С: старое железо часто не тянет требования актуальных релизов платформы и заставляет держать устаревшие версии с уже известными уязвимостями. Актуальные системные требования 1С стоит сверять при каждом обновлении инфраструктуры, а не один раз при покупке сервера.
Сколько стоит обезопасить инфраструктуру после инцидента
Итоговая стоимость складывается из трёх частей, и они не обязаны идти одним пакетом. Перенос 1С на изолированный арендованный сервер с раздельными правами и вынесенным бэкапом — от 3300 руб/мес за сервер, аренда самой 1С в такой конфигурации — от 1100 руб/мес. Разовые работы по разграничению прав и закрытию уязвимых модулей оформляются как доработка 1С и считаются по объёму задач. Аварийные и восстановительные работы, если инцидент уже произошёл, идут по тарифу сисадмина и специалиста 1С — 3800 руб/час.
Из этих трёх частей дешевле всего обходится профилактика: пересобрать права и вынести сервер в изолированную аренду обычно кратно дешевле, чем разбирать шифровальщика, который прошёл по 999 серверам за одну ночь.
❓ Частые вопросы
Как понять, что заражение не пошло дальше одного сервера?
Проверьте журналы аутентификации на соседних серверах на предмет входов под учёткой, которая была скомпрометирована, и посмотрите, монтировались ли с заражённого сервера сетевые папки бэкапов или соседних баз. Если чужих входов нет и сегмент сети изолирован, заражение, скорее всего, осталось локальным.
Обязаны ли мы уведомлять Роскомнадзор, если пострадал только один сервер?
Зависит от того, были ли на нём персональные данные и произошла ли реальная утечка, а не просто шифрование без выгрузки данных наружу. Требования устанавливает 152-ФЗ — при инциденте с персональными данными стоит привлечь юриста и зафиксировать, что именно было доступно вирусу на этом сервере.
Поможет ли просто поставить антивирус получше?
Антивирус ловит не все шифровальщики, особенно новые, и не решает главную проблему — общий администраторский доступ ко всем серверам сети. Без сегментации сети и разграничения прав даже хороший антивирус не остановит распространение, если вредонос уже получил рабочие учётные данные администратора.
Сколько стоит перенести 1С на изолированный сервер, чтобы снизить риск распространения?
Аренда изолированного сервера под 1С начинается от 3300 руб/мес, аренда самой 1С в такой конфигурации — от 1100 руб/мес. Точная стоимость зависит от количества баз, пользователей и того, нужен ли отдельный сегмент сети для резервных копий и распределение прав по ролям.
Что делать в первые 30 минут после обнаружения шифровальщика?
Отключите заражённый сервер от сети физически, не выключая его, и сразу смените пароли всех учётных записей, у которых был к нему доступ. Не перезагружайте сервер и не восстанавливайте базу в ту же сеть до выяснения, как именно вирус попал внутрь.
Или позвоните: +7 495 133-92-44 — в рабочее время с 9:00 до 19:00
Остались вопросы? Нужна помощь?
Менеджеры компании с радостью ответят на ваши вопросы, произведут расчет стоимости услуг и подготовят индивидуальное коммерческое предложение.
Бесплатная консультация

