Сайт заражён вирусом: как найти заражение и вычистить его из индекса

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

Ниже — где искать внедрённые файлы, почему бесполезно чистить сайт, не закрыв точку входа, каким кодом выбивать спам-страницы из индекса и что делать с предупреждением браузера. В SEO с 2005 года: обычно к моменту обращения заражению уже два-три месяца.

Признаки заражения: выдача, браузер и панели вебмастера

Дефейс во весь экран заметен сразу, и это самый безобидный вариант. Опасны тихие заражения, работающие месяцами только для робота и части посетителей. Первое место, куда смотреть, — выдача. Запрос site:вашдомен.ру показывает всё, что поисковик знает о сайте. Если число страниц выросло в разы без вашего участия, а в сниппетах появились чужие тематики, латиница вперемешку с иероглифами или адреса вида /uploads/2024/07/kupit-...html, это внедрённые дорвеи. Полезны уточняющие запросы вроде site:вашдомен.ру казино. Как читать данные об охвате индексом, разобрано в материале Как проверить индексацию сайта в Яндексе.

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

Третий источник — панели: «Диагностика → Безопасность и нарушения» в Вебмастере и «Проблемы безопасности» в Search Console. Формулировка важна: внедрённые URL означают дорвеи в вашем каталоге, внедрённый код — скрипт для посетителей. Четвёртый признак технический: скачок нагрузки на хостинге, рост исходящей почты, десятки POST-запросов в логах к файлам, которых в вашей CMS нет. Логи хостер хранит 7–30 дней, и каждый день промедления стоит информации.

Типы заражения и как отличить одно от другого

От типа зависит, где искать файлы и что делать с индексом. На одном сайте нередко живут два-три типа сразу: сначала бэкдор, потом дорвеи через него, потом перепродажа доступа.

Тип заражения	Что видит посетитель	Что попадает в индекс	Где искать
Внедрённые дорвеи	Ничего необычного	Сотни чужих страниц по коммерческим запросам	Отдельные .php и .html в /uploads/, /cache/, /tmp/
Скрытые ссылки в шаблоне	Ничего, ссылки скрыты стилями	Исходящие ссылки на чужие сайты	footer.php, functions.php темы, опции и виджеты в базе
Условный редирект	Переброс на чужой сайт с мобильного или из поиска	Обвал поведенческих на своих страницах	.htaccess в корне и подпапках, index.php, JS темы
Веб-шелл (бэкдор)	Ничего	Ничего	Обфусцированный файл где угодно, часто под системным именем
Вредоносный скрипт	Всплывающие окна, подмена ссылок	Метка небезопасного сайта	Внешний скрипт в шапке, вставки в базе

Дорвеи и скрытые ссылки бьют по SEO: сайт получает чужую тематику. Редиректы и вредоносные скрипты бьют по посещаемости. Веб-шелл сам по себе вреда не приносит — он приносит второе и десятое заражение. Про каналы проникновения есть разбор — Способы взлома сайта.

Поиск заражённых файлов по дате изменения

Быстрее всего круг сужает сортировка по времени модификации: файлы движка и темы сами не меняются. Если в каталоге, куда вы полгода не заходили, лежит PHP-файл с датой прошлой недели, это кандидат. По SSH достаточно строки find /путь -name "*.php" -mtime -30 -ls, без SSH — сортировки по колонке «Изменён» в файловом менеджере панели. Деталь: mtime подделывают утилитой touch, а ctime подделать сложнее, поэтому вторым проходом полезен find . -name "*.php" -ctime -30.

Второй метод надёжнее и не зависит от дат — сверка с эталоном. Скачайте дистрибутив ровно той версии CMS, что стоит у вас: у WordPress папки wp-admin и wp-includes обязаны совпадать файл в файл, любой лишний файл там — заражение. Проверка wp core verify-checksums делает это автоматически.

Третий метод — поиск по характерным конструкциям. Обфусцированный код почти всегда содержит функции динамического исполнения и декодирования: eval(, base64_decode(, gzinflate(, str_rot13(, assert(, create_function(. Ищутся рекурсивным грепом с ключом --include="*.php". Ложные срабатывания будут, но список сократится с десятков тысяч файлов до десятков строк.

Четвёртый ориентир — места, где исполняемых файлов быть не должно: в каталоге загрузок любой .php или .phar — заражение без вариантов. Туда же права 777 и имена вроде wp-conflg.php, замаскированные под системные. Пятое — база: таблица опций, список администраторов, вставки тега script в записях, запланированные задачи. Задача планировщика, которая раз в час пересоздаёт удалённый файл, — типовая причина того, что «почистил, а через день опять».

Точка входа: как её найти и закрыть

Чистка без закрытия точки входа — потраченный вечер: взломщик вернётся тем же путём и второй раз аккуратнее, положит бэкдор в базу или в crontab. Порядок обратный привычному: сначала точка входа, потом файлы. Определите дату первого появления вредоносного файла по ctime и откройте логи доступа за этот день. Ищите POST-запросы к необычным адресам и серии обращений к wp-login.php с одного адреса. Часто картина видна сразу: сотни попыток подбора пароля, один успешный вход, затем POST на загрузку файла.

Каналов проникновения в практике пять. Устаревший плагин или тема с известной уязвимостью — версии сверяются с базой WPScan или каталогом CVE, а не по ощущениям. Слабый или переиспользованный пароль от админки, FTP, панели хостинга. Украденный пароль с заражённого компьютера: чистка бесполезна, пока не вычищен компьютер. Сосед по аккаунту: если на одном пользователе висят пять сайтов, заражение одного за час переползает на остальные. И nulled-сборки, где бэкдор идёт в комплекте изначально.

Закрытие точки входа — смена всех паролей разом: панель хостинга, FTP и SFTP, SSH, база, учётная запись администратора, почтовые ящики на домене. Плюс проверка authorized_keys на чужие SSH-ключи и ревизия пользователей CMS: лишние администраторы удаляются, у остальных сбрасываются сессии.

Чистка сайта: порядок, при котором ничего не ломается

Шаг первый. Снимите копию заражённого сайта вместе с базой — не для отката, а для расследования: если заражение вернётся, по ней видно, что вы пропустили.

Шаг второй. Закройте сайт на время работ кодом 503 с заголовком Retry-After, а не 404 и не 200 с текстом «идут работы»: при 503 робот понимает, что сайт временно недоступен, и вернётся позже, не выбрасывая страницы из индекса.

Шаг третий. Переустановите ядро CMS поверх текущей установки: свежий дистрибутив заменит все файлы движка разом. Для WordPress это замена wp-admin, wp-includes и файлов в корне, кроме wp-config.php.

Шаг четвёртый. Плагины и темы не чистите руками, а переустанавливайте из официального источника, удалив старые каталоги целиком: ручная чистка почти всегда оставляет один файл. Неиспользуемое удаляйте, а не деактивируйте: деактивированный плагин остаётся исполняемым файлом.

Шаг пятый. Каталог загрузок чистится вручную по списку исполняемых файлов. Проверьте .htaccess в каждой вложенной папке: вредоносный редирект часто прячут внутри uploads, где его никто не ищет.

Шаг шестой. База: лишние администраторы, адрес сайта в опциях, вставки скриптов в записях и виджетах, чужие задачи планировщика. Массовые правки — только с дампом.

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

Как вычистить спам-страницы из индекса

Удалить файлы — половина работы: дорвеи уже в индексе, по ним идут показы, и поисковик считает их вашими страницами. Правильный сигнал — код 410 Gone, «страница удалена навсегда», в отличие от 404, «не найдена сейчас». На практике 404-адреса поисковик перепроверяет месяцами, а 410 обрабатывает быстрее и не возвращается. Настраивается правилом в .htaccess или в конфигурации nginx по маске адресов. Разбор кодов есть в материале Коды ответа сервера: руководство с примерами использования.

Способ	Что происходит технически	Годится для спама	Почему
Код 410 Gone	Ресурс удалён окончательно	Да, основной инструмент	Обрабатывается быстрее 404, повторных проверок не требует
Код 404 Not Found	Не найден, возможно временно	Допустимо, но медленнее	Поисковик месяцами перепроверяет адрес
301 на главную	Постоянный перенос адреса	Нет	Связывает целевую страницу с чужой тематикой
Мета-тег noindex	Страница доступна, но не выводится в поиск	Нет	Требует держать страницу живой, а спам должен исчезнуть
Disallow в robots.txt	Запрет на обход адреса	Нет, как единственная мера	Робот перестаёт видеть 410, адреса зависают в индексе
Удаление URL в панелях	Ускоренное исключение по заявке	Да, как дополнение	Работает поверх 410, но не заменяет его

Отдельно про robots.txt — это самая частая ошибка. Закрыть спам-каталог директивой Disallow кажется логичным, но результат обратный: робот перестаёт заходить на страницы, не видит код 410 и оставляет адреса в индексе как запрещённые к обходу. Сначала 410, потом запрет обхода. Как устроены директивы, разобрано в статье Файл robots.txt для сайта.

Список спам-адресов выгружается из Вебмастера в разделе «Индексирование → Страницы в поиске» и фильтруется по характерным фрагментам. Дальше он прогоняется через «Инструменты → Удаление страниц», где задаётся префикс каталога, и через раздел «Удаления» в Search Console. После настройки проверьте реальный код ответа: curl -I по спам-адресу должен вернуть первой строкой 410. Типичная ошибка — правило написано, но сервер отдаёт страницу «не найдено» с кодом 200.

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

Предупреждение «Обманчивый сайт» в Chrome и «Этот сайт может угрожать безопасности вашего компьютера» в выдаче Яндекса снимаются не автоматически и не одновременно. Для Google: в Search Console открывается «Проблемы безопасности», нажимается «Запросить проверку», в описании перечисляется, что сделано — какие файлы удалены, какая уязвимость закрыта, какие пароли сменены. Проверка занимает от нескольких часов до нескольких суток. Для Яндекса: Вебмастер, «Безопасность и нарушения», кнопка подтверждения устранения.

Главное правило — не нажимать кнопку, пока не уверены, что бэкдор удалён: повторное обнаружение угрозы после заявки отодвигает следующую проверку, и метка держится дольше.

Дополнительно проверьте две вещи. Первая — не попал ли домен и IP хостинга в почтовые чёрные списки: если сайт рассылал спам, письма перестанут доходить, и выясняется это через месяц. Вторая — нет ли поисковых санкций: заражение с дорвеями и продажей ссылок приводит к ручным мерам, которые снимаются отдельно от метки безопасности. Чем отличаются санкции, описано в материале ТОП самых опасных фильтров поисковых систем.

Защита от повторного заражения и когда чистка уже не поможет

Повторное заражение в первый месяц — обычное дело, если ограничиться удалением файлов. Работающий минимум такой. Обновления ставятся в течение недели после выхода, неиспользуемое удаляется полностью. В каталоге загрузок запрещается исполнение PHP правилом в .htaccess или блоком location для nginx: одна настройка закрывает самый популярный сценарий с дорвеями. Права — 644 на файлы, 755 на каталоги, 600 на конфигурационный файл. Вход защищается двухфакторной аутентификацией и ограничением попыток, каждый сайт живёт под отдельным пользователем. Копии хранятся вне сервера с глубиной от 30 дней, иначе к моменту обнаружения все окажутся заражёнными. Список мер собран в статье Как защитить сайт от взлома.

Отдельно — мониторинг целостности: скрипт, который раз в сутки сверяет список файлов с эталонным и сообщает о новых исполняемых файлах.

Чистка бессмысленна в четырёх случаях. Сайт на заброшенной версии CMS, для которой не выходят обновления: уязвимость останется, и дешевле перенос на актуальную версию с сохранением адресов. Самописный сайт без исходников и без разработчика: эталона нет, сравнивать не с чем. Заражение ушло в базу на десятки тысяч записей, а чистых копий нет. Домен месяцами работал площадкой спам-сети и получил санкции — тогда сначала чистка и снятие санкций, и только потом продвижение: вкладываться в тексты и ссылки на помеченном домене бессмысленно. В таких случаях восстановление и последующее продвижение сайта в поиске под ключ идут одним проектом.

После заражения вскрываются и накопленные технические проблемы: битые адреса, потерянные редиректы, сломанные метатеги. Это уже доработка сайта под требования поиска, и делать её логично сразу, пока есть доступ и понимание структуры.

Частые вопросы

Хостинг говорит, что нашёл вирус и сам всё почистил. Этого достаточно?
Обычно нет. Антивирус хостера находит файлы по сигнатурам известных образцов, но не закрывает уязвимость и не трогает базу, поэтому через несколько дней бэкдор возвращается. Отчёт полезен другим: в нём есть пути к файлам и дата обнаружения, от которой удобно отталкиваться при разборе логов.

Сколько времени спам-страницы висят в индексе после чистки?
При корректно настроенном 410 и заявке на удаление основная масса уходит за две-четыре недели. Адреса с внешними ссылками держатся дольше. Ускоряет процесс временная карта сайта со списком спам-адресов: робот обойдёт их быстрее и увидит 410, после чего карту нужно убрать.

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

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

Как понять, что сайт чистый, если внешне всё нормально?
Внешний вид ничего не доказывает — большинство заражений и рассчитаны на то, чтобы владелец не заметил. Критерии проверяемые: файлы ядра совпадают с эталоном по контрольным суммам, в каталоге загрузок нет исполняемых файлов, за две недели не появилось новых PHP-файлов, в администраторах только знакомые учётные записи, планировщик содержит штатные задачи, запрос site: не показывает чужих страниц. Все пункты выполняются одновременно.

Коротко

• Заражение видно по трём независимым источникам: чужие страницы в выдаче по запросу site:, записи в разделах безопасности панелей, аномалии в логах. Внешний вид сайта ничего не подтверждает.
• Порядок работ обратный интуитивному: сначала закрывается точка входа, потом чистятся файлы. Иначе бэкдор вернётся в течение недели.
• Поиск ведётся по трём срезам: файлы, изменённые за месяц по mtime и ctime, расхождения с эталоном, конструкции динамического исполнения кода. Плюс база.
• Спам-страницы выбиваются из индекса кодом 410, а не редиректом на главную и не запретом в robots.txt. Заявка на удаление ускоряет процесс, но код ответа не заменяет.
• Защита — обновления, удаление неиспользуемых компонентов, запрет исполнения PHP в каталоге загрузок, отдельный пользователь на каждый сайт, внешние копии.

Если сайт почищен, а трафик не возвращается, или непонятно, что тянуло позиции вниз — заражение или накопленные технические ошибки, разбираться лучше по данным. На разовой SEO-консультации смотрим логи, историю позиций, отчёты панелей вебмастеров и составляем порядок действий по приоритету: что чинить сегодня, а что подождёт до следующего месяца.