Безопасность MODX: настройка и аудит сайта без догадок

Открытый Manager, забытый установщик или резервная копия в публичной папке могут превратить взлом сайта на MODX Revolution в вопрос времени. Ни один параметр не защитит всё сразу: аудит должен проверить учётные записи, доступ к файлам, обновления и восстановление. Ниже — практический план для MODX Revolution 2.8.x и 3.x; перед изменениями сверьте названия настроек и рекомендации с документацией своей ветки и хостинга.

Сначала зафиксируйте, что именно проверяете

MODX Revolution 2.8.x и 3.x — разные ветки, и пути к файлам или детали установки могут отличаться. Не переносите команды и инструкции между ними наугад. Запишите версию MODX, версию PHP, способ установки, адрес Manager и расположение каталога сайта. Уточните, кто имеет доступ к панели хостинга, SSH, базе данных и Manager. Если сайт обслуживает подрядчик, выясните, какие учётные записи ему ещё нужны.

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

Проверьте доступ в Manager

В Manager часто сосредоточены права на изменение страниц, шаблонов, сниппетов и настроек. Учётная запись с широкими разрешениями — не просто удобство: если её пароль утечёт, атакующий сможет менять содержимое сайта и, в зависимости от выданных прав и настроек, запускать код через управляемые ресурсы.

• Удалите учётные записи бывших сотрудников и подрядчиков. Для каждого действующего пользователя проверьте, нужны ли ему выданные роли и разрешения.
• Не используйте одну общую учётную запись для команды. Именной доступ упрощает отзыв прав и разбор действий.
• Проверьте пароль каждого пользователя и включите второй фактор, если его поддерживает ваша установленная версия или используемое дополнение. Не считайте наличие дополнения гарантией: проверьте его поддержку и совместимость.
• Ограничьте доступ к Manager на уровне веб-сервера или панели хостинга, если это подходит проекту. Сначала проверьте, что ограничения не отрежут администраторов и необходимые интеграции.

Перенос Manager по нестандартному адресу может уменьшить количество автоматических попыток входа, но не заменяет надёжные пароли и контроль прав. Не рассчитывайте на секретность URL как на защиту.

Закройте лишнее в файловой системе

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

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

Обновите ядро и дополнения

Уязвимость может находиться не в ядре MODX, а в установленном дополнении или старой версии PHP. Составьте список компонентов, отметьте их версии и выясните, поддерживаются ли они. Удалите неиспользуемые дополнения, если они больше не нужны: оставленный без обновлений код расширяет поверхность атаки.

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

Безопасность MODX — это не один секретный адрес Manager. Это возможность быстро отозвать лишний доступ, заметить подозрительное изменение и восстановить сайт из проверенной копии.

Проведите аудит по следам изменений

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

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

Термин: публичный корень сайта — каталог, из которого веб-сервер отдаёт файлы по HTTP(S). Всё, что попало туда без подходящего запрета, потенциально может быть запрошено посетителем.

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

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