Безопасность MODX: какие цифры действительно важны

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

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

У MODX есть две основные линии, с которыми сталкиваются владельцы сайтов: Revolution 2.x и Revolution 3.x. У них отличаются требования к окружению, интерфейс менеджера и совместимость дополнений. Нельзя механически переносить рекомендации для одной ветки на другую.

Перед аудитом зафиксируйте:

• точную версию MODX Revolution;
• версию PHP и способ её запуска: FPM, Apache module или другой вариант;
• версию базы данных;
• список установленных дополнений и дату их последнего обновления;
• версию операционной системы и веб-сервера.

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

Главная цифра в безопасности MODX — не номер версии, а время между появлением исправления и его установкой.

Пять метрик для аудита MODX

1. Возраст ядра и дополнений

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

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

Не используйте универсальный порог вроде «старше 30 дней — взлом». Срок зависит от критичности исправления, доступности обновления и риска несовместимости. Для каждого компонента заведите статус: актуален, требует проверки, не поддерживается или неизвестен.

2. Число пользователей с административными правами

Посчитайте всех пользователей, которые могут входить в manager, а затем разделите их на активных и неактивных. Удалённый сотрудник с рабочей учётной записью — не абстрактный риск: его пароль может остаться в утечке, браузере или старом менеджере паролей.

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

• оставьте каждому сотруднику отдельную учётную запись;
• удалите неиспользуемые и тестовые аккаунты;
• запретите общий логин для всей команды;
• разделите публикацию материалов и изменение кода;
• проверьте доступы после смены подрядчика или администратора.

3. Количество внешних точек входа

Составьте список URL и механизмов, которые принимают данные извне: формы, авторизация, API, загрузка файлов, AJAX-обработчики, импорты и интеграции с CRM. Для каждой точки укажите, нужна ли она, кто может к ней обратиться и какие данные она принимает.

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

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

4. Разница между резервной копией и восстановлением

Файл архива сам по себе не доказывает, что резервное копирование работает. Измеряйте четыре показателя:

• возраст самой свежей копии;
• время от начала сбоя до обнаружения;
• время восстановления сайта;
• объём данных, который можно потерять без критического ущерба.

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

Минимальный практический тест — поднять копию на отдельном окружении, восстановить базу и файлы, проверить главную страницу, вход в manager, формы и критичные интеграции. Такой тест нужно проводить не на рабочем сайте.

5. Время обнаружения подозрительного изменения

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

В MODX часть признаков видна в журнале событий, часть — только на уровне веб-сервера, файловой системы или панели хостинга. Один источник не покрывает всё. Логи manager не заменяют контроль файлов, а контроль файлов не показывает успешный вход пользователя.

Где чаще всего ошибаются

Что ломается первым

Старое дополнение после обновления ядра

Обновление MODX может изменить требования к PHP, базовые классы или поведение менеджера. Дополнение способно перестать работать, а попытка быстро вернуть старую версию ядра создаёт ещё более сложную конфигурацию.

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

Неправильные права на файлы

Слишком широкие права позволяют веб-процессу изменять больше файлов, чем требуется приложению. Слишком жёсткие права, наоборот, ломают кеш, загрузку файлов и обновление компонентов. Универсальное число для всех хостингов здесь опасно: схема владельцев и групп зависит от веб-сервера и способа запуска PHP.

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

Публичные архивы и служебные файлы

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

Как превратить цифры в план действий

1. Зафиксируйте состояние. Запишите версии MODX, PHP, базы данных и дополнений, количество пользователей manager и дату последней резервной копии.
2. Составьте карту входов. Перечислите формы, загрузки, API, интеграции и административные URL. Удалите то, что больше не используется.
3. Проверьте права. Сопоставьте роли пользователей с их реальными обязанностями. Уберите общий доступ и неактивные аккаунты.
4. Проведите восстановление. Разверните копию отдельно, восстановите базу и файлы, измерьте время и запишите ошибки.
5. Назначьте владельца. У каждого показателя должен быть ответственный и дата следующей проверки. Иначе аудит останется разовым документом.

Что делать дальше

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

После этого настройте регулярную проверку обновлений MODX и дополнений, контроль изменений файлов и уведомления о событиях входа. В продакшене измеряйте не только ошибки 4xx и 5xx, но и возраст резервной копии, время восстановления и задержку между выпуском исправления и его установкой. Инвалидация кеша и защита от DDoS — отдельные темы; здесь важна именно измеримая безопасность приложения MODX.

Сноска. Точка входа — любой URL, обработчик или интеграция, через которые внешние данные попадают в приложение. Чем больше таких точек, тем больше поверхностей для проверки, но само число не доказывает наличие уязвимости.