Закалка MODX Revolution (перевод)

Своего писать я пока сомневаюсь, уровень не тот, а вот перевести полезную статью с официальной документации — это с удовольствием. Перевод местами может показаться несколько вольным, что касается формулировок, — иначе переводить скучно. Но в том, что касается технических деталей, старался быть дотошно точным. Так что, если найдёте технические неточности — ругайтесь в комментах. А на филологию прошу не жаловаться:) И тем более на идеологические расхождения с Вашим мировоззрением — тут все вопросы к авторам доков. Паранойи и почвы для громких споров среди «экспертов по безопасности» в статье предостаточно. Помни, о читатель, всё это касается в первую очередь важных и заметных проектов.
Добро пожаловать под кат.

Обзор, или Зачем я это читаю

Закалка любого веб-приложения (не исключая MODX Revolution) подразумевает внимательный аудит всех компонентов сайта, включая сервер, все его сервисы, само приложение. Не совершай ошибку — ты на войне, товарищ! Если тебе ещё не страшно, значит, ты сознательно закрываешь на это глаза. Сам факт, что твой сайт доступен онлайн, гарантированно делает тебя объектом хакерской атаки. Мотивы могут быть разные, но слабое звено обязательно будут искать, найдут и используют.
Защита — тема объёмная, так что цель этой страницы — помочь тебе выявить наиболее вероятные векторы атаки на твой сайт и перекрыть их.

Всё, кроме самого MODX

Вопрос защиты сайта включает в себя много аспектов, не имеющих непосредственного отношения к MODX. Справедливости ради мы их упомянем, однако основная цель статьи — именно прокачка MODX. Просто убедись, что уделил внимание безопасности всей среды. Далее — по пунктам:
Компьютер
Использование любой версии Windows до Vista — это сознательное самоубийство. И нет, мы не разводим холивар про Microsoft. Речь о том, что буквально двадцать-икс лет они угрохали на эволюцию от системы «разрешено по умолчанию» к системе «запрещено по умолчанию» (тут подробности), и до сих пор в Windows не включен протокол SSH. Закалка старой винды потребует титанических усилий, и, если только ты не охренительно прокаченный и внимательный спец, твой довистовый аппарат всё равно будет иметь суровые дыры в безопасности.
Но не обольщайся — взломать можно ЛЮБУЮ операционку. Так что не думай, что раз у тебя Mac или ты фанат Linux, ты в безопасности. Не запускай систему от администратора. Следи за патчами и обновлениями. Держи включенными антивирус и файрвол. Никогда не храни пароли в текстовых файлах — используй для этого специальные программы, вот такие например.
Соединение
По возможности не используй для администрирования сайта Wi-fi — только проводное соединение. И уж точно никогда не доверяй общественным вай-фай точкам, использующим что-либо меньшее, чем WPA2-шифрование. Слишком уж легко перехватывать пакеты, передающиеся через роутер, так что даже с самыми скромными хакерскими навыками не составит труда прочитать твои логины и пароли, передача которых прямо-таки нимбом светится вокруг кофешопа.
Сервер
Бесполезно прокачивать всё остальное, если сам сервер не имеет адекватной защиты. Если взломают пароль от FTP, ты уже ничего не сможешь сделать для защиты сайта. Поэтому отключи все ненужные сервисы. Если это возможно, полностью откажись от FTP в пользу SFTP. Рекомендуем так же полностью отключить обычную авторизацию и использовать аутентификацию через SSH с использованием ключа. При этом убедись, что пароль ключа достаточно сложен.
Удостоверься, что на сервере установлен хороший файрвол и что-нибудь, что в реальном времени обнаруживает попытки взлома. ModSecurity — модуль безопасности для apache, обнаруживающий и сдерживающий вредоносные атаки.
Регулярно обновляй сервер и все его технологии! Как только появится хоть какая-то дырочка в безопасности твоего сервера и её обнаружат — это станет брешью в плотине, которую кто-то обязательно прорвёт, ввергнув тебя вместе с твоим сайтом в пучину боли и отчаяния. Храни сервер пропатченным!
Логины и пароли
Выбирай длинные рандомные пароли и регулярно их меняй (от переводчика: неплохой генератор паролей тут). Длинные пароли, как правило, математически сложнее коротких — даже тех, в которых используются специальные символы. Засолка пароля легко запоминающейся фразой для увеличения его длины является неплохой защитой от брут-форса (от переводчика: атаки перебором паролей, кто не знает). Итак, повторим: ты ОБЯЗАН надёжно хранить свой пароль, желательно в зашифрованном виде. Гораздо лучше записать пароль в бумажный блокнот и спрятать у себя в столе, чем сохранить его в текстовом файле у себя в компьютере.
И наконец, крайне важное напоминание: никогда не используй один пароль дважды! Часто хакерские атаки бывают успешными только потому, что какой-то один сервис скомпрометирован и пароль дешифрован, а лентяй или пофигист разработчик использует тот же пароль на других сайтах и сервисах. НЕ НАДО ТАК.
Соблюдай чистоту и порядок
Удаляй с сайта всё, что не используешь. Все ненужные картинки, js-файлы и т. д. Особенно вредны какие-то отладочные php-скрипты или, не дай божЕ, zip-архивы с бэкапом, забытые в корне сайта. Считай свой проект воздушным шаром — если что-то не нужно, кидай это за борт до того, как шар упадёт или загорится. Если не используешь какие-то плагины, сниппеты или шаблоны — удали их файлы. То, что не подключено, не обязательно нельзя использовать против тебя.
Резервные копии
Одно из самых важных, что ты можешь сделать для своего сайта, — это настройка регулярное резервного копирования вне публичной директории. Никогда нет гарантии, что тебя не взломают — так пусть у тебя будет свежий бэкап, если и когда это случится.
Социальная инженерия
Многие взломы связаны со старой как мир хитростью — кто-то звонит или пишет тебе и под надуманными предлогами просит передать ему информацию. Не будь простачком. Это ТОЧНО твой клиент просит прислать ему потерянный пароль? Или кто-то влез в его почту? Почитай про Кевина Митника — чувак получил исходный код многих БОЛЬШИХ проектов, тупо убедительно позвонив нужным людям.

Теперь спрячем Modx

Заметь, что это только небольшой участок того, что нужно закалить. Modx — лишь один из аспектов среды разработки, поэтому не надо геройствовать, пренебрегая предыдущим разделом статьи.
Переназначение системных папок
В отличие от Evo, Revolution позволяет без особых трудностей изменять названия системных папок и даже убрать папку core за пределы корневого web-каталога. Обрати внимание, что только папка /core может (и должна) быть вынесена за корень, так как остальные папки должны быть доступны из интернета. Переименовывание директорий критически важно, если хочешь избежать определения системы управления сайта хакер-ботами по так называемым «спискам быстрого набора».
Advanced-дистрибутив Modx позволяет указать названия и расположение папок еще в процессе установки, но на некоторых хостингах эта сборка не устанавливается.
Перед тем, как что-то менять, обязательно сделай бэкап сайта и базы данных!
core
Это, пожалуй, главное, что стоит изменить. Перенеси папку core за пределы корневого web-каталога. Лучше всего — на один уровень до него. То есть, пусть это будет к примеру /core вместо /public_html/core. Когда папка перенесена, нужно отредактировать конфиги:
  • core/config/config.inc.php (переменная $modx_core_path)
  • /config.core.php (в корне сайта)
  • /connectors/config.core.php
  • /manager/config.core.php
  • Таблица modx_workspaces в базе данных сайта. Правильнее всего — перезапустить установку сайта, как при обновлении или переносе, чтобы убедиться, что всё работает правильно.
Если решил изменить названия и других папок, помни, что после этого тоже лучше запустить повторную установку.
manager
Это следующее по важности изменение. В конце концов, увидев симпатичную страницу авторизации Modx по адресу твой.сайт/manager, не нужно быть гением, чтобы понять, что сайт на Modx, и приступить к перебору паролей.
Используй в качестве нового имени рандомный кусок текста. Для наилучшей совместимости лучше использовать только буквы в нижнем регистре и цифры. Переименуй папку. Затем отредактируй core/config/config.inc.php. Должно получиться что-то такое:
$modx_manager_path = '/home/youruser/public_html/r4nd0m/';
$modx_manager_url = '/r4nd0m/';
Такое перенесение админки помешает ботам быстро опознать сайт как собранный на MODX, однако возможность, что админку всё-таки обнаружат, ещё остаётся (хоть это теперь и значительно сложнее). Для ещё большей конспирации можно и вовсе расположить админку на другом домене:
$modx_manager_url = 'http://другой.сайт/r4nd0m/'
Для этого оба домена должны быть делегированы на один сервер. Преимущество такого решения в том, что определить связь двух доменов значительно сложнее, чем просто найти нужную папку на домене сайта -объекта взлома. Однако, заставить такой вариант установки работать может быть довольно сложно (от переводчика: в частности, может возникнуть проблема с кроссдоменными запросами к коннекторам в админке, из-за чего она не будет нормально работать).
Также можно заблокировать доступ в админку, настроив сервер и/или его файрвол так, чтобы разрешать доступ к адресу админки только с определённых IP адресов. Скажем, работы с сайтом ведутся только из офиса — пусть тогда админка открывается только с офисных IP-адресов. Другой тактикой будет назначение пароля на папку админки через .htaccess. То есть, чтобы войти в админку, пользователю придётся ввести два разных пароля подряд. Неудобно, зато понадёжнее.
connectors
Так же, как и с админкой, переименуй папку во что-то невразумительное и подредактируй core/config/config.inc.php:
$modx_connectors_path = '/home/youruser/public_html/0therp4th/';
$modx_connectors_url = '/0therp4th/';
Опять же, как и админку, эту папку можно расположить на другом домене.
assets
Тут всё меняется точно также, хотя смысла в этом немного — любой всё равно увидит адрес этой папки в вёрстке сайта. Но всё же смысл есть — хотя бы запутать пытающихся опознать CMS.
$modx_assets_path = '/home/youruser/public_html/4ssetsh3r3/';
$modx_assets_url = '/4ssetsh3r3/';
И, опять же, эту папку можно перенести на другой домен (например, оптимизированный для хранения статических файлов).
И что теперь с этим всем делать?
После того, как изменил пути, сохрани новые адреса в безопасном месте (где-нибудь рядом с паролями, например) и перезапусти установку MODX, чтобы убедиться, что все изменения отработают как надо.
Всё это сделает сайт более безопасным, но затруднит его обновление. Теперь придётся вручную копировать новые файлы некоторых компонентов в нужные директории при каждом обновлении.
Изменение страницы входа
В идеале неплохо было бы переверстать страницу входа так, чтобы не было очевидно, что это MODX. Хотя бы убрать кричащие об этом логотип и копирайт. Как работать с темами оформления админки, читай тут.
Изменение префиксов таблиц базы данных
Лучше всего это делать при первоначальной установке, но никогда не поздно. Отказаться от дефолтного modx_ в пользу кастомного префикса полезно, поскольку это затруднит работу хакеру, который как-то заимел возможность делать SQL-инъекции в твою базу.
Не используй имя admin
Если имя администратора сложно угадать, это замедлит брут-форс. Рандомный набор букв — наиболее безопасный вариант. Никогда не используй слишком простые для угадывания имена — admin, manager или имя, совпадающее с доменом или названием сайта. Помни, что немалую часть хакерской атаки составляет социальная инженерия. Затрудни злоумышленникам задачу по максимуму — сделай невозможным угадывание логина администратора.
Ужесточи пропускной режим
Удали всех праздных юзеров. Например, если в процессе создания сайта был создан аккаунт разработчика, убедись, что он деактивирован по завершении работы. Удостоверься, что у всех пользователей с доступом в админку сложные пароли.
Настрой страницу 404
То, что в системных настройках по умолчанию в качестве 404 установлена главная страница, не значит, что так и должно быть. Выдели для этого отдельную страницу. Мы же не хотим привлекать к сайту лишнего внимания? К примеру, сканер ищет известную уязвимость по адресу твой.сайт/malicious/hack, и вместо страницы 404 ему отдаётся главная страницы с кодом 200. Таким образом, мы заставляем его «думать», что на сайте есть страница с уязвимостью, которой на самом деле нет. Это повлечёт дополнительные сканирования и попытки взлома, что отнюдь не прибавит сайту безопасности. Воспользуйся браузерным веб-иеспектором или другим инструментом, чтобы убедиться, что страница 404 на самом деле отдает код 404.

Настаивай на SFTP

Главная заповедь этого раздела: «НИКОГДА НЕ ИСПОЛЬЗУЙ FTP!!!» Если твой сервер не поддерживает SFTP, найди другой хостинг. Даже общие сервера в большинстве своём имеют общие сертификаты для безопасного доступа.

Установи SSL-сертификат для админки

Передавать логины и пароли в нешифрованном виде неумно — любой начинающий хакер может их перехватить. Если безопасность в приоритете, доступ к админке MODX всегда должен осуществляться по защищённому протоколу https.
Использование общего сертификата
Так же как с FTP, если твой сайт расположен на общем хостинге, часто ты можешь пользоваться и общим сертификатом. Это, конечно, приведёт к уродским url, но — дамы и господа, не ставьте эстетику выше безопасности.
Уточни у своих хостеров, как ты можешь использовать общий сертификат. Для примера, иногда это можно делать через HOST_NAME и имя пользователя, либо через IP-адрес и имя пользователя:
'https://myhost.com/~myuser/manager'
'https://127.0.0.1/~myuser/manager'
Само собой, 127.0.0.1 — адрес лишь для примера, ну и ты уже поменял дефолтный адрес папки manager, поменял ведь?
Использование самозаверенного сертификата
Предыдущий вариант годится «чтобы было», но для любого серьёзного проекта имеет смысл установить собственный SSL-сертификат. И в этом случае пора поговорить о выделенном IP-адресе. Множество незащищённых HTTP-соединений прекрасно уживаются на одном сервере, однако протокол HTTPS, как правило, требует отдельного IP. Большинство хостинг-провайдеров предоставляют выделенный IP-адрес за дополнительную плату (как правило, лишние рублей 50-100 в месяц).
Обзаведясь выделенным IP, ты сможешь установить на сайт SSL-сертификат. Теперь возникает дилемма: а какой?
Самый дешёвый вариант — самозаверенный сертификат. Технически, он ничуть не менее надёжен, чем тот, за который нужно заплатить, но из-за политики «доверия» и того, как запрограммированы браузеры, такой сертификат будет вызывать браузерное предупреждение:




Почему? Потому что никто не в курсе, кто ты такой есть. Кто ты такой, чтобы подписывать себе сертификат? Вообще-то всё равно, кто его подпишет, но если ты не одна из немногих доверенных организаций, кто делает это официально, браузеры тебя проклянут — и будут правы. Вспомни Арабскую весну. Правительство Сирии выпустило поддельный сертификат, чтобы шпионить за аккаунтами граждан на Facebook. Мораль такова: видишь в браузере предупреждение — убегай. Но если это твой сертификат, то себе-то ты можешь доверять (или нет?) И если твои клиенты доверяют тебе, можешь смело рекомендовать им игнорировать такие предупреждения на твоём сайте.
Это совершенно законное решение в определённых ситуациях. Так что, если это только для тебя — развлекайся, устанавливай самозаверенный сертификат. Точные инструкции зависят от твоего сервера, но вот тут, к примеру, небольшой мануал для OpenSSL.
Установка доверенного сертификата
Если браузерные предупреждения для тебя или твоего клиента неприемлемы, тогда придётся платить. Цены на сертификаты разнятся просто до абсурда, а практическую разницу трудно заметить, так что не покупай первый попавшийся — поищи выгодное предложение. Вот несколько ссылок для старта:
(от переводчика: практически у всех отечественных хостеров и регистраторов доменных имен можно приобрести сертификат по довольно неплохим ценам. Рег.ру, к примеру, выдаёт бесплатный сертификат на год для доменов, зарегистрированных у них).
Сам ты генерируешь .crt-файл, или покупаешь его, — так или иначе, мечта сбывается — твоё соединение зашифровано. Теперь твой сайт можно открыть по защищенному протоколу. Осталось сделать это обязательным для админки.
Принудительное SSL-соединение для админки
Подключив свой сайт к защищённому протоколу HTTPS, необходимо заставить админку открываться только через него. Для начала убедись, что сайт открывается по обоим адресам: 'http://твой.сайт/' и 'https://твой.сайт/'.
Удостоверившись, что HTTPS работает, отредактируй .htaccess в папке manager (или как ты там её назвал до этого), чтобы заставить все обращения в эту папку проходить через порт 443 (т. е. через шифрованное соединение). Например так:
RewriteEngine On
RewriteBase /
RewriteCond %{SERVER_PORT} 80
RewriteRule ^(.*)$ https://твой.сайт/manager/$1
Проверь, что вышло, — попробуй зайти в админку через небезопасный протокол (http://твой.сайт/manager). Если тебя не перекинуло на 'https://твой.сайт/manager', придётся ещё поколдовать над .htaccess. В интернете можно найти несколько вариантов подобной переадресации.

Мониторинг сайта и сервера

Единожды прокачав систему безопасности своего сайта и сервера, не стоит забывать об их регулярном мониторинге. Существуют некоторые бесплатные службы на эту тему. К примеру, они могут отслеживать изменения определённых файлов и сообщать о них. Ведь, если, скажем, внезапно на твоём сайте был отредактирован файл index.php, скорее всего это означает, что это сделал кто-то посторонний и недобрый.
mngatoff
15 февраля 2016, 02:03
57
14 970
+13

Комментарии: 58

Сергей Шлоков
15 февраля 2016, 07:08
0
+1. Хорошая работа. Информация полезная, я бы попросил сохранить её в доках на docs.modx.pro.
начать брут-форс соответствующими программами.
Тут тоже напрашивается вольный перевод. :)
    Волков Николай
    15 февраля 2016, 10:28
    -1
    Согласен, работа хорошая, но не для доков. Все таки мне кажется, что «чувак» и тп выражения не соответствуют официальному формату.
      Сергей Шлоков
      15 февраля 2016, 10:49
      0
      Доки открыты. Любой желающий может вносить правки. Просто тут это затеряется.
      mngatoff
      15 февраля 2016, 12:35
      +2
      Товарища, которым писал это на rtfm.modx.com официальность ресурса не смутила) ох уж эта наша национальная серьёзность
        Волков Николай
        15 февраля 2016, 13:34
        0
        Ну да, менталитет другой абсолютно. Не удивлюсь, если там еще на 3 буквы будут посылать кого-надо :-)
    mngatoff
    15 февраля 2016, 12:36
    0
    корявенько вышло, да. Поправил
Борода
15 февраля 2016, 10:47
+1
Лучи добра тебе!
    Иван Климчук
    15 февраля 2016, 11:03
    +2
    Понятно, что перевод и на тот момент еще не было релиза, но валидный SSL-сертификат теперь можно получить абсолютно бесплатно на letsencrypt.org/
      mngatoff
      15 февраля 2016, 11:57
      0
      я больше скажу, теперь не всегда и выделенный IP нужен для этого
    Иван Климчук
    15 февраля 2016, 11:04
    0
    Упс, промазал с кнопкой.
Алексей Федоров
16 февраля 2016, 11:42
0
Отлично! Огромное спасибо за перевод, буквально в прошлом месяце делал все операции по англоязычной инструкции, то еще мучение было.
Теперь возник новый вопрос. Как обновить «закаленную» установку modx. Вот я поменял все пути, обозвал ассетс и менеджер другими именами, вынес core за корень сайта в public_html и тут увидел, что вышла версия modx 2.4.3. Как его теперь правильно обновить со всеми этими новыми путями?
    Алексей Федоров
    16 февраля 2016, 15:43
    +1
    Поскольку инфы не нашел, сделал «методом научного тыка». Скачал новый дистрибутив, закинул архив на хостинг, распаковал в корне сайта, затем перенес содержимое всех переименованных папок в соответствующие. assets -> new_assets, connectors -> new_connectors и т.д. (содержимое core из скачанного пакета само-собой тоже перенес))
    Папка setup осталась в корне, запустил sitename.ru/setup/ получил предупреждение, что по адресу public_html/sitename.ru/core/ не найден файл config, и просьбу указать к нему путь. Поскольку папка core вынесена за корень, то соответственно прописал public_html/core/

    Выбрал обновление системы без изменений, все прошло успешно. Были небольшие проблемы на сайте, почистил папку cache внутри core и все стало отлично. Очевидно, делать это нужно перед обновлением системы))
    Затем пришлось все лишние папки на хостинге удалять вручную. Теперь я счастливый обладатель modx 2.4.3 pl
    Надеюсь, если что-то сделано не так, специалисты подправят
      Борода
      17 февраля 2016, 07:28
      0
      Тоже, кстати, думал о том, как обновлять потом с переименованными папками)
      Что то у меня не сходится вот эта твоя фраза:
      затем перенес содержимое всех переименованных папок в соответствующие
      По тексту получается ты перенёс содержимое из своих переименованных папок в оригинальные новые скачанные. А по описанию дальше наоборот, из новых скачанных в свои переименованные.
      assets -> new_assets, connectors -> new_connectors и т.д
      Как в итоге правильно делать то?
        Алексей Федоров
        17 февраля 2016, 08:46
        0
        Содержимое папок нового дистрибутива в переименованные папки.
        assets -> new_assets, connectors -> new_connectors и т.д.
        То есть новое содержимое в старые (переименованные) папки.

        И еще раз уточню, я далеко не спец в разработках и всех этих серверных делах, сайт пока скорее тестовый, чем рабочий, поэтому ни чем особо не рисковал. Не забудь перед обновлением бекап сделать, а то мало ли
          Борода
          17 февраля 2016, 08:49
          0
          Понял. По моей логике тоже надо так действовать) Резервные копии это само собой)
          Борода
          17 февраля 2016, 10:48
          0
          Обновился по этой же схеме, предварительно очистив кеш. Полёт нормальный, видимо, так и надо делать, что вполне логично. Но у меня только папка manager переименована, ввиду того, что уже установлено много компонентов и у них прописаны пути через папку assets.
          Остальное защитил по совету Василия.
            mngatoff
            17 февраля 2016, 11:35
            0
            в кошерных компонентах пути устанавливаются через assets_url, в своих шаблонах тоже лучше писать [[++assets_url]], чем assets/. Тогда при переименовывании папок ничего не пропадёт
              Борода
              17 февраля 2016, 12:59
              0
              Буду иметь ввиду) Как нибудь опробую, как время будет) Хотя особо смысла прятать, что Я использую Модэкс смысла не вижу) Всё равно в robots.txt надо будет эти папки прописывать) Да и по названию компонентов в коде можно понять)
              Считаю, что главное это защитить по возможности так, чтобы гемороя потом меньше было с обновлением компонентов и прочего)
                mngatoff
                17 февраля 2016, 13:09
                0
                в роботсе нужно писать только то, на что где-то в коде есть ссылки, как уже обсуждалось выше:) а ссылки есть только на assets. Собственно, и об этом в статье сказано — есть смысл переименовывать эту папку только из вредности, так как сканер CMS знает стандартную структуру популярных CMS и сверяется с ней. В случае с revo — это папки assets, manager, connectors и core. Суть в том, чтобы обманывать — так до конца, чтобы даже assets не было. Ну и config.core попрятать, как уже в другой теме обсуждалось
                  Борода
                  17 февраля 2016, 14:01
                  0
                  Вот только робот поисковиков и по другим папкам умеет лазить, независимо от того, как они называются) От него и закрывают их) Ну переименую Я /assets. Всё равно в коде останется
                  <script type="text/javascript">TicketsConfig= ...
                  <script type="text/javascript">TicketsConfig.editor={ticket: {onTab: {keepDefault:false, replaceWith:"	"} ...
                  <link rel="stylesheet" href="/new_assets/components/tickets/js/web/editor/editor.css" type="text/css" />
                  <link rel="stylesheet" href="/new_assets/components/tickets/css/web/default.css" type="text/css" />
                  <script type="text/javascript">TicketsConfig.formBefore = 0;TicketsConfig.thread_depth = 0;</script>
                  Как по мне, так овчинка выделки не стоит, чтобы копаться во всех компонентах, для изменения кода) Каждому своё конечно)
                  Вот в расширенной установке config.core можно вообще переименовать, странно, что в этом руководстве этого нет)
                    mngatoff
                    17 февраля 2016, 14:11
                    0
                    я об этом и говорю — как папку не назови, она будет в коде видна. Но только она. Connectors и manager ни в исходном виде, ни в переименованном, нигде на фронтенде не упонимаются (ну если только специально).
                    поэтому ассетс (или как вы ее назовёте) нужно вписывать в роботс. Connectors и manager — нет. А переименовать assets — только из вредности, чтобы совсем не совпадать с шаблоном.
                    Вот в расширенной установке config.core можно вообще переименовать, странно, что в этом руководстве этого нет)
                    Статья про обычную установку, о расширенной в ней говорится только то, что не везде она без проблем устанавливается. Файл config.core не упоминается вовсе. Я например только отсюда понял, что он тоже палится
                      Борода
                      17 февраля 2016, 14:49
                      0
                      Да дело не только в папке, по названию компонента можно понять, что за CMS)
                      Были прецеденты, когда в кэш поисковиков попадала служебная инфа) Поэтому лучше от робота закрыть все лишние папки, чтобы ему проще было индексировать контент) В том числе connectors и manager, как их не назови) Опять же, это моё мнение, основанное на собственном опыте) Поэтому Я просто закрыл их по совету Василия)
                      Я понял, что про обычную установку, поэтому все манипуляции делаются уже после) Я к тому, что тут нет именно про переименование конфиг.кора после установки. По идее, переименуй его и не надо прятать)
    Виталий Батушев
    16 февраля 2016, 12:41
    +2
    Перевод, действительно, отличный и написан живо и грамотно.

    Правда, как филолог, не могу не сделать несколько замечаний, которые, впрочем, не носят характер назидания.
    1. «Своего писать я» правильнее «Свое писать я».
    2. «перевести… с официальной документации» правильнее «перевести… из официально документации»
    3. «вольным, что касается формулировок» правильнее «вольным в том, что касается формулировок»
    4. Следовательно, дальше фраза должна быть выстроена, к примеру, так: «Но в технических деталях старался быть предельно точным». Дотошно — это и есть точно — до + точно. Дотошно точный — это масляное масло.
    5. «Аудит» лучше заменить «проверкой», как в плане импортозамещения, так и просто потому что аудит (по-русски) предполагает стороннюю проверку, а тут предполагается проверка собственными силами.
    6. Первые три фразы «Обзора» не связаны между собой логически. Хорошо, «закалка» предполагает проверку. Но почему вслед за этим утверждением меня тут же предостерегают об ошибке? Я ведь собрался проверять, а тут меня — стой, не делай ошибки. Странно же. Думаю, что необходимо добавить нечто вроде «Не откладывай эту проверку на потом, на завтра или на «как время появится». Не совершай ошибку…» и далее по тексту.
    7. Таки «прокачка» или «закалка»? Может, оба термина слишком жаргонны и не отражают сути?
    8. Перед «например» в последнем предложении подраздела «Компьютер» нужна запятая.

    И да, смешивание стилей научного доклада с использованием третьего лица множественного числа («мы рекомендуем» и т. п.) с неформальным с обращением на «ты» не есть правильно.
    А в основном, могу только еще раз сказать — очень хорошо, просто отлично.
      mngatoff
      16 февраля 2016, 16:14
      1
      0
      могу Вас заверить, что пункты с первого по четвертый мне прекрасно известны, и то, что я написал именно так, было связано исключительно с тем, что мне так захотелось. Никаких правил языка я при этом не нарушил — так как статья — а, следовательно, и перевод — написаны в разговорном стиле, вряд ли тут уместны чрезмерные академические изыскания.
      Слово «Аудит» гораздо полнее передаёт глубину и скрупулёзность процедуры, так уж исторически сложилось. Не люблю импортозамещения.
      Первые три предложения «Обзора» у меня и в оригинале вызывали вопросы своим построением, но мысль они тем не менее передают, так что эта чехарда перетянута оттуда. В конце концов, кто я такой, и так далее.
      По поводу пункта 7 — предложите свой вариант. «Закалка» — это прямой перевод оригинального hardening, «прокачка» используется во избежание постоянных повторений. Оба слова достаточно точно передают суть процесса для человека, хотя бы шапочно знакомого с предметом.
      Запятая перед «например» в данном случае необязательна, я следую за интонацией — это моё право на «авторскую пунктуацию».
      Именно поэтому я и просил во вступлении — без филологических претензий, пожалуйста) но за столь пристальное внимание — спасибо.
    Алексей Карташов
    16 февраля 2016, 15:53
    +1
    Эх, намучался я в своё время с папкой core, которая лежала выше корня сайта и не была доступна из веб. Самое банальное — даже advanced установщик modx не может обновить систему, потому что тупо не видит этой папки, а задать ему путь можно только от "/" (т.е. от корня сайта), вроде бы.
    Плюс невозможно окончательно и бесповоротно сбросить кеш, удалив папку core/cache, потому что из файлового менеджера она не видна и надо лезть на сервер по ssh.

    Короче, вынося папку core за пределы сайта, будьте готовы к приключениям :)
      Василий Наумкин
      16 февраля 2016, 19:05
      0
      А еще нельзя зайти и подебажить какой-нибудь компонент через админку, что очень часто требуется при поддержке дополнений.
        Wassi Wassinen
        16 февраля 2016, 19:10
        0
        И при таком варианте очень быстро устаешь давать доступы рутового юзверя сторонним разработчикам, админам и вебмастерам, так как банально не могут сбросить кеш сайта или обновить систему до следующей версии.

        Выше написали. Пардон. :)
        mngatoff
        16 февраля 2016, 20:19
        0
        это да. Я такое практикую только у хостинга с удобным интерфейсом
      terlim
      25 марта 2017, 17:04
      +1
      Можно подключить вынесенную папку core как еще один источник файлов. в Настройках источника файлов указать basePath полный путь до папки. А basePathRelative выставить в НЕТ. Тогда папка core доступна из админки.
    Yar
    Yar
    08 мая 2016, 13:33
    0
    Чо-то после:
    Переименуй папку. Затем отредактируй core/config/config.inc.php. Должно получиться что-то такое:
    $modx_manager_path = '/home/youruser/public_html/r4nd0m/';
    $modx_manager_url = '/r4nd0m/';
    При открытии mysite.ru/r4nd0m в браузере появляется сообщение:
    Could not find action file at: /home/r/youruser/mysite.ru/public_html/r4nd0m/controllers/default/security/login.php
    Попробовал создать пустой файл login.php, но не прокатило. Переустановку MODX не делал.

    Кто знает почему такая ошибка?
      Сергей Шлоков
      08 мая 2016, 19:34
      +4
        Yar
        Yar
        08 мая 2016, 19:43
        0
        ))) Папку cache под ноль и стало ок, спасибо!
    Yar
    Yar
    08 мая 2016, 19:54
    0
    А вот на главной панели MODX Revo 2.43 есть такое сообщение:
    В настройках системы присутствуют ошибки:
    Каталог ядра в открытом доступе
    MODX обнаружил, что ваш основной каталог (частично) доступен для общественности. Это не рекомендуется из соображений безопасности. Если ваша установка MODX выполняется на веб-сервер Apache, вам следует по крайней мере настроить файл .htaccess внутри каталога с файлами ядра: /home/r/youruser/mysite.ru/public_html/core/. Это можно легко сделать, переименовав уже имеющийся там файл ht.access в .htaccess.
    Файл переименовал, но сообщение осталось.

    Как настроить .htaccess и не перенося ядро за пределы корневого web-каталога спрятать core из открытого доступа?
    Вот содержимое файла /home/r/youruser/mysite.ru/public_html/core/.htaccess:
    IndexIgnore */*
    <Files *.php>
        Order Deny,Allow
        Deny from all
    </Files>
      mngatoff
      09 мая 2016, 11:04
      0
      во-первых, вторую и пятую строчки можешь смело удалить. А во-вторых, если на хостинге статичные файлы отдаются через nginx, то ошибка никуда не денется, т. к. nginx работает мимо htaccess. Проверь файлик changelog.txt, если отправляет на 403 или 404, значит все норм, забей на сообщение.
        Yar
        Yar
        15 мая 2016, 10:54
        0
        Спасибо за ответ!
        Вторую и пятую строчки удалил, однако файл changelog.txt продолжает открываться…
    AdamMort
    21 июня 2016, 00:48
    0
    Люди добрые помогите пожалуйста — что подразумевается под — «отредактировать конфиги»??
    Как именно это сделать? Как я понимаю нужно поменять пути, но как правильно это сделать?
    Особенно меня инетересует — «Таблица modx_workspaces в базе данных сайта.»
    Ибо я поменял пути, но видимо неправильно ведь теперь раздел — /manager/ не работает
    Выдаёт — HTTP ERROR 500 страница не работает

    «Когда папка перенесена, нужно отредактировать конфиги:
    core/config/config.inc.php (переменная $modx_core_path)
    /config.core.php (в корне сайта)
    /connectors/config.core.php
    /manager/config.core.php
    Таблица modx_workspaces в базе данных сайта.»
    Дарья Сизова
    15 декабря 2017, 15:18
    0
    Здравствуйте! Хочу перенеси папку core за пределы корневого web-каталога. Поясните, пожалуйста, для новичка, что именно нужно сделать с таблицей modx_workspaces?

    Таблица modx_workspaces в базе данных сайта. Правильнее всего — перезапустить установку сайта, как при обновлении или переносе, чтобы убедиться, что всё работает правильно.
      Андрей П
      15 декабря 2017, 16:17
      0
      перезапустить установку сайта, как при обновлении или переносе, чтобы убедиться, что всё работает правильно
      Вы же сами цитируете. Иначе говоря, по фтп закидываете MODX с заменой файлов и производите обновление стандартным способом. Папку cache из core не забудьте удалить
    Анна
    28 марта 2018, 12:31
    0
    Здравствуйте!
    Помогите, пожалуйста… Установила MODX с вынесением ядра за пределы корневой директории сайта… На поддомене с указанием в .htaccess «RewriteBase /publik_html» все работало нормально, но после присоединения домена к папке «publik_html» все ссылки формируются с указанием данной папки и не работают, получается что-то типа site.ru/publik_html/ssylka… В чем может быть проблема? RewriteBase для основного домена переписан на "/"
    rexen
    07 апреля 2019, 21:55
    0
    Статья явно требует значительной правки. И стара (про letsencrypt) и невнятна местами — читай коменты. Сам долго мучался-искал как админский шаблон клонировать и править уже не дефолтный, а клона.
    Rostyslav
    16 мая 2019, 00:46
    0
    доброго времени суток а что делать с файлом robots.txt если я переименую manager connectors и assets как запретить индекс он у меня такой

    User-agent: * # правила для всех роботов
    Disallow: /cgi-bin # папка на хостинге
    Disallow: /manager/ # авторизация
    Disallow: /assets/ # папка с системными файлами modx
    Disallow: /core/ # папка с системными файлами modx
    Disallow: /connectors/ # папка с системными файлами modx
    Disallow: /index.php # дубли страниц index.php
    Disallow: *?* # ссылки с параметрами
    Disallow: *utm*= # ссылки с utm-метками
    Disallow: *openstat= # ссылки с метками openstat
    Disallow: *from= # ссылки с метками from

    Sitemap: mysite/sitemap.xml

    Host: mysite
      mngatoff
      16 мая 2019, 00:52
      1
      0
      удалять нафиг.
      и писать нормальный.
      ваш сейчас — это как бумажка с логином и паролем на рабочем компе
      mngatoff
      16 мая 2019, 00:54
      1
      0
      User-agent: *
      Allow: /assets/*.js
      Allow: /assets/*.css
      Allow: /assets/*.svg
      Allow: /assets/*.png
      Allow: /assets/*.jpg
      Allow: /assets/*.jpeg
      Allow: /assets/*.JPG
      Allow: /assets/*.woff
      Allow: /assets/*.woff2
      Allow: /assets/*.ttf
      Disallow: /assets/
      Disallow: *?
      Clean-param: utm_source&utm_medium&utm_term&utm_content&utm_campaign&_openstat&campaign&clid&gclid
      Sitemap: mysite/sitemap.xml

      больше ничего не нужно
        Rostyslav
        16 мая 2019, 01:02
        0
        то что удалью в индекс не попадет? или может с помощью .htaccess закрыть их если такое возможно
        спасибо
        mngatoff
        16 мая 2019, 01:07
        1
        0
        в индекс попадает только то, на что есть публичные ссылки.

        на папку manager нигде ссылок не должно быть, поэтому она в индекс не попадет. так же как core, connectors и все такое прочее.

        папка cgi-bin вообще не доступна извне.

        index.php должен редиректиться через htaccess, и соответственно тоже не будет проиндексирован
          Rostyslav
          16 мая 2019, 01:23
          0
          а если убрать все и просто оставить Sitemap: mysite/sitemap.xml тогда вообще палится движок сайта не будет
            mngatoff
            16 мая 2019, 01:27
            1
            0
            тогда проиндексируются ненужные файлы из assets, а также ссылки с гет-параметрами
              Rostyslav
              16 мая 2019, 01:39
              0
              Спасибо. последний вопрос я когда начал делать сайт на modx то создал каталог, и все картинки скрипты, шрифты положил туда, а в assets только падает галерея minisop2 и еще есть каталог components, мне следует поменять путь галереи minisop2 и в robots указывать этот каталог?
                mngatoff
                16 мая 2019, 01:43
                1
                0
                закройте свой каталог так же как assets
                  Rostyslav
                  16 мая 2019, 01:46
                  0
                  Огроменнешое спасибо вам и автору этого поста, а то сегодня заметил что-то не ладное творится с сайтом, пару раз ошибка что сайт не доступен или не настроен на сервере
    Rostyslav
    17 мая 2019, 00:09
    0
    добрый день может ктото сталкивался на сайте установлен FiveStarRating после вынесения core пререймнования папок перестал работать
Авторизуйтесь или зарегистрируйтесь, чтобы оставлять комментарии.