Как проверить сайт на вирусы и убрать заражение

Заражение прячется от администратора и показывает себя только посетителям из поиска. Как за 30 минут проверить сайт в панелях вебмастера, в файлах и в базе, вылечить его в правильном порядке и снять метку в выдаче.

Симптом почти всегда одинаковый. С закладки сайт открывается нормально, а если зайти на него из поиска с телефона, вместо страницы появляется реклама казино. Владелец проверяет с рабочего компьютера, ничего не находит и еще месяц считает, что клиентам померещилось.

Так устроено большинство современных заражений. Вредоносный код смотрит на User-Agent, реферер и IP-адрес и показывает себя только нужной аудитории: поисковому роботу — одну версию страницы, посетителю из Яндекса — другую, администратору — третью, чистую. Поэтому «я посмотрел, у меня все хорошо» ничего не доказывает.

Проверить сайт на вирусы можно за 30–40 минут, без специальных знаний и без покупки инструментов. Смотреть нужно в 3 местах: в панелях вебмастера, в файлах на хостинге и в базе данных. Ниже — что именно открывать, что искать и в каком порядке лечить, чтобы не удалить рабочий код вместе с вредоносным.

7 признаков, что сайт заражен

Ни один признак сам по себе не приговор, но 2 совпавших — уже повод проверять файлы.

• Метка в поиске. Рядом со сниппетом в Яндексе появляется предупреждение о том, что сайт может угрожать безопасности. В Google — «Этот сайт может нанести вред вашему компьютеру».
• Красный экран браузера. Chrome или Яндекс.Браузер показывают заглушку «Обманчивый сайт впереди» вместо страницы. Это срабатывают базы Safe Browsing, и они общие для многих браузеров.
• Резкая просадка трафика из поиска. Не плавное снижение на 10–15%, а обрыв за 1–2 дня. Особенно если позиции на месте, а переходов нет.
• Письмо от хостинга. Провайдер сообщает о вредоносных файлах в аккаунте или ограничивает сайт. Обычно это самый ранний сигнал, потому что антивирус на стороне хостинга сканирует диск регулярно.
• Чужие страницы в индексе. Наберите в поиске запрос вида site:вашдомен.ru и пролистайте выдачу до конца. Разделы про кредиты, лекарства и ставки, которых вы не создавали, — это дорвеи, размещенные на вашем домене.
• Скачки нагрузки. Хостинг жалуется на превышение лимитов по процессорному времени или по числу писем. Второе означает, что с сайта рассылают спам.
• Домен в черных списках рассылки. Письма с сайта перестали доходить, а в отчетах о доставке появились отказы со ссылкой на репутацию домена. Мы разбирали похожую диагностику в материале о том, почему письма с сайта уходят в спам.

Отдельно про панель вебмастера: если сайт добавлен в Яндекс.Вебмастер и Search Console, письмо об угрозе придет туда раньше, чем метка появится в выдаче. Если сайт туда не добавлен — добавьте прямо сейчас, это 10 минут и единственный бесплатный канал раннего оповещения.

5 типов заражения и где их искать

Понимание типа сокращает поиск: у каждого варианта свое привычное место обитания.

Самый неприятный из списка — веб-шелл. Он не мешает работе сайта и не портит выдачу, поэтому его находят последним, обычно уже после второго заражения. Все остальное — следствия, а шелл — причина.

По наблюдению справки Яндекса, вредоносные вставки чаще всего лежат в самом начале или в самом конце страницы, либо сразу за открывающим тегом body, а отдельная популярная цель взломщиков — файл .htaccess, куда дописывают редирект (Яндекс.Вебмастер, справка «Обнаружение вредоносного кода»).

Проверка за 30 минут: 5 шагов по порядку

Порядок важен: сначала бесплатные внешние источники, потом свои файлы. Так вы быстрее поймете масштаб.

1. Яндекс.Вебмастер. Раздел «Диагностика» → «Безопасность и нарушения». Если Яндекс что-то нашел, здесь будет тип угрозы и примеры зараженных адресов. Это самая полезная точка входа: вы сразу получаете список страниц, с которых начинать.
2. Google Search Console. Раздел «Проблемы безопасности». Google и Яндекс детектируют разное, поэтому проверяйте оба.
3. Антивирус хостинга. В панели управления почти у всех провайдеров есть сканер файлов. Запустите полную проверку и сохраните отчет, не нажимая сразу «Лечить»: список путей понадобится дальше.
4. Штатные средства CMS. В «1С-Битрикс» это модуль «Проактивная защита» и «Сканер безопасности»: они проверяют целостность системных файлов, настройки сессий, права доступа и наличие веб-фаервола. Контроль целостности отвечает на главный вопрос — какие файлы ядра изменились по сравнению с эталоном.
5. Взгляд снаружи. Откройте свой сайт с телефона в режиме инкогнито, перейдя из поисковой выдачи, а не по прямой ссылке. Половина условных редиректов ловится именно так.

Если после этих 5 шагов ничего не нашлось, а признаки заражения есть, дальше идет ручная проверка файлов. Она требует доступа по SSH или хотя бы файлового менеджера в панели хостинга.

Ручной поиск: где прячется код

Ручная проверка строится на 2 идеях: вредоносный файл почти всегда свежий и почти всегда содержит характерные конструкции.

Свежие файлы. Посмотрите, что менялось за последнюю неделю:

find /путь/к/сайту -type f -name "*.php" -mtime -7 -printf "%TY-%Tm-%Td %p\n" | sort

Если вы неделю не выкладывали обновления, а список длинный — это ответ. Дату первого измененного файла запомните: с нее начнется расследование по логам.

Характерные конструкции. Вредоносный код обфусцируют, чтобы он не читался глазами, и это его же и выдает:

grep -rn --include="*.php" -E "eval\(|base64_decode|gzinflate|str_rot13|assert\(|\\\$_(POST|GET|COOKIE)\[.\]\(" /путь/к/сайту | head -50

Здесь важно не увлечься. Часть совпадений будет ложной: base64_decode встречается в нормальных библиотеках, а eval — в старых модулях. Смотрите не на сам факт совпадения, а на контекст: длинная строка из случайных символов в файле, который лежит в папке с картинками, — это точно не библиотека.

Места, где PHP быть не должно. Каталоги загрузок, кеша, временных файлов, папки с изображениями. Один запрос:

find /путь/к/сайту/upload -name "*.php*" -o -name "*.phtml"

Пустой вывод — хорошо. Любой результат — разбирайтесь.

База данных. Заражение живет не только в файлах. Поищите в таблицах с контентом вставки <script, <iframe и display:none — в текстах статей, описаниях товаров, настройках шаблона и в блоках, которые выводятся на всех страницах.

Задания cron. Их проверяют реже всего, а зря: типовой сценарий — раз в час скачивать свежую версию шелла с чужого сервера. Даже полностью вычищенный сайт заражается заново к вечеру.

Лечение: порядок действий

Порядок здесь важнее скорости. Если начать с удаления файлов, вы потеряете следы и не найдете точку входа.

1. Снимите копию зараженного сайта. Файлы и дамп базы целиком, в архив за пределами сервера. Это материал для расследования, а заодно страховка, если чистка что-то сломает.
2. Закройте доступ. Смените пароли: панель хостинга, SSH, FTP, база данных, администраторы CMS. Отдельно проверьте список пользователей с правами администратора — лишние учетные записи создают при взломе почти всегда. Включите двухфакторную аутентификацию там, где она есть.
3. Восстановите ядро из чистого дистрибутива. Файлы CMS и модулей замените официальной версией целиком, а не правьте по одному. Вручную имеет смысл чистить только то, чего нет в дистрибутиве: собственный шаблон, кастомные компоненты, загруженные файлы.
4. Найдите точку входа. Возьмите дату первого измененного файла и посмотрите в этот интервал access.log: обычно видно POST-запрос к странному адресу или серию обращений к админке. Без этого шага чистка превращается в лотерею.
5. Проверьте базу и cron. Удалите посторонние задания, вычистите вставки в контенте.
6. Обновите CMS и модули. Взлом почти всегда идет через известную уязвимость в старой версии, а не через подбор пароля. Про то, почему уязвимостей становится больше, у нас есть отдельный разбор.
7. Зафиксируйте чистое состояние. Снимите контрольные суммы файлов или включите контроль целостности в CMS. Со следующего раза вы увидите изменение в тот же день, а не через месяц.

Про восстановление из резервной копии стоит сказать отдельно, потому что это самый популярный совет и самая частая ошибка. Бэкап недельной давности может быть уже зараженным: шелл лежит в файлах с прошлого месяца, а активничать начал на этой неделе. Откатываться имеет смысл только на дату заведомо раньше первого подозрительного изменения, и после отката все равно нужно закрыть уязвимость, через которую пришли.

Ошибки, из-за которых сайт заражается повторно

Повторное заражение через 2–3 недели после чистки — не редкость, и причины у него всегда одни и те же.

• Почистили файлы, не сменили пароли. Если увели доступ к FTP, вычищенный сайт заражают обратно за минуты.
• Не заглянули в cron и в базу. Смотри выше: восстановление шелла по расписанию сводит на нет всю работу.
• Не нашли точку входа. Дыру в модуле не закрыли, значит через нее зайдут снова.
• Оставили старую версию CMS. «Обновимся потом, сейчас некогда» — это перенос той же проблемы на месяц вперед.
• Удалили все подозрительное разом. Половина сайтов после самостоятельного лечения приезжает к нам не с вирусом, а с белым экраном: вместе с вредоносным кодом снесли рабочие файлы.
• Хранят резервные копии в корне сайта. Архив, доступный по прямой ссылке, — подарок: вместе с ним утекает и база с паролями пользователей.

Мое мнение, за которое иногда спорят: отдельные «антивирусные» плагины для CMS создают ложное спокойствие. Они ищут по базе сигнатур, а веб-шелл в 2 строки, написанный под конкретный сайт, ни в какую базу не попадет. Контроль целостности файлов и внимание к дате изменения дают на порядок больше.

Как снять метку в поиске и предупреждение браузера

Санкции снимаются не автоматически: нужно сообщить поисковику, что вы закончили.

В Яндексе это делается на той же странице «Безопасность и нарушения»: в блоке с описанием нарушения опишите, что именно вы исправили, и нажмите «Я все исправил». Запрос уходит на перепроверку, ограничения снимут, если претензий не осталось (справка Яндекс.Вебмастера). В Google — раздел «Проблемы безопасности» и кнопка запроса проверки.

Точных сроков ни один из поисковиков не гарантирует. На практике перепроверка занимает от суток до нескольких дней, но есть нюанс: если отправить запрос раньше времени и проверка провалится, следующая попытка обойдется дороже по времени. Сначала убедитесь, что код действительно удален, и только потом жмите кнопку.

Предупреждение в браузере снимается тем же путем: базы Safe Browsing обновляются после успешной перепроверки, отдельно писать никуда не нужно.

Базовый минимум, чтобы не возвращаться к теме

Все перечисленное настраивается один раз и дальше работает само.

• Обновления по расписанию. Раз в месяц, а критические патчи безопасности — в день выхода.
• Запрет исполнения PHP в папках загрузок. Одна директива в конфигурации веб-сервера закрывает самый популярный способ залить шелл.
• Двухфакторная аутентификация для администраторов. В «1С-Битрикс» входит в «Проактивную защиту», отдельно платить не нужно.
• Отдельные учетные записи вместо общей. Когда подрядчик уходит, вы отключаете его доступ, а не меняете пароль всей команде.
• Резервные копии вне сервера. Минимум 7 ежедневных и 4 еженедельных, с проверкой восстановления хотя бы раз в квартал. Копия, которую ни разу не разворачивали, — это надежда, а не бэкап.
• Контроль целостности и мониторинг. Уведомление об изменении файлов ядра приходит вам, а не выясняется из письма хостинга.

В Design Lab при постановке сайта на обслуживание мы начинаем ровно с этого: снимаем контрольные суммы, разносим доступы по учетным записям и убираем возможность запускать PHP из папок с пользовательскими файлами. Дальше заражения ловятся на этапе «изменился файл», а не на этапе «Яндекс пометил сайт».

Что сделать сегодня

Если сайт уже помечен поиском — начинайте с копии и смены паролей, только потом чистите. Если признаков заражения нет, потратьте полчаса на профилактику: добавьте сайт в обе панели вебмастера, запустите сканер хостинга, проверьте папку загрузок на PHP-файлы и посмотрите список администраторов. Этого достаточно, чтобы поймать заражение на ранней стадии, когда оно лечится за час.

Если разбираться самому некогда, а сайт приносит деньги, разумнее отдать это на поддержку: там проверка целостности и обновления идут по регламенту, а не когда вспомнили. Что именно входит в такой регламент, мы разбирали в статье про технический аудит сайта.