Как восстановить сайт MODX после взлома компонента

Если сайт на MODX перенаправляет посетителей, показывает чужие страницы или меняет файлы, отключения плагина мало: следы доступа могут остаться в других файлах, базе и учетных записях. Я покажу, как сохранить состояние, проверить дополнения и восстановить сайт без обещаний «почистить за час».

Когда плагин MODX действительно становится точкой входа

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

У MODX есть конкретный исторический пример, который важно не превращать в страшилку про любой старый плагин. В июле 2018 года разработчики сообщили о двух критических уязвимостях в MODX Revolution 2.6.4 и более ранних версиях: одна позволяла удалённо выполнить скрипт, другая — удалить файлы или каталоги. Вендор выпустил исправление в версии 2.6.5. Отдельно служба поддержки MODX описывает широкую волну атак того месяца на сайты с версией 2.6.4 и ниже и с некоторыми установленными Extras. Это не доказывает, что всякий взлом MODX начинается с галереи или что старый компонент автоматически даёт полный контроль. Здесь нужны конкретные данные конкретного сайта.

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

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

Что проверить, если сайт MODX ведёт себя странно

Перенаправления на посторонние страницы, новые публикации, неизвестные администраторы, предупреждение браузера или поисковой системы — сигналы для проверки. Ни один из них по отдельности не называет причину. Например, редирект может находиться в коде сайта, настройках веб-сервера, базе данных или внешнем сервисе; предупреждение браузера может относиться к уже устранённой проблеме или к отдельной странице. Я записываю точное время, адреса страниц и действия пользователя, при которых проявился симптом. Если сайт доступен клиентам, сначала оцениваю риск: временно ограничиваю публичную выдачу или закрываю подозрительный функционал, сохраняя возможность восстановить работу.

Затем я составляю инвентаризацию: версию MODX, установленные Extras и плагины, их версии, источник установки, дату последнего обновления, список учётных записей Manager и недавно изменённые файлы. Важна не только папка дополнения. Проверяются конфигурация, шаблоны, сниппеты, плагины, медиафайлы и записи базы, потому что код или новые права могли появиться в другом месте. Файлы сравнивают с чистой версией той же сборки, а не с произвольным архивом из интернета. Журнал доступа сопоставляют по времени с изменениями. Подробный план можно сверить с материалом про очистку сайта от вредоносного кода.

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

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

• Запишите симптомы и время их появления.
• Сверьте версии ядра и дополнений с официальными выпусками.
• Проверьте неизвестные учетные записи Manager.
• Сопоставьте изменённые файлы с чистой сборкой.
• Сравните журналы доступа с временем изменений.

Как сохранить данные и начать очистку

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

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

Работа с базой не сводится к удалению подозрительных страниц. Я проверяю новые учетные записи, роли, содержимое ресурсов, настройки и сохранённые сниппеты, затем меняю только то, что можно обосновать сравнением и журналами. После очистки отдельно меняю пароли Manager, панели хостинга, SFTP и базы данных, если они могли быть доступны через тот же проект. Пароль не лечит уже внедрённый код; он закрывает один из возможных способов повторного входа. Для системного разбора пригодится и технический аудит веб-приложения, особенно если сайт зависит от нескольких внешних компонентов.

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

• Сохраните отдельные копии файлов, базы и журналов.
• Запишите время копии и источник каждого архива.
• Проверьте чистоту копии до восстановления.
• Обновляйте ядро и Extras на тестовой копии.

Почему удаления плагина недостаточно

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

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

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

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

Как снизить риск повторного взлома MODX

Обновлять нужно и ядро MODX, и используемые Extras, и серверные компоненты. Одно не обновляет другое автоматически: служба поддержки MODX прямо советует после обновления сайта отдельно проверять каждый Extra или плагин. Перед крупным обновлением я делаю копию и проверяю совместимость на тестовой установке; после — прохожу главные сценарии сайта и проверяю журналы. Для конкретного проекта порядок зависит от версии и состава дополнений. По бюллетеням разработчика видно, какие версии затронуты; отдельный материал о уязвимостях CMS MODX помогает следить за темой, но не заменяет проверку своей установки.

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

В MODX настройка error_page задаёт ID ресурса, который показывается для отсутствующей страницы. Это удобная настройка обработки ошибки, а не средство защиты от сканирования или взлома. Для защиты закрывают ненужный публичный доступ к системным каталогам и Manager на уровне веб-сервера, поддерживают актуальные права записи и убирают неиспользуемые файлы. Правила из документации MODX нужно адаптировать к конкретной конфигурации Apache или Nginx: копировать чужой фрагмент без проверки опасно, а ошибка в правилах может закрыть и нормальную работу сайта.

Резервирование настраивают регулярно и хранят отдельно от сайта; период копирования выбирают с учётом того, сколько данных компания готова потерять при восстановлении. Копию нужно не только создать, но и проверить восстановлением на тестовой площадке. Я также фиксирую владельца процесса обновлений, перечень используемых дополнений и порядок действий, если сайт снова показывает посторонний контент. Если хочется сравнить сетевые меры с прикладной защитой, полезен разбор защиты сайта на уровне WAF: межсетевой фильтр помогает отсечь часть запросов, а за чистоту кода и резервные копии всё равно отвечает команда проекта.

• Учитывайте версии ядра, Extras и серверного ПО.
• Проверяйте обновление на копии сайта.
• Ограничьте доступ к Manager подходящим для команды способом.
• Храните резервную копию вне сайта и проверяйте восстановление.
• Уберите неиспользуемые дополнения и старые файлы.

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