MODX безопасность — уязвимости и защита от них

В прошлом уроке мы произвели расширенную установку MODX, тем самым закрыли часть уязвимостей. После входа в админку, вы наверное заметили ошибку: «Каталог ядра в открытом доступе» и жирным написано: Это не рекомендуется из соображений безопасности. А ниже ссылка на руководство по закалке на английском языке.  У меня на блоге есть подобное руководство на русском — которое относится к любым сайтам и не только.

Сегодня мы поговорим о уязвимостях MODX, как защитится от взлома и избавится от ошибки «Каталог ядра в открытом доступе«.

Критические уязвимости modx

Ноябрь 2016 — обнаружена первая критической уязвимости, она основана на SQL иньекциях. Подвержены сайты — которые используют стандартный префикс modx — я так понимаю она еще актуальна.

Июль 2018 — найдены еще две критические уязвимости безопасности. Первая позволяет злоумышленникам удалять на сайте папки и файлы, вторая — загружать на сервер вредоносный код и и выполнять его. — Профикшено в MODX 2.6.5 и выше. Похожая уязвимость так же была найдена в дополнении Gallery версии 1.7.0 и ниже — обновите до 1.7.1.

Обновление до версии 2.6.5 с исправлением уязвимостей выпустили на следующий день. Дополнение Gallery было обновлено до версии 1.7.1.

Апрель 2019 — обнаружен exploit для сайтов, в которых где осталась директория setup. Данная «дыра» позволяет получить полный доступ к сайту, а если хостиг не айс, то и к веб-серверу. — Уязвимость на данный момент не устранена, так что проверьте свой сайт на нее: введите в адресную строку браузера адрес вашего домена + /setup (как в уроке по установке) — если установщик запустится, то зайдите на хостинг и удалите папку setup.

Защита MODX — руководство по закалке

Внимание! Если у вас боевой сайт — перед началом, сделайте его полный бэкап!

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

Защитить ядро можно несколькими способами: вынести ядро (папка Core) из публичной папки. Далеко не на всех хостингах это можно сделать, либо переименовать каталог core.

Защитить служебные каталоги (connectors и manager) можно их переименованием их.

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

И наш сайт перестал работать! Исправим это, для этого нам нужно поправить пути в файлах конфигураций:

/config.core.php, manager/config.core.php, connectors/config.core.php

В файле core/config.core.php указываем все новые пути.

После чего удаляем папку с кэшем core/cache и проверяем работоспособность сайта. Если сайт не работает, значит где-то не поправили путь.

По поводу каталога assets, его тоже можно спрятать (выше приведенным способом). Но есть много но, и об этом будет в конце статьи!

robots.txt

Глупо переименовывать системные папки, и затем писать в robots.txt Disallow: Ejdf20jkfg20ff_conectors, но спрятать их от роботов нужно. Выход: удаляем из робота все старые директивы (которые мы переименовали) и за место них пишем 1 строку: Disallow: Ejdf20jkfg20* (указанный вам префикс без знака _ и нескольких последних символов до него) .

Таким образом мы скрываем от робота все что находится в переименованных каталогах с префиксом Ejdf20jkfg20ff_.

Здесь можно проверить правильность своего robots.txt — https://webmaster.yandex.ru/tools/robotstxt/

Скрытие конфигурационных файлов сайта и версии php

Открываем .htaccess и добавляем в него следующие строчки.

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

Защита таблиц базы данных

Если во время установки MODX, в настройках БД, вы не изменили префикс таблиц, который предлагается по умолчанию «modx_». То меняем его на сложный, для этого идем в phpMyAdmin (управление базами данных в админке хостинга):

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

после этого идем в core/config.core.php , меняем в нем префикс и удаляем папку с кэшем.

Базовая защита от определения CMS

Для тех кто устанавливал MODX не по моему мануалу, проверьте отключение «X-Powered-By», чтобы сайт не «палился», отправляя в заголовках информацию о том, что сайт сделан на MODX.

Идем в системные настройки, в поиск по ключу вбиваем send_poweredby_header — ставим нет.

Дополнительные примочки по защите

Кроме описанных выше приёмов, можно применить еще пару небольших хитростей.

Многие «попсовые» CMS добавляют свои мета теги с указанием названия и версии CMS, например джумла:

<meta name=»generator» content=»Joomla x.x.x» />

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

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

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

Каталог ядра в открытом доступе — решение проблемы

Если после всего выше перечисленного у вас все еще весит в админке данное уведомление (а оно в 90% еще весит). Можно смело избавиться от данной ошибки. Для этого переименуйте файл ht.access в .htaccess, который лежит в каталоге core. После этого идем в каталог «core/docs» и удаляем из него файл «changelog.txt».

Если ошибка не ушла, очистите кэш.

Полное скрытие информации о том что сайт работает на MODX

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

1. Если сайт боевой, то в данном каталоге скорее всего лежат все картинки, скрипты, стили — следовательно к ним изменится путь — это пародист 404 ошибки (файл не найден) — в плюс со стороны поисковых систем думаю не с играет.
2. Если забить на поисковики, либо предположить что у вас свеже установленный сайт. То все равно это пародит кучу доп проблем. Например: нам нужно будет избавляться от всего что выводится в код из данного каталога: скриптов, которые подключаю пакеты, картинок которые вы режете при помощи pThumb (или подобных пакетов) и т.д.

Для тех кому трудности не почем, и кто решил все таки переименовать каталог assets, читаем далее, пути решения выше упомянутых проблем. Уточню! Актуально в первую очередь для тех у кого сайт с контентом!

Переделываем шаблоны

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

Изменяем путь к уменьшенным изображениям

При использовании pThumb, phpthumbof или phpthumbon, мы имеем путь к изображению вида /assets/components/pthumb/cache/7a...73.jpg. Так как папку assets мы переименовали. Но умный скрипт или зоркий глаз может увидеть components/pthumb/cache и все понять.

Чтобы поменять этот путь заходим в системные настройки и меняем значения в полях Images Base Directory (pthumb.ptcache_images_basedir) и pThumb Cache Location (pthumb.ptcache_location), на новые значения. Также рекомендую включить: Используйте pThumb Cache (pthumb.use_ptcache) — Да

После чего удаляем папки с кэшированными картинками из /assets/components/phpthumbof/cache/

Возможные проблемы с miniShop2

Если пропали картинки товаров miniShop2 — перейдите в Медиа -> Источники файлов -> MS2 Images, и отредактируйте настройки basePath и baseUrl. Укажите новый путь к папке assets или к папке с изображениями вне assets.

Прочие проблемы

Это далеко не все, открываем код и ищем в нем assets и смотрим что еще выводится, например js скрипты — их тоже нужно перенести! В будущем расширю данную статью решением прочих проблем. Если столкнулись с ними — пишите в комментариях, постараюсь вам помочь.