Обновление Advanced версии MODx до новой версии

https://modx.pro/howto/7902

 

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

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

Закалка любого веб-приложения (не исключая 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.

Установка доверенного сертификата

Если браузерные предупреждения для тебя или твоего клиента неприемлемы, тогда придётся платить. Цены на сертификаты разнятся просто до абсурда, а практическую разницу трудно заметить, так что не покупай первый попавшийся — поищи выгодное предложение. Вот несколько ссылок для старта:

• Thawte
• EV
• Verisign
• Positive SSL
• GeoTrust
• Comodo

(от переводчика: практически у всех отечественных хостеров и регистраторов доменных имен можно приобрести сертификат по довольно неплохим ценам. Рег.ру, к примеру, выдаёт бесплатный сертификат на год для доменов, зарегистрированных у них).
Сам ты генерируешь .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, скорее всего это означает, что это сделал кто-то посторонний и недобрый.