Каталог ядра в открытом доступе modx revo как исправить

Исправление ошибки «Каталог ядра в открытом доступе» в MODX 2.5

Всем привет! Недавно я сталкнулся с проблемой, а именно у меня возникала ошибка «Каталог ядра в открытом доступе» в MODX 2.5. Разработчики CMF добавили эту проверку вроде бы с версии 2.4, она связанна с безопасностью сайта.

Дело в том, что если не исправить данную ошибку, то злоумышленник сможет украть у Вас данные к БД, ну или узнать версию MODX. Так что лучше исправить эту проблему.

Начнем с простого

Для начала, давайте начнем с самых простых вещей, которые указаны в самой ошибки. Первым делом необходимо переименовать уже имеющийся там файл в папке /core  «ht.access» в «.htaccess» и очистить кэш.

Начиная с версии 2.5, содержимое «.htaccess» выглядит так:

# deny access to _all_ files in the core, including changelog.txt and error.log
# original borrowed from owncloud

# line below if for Apache 2.4
<ifModule mod_authz_core.c>
    Require all denied
</ifModule>

# line below if for Apache 2.2
<ifModule !mod_authz_core.c>
    deny from all
    Satisfy All
</ifModule>

# section for Apache 2.2 and 2.4
IndexIgnore *

Не помогло? Вот и мне не помогло :D, когда я пытался решить эту проблему с переносом сайта на другой хостинг.

Дело в том, что большинство хостинг компаний, используют следующую схему работы, при которой запросы к статичным файлам (в частности txt) обрабатываются с помощью Nginx, а остальные запросы передаются Apache.

Поэтому файл «.htaccess» не может использоваться для отключения доступа к статическим файлам, так как он обрабатывается только на уровне Apache. А MODX как раз-таки и проверяет файл (/core/docs/changelog.txt)

UPD. На некоторых сайтах использую

Deny from all
AllowOverride None

Можно ещё проще, нужно проверить, что не открывается в браузере файл /core/cache/logs/error.log, а потом просто удалить или переименовать файл /core/docs/changelog.txt

Второй метод справления ошибки «каталог ядра в открытом доступе»

Что же делать? Как решить проблему «каталог ядра в открытом доступе«? Всё очень просто, для этого нужно перенести /core за пределы публичной части сайта (public_html).

• Переносим папку core за пределы public_html
• Дальше необходимо в /core/config/config.inc.php изменить путь к папке /core в переменных $modx_core_path, $modx_processors_path

Также меняем путь к папке /core в файлах:

• /config.core.php 
• /connectors/config.core.php
• /manager/config.core.php

И вручную удаляем содержимое папки /core/cache. Саму папку cache не удаляем! Вот и всё, мы исправили проблему «каталог ядра в открытом доступе» в MODX

Если у Вас возникли вопросы, задавайте через форму ниже.

31.07.2016 / 19436

Если вы только что установили Modx Revolution, то в процессе установки вам надо было переименовать файлы ht.access и /core/ht.access в .htaccess.

Вы все сделали все по инструкции, но надоедливое предупреждение «Каталог ядра в открытом доступе» не удалилось из главной страницы admin панели Modx.

Это предупреждение ссылается на доступность каталога ядра — папки /core для общественности и не рекомендуется из соображений безопасности.

Почему при правильной настройки не убралось предупреждение?

Частой причиной этому является NGINX сервер — по умолчанию предоставляет доступы к .txt 

Ршение:

Нужно удалить или переименовать файл: /core/docs/changelog.txt

Если у вас сервер Apache нужно добавить правило в файл .htaccess:

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

Способ:

Изменение корневой директории, другими словами перенос папки /core выше уровнем, например за пределы папки /public_html.

В панеле управления моего сайта сообщение:
«Каталог ядра в открытом доступе. MODX обнаружил, что ваш основной каталог (частично) доступен для общественности. Это не рекомендуется из соображений безопасности. Если ваша установка MODX выполняется на веб-сервер Apache, вам следует по крайней мере настроить файл .htaccess внутри каталога с файлами ядра: /home/k/kolibriya/modx/public_html/core/. Это можно легко сделать, переименовав уже имеющийся там файл ht.access в .htaccess.»

У меня это все сделано. А сообщение все равно не исчезает. Кроме того, написано: «Если вы настроили всё правильно, то при открытии списка изменений страница должна вернуть вам ошибку 403 (доступ запрещен), а лучше ошибку 404 (страница не найдена).»

А у меня там код на всю страницу. Что это значит? Кто-нибудь подсказать может?

Не то, что искали? Воспользуйтесь поиском

В прошлом уроке мы произвели расширенную установку 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 скрипты — их тоже нужно перенести! В будущем расширю данную статью решением прочих проблем. Если столкнулись с ними — пишите в комментариях, постараюсь вам помочь.