ADC смотрит на внешнюю оболочку сервера, не на его содержимое; но злоумышленник и ошибка релиза касаются именно содержимого.
Традиционная health-проверка работает с протокольного уровня: «порт открыт», «возвращает HTTP 200», возможно «содержимое страницы включает это слово». Эти ответы говорят, что сервер обслуживает, но не говорят, КАКИМ содержимым он обслуживает.
Современные проблемы живут именно в этом разрыве. Если злоумышленник прошёл WAAP и оставил на сервере webshell, health-проб продолжает говорить «сервер здоров». Если релиз вышел ошибочным, сервер отвечает старым binary, но для протокольного проба это снова 200 OK. Если оператор вручную изменил config-файл, отклонение от baseline проходит незаметно.
На масштабе кластера ситуация ещё хуже. На 9 из 10 серверов новая версия, на 1 нет; health-проб видит все здоровыми, запрос пользователя по невезению попадает на устаревший сервер. Или наоборот, на 1 сервере злоумышленник подбросил новый файл; остальной кластер чист, но с этого одного сервера трафик не выводится, потому что никто не смотрит.
ETM Целостность сервера и интеллект релизов заполняет этот разрыв: состояние файлов, каталогов, binary и config на сервере непрерывно отслеживается; изменения поступают в ADC и SOC как событие; решение routing выходит за пределы внешней оболочки.
Наш подход
Агент на сервере выполняет непрерывный аудит на уровне файлов; обнаруживает изменения, вживую привязывается к решению routing ADC и системе событий SOC.
Хеш файлов и каталогов измеряется непрерывно
Для выбранных критичных файлов (содержимое webroot, application binary, config-файлы, TLS-сертификаты) периодически вычисляется хеш. Для деревьев каталогов порождается совокупный хеш в стиле Merkle. Изменение мгновенно обнаруживается через сравнение хешей.
Новые, изменённые и удалённые файлы отражаются как событие
Добавление нового файла вне ожидаемого baseline, изменение существующего файла или удаление ожидаемого файла порождает мгновенное событие. Новый файл .aspx/.php/.jsp, подброшенный в webroot, помечается как подозрение на webshell.
Проверка согласованности по всему кластеру
Между серверами, обслуживающими один и тот же application service, выполняется сравнение хешей. Один сервер, выпадающий из ожидаемого распределения (drift или компрометация), отделяется от кластера; трафик направляется на согласованные серверы.
Решение routing и координация релизов привязываются вживую
При обнаружении изменения политика трафика ADC может автоматически среагировать: период warm-up, постепенный routing, временная изоляция. При обнаружении нового релиза трафик переходит плавно; при обнаружении неавторизованного изменения трафик отрезается.
Возможности
Целостность файлов и интеллект релизов — это не только безопасность, а часть механизма операционных решений.
Целостность содержимого webroot — каталоги vhost Microsoft IIS, Apache, Nginx
Для файлов содержимого (HTML, ASP, ASPX, PHP, JSP, JS, CSS, изображения), хранящихся в корнях vhost веб-сервера, вычисляются периодический хеш и целостность дерева каталогов. Оператор политикой определяет, какие каталоги отслеживать и какие расширения считать чувствительными. Неожиданное изменение отражается как мгновенное событие.
Обнаружение webshell — защита last-mile
Когда злоумышленник пытается пройти WAAP и разместить webshell на сервере, ETM мгновенно ловит новое исполняемое расширение (например, .aspx, .php, .jsp), подброшенное в webroot. Сервер может быть автоматически помещён на карантин, трафик отрезан, SOC получает тревогу. Это последний слой защиты ПОСЛЕ WAAP.
Обнаружение релиза и координация трафика
Изменение хеша application binary или артефакта интерпретируется как событие релиза. ADC ждёт это событие: пока показатели состояния не стабилизируются, на сервер направляется мало трафика, по завершении warm-up открывается полный трафик. Ручные шаги «вывести из load balancer, выкатить, вернуть обратно» автоматизируются.
Обнаружение configuration drift
Когда конфигурационные файлы, такие как Apache config, Nginx config, IIS application config, systemd unit, определения cron, отклоняются от baseline, порождается тревога. Оператор может вмешаться до неавторизованного изменения; регулярные изменения покрываются обновлением baseline.
Целостность системных binary и обнаружение tampering
Хеш критичных системных binary, файлов библиотек и вспомогательных инструментов сравнивается с baseline. Изменение binary в результате rootkit, supply-chain compromise или ручного вмешательства обнаруживается мгновенно; сервер помещается в изоляцию, остаётся открытым для форензики.
Отслеживание изменения прав (ACL) и владельца
Когда меняются владелец, права или записи ACL критичных файлов и каталогов, порождается событие. Неавторизованное повышение привилегий, смена владельца файла или открытие права записи в чувствительную конфигурацию становятся мгновенно видимыми.
Согласованность кластера — сравнение хешей на N серверах
Между серверами, обслуживающими один и тот же application service, выполняется сравнение baseline-хешей. Если 9 из 10 серверов совпадают, а 1 отличается, отличающийся подозревается в drift или компрометации. Может применяться автоматический карантин или изоляция с подтверждением оператора.
Maintenance window awareness — распознаёт плановое изменение
Когда оператор открывает окно обслуживания, изменения внутри этого окна не порождают тревогу; baseline обновляется согласно политике. Ожидаемое событие релиза не интерпретируется как «реальное изменение»; внезапное изменение запускает тревогу.
Триггер rollback — если после релиза обнаруживается деградация
Если после новой версии телеметрия ETM (время GC, error rate, частота restart) показывает деградацию, ETM связывает это с событием релиза. ADC routing может отдавать приоритет серверам с предыдущей версией; команда rollback автоматически информируется.
Поток в SIEM и комплаенс — цепочка записей событий изменения
Каждое изменение файла/конфигурации/binary записывается в аудиторскую запись; передаётся в SIEM. На каком сервере, когда, какой файл с какого хеша на какой хеш изменился — цепочка доказательств для аудита готова. Живая поддержка для GDPR Art 32 и отраслевых требований аудита.
Операционная глубина
Мониторинг целостности — это не только техническая функция, а живой слой управления корпоративными процессами релизов и безопасности.
Конфигурация охвата мониторинга
Какие каталоги отслеживать, какие расширения файлов считать чувствительными, какие файлы игнорировать (лог, кеш, временные файлы) — определяется политикой. Для веб-сервера, сервера приложений и сервера базы данных могут определяться разные профили.
Период хеширования и баланс производительности
Критичные файлы (системные binary, TLS cert) могут хешироваться в масштабе секунд; среднеприоритетные (config-файлы) — минут; низкоприоритетные (статическое содержимое) — почасовыми интервалами. Нагрузка disk IO держится под контролем.
Привязка к политике routing ADC
События целостности вживую привязываются к политике routing ADC. Правила политики, такие как «обнаружен новый файл + есть контекст атаки WAAP → изоляция», «обнаружен hash drift → низкий приоритет», «обнаружен релиз → warm-up», определяются оператором.
Интеграция с процессом релиза
CI/CD pipeline может сообщать ETM API о событии релиза; ETM интерпретирует это событие как ожидаемое изменение, запускает координацию routing вместо тревоги. По завершении релиза ETM подписывает новый baseline.
Интеграция с SOC
Высокоприоритетные события, такие как подозрение на webshell, binary tampering, cluster drift, передаются в SOC напрямую тревогой. Событие обогащается: какой сервер, какой файл, результат сравнения хешей, время последнего изменения, рекомендуемое действие.
Комплаенс и аудит
Каждое событие целостности заносится в аудиторскую запись. Когда аудитор спрашивает «на каком сервере какой файл изменился за последние 30 дней?», даётся живой ответ. Цепочка доказательств для PCI DSS, GDPR Art 32 и отраслевых требований аудита автоматизируется.
В каких сценариях используется
Обнаружение webshell: новый файл .aspx в webroot → автоматический карантин
Даже если WAAP не обнаружил атаку, новый исполняемый файл, размещённый в каталоге vhost IIS на сервере, мгновенно ловится ETM. Сервер автоматически выводится из кластера, трафик отрезается, SOC получает мгновенную тревогу; устройство остаётся открытым для форензики.
Координация релиза: обнаружен новый артефакт → warm-up → полный трафик
Когда команда DevOps выпускает новую версию, ETM обнаруживает изменение хеша application binary; ADC делает постепенный routing на сервер. Когда метрики состояния (CPU, время GC, error rate) остаются стабильными, открывается полный трафик. Ручные процессы «вывести из load balancer, выкатить, вернуть обратно» устраняются.
Cluster drift: 1 из 10 серверов с другим хешем → автоматическая изоляция
9 из 10 серверов в production-кластере совпадают с baseline-хешем; 1 показывает другой хеш. Устаревшая версия, ручное вмешательство или компрометация? ETM автоматически помещает этот сервер на карантин; оператор изучает причину. Запрос пользователя по невезению не попадает на неправильную версию.
Триггер rollback: после новой версии вырос error rate
После новой версии телеметрия ETM показывает, что время GC затянулось, error rate вырос и частота restart повысилась. ETM связывает это с событием релиза; ADC routing отдаёт приоритет серверам с хешем предыдущей версии. Команда rollback автоматически информируется; решение о релизе подкрепляется данными.
Binary tampering: системный binary изменился → изоляция
Когда хеш критичного системного binary на сервере отклоняется от baseline — подозрение на rootkit, supply-chain compromise или неавторизованное изменение — сервер отделяется от кластера, доступ в интернет отрезается, открытым остаётся только канал управления ETM. SOC выполняет удалённое изучение для форензики.
Частые вопросы
Влияет ли вычисление хеша на производительность сервера?
Какие каталоги мне отслеживать?
Не породит ли авторизованное изменение релиза false-positive?
Куда, кроме SIEM, могут передаваться события целостности?
Заменяет ли эта функция active health monitoring?
Сделайте файл на сервере частью решения routing
Посмотрим ETM Целостность сервера вживую на вашем собственном backend — запланируем установочную сессию, охватывающую определение baseline, привязку к ADC и поток в SIEM на пилотной группе серверов.