modx обнаружил что папка ядра доступна частично извне
Исправление ошибки «Каталог ядра в открытом доступе» в MODX 2.5
Всем привет! Недавно я сталкнулся с проблемой, а именно у меня возникала ошибка «Каталог ядра в открытом доступе» в MODX 2.5. Разработчики CMF добавили эту проверку вроде бы с версии 2.4, она связанна с безопасностью сайта.
Дело в том, что если не исправить данную ошибку, то злоумышленник сможет украть у Вас данные к БД, ну или узнать версию MODX. Так что лучше исправить эту проблему.
Начнем с простого
Для начала, давайте начнем с самых простых вещей, которые указаны в самой ошибки. Первым делом необходимо переименовать уже имеющийся там файл в папке /core «ht.access» в «.htaccess» и очистить кэш.
Начиная с версии 2.5, содержимое «.htaccess» выглядит так:
Не помогло? Вот и мне не помогло :D, когда я пытался решить эту проблему с переносом сайта на другой хостинг.
Дело в том, что большинство хостинг компаний, используют следующую схему работы, при которой запросы к статичным файлам (в частности txt) обрабатываются с помощью Nginx, а остальные запросы передаются Apache.
Поэтому файл «.htaccess» не может использоваться для отключения доступа к статическим файлам, так как он обрабатывается только на уровне Apache. А MODX как раз-таки и проверяет файл (/core/docs/changelog.txt)
UPD. На некоторых сайтах использую
Можно ещё проще, нужно проверить, что не открывается в браузере файл /core/cache/logs/error.log, а потом просто удалить или переименовать файл /core/docs/changelog.txt
Второй метод справления ошибки «каталог ядра в открытом доступе»
Что же делать? Как решить проблему «каталог ядра в открытом доступе«? Всё очень просто, для этого нужно перенести /core за пределы публичной части сайта (public_html).
Также меняем путь к папке /core в файлах:
И вручную удаляем содержимое папки /core/cache. Саму папку cache не удаляем! Вот и всё, мы исправили проблему «каталог ядра в открытом доступе» в MODX
Если у Вас возникли вопросы, задавайте через форму ниже.
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 (я добавил такой же префикс, который указывал когда при установке переименовывал служебные каталоги — не используйте его в своих проектах — придумайте или сгенерите свой), в конечном итоге получаем следующее.
И наш сайт перестал работать! Исправим это, для этого нам нужно поправить пути в файлах конфирураций:
В файле core/config.core.php указываем все новые пути.
После чего удаляем папку с кэшем core/cache и проверяем работоспосбность сайта. Если сайт не работает, значит где-то не поправили путь.
По поводу каталога assets, его тоже можно спрятать (выше приведенным способом). Но есть много но, и об этом будет в конце статьи!
robots.txt
Здесь можно проверить правильность своего robots.txt — https://webmaster.yandex.ru/tools/robotstxt/
Скрытие конфигурационных файлов сайта и версии php
Защита таблиц базы данных
Если во время установки MODX, в настройках БД, вы не изменили префикс таблиц, который предлагается по умолчанию «modx_». То меняем его на сложный, для этого идем в phpMyAdmin (управление базами данных в админке хостинга):
Базовая защита от определения CMS
Для тех кто устанавливал MODX не по моему мануалу, проверьте отключение «X-Powered-By», чтобы сайт не «палился», отправляя в заголовках информацию о том, что сайт сделан на MODX.
Идем в системные настройки, в поиск по ключу вбиваем send_poweredby_header — ставим нет.
Дополнительные примочки по защите
Кроме описанных выше приёмов, можно применить еще пару небольших хитростей.
Многие «попсовые» CMS добавляют свои мета теги с указанием названия и версии CMS, например джумла:
можно смело добавить такой код, чтобы увести возможных злоумышленников по ложному следу.
В добавок к этому, можно создать фэйковую стандартную страницу входа в админку указанной версии имитируемой CMS.
Большинство автоопределялок будут интерпретировать наш движок как Joomla, а если хулиганы захотят залезть в админку, то будут долго и нудно пытаться подобрать отмычки к нерабочему замку.
Каталог ядра в открытом доступе — решение проблемы
Если ошибка не ушла, очистите кэш.
Полное скрытие информации о том что сайт работает на MODX
После проделанного выше большинство сервисов автоматического определения CMS, не поймут что сайт работает на MODX, но практически любой знающий модх человек, с большой долей вероятности определит ее, по подключенным скриптами пакетов из папки assets, и как я писал выше ее тоже можно скрыть, но влечет за собой кучу проблем.
Для тех кому трудности не почем, и кто решил все таки переименовать каталог assets, читаем далее, пути решения выше упомянутых проблем. Уточню! Актуально в первую очередь для тех у кого сайт с контентом!
Переделываем шаблоны
Если у вас все файлы хранились в assets/ то дизайн у вас весь поломался, так как такого каталога больше нет. Рекомендую в корне сайта создать каталог template (или просто в корень) и перенести все файлы шаблона (скрипты, стили и т.д. в него), далее сменить все пути в шаблонах, сделать это можно быстро при помощи пакета ModxDevTools (функция поиск и замена — работает для обычных шаблонов и чанков — в статических не ищет, там правите руками).
Изменяем путь к уменьшенным изображениям
Чтобы поменять этот путь заходим в системные настройки и меняем значения в полях Images Base Directory (pthumb.ptcache_images_basedir) и pThumb Cache Location (pthumb.ptcache_location), на новые значения. Также рекомендую включить: Используйте pThumb Cache (pthumb.use_ptcache) — Да
После чего удаляем папки с кэшированными картинками из /assets/components/phpthumbof/cache/
Возможные проблемы с miniShop2
Прочие проблемы
Это далеко не все, открываем код и ищем в нем assets и смотрим что еще выводится, например js скрипты — их тоже нужно перенести! В будущем расширю данную статью решением прочих проблем. Если столкнулись с ними — пишите в комментариях, постараюсь вам помочь.
Доброго дня.
После установки MODX Revo 2.4.0-pl
Вот такое предупреждение:
Переименование «ht.access» в «.htaccess» не помогло.
Комментарии: 19
Если не поможет (например, на TimeWeb не работает), то два варианта:
1. Простой: убрать виджет «Проверка конфигурации» с панели (не рекомендуется)
2. Радикальный: вынести директорию core за пределы public_html или что там у Вас.
Естественно, поменять пути в следующих файлах:
config.core.php
connectors/config.core.php
core/config/config.inc.php
manager/config.core.php
Ну и почистить core/cache.
Илья Уткин пишет:
Сначала проверить, что у вас не открывается в браузере файл /core/cache/logs/error.log, а потом просто удалить файл changelog.txt
Хостинг beget.ru — что б его. храни его Бог.
а htaccess переименовали в какой папке? он есть в корне, но нужно так же переименовать и тот, который внутри /core/
Защищаем MODX Revolution
Привет, друзья!
Немало статей написано и переписано о том, как защитить MODX, но в этой статье я опишу не только стандартные рекомендации по защите инстанса MODX Revolution (далее я буду писать просто MODX, потому что ветка MODX Evolution — это тупиковая ветвь «эволюции» являющаяся рудиментом не заслуживающим внимания современных разработчиков), но и некоторые новые методы «заметания следов».
Итак, начнем самого важного.
Существует две разновидности установщика MODX — это Traditional и Advanced.
Какая между ними разница?
Traditional — это простой вариант установки на любой хостинг соответствующий рекомендациям для установки MODX, где ядро устанавливается прямо в корень публичной папки сайта. Незатейливые «сайтоклёпы» ставят версию Tradtiional, не закрывают директории от просмотра и в итоге всё содержимое сайта, в т.ч. служебных директорий, попадает в индекс поисковиков. Не станем фантазировать на тему, к чему это может привести. Здесь всё понятно.
Advanced — версия для парней, которые, как минимум «смотрели кино про нидзей». Этот вид установщика позволяет разместить ядро MODX вне публичной папки, спрятав его от посягательств злоумышленников. Для серьезных проектов это рекомендуемый вариант, но лично я его использую всегда.
Защита ядра
Защитить ядро можно двумя способами:
2. На дурацком хостинге — переименовать каталог ядра воспользовавшись, например, генератором паролей (без спецсимволов, конечно же — только буквы и цифры) И во время установки указать физический путь к каталогу ядра. Именно поэтому лучше использовать Advanced установщик.
Защита служебных каталогов
Не секрет, что кроме каталога ядра, другие служебные каталоги должны остаться в публичной папке сервера.
Что нам сделать для защиты от попыток взлома через коннекторы и попыток проникнуть в админку? Стандартные наименования каталога коннекторов /connectors, а для админки — /manager, и это палево.
Во время установки вам будет предложено изменить эти названия. В этом нам поможет, правильно, — генератор паролей и, как ни странно, в случае с админкой собственная голова. Название каталога админки лучше сделать человекопонятным, но не /admin, конечно же 🙂
Возможно, вы захотите спросить: Почему мы не прячем /assets?
И, возможно, я отвечу: А зачем? Все картинки и скрипты лежат в /assets, а в коде страницы есть все ссылки на картинки и скрипты 🙂
Защита таблиц БД
Во время установки, в настройках БД, по умолчанию предлагается префикс таблиц «modx_». Так дело не пойдет. И вновь нам поможет генератор паролей (Помнишь, товарищ? Только из букв и цифр!). Меняем стандартный префикс на кракозябры, в конце которых ставим нижнее подчеркивание. Например, «IU1xbp4_».
Защита от определения CMS
Сервисы автоматического определения CMS сайтов, конечно, не в курсе, что MODX — это CMF, но это не мешает им определить, что контентом на сайте рулит именно MODX. Казалось бы, мы уже спрятали всё что надо. А вот и нет.
Первым делом, при установке MODX Revolution необходимо отключить чекбокс «X-Powered-By», который включен по умолчанию (на картинке ниже). Это необходимо для того, чтобы MODX не «палился», отправляя в заголовках информацию о том, что сайт сделан на MODX.
Если сайт уже установлен, то проверить этот параметр можно в системных настройках по адресу: домен_вашего.сайта/manager/?a=system/settings
И в поле «Поиск по ключу» ввести «send_poweredby_header» или просто «header» и нажать Enter на клавиатуре. Значение «send_poweredby_header» должно быть установлено как «Нет».
Кое-что ещё
Кроме описанных приёмов, можно применить небольшую хитрость, чтобы увести возможных злоумышленников по ложному следу. Некоторые «попсовые» CMS добавляли метатэги с указанием названия CMS:
Можно смело добавить в свой код такой тэг, и создать фэйковую стандартную страницу входа в админку указанной версии имитируемой CMS.
Автоопределялки будут интерпретировать наш MODX как WordPress, а если хулиганы захотят залезть в админку, то будут долго и нудно пытаться подобрать отмычки от простого замка к сканеру сетчатки глаза ( это метафора 🙂 ).
А что, если сайт уже установлен?
В час наименьшей нагрузки, переименуйте все указанные каталоги (/core, если позволяет хостинг, лучше вынести из паблика).
Смените префикс существующих, с помощью phpMyAdmin:
Проверить права и доступ (на каталоги 755, на файлы 644).
Запустить процесс установки.
Во время установки вам надо будет указать физический путь до каталога ядра.
ВАЖНО выбрать вариант установки «Расширенное обновление (с настройкой параметров базы данных)», потому что после ввода данных БД, появится диалог переименования каталогов.
Можно, конечно, было залезть в config.inc.php и отредактировать всё там. Но зачем что-то делать, если этого можно не делать? 🙂
На этом всё. Если информация из этой статьи окажется Вам полезной — супер. Если захотите что-то спросить, добавить или просто поумничать — вэлкам в коменты!
Безопасность и проблемы с ней в MODx Revolution
Данный топик посвящается вопросам защищенности MODx Revolution в целом, а так же коннекторов и контекстов в отдельности (релиз Revolution 2.1.0 ).
Предыстория: встал вопрос создать серьезный ресурс на движке MODx Revolution. Технических проблем мы не видели, но решили больше внимания уделить вопросам защищенности движка.
Честно сказать, я всегда считал механизмы безопасности в MODx Revolution очень гибкими и надежными, но тут я получил довольно много сюрпризов… Постараемся разобрать их как можно больше и подробней.
Кто любит сразу самое интересное читать, начинайте читать со слов «Теперь подытожим, что же надо чтобы работал коннектор. », так как сначала рассмотрели не проблему, а задачу.
UDP: в версии 2.1.1 пофиксили. Но зная на сколько >2.1.0 сырая еще, уверен что 99% Рево в ходу это более ранние релизы.
Во-вторых, решили мы сделать попутный сервис для привилегированных пользователей, но не на базе админки (то есть не так, чтобы они входили в админку, там настройками безопасности все от них скрыто было, кроме нового модуля для них), а на базе дополнительного контекста (то есть на новом субдомене и т.п.). У нас же MODx Revolution — многосайтовая платформа))).
Вот тут всё самое интересное и начинается…
Итак по порядку…
Для начала создаем новый контекст, создаем в нем несколько нужных нам документов, прописываем все необходимые настройки, привязываем к сайту новый поддомен, в index-файле прописываем по данному домену инициализацию нужного нам контекста… Проверяем — работает. Теперь самое важное — запретить доступ к данному контексту всем, кроме тех, кому разрешено…
Прежде, чем продолжить, немного о принципах безопасности:
В MODx Revolution на всё действует правило: «Если к чему-то назначены права, значит действует принцип ‘все, что не разрешено, то запрещено’. А если ничего ни для кого не назначено, то всем все можно».
Поясняю: Если есть группа ресурсов, на которую назначены кому-то доступы, то все остальные, кому не разрешено, ходят лесом. А если вы просто создали группу ресурсов для группировки, то и доступ к ним имеют все подряд.
Так же и с контестами: если к контексту прописаны доступы для каких-то Ролей политик безопасности, то все остальные идут лесом. Всё логично.
Итак, нам можно было создать группу ресурсов, на которую назначили бы уровни доступа, и в которую бы объединили наши закрытые документы. Но мы от этого простого способа отказались, так как во-первых, мог бы иметь место человеческий фактор (к примеру кто-то создал новый ресурс и забыл его добавить в группу), а во-вторых, мы хотели в принципе закрыть доступ ко всему контексту: ли авторизуйся, или иди дальше.
Вот мы и решили закрыть доступ к контексту. Лезу я, значит, редактировать наш новый контекст, дабы запретить к нему доступ… И тут я в небольшой ступор вошел… А как это так, закрыть к нему доступ? На контекст установлен доступ для Роли супер-юзера, больше ни для кого. Тем не менее все имеют доступ.
Поразмыслив, я понимаю, что логично, чтобы к нему имели доступ, это же публичный контекст… Но зачем тогда вообще существует механизм доступов к контекстам?
Покапавшись получше, все оказалось просто: оказывается на публичные контексты вообще не проверяются доступы, доступы проверяются только на контекст mgr, потому что обработчики запросов вообще разные. Это тоже отдельная статья, потому отправляю на уже написанное: про доступы к контекстам MODx Rvolution
Хорошо. Создаем новый обработчик для нашего контекста, который перехватывает доступы к контексту. Кстати, тут себя MODx показывает во всей красе. Занимает это буквально 30 минут (с учетом освоения новых технологий и 10 строк кода). Если не авторизован, выводим страницу авторизации. Если авторизован, но не имеет доступа к загрузке панели (Специально для этого добавили пользовательскую настроку политик безопасности), то выводит сообщение об отсутствии доступа. Получилось просто отлично: даже супер-пользователи, если не находятся одновременно в нужной группе пользователей и доступа к контексту с определенной Ролью, не имеют доступа к панели. Супер)))
Все вроде клева, но добрался я до написания необходимых коннекторов. Создаю по всем правилам коннектор, прописываю код, создаю процессор. Выполняю запрос… Пустой ответ. Это связано с выполнением файла connectors/index.php
Есть там такой код:
if (defined( ‘MODX_REQP’ ) && MODX_REQP === false ) <
> else if (!$modx->context->checkPolicy( ‘load’ )) <
Так что ребята, защищайте свои сайты, у кого есть что важное 🙂
Кстати, как это сделать?
Очень просто. В файле connectors/index.php перепишите код
/* initialize the proper context */
$ctx = ‘mgr’ ;
$modx->initialize($ctx);