Защита сайта на MODX Revolution. Защита сайта modx
ObfuscateEmail Revo MODX Revolution. Защита email адресов MODX
Что делает:
MODX Revolution плагин незаметно работает в фоновом режиме, аккуратно выделяя все e-mail, которые обнаружит на заданной странице – и в виде ссылок, и в виде обычного текста. Он найдет все e-mail адреса, соответствующие RFC2822, даже с обычно неиспользуемыми, но разрешенными символами.
Как работает:
Превращает [email protected] в
Для кого это работает:
Для все пользователей проекта, связанных с внешними e-mail адресами, с e-mail адресами этого же сайта и т.д.
Он просто работает со всеми e-mail адресами.
Дополнительная функциональность.
Т.к. плагин работает в фоновом режиме, есть возможность выполнять другое задание. Он постоянно выполняет рандомизацию кодировки e-mail адресов, чтобы она постоянно изменялась, при этом все e-mail приложения продолжают работать безошибочно и поддерживают простые операции “вырезать и вставить”.
Примеры
Это добавляет дополнительный уровень защиты. Нижеприведенные три примера – это один и тот же e-mail адрес на одной и той же странице:
Установка с помощью Менеджера пакетов
Просто загрузите и установите с помощью Package Manager. Если другие OnWebPagePreRender события присутствуют в проекте, приоритет запуска может быть задан в соответствующем плагине, при необходимости.
Код так же доступен для загрузки через Github
Ручная установка
- Создайте новый плагин.
- Вставьте код, загруженный из github.com/wshawn/ObfuscateEmail
- Кликните по опции OnWebPagePreRender на вкадке событий (в самом низу)
- Сохраните плагин.
Защита проекта и пользователей.
С помощью данного плагина очень просто защищать папку Входящие любых e-mail адресов, размещенных на ваших страницах.
Защитите ваших пользователей, и сделайте это красиво!
История разработки
Данный плагин изначально создан для MODX Evolution Aloysius Lim: modx.com/extras/package/obfuscateemail. “Когда я перепрыгнул на MODX Revolution несколько лет назад, я захватил с собой и этот плагин, т.к. он служил моим клиентам верой и правдой. С выходом MODX Revolution 2.1, из-за измененного кода, пришлось сделать несколько обновлений плагина. Я надеюсь, что вы найдете MODX Revolution 2.1 таким же эффективным, как и я на протяжении многих лет ”.
www.modx.cc
Защищаем MODX Revolution
Привет, друзья!
Немало статей написано и переписано о том, как защитить MODX, но в этой статье я опишу не только стандартные рекомендации по защите инстанса MODX Revolution (далее я буду писать просто MODX, потому что ветка MODX Evolution — это тупиковая ветвь «эволюции» являющаяся рудиментом не заслуживающим внимания современных разработчиков), но и некоторые новые методы «заметания следов».Итак, начнем самого важного.
Существует две разновидности установщика MODX — это Traditional и Advanced.Какая между ними разница?
Traditional — это простой вариант установки на любой хостинг соответствующий рекомендациям для установки MODX, где ядро устанавливается прямо в корень публичной папки сайта. Незатейливые «сайтоклёпы» ставят версию Tradtiional, не закрывают директории от просмотра и в итоге всё содержимое сайта, в т.ч. служебных директорий, попадает в индекс поисковиков. Не станем фантазировать на тему, к чему это может привести. Здесь всё понятно.
Advanced — версия для парней, которые, как минимум «смотрели кино про нидзей». Этот вид установщика позволяет разместить ядро MODX вне публичной папки, спрятав его от посягательств злоумышленников. Для серьезных проектов это рекомендуемый вариант, но лично я его использую всегда.
Защита ядра
Защитить ядро можно двумя способами:
1. На нормальном хостинге — вынести ядро из публичной папки и можно его не переименовывать и не настраивать .htaccess лежащий в этом каталоге (на VDS не стоит забывать о настройке прав доступа пользователя, от которого запускается Apache).
2. На дурацком хостинге — переименовать каталог ядра воспользовавшись, например, генератором паролей (без спецсимволов, конечно же — только буквы и цифры) И во время установки указать физический путь к каталогу ядра. Именно по этому лучше использовать Advanced установщик.
Защита служебных каталогов
Не секрет, что кроме каталога ядра, другие служебные каталоги должны остаться в публичной папке сервера.
Что нам сделать для защиты от попыток взлома через коннекторы и попыток проникнуть в админку? Стандартные наименования каталога коннекторов /connectors, а для админки — /manager, и это палево.
Во время установки вам будет предложено изменить эти названия. В этом нам поможет, правильно, — генератор паролей и, как ни странно, в случае с админкой собственная голова. Название каталога админки лучше сделать человекопонятным, но не /admin, конечно же :)
Возможно, вы захотите спросить: Почему мы не прячем /assets?И, возможно, я отвечу: А зачем? Все картинки и скрипты лежат в /assets, а в коде страницы есть все ссылки на картинки и скрипты :)
Защита таблиц БД
Во время установки, в настройках БД, по умолчанию предлагается префикс таблиц «modx_». Так дело не пойдет. И вновь нам поможет генератор паролей (Помнишь, товарищ? Только из букв и цифр!). Меняем стандартный префикс на кракозябры, в конце которых ставим нижнее подчеркивание. Например, «IU1xbp4_».
Защита от определения CMS
Сервисы автоматического определения CMS сайтов, конечно, не в курсе, что MODX — это CMF, но это не мешает им определить, что контентом на сайте рулит именно MODX. Казалось бы, мы уже спрятали всё что надо. А вот и нет.
Для примера, возьмем первую ссылку из приведенного выше списка поиска Google, и попробуем открыть файл настроек config.core.php, или, не смотря на то, что на этом сайте уже закрыт листинг каталогов, по ссылке «www.vvhotel.ru/core/config/config.inc.php», сайт отдает результат исполнения файла .php, а это значить что каждый из этих файлов существует и даже по первому из них можно предположить, что сайт на MODX.
Скрыть этот файл можно при помощи .htaccess, дописав:
<IfModule mod_rewrite.c> RewriteCond %{REQUEST_URI} ^(.*)config.core.php$ RewriteRule ^(.*)$ [R=404] </IfModule>Кое-что ещё
Кроме описанных приёмов, можно применить небольшую хитрость, чтобы увести возможных злоумышленников по ложному следу. Некоторые «попсовые» CMS добавляли метатэги с указанием названия CMS:
<meta name="generator" content="WordPress x.x.x" />Можно смело добавить в свой код такой тэг, и создать фэйковую стандартную страницу входа в админку указанной версии имитируемой CMS.
Автоопределялки будут интерпретировать наш MODX как WordPress, а если хулиганы захотят залезть в админку, то будут долго и нудно пытаться подобрать отмычки от простого замка к сканеру сетчатки глаза ( это метафора :) ).
А что, если сайт уже установлен?
В час наименьшей нагрузки, переименуйте все указанные каталоги (/core, если позволяет хостинг, лучше вынести из паблика).
Смените префикс существующих, с помощью phpMyAdmin:
- в левой части phpMyAdmin кликаете на название нужной базы;
- в основной области появится список всех таблиц, внизу которого надо отметить чекбокс «Отметить все»;
- справа от чекбокса комбобокс «С отмеченными:» в котором надо выбрать «Заменить префикс таблицы»;
- в новом окне указать старый префикс и новый префикс, на который надо заменить старый.
Затем, если у вас Traditional, но вы хотите заменить на Advanced, то поверх содержимого /core (или как вы его по-новому назвали) надо записать содержимое каталога /core из архива Advanced установщика, а в корень сайта поместить /setup.
Проверить права и доступ (на каталоги 755, на файлы 644).
Запустить процесс установки.
Во время установки вам надо будет указать физический путь до каталога ядра.
ВАЖНО выбрать вариант установки «Расширенное обновление (с настройкой параметров базы данных)», потому что после ввода данных БД, появится диалог переименования каталогов.
Можно, конечно, было залезть в config.inc.php и отредактировать всё там. Но зачем что-то делать, если этого можно не делать? :)
На этом всё. Если информация из этой статьи окажется Вам полезной — супер. Если захотите что-то спросить, добавить или просто поумничать — вэлкам в коменты!
Автор: Scissor
Источник
www.pvsm.ru
Защита MODX Revolution | Веб-разработчик Илья Ершов
На этапе инсталляции системы
1) Обязательно меняйте префиксы таблиц базы данных (advanced дистрибутив MODX), это создаст проблем хакеру использующему SQLi.
По умолчанию при установке MODX префикс указан: modx_ - меняйте его на что-нибудь персональное, например:
- revo_ (не самый оригинальный вариант)
- mmm_
- sd_
- ivan_
- cmf_
- #@!_
Потому, что когда через слабозащищённые модули принимающие информацию вводимую пользователем вам будут пихать SQL инъекции, в первую очередь будут долбить в modx_users
2) Переопределяйте пути к папкам:
- /manager/
- /connectors/
- /core/
Опция переопределения путей имеется в дистрибутиве MODX типа advanced, в traditional такой опции нет. Это именно те места, где хакеры будут искать уязвимые скрипты и будут стараться обращаться к ним напрямую. Большую опасность представляет даже не папка /manager/, а /connectors/.
На уже действующей системе
Можно закрыть к пикантным разделам доступ по IP адресу, если вы заходите всё время только с определённых адресов. Это серьёзно усилит вашу оборону.
Содержимое файла .htaccess тривиально (гуглится надёжно).
RewriteEngine Off Order deny,allow deny from all Allow from 159.198.14.84 # home Allow from 160.198.14.84 # work Allow from 161.198.14.84 # cafeСоответственно будет защищено всё, что лежит в одной папке с этим файлом и глубже. Такой файлик можно спокойно класть в /manager/, /connectors/ и /core/. Разве что персонально для /core/ можно запретить прямое обращение к php файлам, добавив:
IndexIgnore */* <Files *.php> Order Deny,Allow Deny from all </Files>эта мера совершенно не помешает в качестве "перестраховаться".
Но если Вы часто обращаетесь к админке своего сайта из разных мест, ездите с ноутбуком по клиентам, конференциям, то задачу можно усложнить. Давать доступ или по IP или по базовой аутентификации через .htpasswd
Для /manager/ и /connectors/
RewriteEngine Off Order deny,allow Deny from all AuthName "htaccess password prompt" # здесь нужно указать абсолютный путь к файлу .htpasswd # он вполне может быть общим для всех сайтов на одном хостинге # файл .htpasswd нужно отдельно генерировать, об этом далее в статье AuthUserFile /home/askapache.com/.htpasswd AuthType Basic Require valid-user Allow from 127.0.0.1 Allow from 192.168.1.1 Satisfy AnyДля /core/
IndexIgnore */* <Files *.php> Order Deny,Allow Deny from all </Files> Order deny,allow Deny from all AuthName "htaccess password prompt" AuthUserFile /home/askapache.com/.htpasswd AuthType Basic Require valid-user Allow from 127.0.0.1 Satisfy AnyУ этого подхода две стороны медали.
Плюсы: Вы получаете требуемую мобильность. Дополнительный пароль не надо вводить в местах, ip которых вы внесли в разрешённые.
Минусы: У злоумышленника удалённого от вас - всё таки остаётся возможность подобрать пароль и получить доступ к вашим "интимным местам"
Генерация htpasswd
Если у Вас есть ssh-доступ на сервер (доступ к командной строке сервера), то Вы можете воспользоваться утилитой htpasswd. Синтаксис команды таков:
htpasswd -c /full/path/.htpasswd имя_пользователяПосле ввода команды будет запрошен пароль и просьба его повторить. В результате будет создан новый файл .htpasswd или же дополнен старый, содержащий логин и зашифрованный пароль. Если Вы хотите добавить новых пользователей, то следует запустить команду с ключом:
htpasswd -m .htpasswd имя_пользователяВ результате в существующий файл с паролями будет добавлена новая строка с именем пользователя и паролем.
Если у Вас нет доступа по ssh, а вероятно только по ftp, то для генерации файла htpasswdможно воспользоваться любым онлайн генератором, например htaccesstools
Общие советы
Изучите систему управления правами доступа MODX. Давайте контент-менеджерам прав ровно столько, сколько им нужно, не больше, со временем если понадобится - добавите.
И в принципе регулярно проверяйте журналы ошибок на предмет подозрительного и кто у вас там вообще на сайте админами числится, а то бывают случаи появляются админы с e-mail'ами типа: [email protected] (хер там, больше не выйдет )))
P.S.
Почему я написал эту статью? В ночь с 5 на 6 марта взломали один из сайтов моих клиентов. Сайт на MODX. Хочу заметить, что этого бы не случилось, если бы они обновляли ПО своего сайта регулярно. На поиск истории взлома, удаление вредоносного кода, обновление ПО и построение дополнительной защиты у меня ушло в сумме 1,5 часа - не так и много по сравнению с вредом, который мог быть нанесён злоумышленником. Не ленитесь - сделайте.
Update 01.04.2014
написал скрипт-обманку пишущий в журнал попытки перебора админок разных CMS.
Удачи!
ershov.pw
Защита сайта на MODX Revolution
Команда разработчиков MODX постоянно проводит аудит кода и исправляет проблемы безопасности разрабатываемой системы управления. Тем не менее, абсолютно защищенных сайтов не существует. При их создании необходимо самому приложить определенные усилия для повышения уровня безопасности интернет-проекта.
Эффективные способы защиты
Перемещение ядра (каталог core)
Ядро приложения должно располагаться в максимально недоступном для доступа извне месте. Лучший вариант решения проблемы – перенести каталог с ядром MODX (core) за пределы корневого web-каталога, то есть выше по дереву файловой системы: к примеру «/core» вместо «/public_html/core». При этом все остальные папки должны быть доступны из Интернет.
После перенесения каталога нужно отредактировать конфигурационные файлы, указав в них новый путь до ядра MODX:
- config.core.php
- connectors/config.inc.php
- core/config/config.inc.php
- manager/config.inc.php
По окончании желательно перезапустить установку сайта как при обновлении.
Смена адреса административной панели
Второе по важности изменение – перенесение админки сайта, что помешает ботам быстро опознать сайт как созданный с помощью MODX. Возможность обнаружения, конечно, остается, но станет значительно сложнее.
Административная панель сайта на MODX по дефолту находится по адресу http://site.ru/manager. Переместить системную папку несложно – достаточно переименовать сам каталог (например, из manager в mysecuresite), а затем указать новый путь в файле конфигурации core/config/config.inc.php.
Регулярное обновление MODX
Всегда обновляйте MODX до последней стабильной версии. Это уменьшит вероятность взлома сайта через уже известные уязвимости.
Требование регулярно обновляться относится не только к самому движку, но и к дополнениям MODX. Для повышения безопасности старайтесь выбирать только проверенные временем дополнения.
Настройка прав доступа
В случае, если над вашим сайтом работает несколько человек одновременно (особенно это касается контент-менеджеров), стоит задуматься над установкой минимально необходимых прав доступа для них.
Маловероятно, что сотрудникам, которые занимаются информационным наполнением сайта, понадобится доступ к системным настройкам, шаблонам, чанкам и сниппетам.
Резервное копирование
Регулярно выполняйте резервное копирование как самого сайта, так и базы данных. Только в этом случае появится возможность быстро восстановить сайт после атаки злоумышленников или случайных некорректных действий с вашей стороны.
Архивы должны создаваться постоянно в автоматическом или ручном режиме и сохраняться на другом физическом носителе, нежели сам сайт. Таких архивов следует создавать несколько, причем держать их необходимо в разных местах.
Кстати, через месяц, 31 марта, отмечается международный день резервного копирования (День бэкапа), призванный привлечь общественное внимание к вопросам обеспечения сохранения информации, а также распространить информацию о необходимости защиты от потери данных.
Если вы только начинаете разворачивать сайт, желательно воспользоваться возможностью расширенной установки MODX Revolution. В этом случае изначально произвести перемещение ядра и смену адреса панели будет значительно проще.
Усилив систему безопасности своего сайта, не забывайте и о регулярном мониторинге: проверяйте журналы ошибок на предмет подозрительных сообщений, список пользователей, изменения критически важных файлов.
Источник: https://modxinfo.ru/modx-securityilyaut.ru
FreelGraf | Защита сайта от взломов
Подсмотрела тут.
На этапе инсталляции системы
1) Обязательно меняйте префиксы таблиц базы данных, это создаст проблем хакеру использующему SQLi.По умолчанию при установке MODX префикс указан: modx_ - меняйте его на что-нибудь персональное, например:
revo_ mmm_sd_cmf_
Потому, что когда через слабозащищённые модули принимающие информацию вводимую пользователем вам будут пихать SQL инъекции, в первую очередь будут искать modx_users
2) Переопределяйте пути к папкам:
/manager//connectors//core/
Опция переопределения путей имеется в дистрибутиве MODX типа advanced, в traditional такой опции нет. Это именно те места, где хакеры будут искать уязвимые скрипты и будут стараться обращаться к ним напрямую. Большую опасность представляет даже не папка /manager/, а /connectors/.
На уже действующей системе
Можно закрыть к разделам доступ по IP адресу, если вы заходите всё время только с определённых адресов. Это серьёзно усилит вашу оборону.Содержимое файла .htaccess.
RewriteEngine OffOrder deny,allowdeny from allAllow from 159.198.14.84
Соответственно будет защищено всё, что лежит в одной папке с этим файлом и глубже. Такой файлик можно спокойно класть в /manager/, /connectors/ и /core/. Разве что персонально для /core/ можно запретить прямое обращение к php файлам, добавив:
IndexIgnore */* <Files *.php>Order Deny,AllowDeny from all</Files>
Но если Вы часто обращаетесь к админке своего сайта из разных мест, ездите с ноутбуком по клиентам, конференциям, то задачу можно усложнить. Давать доступ или по IP или по базовой аутентификации через .htpasswd
Для /manager/ и /connectors/
RewriteEngine OffOrder deny,allowDeny from allAuthName "htaccess password prompt"# здесь нужно указать абсолютный путь к файлу .htpasswd# он вполне может быть общим для всех сайтов на одном хостинге# файл .htpasswd нужно отдельно генерировать, об этом далее в статьеAuthUserFile /home/askapache.com/.htpasswd AuthType BasicRequire valid-userAllow from 127.0.0.1Allow from 192.168.1.1Satisfy Any
Для /core/
IndexIgnore */*<Files *.php>Order Deny,AllowDeny from all</Files>Order deny,allowDeny from allAuthName "htaccess password prompt"AuthUserFile /home/askapache.com/.htpasswdAuthType BasicRequire valid-userAllow from 127.0.0.1Satisfy Any
Генерация htpasswd
Если у Вас есть ssh-доступ на сервер (доступ к командной строке сервера), то Вы можете воспользоваться утилитой htpasswd. Синтаксис команды таков:
htpasswd -c /full/path/.htpasswd имя_пользователя
После ввода команды будет запрошен пароль и просьба его повторить. В результате будет создан новый файл .htpasswd или же дополнен старый, содержащий логин и зашифрованный пароль. Если Вы хотите добавить новых пользователей, то следует запустить команду с ключом:
htpasswd -m .htpasswd имя_пользователя
В результате в существующий файл с паролями будет добавлена новая строка с именем пользователя и паролем.Если у Вас нет доступа по ssh, а вероятно только по ftp, то для генерации файла htpasswd можно воспользоваться любым онлайн генератором.
Общие советы
Изучите систему управления правами доступа MODX. Давайте контент-менеджерам прав ровно столько, сколько им нужно, не больше, со временем если понадобится - добавите.И в принципе регулярно проверяйте журналы ошибок на предмет подозрительного и кто у вас там вообще на сайте админами числится, а то бывают случаи появляются админы с e-mail'ами типа: [email protected]
freelgraf.in.ua