Как проверить сайт на MODX и не уничтожить улики

Если на сайте появились чужие страницы, редиректы или неизвестные PHP-файлы, сначала сохраните состояние файлов и базы, затем проверьте логи, целостность MODX и дополнений. Отдельный признак ещё не доказывает взлом. Ниже — порядок проверки, который помогает не затереть следы и не принять обычную работу CMS за атаку.

1. Сначала сохраните состояние сайта

Если вы подозреваете компрометацию, не начинайте с удаления файлов и обновления ядра. Сохраните копию файлов сайта и отдельный дамп базы данных; по возможности разместите копии вне веб-каталога и проверьте, что архив читается. Запишите время создания копии, версию MODX и то, что именно вызвало подозрение. Это не превращает резервную копию в доказательство чистоты: она фиксирует состояние, чтобы сравнивать и при необходимости разбирать его позже. Перед обновлением MODX резервная копия особенно нужна — это прямо указано в инструкции проекта. В ней же советуют учитывать совместимость дополнений: старое дополнение после обновления ядра способно привести к ошибкам и закрыть доступ в Manager. Проверку безопасности сайта лучше поручить специалисту, если нет отдельной копии и безопасной среды для анализа.

Если сайт меняет содержимое прямо сейчас, ограничьте доступ согласованным способом на уровне веб-сервера или панели хостинга, сохранив доступ администраторам и не забыв про проверку конфигурации. Не копируйте вслепую фрагмент return 403: одна эта директива не означает «разрешить мой адрес и запретить всем остальным». В nginx для списка разрешённых адресов применяют правила allow и deny; порядок и контекст важны. Ошибка в виртуальном хосте может закрыть сайт вместе с Manager. Сначала проверьте конфигурацию штатной проверкой nginx, затем применяйте её в согласованное окно. Если изоляция недоступна, зафиксируйте это и переходите к сохранению данных и сбору журналов, не обещая себе, что один запрет остановил уже получивший доступ процесс. Для разбора используйте отдельное место хранения с ограниченным доступом: архив может содержать пароли, персональные данные и конфигурацию. Не отправляйте его в публичный сканер и не оставляйте копию в корне сайта. Если подозреваете доступ к базе, зафиксируйте и её состояние, а учётные записи меняйте уже после сохранения данных. Так у расследования будет исходная точка, а у владельца — рабочий путь к восстановлению.

• Сохранить копию файлов и отдельный дамп БД
• Зафиксировать время, версии и симптомы
• Проверить доступность копии до любых изменений

2. Прочитайте логи, но не объявляйте каждый запрос взломом

Соберите журналы веб-сервера за период перед первым симптомом и после него. Ищите время, URI, HTTP-метод и результат запроса: например, повторные обращения к неизвестному PHP-файлу, всплеск запросов к Manager, неожиданную загрузку файла или последовательность ошибок рядом с изменением сайта. Если на сервере доступны журналы PHP и MODX, сохраните и их. В базе знаний есть практический ориентир: при замедлении MODX сначала проверяют логи на ошибки, а перед обновлением — тоже просматривают журналы. Это полезная очередность, но сами ошибки не доказывают атаку. Сопоставляйте запись с реальным файлом, изменением в админке и временем входа. Ищите закономерность, а не «подозрительный IP» в вакууме.

Пути /setup/ и /manager/ сами по себе не говорят о взломе. После установки или обновления MODX использует каталог setup; официальная инструкция требует удалить его после завершения процедуры. Поэтому обращение к оставшемуся setup/ может указывать на ошибку обслуживания и требует проверки, но не доказывает успешное проникновение. Обычные сканеры тоже могут запрашивать типовые адреса и получать 404. Сверьте статус и время запроса с журналом PHP, изменениями файлов и событиями Manager. Не делайте вывод «404 значит бэкдор» и не блокируйте все запросы к Manager без понимания, кто использует административную часть. Для инцидента важна связка событий, а не одно слово в URL. Проверьте, включена ли ротация журналов и не перекрывает ли она нужный период. Если записи уже удалены, не делайте вид, что пустой лог оправдывает сайт: его просто недостаточно для вывода. Зафиксируйте временной диапазон, источник каждого журнала и ограничения доступа к нему. Если приложение и веб-сервер показывают разное время, запишите смещение — иначе последовательность событий получится убедительной, но неправильной.

• Скопировать логи до ротации
• Сверить запросы с временем изменения файлов
• Разделять сканирование, ошибку и подтверждённый доступ

3. Ищите изменения в файлах и коде

Сравните дерево сайта с дистрибутивом того же релиза и с известной чистой копией проекта. Отдельно проверьте каталоги, куда веб-процесс может записывать файлы, пользовательские загрузки, шаблоны, плагины и конфигурацию. Неизвестный файл — повод выяснить, кто и когда его создал, а не готовый диагноз. У MODX бывают собственные и добавленные разработчиком файлы; удаление «лишнего» без сравнения может сломать сайт и стереть следы. Зафиксируйте путь, размер, время изменения и контрольную сумму подозрительного объекта, если умеете это сделать. Сверка должна учитывать установленные дополнения и локальные правки. После этого проверяйте содержимое и происхождение, не запускайте найденный PHP-код ради любопытства.

Поиск eval и base64_decode полезен как фильтр для ручной проверки, но не как автоматический детектор заражения. eval исполняет переданную строку как PHP-код и потому требует особого внимания; base64_decode лишь декодирует данные и встречается в легитимном коде. Совместное присутствие, обфускация, удалённое получение данных или выполнение кода — сильнее как сигнал, чем отдельное совпадение имени функции. Просмотрите контекст вызова и сравните файл с официальной сборкой или пакетом дополнения. Команды вроде grep -R могут показать совпадения, но результат зависит от путей и исключений; на живом сайте не запускайте неизвестные скрипты и не заменяйте файлы только потому, что строка выглядит непривычно. Отдельный разбор PHP-шеллов и логов помогает продолжить анализ, если совпадения подтвердились. Уточните владельца файла и учётную запись, от которой работает PHP. Это помогает понять, мог ли веб-процесс записать объект в конкретный каталог. Не меняйте владельца и права ради «чистоты» до фиксации исходных значений: такая правка уничтожает часть контекста. Сверку делайте на копии, а найденный фрагмент рассматривайте вместе с соседними строками, точкой входа и тем, откуда в него поступают данные.

• Сверить файлы с дистрибутивом той же версии
• Проверить контекст опасных вызовов
• Зафиксировать подозрительные файлы до карантина

4. Сверьте версии ядра, дополнений и конфигурацию

Уточните точную версию MODX и PHP, перечень установленных дополнений и откуда они получены. Затем проверьте доступные исправления и совместимость по документации соответствующего релиза. База знаний отдельно фиксирует три практичных пункта: проверять версии ядра, дополнений и пользовательского кода; обновлять дополнения ради исправлений; перед обновлением смотреть логи и делать резервную копию. Это хорошая последовательность, но «старое» само по себе не доказывает эксплуатацию. Сначала зафиксируйте текущее состояние, выясните, какие версии поддерживает конкретный сайт, и только после этого планируйте обновление. Руководство MODX предупреждает, что устаревшие Extras могут вызвать фатальные ошибки после обновления ядра. Обновление наугад — быстрый способ получить второй инцидент поверх первого.

Проверьте права на файлы и каталоги, конфигурацию веб-сервера, доступность core/ из браузера и состояние setup/. В рекомендациях MODX по укреплению сайта среди приоритетов названы закрытие публичного доступа к core/ и Manager, обновление сервера, ядра и дополнений, а также резервная копия до изменений. Если видите неизвестное правило в .htaccess или nginx, сравните его с конфигурацией из репозитория или резервной копией и проверьте, какой URL оно меняет. Не удаляйте строку без фиксации: правило могло быть добавлено при штатном переносе или настройке URL. У MODX есть разные варианты установки и пути каталогов могут настраиваться, поэтому проверяйте реальную конфигурацию конкретного проекта, а не только имена по умолчанию. Проверьте, не лежат ли резервные архивы, дампы или временные файлы внутри публичного каталога. Это отдельный риск даже тогда, когда бэкдор не обнаружен. Сверьте права записи с назначением каталога: загрузки не должны давать повод разрешать выполнение произвольного PHP. Конкретные ограничения зависят от схемы сайта и веб-сервера, поэтому берите конфигурацию из документации своей версии и сначала испытывайте её на копии.

• Зафиксировать версии MODX, PHP и Extras
• Проверить права и публичную доступность core/
• Сначала копия и проверка совместимости, потом обновление

5. Проверьте внешние признаки и выберите план восстановления

Посмотрите страницы сайта снаружи: неожиданные редиректы, незнакомый контент и выдача поисковика могут показать проблему, которую не видно в Manager. Запрос site:домен годится как грубая подсказка, но выдача не является полным списком страниц и обновляется не мгновенно. Для Google используйте отчёт о проблемах безопасности в Search Console и проверку Safe Browsing; наличие предупреждения требует расследования, отсутствие предупреждения не подтверждает чистоту. По документации Google, после очистки владелец может запросить повторную проверку в Search Console. Сохраните подозрительные URL и скриншоты, но проверьте ответ сервера и исходный код страницы: поисковый фрагмент может быть устаревшим.

Если подтвердились чужой код, вход через Manager или изменение конфигурации, составьте временную линию: первый подозрительный запрос, изменение файла, обновление или вход пользователя. Сохраните копии и журналы, смените учётные данные с чистого устройства, устраните исходную уязвимость и восстановите файлы из проверенного источника. Затем обновите MODX и Extras по плану совместимости, проверьте права и повторно осмотрите сайт. В статье о реагировании на взлом сервера есть общий порядок дальнейшей эскалации. Если признаков мало, оставьте наблюдение и контроль целостности вместо поспешного отката. «За 15 минут» можно успеть собрать первые сигналы; подтвердить отсутствие бэкдора за такое время нельзя. Проверка — это начало расследования, не магический сертификат чистоты. После восстановления проверьте главную страницу, формы, вход в Manager и несколько ключевых сценариев сайта, а затем повторно сравните файлы и журналы. Зафиксируйте, какие учётные данные меняли, какие пакеты обновили и какие симптомы исчезли. Если предупреждение поисковой системы сохраняется, действуйте через её официальный отчёт. Такой контроль не гарантирует, что похожий инцидент невозможен, зато позволяет обнаружить повторное изменение раньше и не полагаться на память.

• Сохранить подозрительные URL и скриншоты
• Восстановление — только из проверенного источника
• После очистки проверить сайт и запросить пересмотр предупреждения

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