Сканер вредоносных программ Imunify360: функции, обновления и ограничения

Imunify360 как многоуровневая система безопасности хостинга

Imunify360 — это не просто программа для поиска вирусов, а решение для обеспечения безопасности Linux с несколькими уровнями защиты. Это Сканер вредоносных программ проверяет файлы на наличие известного или подозрительного содержимого. Брандмауэр, а также системы IDS/IPS отслеживают и ограничивают подозрительную сетевую активность, в то время как брандмауэр веб-приложений (WAF) оценивает HTTP-запросы перед их передачей в приложение на основе набора правил. Проверки репутации предоставляют дополнительные сигналы для классификации источников и действий.

Это разделение имеет решающее значение для хостинг-провайдеров, поскольку эти уровни срабатывают на разных этапах. HTTP-атака, направленная на известную уязвимость, может быть отражена WAF ещё до того, как WordPress, Joomla или Magento обработают запрос. В то же время вредоносная загрузка файла становится актуальной на этапе проверки файлов. Если запускается PHP-веб-шелл, то Проактивная оборона реагировать на подозрительное поведение во время выполнения PHP; однако это не является ретроспективным анализом всего инцидента.

Модель называется Многоуровневая защита: Один-единственный пробел или упущенная находка не должны сами по себе определять безопасность учетной записи клиента. Система обнаружения вредоносного ПО может выявить уже присутствующий вредоносный код, но она не всегда предотвращает исходную уязвимость. Точно так же WAF может заблокировать атаку, но не удалить уже сохраненные файлы или исправленное содержимое базы данных.

Ни один из этих уровней не заменяет основные задачи по обслуживанию сайта. Ядро CMS, плагины, темы и расширения нуждаются в своевременных обновлениях безопасности; ограничительные права доступа к файлам и раздельные учетные данные позволяют свести к минимуму последствия взлома учетной записи. Проверенные резервные копии позволяют восстановить систему, а в случае обнаружения инцидента только анализ инцидента позволяет выяснить путь проникновения, масштаб и возможную стойкость угрозы. Imunify360 предоставляет для этого сигналы защиты и обнаружения, но не является полным доказательством безопасности окружающей среды.

Различия между Imunify360, ImunifyAV и ImunifyAV+

Списки функций должны быть соотнесены с конкретным используемым продуктом. Imunify360 представляет собой более комплексное решение для обеспечения безопасности серверов; ImunifyAV и ImunifyAV+ — это отдельные продукты, предоставляющие функции защиты от вредоносных программ. Те, кто приравнивает эти названия, могут, например, перепутать имеющуюся функцию сканирования с брандмауэром, защитой в режиме реального времени или защитой PHP и на этом основании сформировать неверные ожидания в отношении управляемого сервера или сервера для реселлеров.

Особенно важно отметить, что, согласно документации производителя, функции сканирования в режиме реального времени и «Проактивной защиты» в ImunifyAV и ImunifyAV+ доступны не так, как в Imunify360. Сканирование в режиме реального времени позволяет оперативно обнаруживать новые или измененные файлы; функция «Проактивная защита» рассматривает выполнение PHP-кода как отдельную точку вмешательства. Обе функции дополняют плановое сканирование файлов, но не делают его излишним и не заменяют техническое обслуживание приложений.

Расширение для WordPress под названием «Imunify Security Plugin» также не является самостоятельной заменой серверного агента. Оно управляется агентом Imunify и не распространяется через каталог WordPress.org. В админке WordPress оно может предоставлять доступ к информации о сканировании и защите; однако то, какие функции будут отображаться, зависит от используемого продукта Imunify и необходимых версий агента и расширения.

Поэтому для ведения эксплуатационной документации рекомендуется провести четкий анализ текущего состояния: вариант продукта, установленная версия агента, панель хостинга и активированные модули защиты должны быть включены в документацию об изменениях. Администратор WordPress сможет тогда правильно интерпретировать сообщения в бэкенде, не предполагая, что плагин контролирует правила брандмауэра или защищает другие учетные записи пользователей на сервере. Архитектура безопасности на стороне сервера по-прежнему играет определяющую роль.

Что на самом деле означают обнаружения вредоносного ПО

Фоновые и сканирования по запросу предоставляют результаты обнаружения в интерфейсе администрирования с указанием времени, пути к файлу и причины обнаружения. Эти данные служат отправной точкой для сортировки: путь позволяет соотнести обнаруженный файл с учетной записью клиента и приложением, а время помогает сопоставить его с развертываниями, загрузками или подозрительными записями в журналах. Однако они не заменяют проверку конкретного содержимого и пути его появления.

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

Обнаружение угрозы не доказывает, что все файлы в учетной записи скомпрометированы, и не позволяет автоматически определить масштаб взлома. И наоборот, сканирование без обнаружения угроз не гарантирует полной безопасности: новые эксплойты, замаскированный код или механизмы персистентности за пределами просканированной области могут потребовать дополнительного расследования. Кроме того, отсутствие обнаружения со стороны WAF или сканера не является доказательством того, что атака не имела места.

Если, например, сканер обнаруживает файл PHP внутри плагина WordPress, администратору следует сначала сохранить историю обнаружений и путь к файлу, а затем сравнить файл с версией от проверенного производителя или с проверенной резервной копией. После этого необходимо проверить версию плагина, администраторов, учетные данные и возможные бэкдоры. Для организационной интеграции нескольких проектов WordPress полезны рекомендации по Требования к безопасности при хостинге блогов, однако они не заменяют судебную экспертизу, проводимую в конкретном деле.

Методы сканирования, требования и дальность действия

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

Der Сканирование в режиме реального времени расширяет эту проверку на определенные каналы передачи данных. Для сканирования загрузок по протоколам HTTP и HTTPS в документации в качестве предварительного условия указан ModSecurity; для загрузок по FTP требуется Pure-FTPd. Поэтому необходимо проверить для каждого сервера, активны ли эти службы и правильно ли они настроены. Эта функция не включается автоматически для каждого канала загрузки только путем установки агента.

В сферу сканирования входит также проверка архивов. Согласно документации, с версии Imunify360 6.2 ZIP-архивы сканируются по умолчанию. Это особенно полезно в случае пакетов плагинов, архивов резервных копий или загруженных расширений, однако не дает никакой информации о том, будет ли приложение впоследствии распаковывать архив небезопасным способом или является ли его содержимое допустимым с технической точки зрения.

Der Сканер базы данных вредоносных программ (MDS) дополняет сканирование файлов в тех случаях, когда вредоносный код был внедрен, например, в записи, настройки или содержимое виджетов системы управления контентом (CMS). Документированная поддержка ограничивается WordPress, Joomla и Magento 2. В отношении собственных приложений, иных структур баз данных или других систем интернет-магазинов не следует предполагать полного охвата баз данных.

Планирование запусков RapidScan и проверок баз данных

RapidScan изменяет процесс повторных проверок, но не саму суть сканирования на наличие вредоносного ПО. Для этого Imunify360 сохраняет метаданные файлов и хэши локально и сверяет хэши с облачной базой данных. При последующих прогонах локальный анализ можно сосредоточить на файлах, которые были изменены или пока неизвестны.

При этом первый прогон сначала требует обычной проверки файлового массива. Производитель указывает, что последующие сканирования могут выполняться в 5–20 раз быстрее. Этот диапазон является ориентировочным указанием производителя, зависящим от конкретной ситуации, а не гарантированным показателем для каждого сервера: на результат влияют размер и состав файлового хранилища, частота изменений, доступная производительность ввода-вывода и условия сети.

С точки зрения планирования это означает: сервер с большим количеством неизменённых веб-файлов может быть RapidScan приносит больше пользы, чем аккаунт, который постоянно генерирует загрузки, кэш-данные или файлы журналов. Поэтому не ограничивайтесь измерением общего времени выполнения, а перед внесением изменений зафиксируйте затронутые пути, объем файлов и время ожидания ввода-вывода. Так можно будет определять окна сканирования и исключения на основе конкретных причин, а не предположений.

В случае поддельных записей в WordPress или скриптов, внедренных в настройки, простого сканирования файлов может оказаться недостаточно. MDS может сначала работать с поддерживаемыми базами данных WordPress в неинтервенционном режиме --scan проверить. Этот шаг не приводит к изменению данных и создает основу для оценки мест обнаружения, последствий для веб-сайта и возможности восстановления до принятия решения.

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

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

Интеграция с WordPress и контролируемые обновления WAF

Плагин для WordPress под названием «Imunify Security Plugin» управляется агентом Imunify на сервере и не распространяется через каталог WordPress.org. Оно позволяет администраторам WordPress просматривать информацию о состоянии системы и, в зависимости от используемого продукта Imunify, дополнительные функции безопасности в админ-панели. Таким образом, оно представляет собой интерфейс и дополнение, но не заменяет механизмы сканирования и защиты на стороне сервера.

В документации в качестве базовой версии указана как минимум Imunify360 8.4.1 на стороне сервера. Такие функции, как интеграция с WAF или управление ботами с помощью ИИ, дорабатываются отдельно и привязаны к конкретным версиям агентов и плагинов. Поэтому перед развертыванием проверьте конкретную комбинацию версий, а не делайте выводы о наличии той или иной функции защиты, основываясь лишь на самом факте наличия плагина.

WAF также следует эксплуатировать как отдельный уровень. Начиная с imunify360-firewall 8.6.0 Существует задокументированная процедура, позволяющая отключить автоматическое обновление правил ModSecurity, отобразить список доступных версий правил и выбрать конкретную версию. Это дает возможность операторам хостинга контролировать сроки внесения изменений в правила и, при необходимости, переходить на проверенную версию.

Рациональный подход заключается в том, чтобы сначала внедрить новую версию правила на тестовом сервере с типичными страницами WordPress, акциями в интернет-магазине и загруженными файлами. Только после того, как не будет обнаружено никаких значимых ложных блокировок или проблем с функциональностью, следует поэтапный перенос в производственную среду. Управление версиями касается при этом правил ModSecurity, а не сигнатур вредоносного ПО в целом, всего агента или других компонентов Imunify.

Контролируемые Обновления правил WAF Они не позволяют избежать всех сбоев, но устанавливают четкие полномочия: кто проверяет изменения, какие приложения используются в качестве тестовых случаев и когда следует откатывать изменения? Эти вопросы должны быть включены в рабочий процесс. По-прежнему необходимы своевременные обновления CMS и расширений, ограниченные права доступа, а также проверенные резервные копии, поскольку ни один WAF не устраняет известные уязвимости в установленном программном обеспечении.

Безопасная проверка и устранение обнаруженного вредоносного ПО

Обнаружение вредоносного ПО — это процедура проверки, а не автоматическая команда на удаление. Сначала проверьте в интерфейсе историю обнаружений, время, полный путь и причину обнаружения. Эта информация поможет определить, относится ли файл к плагину, теме, каталогу загрузок или индивидуально разработанному приложению, а также выяснить, встречалось ли такое же обнаружение ранее.

Сравните подозрительный файл PHP с надежным исходным кодом от производителя той же версии или с проверенной резервной копией. В случае стандартных компонентов полная перепроверка, как правило, дает более достоверные результаты, чем изолированный анализ отдельных, возможно замаскированных строк кода. Перед любым изменением сохраните обнаруженный файл и соответствующие протоколы, чтобы впоследствии можно было проследить путь проникновения.

Собственно анализ причин выходит за рамки указанного пути: обновите затронутые версии CMS, плагинов и тем, проверьте учетные записи пользователей и, при наличии обоснованных подозрений, смените учетные данные. Кроме того, проведите поиск дополнительных веб-шеллов, неизвестных администраторов и подозрительных запланированных задач. Удаление одного файла не исключает того, что злоумышленник оставил второй канал доступа.

Проверка базы данных требует особой осторожности, поскольку действия по очистке могут привести к изменению контента или настроек. Сканирование — это, в первую очередь, проверка; для очистки или восстановления необходимы доступная резервная копия, одобрение специалиста и план действий на случай сбоя. Сканер базы данных вредоносных программ поддерживает только задокументированные случаи для WordPress, Joomla и Magento 2 и не является универсальной проверкой произвольных схем приложений.

Если обнаружен Adminer, это может означать, что инструмент установлен законно, однако его обнаружение вполне объяснимо, учитывая набор функций, которые могут быть использованы не по назначению. Вместо того чтобы глобально отключать категорию обнаружения, проверьте необходимость, целостность и защиту доступа к конкретному файлу. Если исключение неизбежно, то исключение по узкому пути лучше устраняет уязвимость, чем отключение обнаружения на уровне учетной записи или всего сервера.

Анализ нагрузки, ложных срабатываний и стойкости

Если загрузка ЦП или время ожидания ввода-вывода увеличиваются, исключение не должно быть первой мерой. Сначала необходимо собрать данные о событиях сканирования, затронутых путях, частоте изменений, активных процессах и периоде возникновения нагрузки. Только временная корреляция покажет, может ли сканирование в режиме реального времени быть причиной проблемы или же ресурсы занимают, например, резервное копирование, импорт, некорректно работающие приложения или другая служба.

Часто описываемые файлы журналов могут неоднократно вызывать сканирование и, таким образом, стать возможной причиной дополнительной нагрузки. В одном из задокументированных обращений в службу поддержки рассматривается именно этот паттерн для файлов журналов WordPress, однако он не подтверждает существование общего правила «причина-следствие» для каждого перегруженного сервера. Поэтому следует конкретно проверять пути к файлам и частоту записи, а не в качестве меры предосторожности исключать целые каталоги клиентов из Сканер вредоносных программ исключить.

Исключения должны иметь четко очерченную цель, ответственное лицо и подвергаться регулярной проверке. Для законно созданного, очень активного маршрута после анализа может быть оправдано ограниченное исключение. Однако оно не должно незаметно распространяться на каталоги загрузки или приложений, в которых злоумышленники могут размещать или изменять файлы.

Повторные находки после очистки свидетельствуют о необходимости проведения исследования на Настойчивость а не просто удалить их. Помимо файлов и баз данных, проверке подлежат задания Cron, неизвестные учетные записи администраторов, учетные данные, журналы веб-серверов и запущенные процессы. В частности, запланированные задания могут повторно загрузить вредоносный код или заменить удаленную веб-оболочку.

Начиная с версии 6.10, Imunify360 документирует сканирование системных и пользовательских файлов crontab как экспериментальную функцию, отключенную по умолчанию. Это расширяет возможности проверки, но не заменяет ручную оценку подозрительных заданий. Перед активацией необходимо проверить нагрузку, совместимость и влияние на собственный рабочий процесс; это не означает, что следует активировать эту функцию повсеместно для всех хостинговых сред.

Принятие решений по эксплуатации, миграции и внедрению

Для небольшого сервера с небольшим количеством веб-сайтов может быть достаточно запланированных фоновых сканирований, понятных уведомлений и ручного утверждения мер. В средах реселлерского и виртуального хостинга, напротив, требования к Процедуры эскалации: Кто оценивает обнаруженные проблемы, кто связывается с клиентами, кто имеет право делать исключения и при каких условиях учетная запись подвергается ограничениям? Четко зафиксированные полномочия позволяют избежать ситуаций, когда корректирующие меры или уязвимости в системе безопасности остаются без внимания на стыке служб поддержки и администрирования.

Защита в режиме реального времени, интервалы сканирования и уведомления должны соответствовать скорости изменений и ресурсам сервера. Многие независимые учетные записи клиентов выигрывают от применения последовательных процедур и понятного ведения журналов. Отдельный проект, критически важный для бизнеса, часто требует дополнительно согласованного процесса обслуживания и утверждения. При этом по-прежнему необходимы базовые меры защиты, такие как обновления, минимальные права доступа и проверенные резервные копии.Критерии выбора подходящего предложения по веб-хостингу

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

Контролируемый Развернуть Начинается с определения версии и запуска репрезентативного тестового или пилотного сервера. После обновления необходимо проверить состояние агентов, управление пакетами, подозрительные записи в журналах и функции, важные для клиентов. Только при отсутствии проблем следует приступать к поэтапному развертыванию. Это не устраняет все риски, но позволяет раньше выявить отклонения и облегчает принятие целенаправленных мер.

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

Конкретная проблема с обновлением в imunify-common Согласно заявлению производителя, проблема в версии 1.3.21-1 на CloudLinux 8 с базой данных RPM, основанной на Berkeley DB, была устранена начиная с версии 1.3.22-2. Из этого не следует общего аргумента против обновлений. Однако это подчеркивает, почему окна обслуживания, документированные версии и последующие проверки системы управления пакетами являются неотъемлемой частью профессионального процесса обновления.