Кажется я нашел на своем сервере самый старый вредоносный файл. Появился 19-го числа (большинство же взломов было зафиксировано с 20-го числа). assets/components/gallery/cache/var_www_vhosts{sitename}_.b7e3a964094cfe6e29fc9228bad6e7b2.php С таким содержимым: На вид очень похоже на то, что именно через этот файл и осуществлялся взлом, то есть уязвимость действительно в gallery была.
Более эффективного метода не существует) Если уязвимость на сайте есть, то переустановка сервера особо не поможет. Здесь же речь не о уязвимости на уровне серверов, а именно об уязвимости на уровне сайтов. Я сделал так: 1. На уровне nginx отключил все сайты. То есть сами конфиги лежат в /etc/nginx/sites-available, а на подключенные сайты симлинки на них в /etc/nginx/site-enabled. 2. По одному вычищаю сайты и подключаю. При этом в каждый прописываю fastcgi_param PHP_VALUE open_basedir="/www/site_path/"; , то есть изоляция процессов в рамках конкретной директории. Это не гарантирует отсутствие последующих взломов, но так зараза из взломанного сайта не распространится на другие. Таким образом легче будет проанализировать природу взлома, да и последствия меньше.
Спасибо за инструкции. Жизненно необходимая информация, если бэков не было. Я частью, буквально за неделю сделал свежие бэки. Там вроде все чисто, тфу тфу) Поэтому решил полностью переутсановить сервер и выложить копии с моментальным обновлением до 2.6.5. Более эффективного метода не существует)
<<< детектится просто, смотрим index.php на наличие подозрительных @include и других отличий от стандартного, а также наличия файлов index.php в папках где их не должно быть (assets, core/packages и т.д.). На некоторых сайтах лишних и инфецированных файлов были замечено больше тысячи. Если бэкап есть, то замечательно. Если нет бэкапа, но восстанавливать сайт как-то надо, можно сделать так: с учетом того, что не было замечено заразы в базе данных, если у вас сайт делался просто на уровне MODX-овых шаблонов, сниппетов и ченков, то делаем так: 1. Делаем бэкап текущего сайта. Даже с вирусами, это все равно бэкап. 2. Сохраняем отдельно файл-конфиг core/config/config.inc.php 3. Удаляем на сайте все php-файлы. find -regex ..php -print0 | xargs -0 rm Если JS-файлы тоже были заражены, их тоже надо удалить find -regex ..js -print0 | xargs -0 rm 4. Закидываем конфиг-файл обратно. 5. Накатываем и обновляем MODX. 6. В управлении компонентами переустанавливаем имеющиеся компоненты. В большинстве случаев, даже если вы использовали какие-то сторонние js-библиотеки или типа того, их не составит труда найти в сети и залить на сайт.
Одна из самых крупных катастроф с MODx Revo в истории? Не, было уже раньше, правда больше на Эво. Я думаю, дело в том, что технологии (и пропускная способность сети возросла сильно), и количество сайтов на MODX. Тем более, как тут же и говорят, вирус спал. То есть неделю (а то и больше) он просто заражал все, и только потом показался. Получилось эффектненько.
" Мониторинг " - Список измененных файлов приходит на почту. Весьма удобно, не искать , а сразу знать куда влезли. Вот у меня только на одном из сайтов заменено содержимое более 2000 файлов. И чего мониторинг тут даст? Только одно: оперативное уведомление на счет того, что что-то на сайте изменилось. Но в восстановлении не поможет. Для восстановления очень полезен git. Конечно, бэкапы тоже очень помогают, но они не показывают что же было изменено. А git и поможет восстановить, и покажет где что изменилось (конечно же с учетом настроек .gitignore).
Одна из самых крупных катастроф с MODx Revo в истории?
" Мониторинг " - Список измененных файлов приходит на почту. Весьма удобно, не искать , а сразу знать куда влезли.
Николай, здравствуйте, не смог восстановить старый аккаунт. Угроза действительно серьезная, у нас около 9 пострадавших сайтов, правда все почему-то на 2.5.х и 5.4-5.6. php. Обнаружили в пятницу, вирус спит, а потом заменяет содержимое всех .js файлов (сайт начинает на фишинговые и рекламные сайты редиректить) детектится просто, смотрим index.php на наличие подозрительных @include и других отличий от стандартного, а также наличия файлов index.php в папках где их не должно быть (assets, core/packages и т.д.).