- Критические уязвимости modx
- Защита MODX — руководство по закалке
- Защита ядра и служебных каталогов
- robots.txt
- Скрытие конфигурационных файлов сайта и версии php
- Защита таблиц базы данных
- Базовая защита от определения CMS
- Дополнительные примочки по защите
- Каталог ядра в открытом доступе — решение проблемы
- Полное скрытие информации о том что сайт работает на MODX
- Переделываем шаблоны
- Изменяем путь к уменьшенным изображениям
- Возможные проблемы с miniShop2
- Прочие проблемы
В прошлом уроке мы произвели расширенную установку 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, и как я писал выше ее тоже можно скрыть, но влечет за собой кучу проблем.
- Если сайт боевой, то в данном каталоге скорее всего лежат все картинки, скрипты, стили — следовательно к ним изменится путь — это пародист 404 ошибки (файл не найден) — в плюс со стороны поисковых систем думаю не с играет.
- Если забить на поисковики, либо предположить что у вас свеже установленный сайт. То все равно это пародит кучу доп проблем. Например: нам нужно будет избавляться от всего что выводится в код из данного каталога: скриптов, которые подключаю пакеты, картинок которые вы режете при помощи 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 скрипты — их тоже нужно перенести! В будущем расширю данную статью решением прочих проблем. Если столкнулись с ними — пишите в комментариях, постараюсь вам помочь.