После эпичного взлома MODX Revolution, произошедшего приблизительно с 12 по 20 июля 2018 года, многие совершенно естественно задумались о том, как максимально защитить свои сайты от повторения подобного. После восстановления 10+ сайтов невольно задумываешься о многом! Мне пришлось восстанавливать больше пятнадцати взломанных и заражённых сайтов, и поэтому в процессе я сделал для себя небольшую инструкцию на будущее, что должно быть сделано для безопасности в MODX в обязательном порядке.
Базовая защита
Желательно предпринять все действия по "закалке" Модэкса, описанные в официальном руководстве, в особенности то, что касается перемещения и переименования основных папок.
1. Обновление
Необходимо обязательно обновиться до последней версии MODX Revolution 2.6.5 или старше, а также обновить все плагины до последних версий. Особенно Gallery, именно через него были взломаны многие сайты. При восстановлении сайтов я успешно обновлял их с 2.2.16 до 2.6.5.
2. Перемещение папки core на уровень выше
Вынести папку core над public_html -- одно из самых важных действий. После этого необходимо заменить пути к папке core на новые пути в следующих файлах:
/core/config/config.core.php
/public_html/config.core.php
/public_html/connectors/config.core.php
/public_html/manager/config.core.php
3. Переименование служебных папок
Переименовать все служебные папки (assets, connectors и manager), например так:
assets -> assets6827hdh2gj2
connectors -> connectors6893ngkeh39dj
manager -> manager9673jdhdg373
После переименования нужно прописать новые пути к этим папкам тут:
/core/config/config.core.php
Саму по себе папку /assets/ можно оставить для файлов шаблонов и всяких подгружаемых картинок. При этом в новую папку /assets6827hdh2gj2/ нужно перенести только папку /assets/components/ и служебные папки, которые создавались компонентами, то есть, всё то, что вы сами не создавали, но оно там как-то появилось.
4. Настройка плагинов Gallery и PhpThumbOf
Также, если вы используете плагины Gallery и PhpThumbOf, в их настройках лучше указать пути именно к старой папке assets.
Системные настройки для Gallery:
gallery.files_url = /assets/gallery/
gallery.files_path = /path_on_your_server/public_html/assets/gallery/
gallery.default_batch_upload_path = /path_on_your_server/public_html/assets/images/
Системные настройки для PhpThumbOf:
phpthumbof.cache_url = /assets/cache/
phpthumbof.cache_path = /path_on_your_server/public_html/assets/cache/
Теперь эти плагины будут создавать файлы и папки в старой папке / assets / и не будут светить новую папку в HTML-коде.
Зачем вообще это нужно?
Есть данные, что во время взлома вражеские скрипты тупо проверяли доступность на сайте файла /assets/components/gallery/connector.php, и если он был доступен, взламывали сайт, посылая на этот коннектор определённые запросы. Скрывая папку /assets/ через переименование, вы сможете избежать такой атаки. Для этого же нужно и разделение папки assets на две. За счёт того, что файлы шаблона будут лежать в старой папке, именно путь /assets/ будет светиться в HTML-коде вашего сайта. О существовании папки /assets6827hdh2gj2/ злоумышленники могут и не догадаться, ведь этот путь по большей части будет использоваться в админке сайта. Если только какой-то специфический компонент не потребует явного указания своих скриптов в коде страницы! Что ж, тогда придётся засветить этот путь... Или перенести необходимые файлы компонента в старую папку /assets/, убедившись, что после этого всё работает, что предпочтительнее с точки зрения безопасности, хоть и может создать проблемы при обновлении.
5. При установке MODX указывайте нестандартный префикс баз данных
Это классика закалки Модэкса. Можно переименовать например так: modx_ -> g538_
6. Зачистка старого кэша
На этом этапе логично зачистить всё содержимое папки /core/cache/
Более продвинутая защита
1. Необходимо закрыть папки коннекторов и админки базовой авторизацией через .htaccess или в вашем конфиге для NGINX. Напомню, что папка core уже вынесена над public_html. Если нет, то закройте и её тоже. Дополнительный слой защиты с хорошим паролем никогда не помешает!
2. Уберите из файла robots.txt специфичные для MODX Revolution папки, чтобы по нему нельзя было с ходу понять, на какой системе сделан сайт. Это же касается системного параметра send_poweredby_header, он должен быть выставлен в «нет»
3. Пропишите в .htaccess или в вашем конфиге для NGINX, чтобы при обращении к файлу /public_html/config.core.php в корне вашего сайта возвращался ответ 404 – страница не найдена. Это также поможет затруднить определение CMS.
Общие вещи в порядке паранойи
1. Убедитесь, что для всех файлов на вашем сайте выставлены правильные разрешения. По умолчанию в MODX это 755 для папок, и 644 для файлов.
2. Убедитесь, что используете сложные пароли для пользователей админки
3. Скачайте сайт и прогоните его какой-нибудь антивирусной утилитой типа «ai-bolit» чтобы убедиться, что там нет ничего вредоносного.
4. Подключите какой-нибудь сертификат SSL, например бесплатный от LetsEnctypt.
5. Поставьте максимально высокую версию PHP для сайта.
6. Забэкапьте все файлы и базу на сервере и у себя локально, настройте систему реулярных бэкапов на хостинге.
7. Закройте доступ через SSH из контрольной панели хостера или настройте доступ по публичному ключу, если это выделенный сервер.
Заключение
В целом, даже этих мер достаточно, чтобы надолго забыть про проблемы с безопасностью в MODX Revolution. Кстати, уже после очищения сайтов, злоумышленники продолжают регулярно бомбить адрес /assets/components/gallery/connector.php и получать 404 в ответ. Враг не дремлет, и вы тоже не спите!