Защита MODX Revolution

Последнее обновление Oct 11th, 2026 | История страницы | Улучшить эту страницу | Сообщить о проблеме

Support the team building MODX with a monthly donation.

The budget raised through OpenCollective is transparent, including payouts, and any contributor can apply to be paid for their work on MODX.

Backers

Budget

$194 per month—let's make that $500!

Learn more

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

Защита — это внимание ко всем слоям: сервер, его службы и само приложение. Эта страница посвящена MODX.

Четыре главных шага по защите MODX¶

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

Закройте каталог /core/ от публичного доступа через веб.
Закройте публичный доступ к manager или скройте его: переименуйте каталог или вынесите на поддомен.
Регулярно обновляйте сервер, ядро MODX и дополнения.
Поставьте перед сайтом WAF.

Остальные рекомендации усложняют определение MODX и добавляют дополнительные слои защиты или маскировки. Цена: больше времени и сложности при обновлении или переносе сайта.

Защита core и других каталогов¶

В ядре есть код, который в руках злоумышленников может нанести серьёзный ущерб.

В старых версиях MODX Revolution ядро можно было вынести за пределы web root; в 3.x каталог ядра больше нельзя переместить на произвольный путь или переименовать — из-за того, как Composer генерирует автозагрузчик с прописанным в нём путём core (#15476). Запрет публичного доступа к каталогу core даёт тот же уровень защиты.

Примеры ниже блокируют core и всё внутри него от публичного доступа. Ответ 404 (не найдено) вместо 403 (доступ запрещён) выбран намеренно.

Для Apache добавьте в .htaccess:

RewriteCond %{HTTP_HOST} ^(www\.)?example\.com$ [NC]
# Block access to dotfiles and folder people have no need to touch
RewriteRule ^(\.(?!well-known)|_build|_gitify|_backup|core|config.core.php)  /index.php?q=doesnotexist [L,R=404]

Чтобы показывалась ваша страница ошибки, укажите путь в .htaccess, например:

ErrorDocument 404 /404

Для NGINX добавьте правило, которое передаёт rewrite в обработчик ошибок MODX:

location ~ ^/(\.(?!well-known)|_build|_gitify|_backup|core|config.core.php) {
    rewrite ^/(\.(?!well-known)|_build|_gitify|_backup|core|config.core.php) /index.php?q=doesnotexist;
}

На высоконагруженном сайте можно обойти PHP MODX и сразу отдавать 404 из NGINX (или 444, когда соединение закрывается без ответа):

location ~ ^/(\.(?!well-known)|_build|_gitify|_backup|core|config.core.php) {
    return 404;
}

Стандартная страница 404 NGINX не совпадёт со страницей ошибок MODX; чтобы сохранить единый отпечаток, отдавайте свою. Создайте HTML-файлы в web root и добавьте следующее в правила NGINX. Своя страница 500 также может нести контакты и логотип, когда сайт падает или база перегружена и отвечает 502 или 504. Свои страницы стоит сделать и для других кодов 4xx и 5xx:

error_page 404 /custom_404.html;
error_page 500 502 503 504 /custom_500.html;

См. пример кода кастомной страницы ошибки.

Защита Manager¶

Каталог MODX Manager на втором месте по важности. Если по адресу http://example.com/manager/ видна типичная форма входа MODX, определить CMS несложно, и начнутся попытки перебора паролей.

Вместо переименования каталога manager используйте системную настройку manager_login_url_alternate (область authentication): она заставляет MODX перенаправлять неаутентифицированные запросы к Manager на любой URL по вашему выбору, например на страницу входа по менее очевидному пути. Стандартная структура каталогов сохраняется, обновления остаются простыми, а узнаваемый URL входа /manager/ исчезает.

Лучше не открывать Manager по тому же URL, что и публичный сайт, по аналогии с защитой core: отдавайте редактирование с поддомена вроде cms.example.com или чего-то ещё менее очевидного.

Для NGINX добавьте правило для всех публичных (под)доменов сайта:

# only allow manager access on cms.example.com
set $mgrcheck $host$request_uri;
if ($mgrcheck ~* "((?<!cms.)example\.com/manager)") {
    rewrite /manager /index.php?q=doesnotexist;
}

Если у вас уже настроена кастомная страница 404 из предыдущего раздела:

set $mgrcheck $host$request_uri;

if ($mgrcheck ~* "((?<!cms.)example\.com/manager)") {
    return 404;
}

Для Apache добавьте в .htaccess:

RewriteCond %{HTTP_HOST} ^(www\.)?example\.com$ [OR]
RewriteCond %{HTTP_HOST} ^promos\example\.com$ [OR]
RewriteCond %{HTTP_HOST} ^blog\.example\.com$ [NC]
RewriteRule ^manager/ /index.php?q=doesnotexist [L,R=404]

Доступ к Manager можно дополнительно ограничить на уровне сервера или файрвола: разрешить только с определённых IP. Если сайт правят только сотрудники офиса, отклоняйте запросы с других адресов. Ещё вариант: HTTP Basic Auth на каталог manager через .htaccess. Пользователю придётся ввести два пароля перед входом в MODX Manager. Неудобно, но надёжнее.

Разверните файрвол или WAF¶

На сервере должен быть файрвол с обнаружением вторжений, которое блокирует типичные атаки.

ModSecurity это модуль безопасности для Apache и NGINX, который отсекает часть вредоносных запросов. WAF (web application firewall) у Cloudflare, Fastly, Imperva, StackPath и других провайдеров тоже снижает число brute-force атак и блокирует известных злоумышленников.

Обновляйте сервер, MODX и дополнения¶

Если сервер скомпрометирован, остальные меры не гарантируют целостность сайта или всей машины.

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

Обновляйте и MODX: если в релизе упоминают проблему с безопасностью или баг, обновляйтесь как можно скорее.

Другие способы защиты MODX¶

Можно довести маскировку до крайности и заставить MODX выглядеть как другая CMS. Ниже дополнительные шаги, которые усложняют атаку.

Изменение типовых путей¶

Предсказуемые пути помогают определить ваш стек. Security through obscurity слабая тактика, но при zero-day автоматизированным сканерам будет сложнее.

Advanced Distribution и Git-установки MODX Revolution позволяют задать имена каталогов при установке, но на части хостингов такая установка не пройдёт.

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

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

manager¶

Выберите случайную буквенно-цифровую строку для каталога manager. Для совместимости используйте только строчные буквы. Обновите core/config/config.inc.php:

$modx_manager_path = '/home/youruser/public_html/r4nd0m/';
$modx_manager_url = '/r4nd0m/';

connectors¶

Как и для manager, задайте случайное имя каталога connectors и обновите core/config/config.inc.php:

$modx_connectors_path = '/home/youruser/public_html/0therp4th/';
$modx_connectors_url = '/0therp4th/';

Manager обращается к connectors как к AJAX-эндпоинтам, поэтому они должны быть на том же домене, что и Manager, если вы не настроили cross-origin запросы. Теоретически connectors можно вынести на отдельный домен.

assets¶

URL assets можно сменить, но это низкий приоритет: пути видны в HTML любой страницы. Смена всё же мешает простому автоматическому fingerprinting.

$modx_assets_path = '/home/youruser/public_html/4ssetsh3r3/';
$modx_assets_url = '/4ssetsh3r3/';

Assets тоже можно вынести на другой домен (например, для статики). Дополнения ставят сюда JavaScript для бэкенда, поэтому обычно нужен тот же origin, если нет cross-origin. Media Sources позволяют хранить фронтенд-файлы и загрузки где угодно, но для Manager чаще удобнее держать assets на том же домене.

Смена шаблона страницы входа в Manager¶

Скройте форму входа, чтобы не было очевидно, что сайт на MODX. Подробнее: шаблоны Manager.

Смена префикса таблиц БД¶

Лучше задать свой префикс при первой установке вместо modx_. Если злоумышленник выполнит SQL через injection, нестандартный префикс усложнит атаку.

Отдельная страница 404¶

Не направляйте 404 на главную. Сделайте отдельную страницу ошибки.

Сканер не должен получать HTTP 200 там, где страницы нет. Например, запрос к http://yoursite.com/malicious/hack с ответом 200 может убедить сканер, что уязвимый файл есть, и привлечёт новые проверки. В Firefox с дополнением «Web Developer» (или аналогом) проверьте заголовки и убедитесь, что 404 действительно 404.

Всё остальное¶

Защита выходит далеко за рамки MODX; главное из полного аудита безопасности:

Резервные копии¶

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

Уникальное имя администратора¶

Сложное для угадывания имя админа замедляет brute-force. Случайная строка символов надёжнее всего. Не используйте admin, manager или имя, совпадающее с названием сайта. Большая часть атак опирается на social engineering. Сделайте имя администратора практически неугадываемым.

Политика паролей¶

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

Только SSH/SFTP¶

Повторим: plain FTP небезопасен по design. Ещё лучше — только SFTP с SSH-ключами и сложной passphrase. Если сервер не поддерживает ни того ни другого, смените хостинг.

Инструменты администрирования БД¶

Adminer, phpMyAdmin и аналоги удобны для быстрых правок. После работы удалите их. Иначе тем же инструментом может воспользоваться злоумышленник.

Всегда используйте SSL¶

HTTPS сегодня базовое требование: браузеры предупреждают посетителей, если соединение не защищено. Установите современный набор шифров и регулярно продлевайте сертификаты.

После проверки HTTPS принудительно переводите весь трафик на порт 443.

Пример для Apache в .htaccess:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://example.com/$1 [L,R=301]

То же для NGINX:

# The intended URL is "www.example.com" over HTTPS.

if ($scheme != "https") {
    return 301 https://www.example.com$request_uri;
}

# Handles redirects for the "www." on the intended URL and
# allows other URLs to work when requested over HTTPS

if ($host = "example.com") {
    return 301 https://www.example.com$request_uri;
}

Проверьте переход с незащищённого URL, например http://yoursite.com/manager. Если редиректа на HTTPS нет, поправьте .htaccess или правила NGINX.

Если не знаете, как установить SSL-сертификат и включить принудительный HTTPS, обратитесь к хостинг-провайдеру.

Мониторинг сайта и сервера¶

После настройки защиты полезен регулярный мониторинг. Есть бесплатные сервисы. Лучшие следят за конкретными файлами и сообщают об изменениях. Внезапная правка index.php может означать вмешательство.

Пароли и входы¶

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

Никогда не используйте один пароль дважды. Часто взламывают один сервис, расшифровывают пароль, а пользователь применял его везде.

Ваш компьютер¶

Любую ОС можно взломать. Mac и Linux не делают вас неуязвимым. Работайте с ограниченными правами, ставьте патчи, используйте IDS от keylogger и screen-capture malware. Не храните пароли в открытом виде. Используйте менеджер паролей браузера или сторонний.

Не входите с публичного компьютера: он может логировать всё, что вы вводите.

Ваше подключение¶

Считайте, что в публичной Wi-Fi сети за вами могут следить.

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

Держите сайт в порядке¶

Удалите лишнее: неиспользуемые изображения, JavaScript, старые PHP-скрипты, бэкапы и zip в document root. Если Plugin, Snippet или Template не нужны, удалите их файлы с сервера. Неактивный код тоже можно эксплуатировать.

Многие атаки начинаются с обмана: звонок или письмо с просьбой передать данные. Не поддавайтесь. Вы уверены, что пароль просит клиент? Или тот, кто взломал его почту?