Безопасность MODX 2 и 3: как защитить сайт от взлома

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

Инструкция подходит для MODX Revolution 2 и 3. Общие действия выполняем один раз, а различия веб-серверов и веток CMS разбираем отдельно. MODX Evolution в этом уроке не рассматриваем.

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

Срочное обновление PHP: уведомление октября 2026 года

21 октября 2026 года команда PHP выпустила исправления двух критических уязвимостей: CVE-2026-109618 и CVE-2026-109619. Их также называют PHP2Shell. При определенных условиях они позволяют выполнить посторонний код на сервере без входа в административную панель.

Это уязвимости PHP, а не только MODX. Обновление одной CMS их не устраняет. Закрытый каталог core, нестандартный адрес админки и надежный пароль также не заменяют исправление PHP.

Какие выпуски содержат исправления

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

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

Что сделать владельцу сайта

1. Откройте настройки сайта в панели хостинга и посмотрите, какая ветка PHP назначена именно этому домену.
2. Обратитесь в поддержку хостинга или к администратору сервера. Попросите подтвердить установку исправлений для обеих CVE и перезапуск обслуживающих сайт процессов PHP.
3. Если требуется смена ветки PHP, проверьте совместимость вашей версии MODX и установленных дополнений. Не переключайте рабочий сайт на самую новую ветку наугад.
4. После обновления проверьте публичные страницы, вход в админку, сохранение ресурсов, загрузку файлов и отправку форм.

В поддержку можно отправить такой запрос:

Здравствуйте. Проверьте пожалуйста PHP, обслуживающий сайт example.ru.

Установлены ли исправления CVE-2026-109618 и CVE-2026-109619?
Перезапущены ли после обновления процессы PHP, обслуживающие сайт?
Если исправления перенесены в пакет с прежним номером версии, подтвердите, пожалуйста, что этот пакет содержит необходимые патчи.

Замените example.ru своим доменом. Если у вас VPS без администрирования, обновление пакетов и перезапуск сервисов нужно организовать самостоятельно или поручить специалисту.

Для PHP 8.1 и более старых веток нельзя рассчитывать на обычные обновления от проекта PHP: эти ветки больше не получают его штатные исправления безопасности. Наличие сторонних исправлений уточняйте у поставщика. Для дальнейшей работы планируйте переход на поддерживаемую ветку с проверкой совместимости сайта.

Дополнение PHP от 23 октября

23 октября команда PHP отдельно рекомендовала временно отключить session.upload_progress.enabled до следующего обычного выпуска с исправлениями. Это связано с дополнительным сценарием выполнения кода при необычном сочетании настроек и переключения обработчика сериализации сессий приложением.

Если сервером управляет хостинг, попросите поддержку проверить применимость рекомендации и установить значение 0 на уровне конфигурации PHP. Самостоятельно добавлять ini_set() в шаблон MODX для этой задачи не нужно.

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

Официальные сведения: уведомления безопасности PHP за октябрь 2026 года и сообщение команды MODX. WAF и другие фильтры запросов могут уменьшать риск отдельных атак, но не заменяют обновление PHP.

С чего начать проверку безопасности MODX

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

• Есть резервная копия файлов и базы, которую можно восстановить.
• Установлены актуальные исправления MODX, дополнений и PHP.
• Каталог ядра не отдает файлы посетителям через браузер.
• После установки удалены setup, архив дистрибутива и вспомогательные установочные скрипты.
• Админка открывается по HTTPS, учетные записи защищены уникальными паролями.
• В публичном каталоге не лежат резервные копии, дампы базы и временные служебные файлы.

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

Обновляем MODX и дополнения

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

Проверяем версию ядра

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

Например, 21 июля 2026 года вышли MODX 2.8.9 и 3.2.3 с исправлением недостаточной проверки входных данных. Согласно уведомлению команды, последствия зависят от конфигурации сайта и могут доходить до выполнения постороннего кода. Самостоятельно считать свою установку незатронутой по внешним признакам нельзя.

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

Для сайта на MODX 2 установка исправлений своей ветки не требует автоматически превращать обновление в миграцию на MODX 3. Переход между основными ветками — отдельная работа с проверкой кода и дополнений.

Проверяем установленные пакеты

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

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

Сам порядок обновления ядра разобран в статье об обновлении MODX, работа с пакетами — в инструкции по установке дополнений. Эти операции не заменяют обновление PHP и серверного ПО.

Закрываем HTTP-доступ к каталогу core

Каталог core должен оставаться доступным PHP на сервере, но не посетителям через HTTP. Переименовать папку и запретить доступ к ней — разные действия.

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

Apache: используем файл внутри core

1. Откройте файловый менеджер хостинга и перейдите в фактический каталог ядра. При обычной установке это core внутри каталога сайта.
2. Включите показ скрытых файлов, чтобы видеть имена с точкой в начале.
3. Найдите файл ht.access, поставляемый с MODX. Если .htaccess здесь еще нет, переименуйте ht.access в .htaccess.
   
4. Если .htaccess уже существует, сначала сохраните его копию. Не перезаписывайте действующие правила вслепую.
5. Проверьте доступ к существующему файлу ядра из браузера и HTTP-статус ответа.

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

Для проверки можно использовать существующий файл core/docs/changelog.txt. Откройте его адрес в приватном окне. Если сайт установлен в подпапке или каталог ядра переименован, учитывайте это в адресе.

Ожидаемый результат — отказ в доступе с HTTP-статусом 403 или 404, без содержимого файла. Посмотреть статус можно в инструментах разработчика браузера: откройте вкладку «Сеть» или «Network», обновите страницу и выберите основной запрос.

Если файла уже нет, ответ 404 сам по себе ничего не доказывает. Для проверки нужен файл, существование которого вы подтвердили в файловом менеджере. Не создавайте для этого тестовый файл с паролями или другой служебной информацией.

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

Nginx и связка Nginx с Apache

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

Если у вас есть доступ к конфигурации Nginx, для обычного расположения ядра в корне домена можно использовать такой блок внутри соответствующего server:

location ^~ /core/ {
    return 404;
}

Это фрагмент конфигурации, а не полный файл. Не вставляйте его в .htaccess. Для установки в /rikidom/ путь в этом примере должен быть /rikidom/core/, а для переименованного ядра — соответствовать его фактическому URL.

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

Пример запроса в поддержку:

Здравствуйте. Нужно запретить внешний HTTP-доступ ко всему каталогу ядра MODX на сайте example.ru.

Фактический URL каталога: /core/
Просьба учесть выдачу файлов Nginx напрямую, если используется связка Nginx и Apache.
Доступ PHP к файлам ядра на сервере должен сохраниться.

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

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

Нужно ли переносить или переименовывать core

Для первичной защиты достаточно правильно закрыть HTTP-доступ. Переименование не делает найденный каталог недоступным, а перенос меняет устройство установки и порядок ее сопровождения.

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

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

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

Удаляем установщик и временные файлы

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

Затем проверьте адрес https://example.ru/setup/, заменив домен своим. Установщик не должен открываться. Для сайта в подпапке проверьте соответствующий адрес, например https://example.ru/rikidom/setup/.

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

В публичной папке сайта также не должны оставаться:

• ZIP-архив установочного дистрибутива.
• Вспомогательные скрипты установки, включая installmodx2.php или installmodx3.php, если вы использовали их из урока установки.
• Временные скрипты восстановления пароля, тестирования почты и диагностики.
• Файлы с выводом phpinfo().
• Выгрузки базы данных и архивы резервных копий.
• Копии конфигурации с окончаниями .bak, .old и похожими именами.

Временный Adminer, загруженный прямо в каталог сайта для разовой работы с базой, после завершения тоже удалите. Штатный phpMyAdmin в защищенной панели хостинга — другой случай, его файлы на сервере самостоятельно удалять не нужно.

Проверяем конфигурационные файлы и права

При стандартном расположении основной файл конфигурации MODX находится здесь:

core/config/config.inc.php

В нем хранятся параметры подключения к базе и пути установки. Файлы config.core.php в корне сайта, в manager и connectors выполняют другую задачу: указывают путь к ядру. Если каталоги переименованы, их фактические пути будут отличаться.

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

Закрываем прямой запрос к config.core.php

Кроме защиты ядра, проверьте ограничение внешнего доступа к служебному config.core.php. Для Apache 2.4 можно добавить в корневой .htaccess сайта следующий блок, предварительно сохранив копию файла:

<Files "config.core.php">
    Require all denied
</Files>

Это правило запрещает HTTP-доступ к файлу, но не мешает PHP подключать его на сервере. На хостинге должна быть разрешена соответствующая директива в .htaccess. Если после изменения появилась ошибка 500, восстановите копию и уточните настройки у поддержки.

Для Nginx при установке в корень домена соответствующий фрагмент в блоке server может выглядеть так:

location = /config.core.php {
    return 404;
}

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

Не выдаем 777 всем файлам

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

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

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

Защищаем вход в административную панель

Проверяем HTTPS и учетные записи

1. Откройте сохраненный адрес админки по HTTPS. Браузер не должен показывать предупреждение о сертификате.
2. Используйте отдельный длинный пароль администратора. Он не должен совпадать с паролем почты, хостинга или базы данных.
3. Проверьте рабочий email администратора и возможность восстановления доступа. Доставка писем должна быть проверена, а не только настроена в интерфейсе.
4. Для каждого сотрудника создавайте собственную учетную запись с нужными правами вместо общего доступа под администратором.
5. Проверьте старые учетные записи разработчиков и подрядчиков. Неиспользуемый доступ отключайте с учетом действующих интеграций и рабочих процессов.

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

Подключение HTTPS разобрано в отдельном уроке. Не добавляйте несколько конкурирующих перенаправлений в панель, .htaccess и настройки прокси одновременно.

Нестандартный адрес manager

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

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

На рабочем сайте нельзя просто переименовать папку manager в файловом менеджере: адреса и серверные пути должны соответствовать конфигурации. Для первичной проверки безопасности такую операцию не выполняем.

Дополнительное ограничение доступа

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

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

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

Не показываем посетителям ошибки PHP

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

Откройте настройки PHP нужного сайта в панели хостинга. Для рабочего окружения проверьте следующие значения:

display_errors = Off
display_startup_errors = Off
log_errors = On

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

Не вставляйте php_flag display_errors off в .htaccess наугад. Такая директива подходит не для любого способа запуска PHP и может привести к ошибке сервера.

Уточните расположение PHP-журнала в панели хостинга и проверьте, что он недоступен посетителям. Журнал MODX при стандартной конфигурации находится в core/cache/logs/error.log и тоже должен быть закрыт от HTTP-доступа.

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

Почему robots.txt не защищает служебные каталоги

Файл robots.txt задает рекомендации для обхода сайта поисковыми роботами. Он не запрещает посетителю или вредоносному скрипту открыть указанный адрес напрямую.

Поэтому строка Disallow не заменяет запрет доступа к ядру, конфигурации или резервным копиям. Сам файл robots.txt открыт для чтения, и записанный в нем нестандартный адрес админки перестает быть скрытым.

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

Нужно ли менять префикс таблиц базы данных

Префикс modx_ сам по себе не создает SQL-инъекцию. Уязвимость возникает в обработке запросов, а не потому, что таблица получила стандартное имя.

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

Если префикс действительно требуется изменить, необходимо учитывать не только таблицы ядра, но и дополнения, пользовательские запросы и конфигурацию. При стандартной установке переменная $table_prefix находится в core/config/config.inc.php, а не в core/config.core.php. Такая операция требует отдельной проверки и резервной копии.

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

Как затруднить определение MODX

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

Но полностью скрыть MODX такими действиями нельзя. CMS определяют не только по названию папки, но и по HTML, cookies, подключенным файлам и ответам обработчиков. Некоторые сканеры вообще не определяют движок заранее, а сразу проверяют известные адреса.

Поэтому маскировку используем как дополнительный слой защиты. Она не заменяет обновления, запрет HTTP-доступа к ядру и ограничение доступа к административной панели.

Отключаем необязательный заголовок MODX

Откройте системные настройки MODX, найдите ключ send_poweredby_header и установите «Нет». Сохраните значение и очистите кеш MODX.

Затем откройте публичную страницу сайта, вызовите инструменты разработчика браузера и перейдите на вкладку «Сеть» или «Network». Обновите страницу, выберите основной запрос документа и посмотрите заголовки ответа.

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

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

Используем нестандартный адрес админки без повторного переименования

Если при установке Advanced вы уже изменили manager на другое имя, оставьте этот адрес. Это может помешать автоматическим обращениям, рассчитанным только на стандартный путь /manager/.

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

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

Что делать с публичными файлами шаблона

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

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

Если сайт уже работает, сначала проверьте, где используются существующие адреса:

• В шаблонах и чанках.
• В файловых элементах и подключаемых файлах.
• В содержимом ресурсов и TV.
• В настройках дополнений и источников файлов.
• В JavaScript, CSS и настройках сборки, если она используется.

Переименование одного каталога не обновляет эти ссылки автоматически. Если меняете адреса, делайте это на тестовой копии: перенесите файлы, исправьте подключения и проверьте запросы во вкладке «Сеть». Не должно остаться ошибок загрузки CSS, JavaScript и изображений.

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

Нужно ли переименовывать assets

Само имя assets не является уязвимостью. Важнее то, какие файлы внутри доступны извне, какие обработчики выполняют PHP-код и обновлены ли соответствующие компоненты.

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

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

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

Меняем адреса миниатюр pThumb

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

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

Для примера предположим, что исходные изображения находятся в assets/images/, а миниатюры нужно сохранять в image-cache/ относительно корня установки MODX.

1. Откройте системные настройки и найдите параметры pThumb. Перед изменением запишите их текущие значения.
2. Найдите pthumb.ptcache_images_basedir — Images Base Directory. Для нашего примера укажите assets/images.
3. Найдите pthumb.ptcache_location — pThumb Cache Location. Укажите image-cache.
4. Найдите pthumb.use_ptcache — Use pThumb Cache. Установите «Да», чтобы использовать этот механизм кеширования.
5. Сохраните настройки и очистите кеш MODX, чтобы повторно сформировался HTML страниц с адресами миниатюр.
6. Откройте страницу, на которой изображения обрабатываются pThumb, и проверьте результат.

Это пример, а не значения для любого сайта. Если оригиналы хранятся в другом месте, укажите свой каталог. Для установки MODX в подпапке значение image-cache остается относительным к базовому каталогу этой установки.

Параметр pthumb.ptcache_images_basedir не меняет адреса оригиналов и не скрывает их автоматически. Он задает, какую начальную часть пути не включать в структуру каталога миниатюр.

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

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

Настройки описаны в документации pThumb. Совместимость самого пакета с вашей версией MODX и PHP проверяйте отдельно: этот пример не является рекомендацией устанавливать pThumb в каждый проект, включая новый сайт на MODX 3.

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

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

Не заменяйте оба значения одной и той же строкой наугад: серверный путь и публичный URL выполняют разные задачи. Учитывайте также настройки относительности путей конкретного источника.

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

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

Это дополнительная проверка для существующего магазина. В проекте FlexStart на MODX 3 устанавливать miniShop2 для выполнения этого раздела не требуется. Общая работа с путями разобрана в уроке об источниках файлов.

Проверяем результат маскировки

После изменения заголовков или публичных путей проверьте сайт как посетитель и как администратор:

• Открываются страницы и не пропало оформление.
• Загружаются CSS, JavaScript, оригиналы изображений и миниатюры.
• Работают формы и другие запросы дополнений.
• В админке сохраняются ресурсы и открывается выбор файлов.
• В журналах не появились новые ошибки.

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

Резервные копии, журналы и регулярная проверка

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

Проверяем резервное копирование

1. Откройте раздел резервных копий в панели хостинга и посмотрите даты доступных копий.
2. Убедитесь, что сохраняются и файлы, и база данных. Одного из этих компонентов для полного восстановления обычно недостаточно.
3. Храните дополнительную копию вне публичного каталога сайта, желательно отдельно от самого хостинг-аккаунта.
4. Проверьте восстановление на отдельной закрытой площадке. Наличие архива еще не подтверждает, что из него получится вернуть рабочий сайт.

Не храните единственный бэкап в папке backup внутри доступного по домену каталога. Сложное имя архива не является контролем доступа.

Следим за изменениями

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

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

Если сайт уже взломан

Не ограничивайтесь сменой адреса админки или удалением одного найденного файла.

1. Свяжитесь с хостингом и ограничьте публичный доступ к скомпрометированному сайту.
2. Сохраните журналы и копию текущего состояния для разбора. Не очищайте их первым действием.
3. Проверьте учетные записи, файлы, элементы MODX и другие сайты в том же аккаунте.
4. Восстановите сайт из проверенной чистой копии либо выполните очистку с привлечением специалиста.
5. Устраните причину проникновения, установите исправления и замените скомпрометированные секреты с доверенного устройства.
6. Проверьте результат до возвращения сайта в публичный доступ.

Восстановление старого бэкапа без исправления исходной уязвимости может привести к повторному взлому.

Проверка после настройки защиты

В конце откройте сайт как обычный посетитель и отдельно войдите в административную панель. Проверьте:

• Публичные страницы и админка работают по HTTPS без предупреждения о сертификате.
• PHP получил необходимые исправления безопасности, а его процессы перезапущены после обновления.
• Версии MODX и дополнений проверены по официальным сообщениям и требованиям совместимости.
• Существующие файлы внутри core не выдаются через браузер.
• Каталог setup, архив установки и временные служебные скрипты удалены.
• Конфигурационные файлы, дампы и резервные копии недоступны посетителям.
• Вход в админку, сохранение ресурсов, загрузка файлов и работа форм не сломались после ограничений доступа.
• PHP-ошибки записываются в закрытый журнал, а не показываются посетителям.
• Есть отдельная резервная копия и проверенный способ восстановления.

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

← Предыдущая статьяЛексиконы в MODX: руководство по созданию и применению

Следующая статья →Fenom в MODX: включение, синтаксис и примеры