Антивирус и EDR на серверах, когда прежний вендор перестал обновляться

MAATRIX

Однажды консоль зарубежного EDR перестаёт показывать «онлайн» напротив части серверов, база сигнатур застывает на дате полугодовой давности, а тикет в поддержку вендора уходит в никуда — компания отреагировала на бизнес-решение вендора уйти с российского рынка или прекратить продление лицензий для российских юрлиц. Агент при этом обычно продолжает работать: значок в трее зелёный, служба запущена, память и процессор он ест как прежде — но реальной защиты за этим больше нет, а самое опасное в этой ситуации — то, что она незаметна снаружи. Разберём, чем это грозит, какие есть варианты замены и как перейти на новое решение так, чтобы между отключением старого и включением нового не было ни одного часа фактической беззащитности.

Почему нельзя оставить как есть

Первая и главная опасность — не отсутствие защиты как таковое, а иллюзия защиты. Команда видит зелёный статус агента, не включает дополнительный мониторинг, не пересматривает процессы реагирования — потому что формально «антивирус стоит». На практике устаревшая база сигнатур не ловит ничего, что появилось после последнего обновления, а именно последние месяцы — самое релевантное окно: свежие варианты шифровальщиков, новые эксплойты под недавно раскрытые CVE, актуальные версии майнеров, которые модифицируют сигнатуру специально под обход старых баз.

Для EDR-решений (в отличие от классического антивируса) проблема ещё глубже. EDR не столько сравнивает файлы с базой, сколько отправляет телеметрию поведения процессов в облако вендора и получает оттуда вердикты и обновления логики детектирования. Если облако недоступно или лицензия истекла, агент на сервере в лучшем случае откатывается к локальным эвристикам трёхлетней давности, в худшем — вовсе перестаёт присылать алерты, а разбираться в этом на сервере, где что-то уже пошло не так, будет некому: у вас нет ни свежих сигнатур, ни центра реагирования на стороне вендора.

Отдельный практический риск — сам агент как источник проблем. Легаси-агент с истёкшей лицензией иногда продолжает держать эксклюзивные блокировки на файлы, конфликтует с ядерными модулями при обновлении ОС или мешает установке нового защитного ПО, которое пытается занять те же хуки (файловый фильтр, сетевой драйвер). Оставлять его «просто так» — не нейтральное бездействие, а накопление технического долга.

Если сервер подпадает под требования 152-ФЗ по обработке персональных данных, входит в контур КИИ или ГИС — есть и регуляторный аспект: часть требований подразумевает сертифицированные средства защиты, а сертификат зарубежного продукта, переставшего поддерживаться в России, фактически не работает как формальная гарантия, даже если сама сертификация не отозвана.

Как проверить, что защита реально не работает

Прежде чем что-то менять, убедитесь фактами, а не ощущением, что старое решение действительно мертво — иногда проблема в сетевой доступности до серверов обновлений вендора, а не в уходе с рынка, и чинится проще, чем кажется.

Проверьте дату последнего обновления баз локально. Путь зависит от продукта, но общий подход — найти каталог с сигнатурами и посмотреть время изменения файлов:

find /opt/ /var/lib/ /etc/ -maxdepth 4 \
  \( -iname "*.cvd" -o -iname "*definitions*" -o -iname "*signatures*" \) \
  -printf '%T+ %p\n' 2>/dev/null | sort

Проверьте статус и логи самой службы:

systemctl status <имя-службы-агента>
journalctl -u <имя-службы-агента> --since "14 days ago" | grep -iE "update|license|error|fail"

Проверьте сетевую доступность до инфраструктуры обновлений — если DNS-имя вендора не резолвится или соединение обрывается по таймауту, это подтверждает, что канал обновлений закрыт, а не просто временно недоступен:

curl -v --max-time 10 https://<update-host-вендора>/

Если у продукта есть собственная CLI-утилита статуса (почти у всех коммерческих EDR она есть), вызовите её напрямую — там обычно виден статус лицензии и дата последнего check-in с облаком (<agent-cli> status, <agent-cli> license-info — конкретная команда своя у каждого продукта).

Отдельно проверьте признаки того, что сервер уже скомпрометирован, пока защита простаивала — если давно не было полной ручной проверки процессов и соединений, это стоит сделать параллельно с выбором замены. Разбор конкретных команд для такой проверки — в статье как проверить сервер на майнер и вирусы.

Карта вариантов замены

Развилка обычно сводится к двум трекам: сертифицированное российское решение из реестра отечественного ПО или open source стек, который вы собираете и поддерживаете сами. Есть и третий вариант — гибрид, когда open source закрывает базовый мониторинг, а сертифицированный продукт ставится точечно только там, где это требует регулятор.

Если сервер попадает под требования, где сертификация обязательна (КИИ, ГИС, определённые категории персональных данных) — начинайте с реестра отечественного ПО и уточняйте у регулятора или интегратора нужный класс сертификации; это не тема для общих рекомендаций из статьи. Для остальных серверов — веб-приложений, баз данных, API-бэкендов без прямых регуляторных требований — open source стек часто даёт больше контроля и меньше риска зависимости от одной компании, но требует, чтобы кто-то в команде реально умел его администрировать, а не просто установил и забыл.

Что проверить при выборе конкретного продукта

Совместимость с ОС и ядром — проверяйте буквально, а не по общему описанию «поддерживает Linux». Уточните точный список дистрибутивов и версий ядра, особенно если у вас нестандартное или урезанное ядро (контейнерные хосты, кастомные сборки). Агенты с ядерными модулями более хрупкие к обновлениям ядра, чем агенты на eBPF или работающие в user space — узнайте, какой подход использует продукт.

Нагрузка на систему — прогоняйте не по заявленным вендором цифрам, а по собственному тесту на сервере с похожей нагрузкой: снимите метрики CPU, RAM и дисковой очереди до установки, поставьте агент, повторите замер под той же нагрузкой в течение нескольких дней. Вендорские бенчмарки почти всегда занижены относительно вашей реальной нагрузки.

Качество детектирования — самая сложная часть для самостоятельной оценки, настоящий тест на реальном малваре на проде не проводят. Разумный минимум: проверьте базовую работоспособность сканера тестовым EICAR-файлом (стандартный безопасный тестовый файл, который обязан детектировать любой антивирус — это тест того, что сканер вообще работает, а не тест качества); поищите независимые результаты сравнительных тестов, если продукт в них участвует; уточните политику обновления сигнатур — автоматически или вручную, есть ли offline-режим; поспрашивайте про историю ложных срабатываний — продукт, блокирующий легитимные процессы на проде, риск не меньше пропущенной угрозы.

Интеграция и телеметрия — сможет ли решение слать события в вашу систему логирования или SIEM, есть ли API, и где физически хранится телеметрия (для части компаний принципиально, чтобы данные не покидали Россию).

Риск повторения истории — узнайте модель лицензирования и договорные гарантии на случай повторного ухода вендора: возможность оффлайн-работы агента, экспорт правил в открытом формате, консоль управления не только в облаке вендора.

Собираем open source стек для сервера без вендора

Если решили собирать защиту без коммерческого продукта, вот рабочий набор компонентов, закрывающих разные слои — ни один из них не заменяет остальные, речь именно про стек:

ClamAV — файловый антивирусный движок с базой сигнатур, оправдан там, где сервер реально принимает и раздаёт файлы от посторонних (файлообменник, вложения почты, загрузки пользователей). Для веб-бэкенда без транзита файлов эта часть может быть избыточной — подробнее в статье миф про обязательный антивирус на сервере. Автообновление баз:

apt install clamav clamav-daemon
freshclam
systemctl enable --now clamav-freshclam clamav-daemon

Wazuh (форк OSSEC) — HIDS-платформа с централизованным менеджером: мониторинг целостности файлов, анализ логов, детектирование по правилам, агенты под Linux и Windows. Закрывает большую часть функций, за которые раньше отвечал EDR. Фрагмент конфигурации мониторинга целостности файлов в /var/ossec/etc/ossec.conf:

<syscheck>
  <directories check_all="yes" realtime="yes">/etc,/bin,/sbin,/usr/bin,/usr/sbin</directories>
  <directories check_all="yes">/var/www</directories>
  <frequency>43200</frequency>
</syscheck>

auditd — аудит системных вызовов на уровне ядра, полезен для расследования инцидентов постфактум: кто и когда менял конфиги, запускал бинарники из нетипичных мест, повышал привилегии. Пример правила слежения за изменением важных файлов:

auditctl -w /etc/passwd -p wa -k passwd_changes
auditctl -w /etc/shadow -p wa -k shadow_changes

AIDE — построение и периодическая сверка контрольных сумм файловой системы, дешёвый способ заметить неожиданные изменения бинарников и конфигов.

rkhunter / chkrootkit — периодическая проверка на руткиты и известные бэкдоры, в cron:

0 4 * * * /usr/bin/rkhunter --check --skip-keypress --report-warnings-only

CrowdSec или fail2ban — поведенческая блокировка по паттернам атак (перебор паролей, сканирование, известные вредоносные IP), закрывает часть того, что раньше делал сетевой модуль EDR.

Falco — если сервер гоняет контейнеры, стоит рассмотреть Falco для рантайм-мониторинга контейнерной среды: он ловит аномальное поведение процессов внутри контейнеров, чего файловый антивирус на хосте не видит.

Ключевая ошибка при сборке такого стека — расставить компоненты и не свести их в одно место. Без централизации логов и алертов (менеджер Wazuh, ELK или другая система агрегации) вы получаете россыпь разрозненных источников, за которыми никто не следит в реальном времени, — та же иллюзия защиты, с которой вы начали, только собранная своими руками.

План миграции без окна незащищённости

Главное правило миграции защитного ПО — никогда не выключать старое до подтверждённой работоспособности нового. Отдельно от вопроса выбора решения, вот последовательность, которая исключает разрыв:

1. Инвентаризация и приоритизация. Составьте список серверов со старым агентом, отсортируйте по экспозиции — сначала интернет-facing, затем внутренние, затем изолированные в приватных сетях.
2. Пилот на некритичном сервере. Установите замену на 1-2 тестовых серверах, проверьте совместимость с реальным софтом, а не с чистой ОС — конфликты чаще всплывают на прикладном уровне (например, файловый монитор реального времени конфликтует с временными файлами приложения).
3. Параллельный запуск. Ставьте новое решение рядом со старым, не удаляя старое сразу — даже полумёртвый агент со старыми сигнатурами на что-то реагирует. Следите за конфликтами по ресурсам: два файловых сканера одновременно заметно повышают дисковую нагрузку и I/O wait, это стоит замерить на пилоте.
4. Валидация детектирования. Тест EICAR-файлом для файлового сканера, проверка, что события доходят до централизованной консоли или SIEM, тестовый алерт по заведомо подозрительному, но безопасному действию (например, попытка чтения /etc/shadow нестандартным процессом).
5. Выдержка перед отключением старого. Дайте новому решению поработать в проде несколько суток стабильно, без ложных срабатываний и пропусков событий — и только после этого деинсталлируйте старый агент.
6. Поэтапный роллаут остальных серверов. Идите по списку из шага 1 группами, с тем же окном параллельной работы на каждой — чтобы неожиданная проблема с новым решением не осталась незамеченной сразу на всей инфраструктуре.
7. План отката наготове. Держите процедуру быстрого отката (переустановка старого агента, если лицензия ещё действует, или усиление компенсирующих мер — firewall, fail2ban, ручной мониторинг) на случай нестабильности нового решения.
8. Обновление документации. После роллаута обновите runbook реагирования на инциденты и контакты дежурных — команда должна знать, куда смотреть при подозрении на компрометацию.

Логика поэтапного переноса с окном параллельной работы и точками валидации на каждом шаге в целом похожа на подход к миграции серверов вообще — если раньше не составляли формальный план такого рода, пригодится общий разбор в статье как составить план миграции на новый сервер.

Частые вопросы