Привет, друзья!

Немало статей написано и переписано о том, как защитить MODX, но в этой статье я опишу не только стандартные рекомендации по защите инстанса MODX Revolution (далее я буду писать просто MODX, потому что ветка MODX Evolution — это тупиковая ветвь «эволюции» являющаяся рудиментом не заслуживающим внимания современных разработчиков), но и некоторые новые методы «заметания следов».

Итак, начнем самого важного.

Существует две разновидности установщика MODX — это Traditional и Advanced.
Какая между ними разница?

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

Advanced — версия для парней, которые, как минимум «смотрели кино про нидзей». Этот вид установщика позволяет разместить ядро MODX вне публичной папки, спрятав его от посягательств злоумышленников. Для серьезных проектов это рекомендуемый вариант, но лично я его использую всегда.

Защита ядра

Защитить ядро можно двумя способами:

1. На нормальном хостинге — вынести ядро из публичной папки и можно его не переименовывать и не настраивать .htaccess лежащий в этом каталоге (на VDS не стоит забывать о настройке прав доступа пользователя, от которого запускается Apache).

2. На дурацком хостинге — переименовать каталог ядра воспользовавшись, например, генератором паролей (без спецсимволов, конечно же — только буквы и цифры) И во время установки указать физический путь к каталогу ядра. Именно по этому лучше использовать Advanced установщик.

Защита служебных каталогов

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

Что нам сделать для защиты от попыток взлома через коннекторы и попыток проникнуть в админку? Стандартные наименования каталога коннекторов /connectors, а для админки — /manager, и это палево.

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

Возможно, вы захотите спросить: Почему мы не прячем /assets?
И, возможно, я отвечу: А зачем? Все картинки и скрипты лежат в /assets, а в коде страницы есть все ссылки на картинки и скрипты :)

Защита таблиц БД

Во время установки, в настройках БД, по умолчанию предлагается префикс таблиц «modx_». Так дело не пойдет. И вновь нам поможет генератор паролей (Помнишь, товарищ? Только из букв и цифр!). Меняем стандартный префикс на кракозябры, в конце которых ставим нижнее подчеркивание. Например, «IU1xbp4_».

Защита от определения CMS

Сервисы автоматического определения CMS сайтов, конечно, не в курсе, что MODX — это CMF, но это не мешает им определить, что контентом на сайте рулит именно MODX. Казалось бы, мы уже спрятали всё что надо. А вот и нет.

Для примера, возьмем первую ссылку из приведенного выше списка поиска Google, и попробуем открыть файл настроек config.core.php, или, не смотря на то, что на этом сайте уже закрыт листинг каталогов, по ссылке «www.vvhotel.ru/core/config/config.inc.php», сайт отдает результат исполнения файла .php, а это значить что каждый из этих файлов существует и даже по первому из них можно предположить, что сайт на MODX.

Скрыть этот файл можно при помощи .htaccess, дописав:

    RewriteCond %{REQUEST_URI} ^(.*)config.core.php$
    RewriteRule ^(.*)$ [R=404]

Кое-что ещё

Кроме описанных приёмов, можно применить небольшую хитрость, чтобы увести возможных злоумышленников по ложному следу. Некоторые «попсовые» CMS добавляли метатэги с указанием названия CMS:

Можно смело добавить в свой код такой тэг, и создать фэйковую стандартную страницу входа в админку указанной версии имитируемой CMS.

Автоопределялки будут интерпретировать наш MODX как Wordpress, а если хулиганы захотят залезть в админку, то будут долго и нудно пытаться подобрать отмычки от простого замка к сканеру сетчатки глаза ( это метафора :) ).

А что, если сайт уже установлен?

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

Смените префикс существующих, с помощью phpMyAdmin:

• в левой части phpMyAdmin кликаете на название нужной базы;
• в основной области появится список всех таблиц, внизу которого надо отметить чекбокс «Отметить все»;
• справа от чекбокса комбобокс «С отмеченными:» в котором надо выбрать «Заменить префикс таблицы»;
• в новом окне указать старый префикс и новый префикс, на который надо заменить старый.

Затем, если у вас Traditional, но вы хотите заменить на Advanced, то поверх содержимого /core (или как вы его по-новому назвали) надо записать содержимое каталога /core из архива Advanced установщика, а в корень сайта поместить /setup.

Проверить права и доступ (на каталоги 755, на файлы 644).

Запустить процесс установки.

Во время установки вам надо будет указать физический путь до каталога ядра.

ВАЖНО выбрать вариант установки «Расширенное обновление (с настройкой параметров базы данных)», потому что после ввода данных БД, появится диалог переименования каталогов.

Можно, конечно, было залезть в config.inc.php и отредактировать всё там. Но зачем что-то делать, если этого можно не делать? :)

На этом всё. Если информация из этой статьи окажется Вам полезной — супер. Если захотите что-то спросить, добавить или просто поумничать — вэлкам в коменты!

https://habrahabr.ru/post/335148/