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

Пошаговая методика для владельцев сайтов: какие сервисы использовать, что искать в файлах и как читать отчеты Google и Яндекса

Проверка начинается с уведомлений Google Search Console и Яндекс Вебмастера, затем продолжается анализом HTTP-ответов, файлов CMS, базы данных, планировщика и журналов сервера. Один внешний сканер видит только публичную часть сайта и не может подтвердить, что сервер полностью чист.

Перед диагностикой сохраните копию файлов и журналов. Не загружайте в публичные сервисы архив сайта, конфигурацию, дамп базы, ключи или другие закрытые данные.

Зачем вообще этим заниматься

Первым сигналом иногда становится предупреждение в Google Search Console или Яндекс Вебмастере, жалоба посетителя либо неожиданный переход на посторонний домен. Избирательное заражение сложнее заметить: ответ может зависеть от устройства, источника перехода, cookie или User-Agent.

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

Что такое вредоносный код и скрытые редиректы на сайте

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

• Вредоносный редирект. Сервер, JavaScript или правило веб-сервера переводит часть посетителей на посторонний домен.
• Клоакинг. Разные пользователи получают разные ответы в зависимости от технических признаков запроса.
• SEO-спам. В шаблон, базу или новые страницы добавляют посторонние тексты и ссылки.
• Бэкдор или веб-шелл. Скрытый механизм позволяет вернуться на сервер после поверхностной очистки.
• Open redirect. Легитимный endpoint разрешает перейти на произвольный внешний адрес. SSRF относится к другой угрозе: сервер выполняет запрос к указанному атакующим ресурсу и проверяется отдельно.

Как это устроено технически

После первоначального доступа злоумышленник может изменить шаблон, .htaccess, настройки базы, задания cron или создать дополнительный PHP-файл. Поэтому проверяют не только видимую страницу, но и изменения файлов, базу данных, планировщик, пользователей и журналы. [6][7]

Конструкции eval, base64_decode, gzinflate и обфусцированные строки требуют анализа контекста. Они встречаются и в легитимном коде, поэтому удаление обосновывают сравнением с доверенной версией и историей изменений.

curl -I выводит заголовки ответа, -L следует по редиректам, -H добавляет собственный заголовок, а сочетание -sS скрывает индикатор прогресса, сохраняя сообщения об ошибках. Для сравнения ответов выполняют отдельные запросы с обычным и заданным User-Agent; различие служит поводом для проверки, но само по себе не доказывает заражение. [5]

curl -sSIL "https://example.com"
curl -sSIL -H "User-Agent: Googlebot" "https://example.com"

Российская специфика

Яндекс Вебмастер показывает обнаруженные угрозы и сообщения диагностики, а Google Search Console — проблемы безопасности, связанные со взломанным контентом, вредоносным ПО и социальной инженерией. Эти отчёты полезны как сигнал и список примеров, но не заменяют проверку сервера. [1][3][4]

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

Пошаговая методика проверки сайта

1. Отчеты поисковых систем — начните отсюда

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

• Google Search Console → «Безопасность и действия вручную» → «Проблемы безопасности»;
• Яндекс Вебмастер → «Оптимизация сайта» → «Безопасность и нарушения», где нужно устранить указанные на сайте или его разделах нарушения.

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

2. Онлайн-сканеры вредоносного кода

Внешний сканер может проверить публичный URL, цепочку редиректов и известные сигнатуры в отданном HTML или JavaScript. Он не видит закрытые файлы, задания планировщика, базу данных и код, который срабатывает только при определённых условиях.

Используйте такие сервисы как дополнительный сигнал. Для публичной проверки передавайте только URL. Архивы сайта, дампы базы, конфигурацию и журналы с персональными данными анализируют в контролируемой среде.

3. Проверка редиректов вручную

Автоматические сканеры хорошо ловят известные сигнатуры, но избирательный клоакинг — когда вредоносный контент показывается не всем подряд — они иногда пропускают. Здесь помогает связка из нескольких проверок:

• запрос через curl с заголовком User-Agent, имитирующим Googlebot или Yandexbot, и сравнение результата с обычным запросом браузера;
• открытие сайта в режиме инкогнито без сохраненных cookies — часть редиректов срабатывает только при первом визите или один раз в сутки на устройство;
• проверка с мобильного User-Agent отдельно от десктопного — некоторые схемы монетизации через вредоносный редирект нацелены именно на мобильный трафик;
• сравнение того, что видит браузер, с версией страницы, которую индексирует поисковик, — расширения для анализа скрытого контента показывают разницу между текстом на странице для пользователя и текстом, который получает поисковый робот, что и позволяет выявлять клоакинг, а инструменты такого рода отслеживают, какие URL на страницы скрыты именно от поисковиков.

4. Осмотр файлов и кода сайта

Если доступ к хостингу есть, стоит просмотреть в первую очередь несколько точек, где чаще всего оказывается вредоносный код:

• файл .htaccess в корне сайта — на предмет строк с RewriteRule, Redirect и упоминаний посторонних доменов;
• файлы темы, в первую очередь header.php / footer.php, и главный index.php — на предмет вставок в самое начало или конец файла;
• ключевые файлы конфигурации CMS (например, wp-config.php) — они реже нужны для редиректа, но часто содержат бэкдор;
• проверка участков с eval, base64_decode, gzinflate и str_rot13: сочетание таких конструкций требует ручного анализа, сравнения с доверенной версией и историей изменений, но само по себе заражение не доказывает;
• сравнение текущих файлов сайта с чистой резервной копией — при наличии бэкапа, сделанного до заражения, разница между версиями быстро покажет, какой именно файл был изменен и что именно в него добавили, для чего стоит сравнить код бэкапа и зараженной версии, чтобы найти слабое место.

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

5. Проверка через кэш и внешние источники

Сравните текущие файлы с доверенной резервной копией или исходным дистрибутивом CMS. Отдельно проверьте записи базы, задания cron, автозагрузку, системные службы, правила веб-сервера и пользователей панели управления. Именно там может сохраниться механизм повторного заражения.

Резервную копию не возвращают в рабочую среду вслепую: сначала проверяют её дату и состав, закрывают установленную точку входа и тестируют восстановление изолированно. [8]

Ограничения, типичные ошибки и риски

• Один чистый отчёт. Он означает лишь, что конкретный инструмент не нашёл известный ему признак.
• Проверка только браузером. Редирект может зависеть от устройства, источника перехода, cookie или User-Agent.
• Удаление файла без поиска причины. Учётная запись, задание или другой бэкдор способны вернуть заражение.
• Игнорирование базы и сервера. Вредоносный код хранится не только в шаблонах CMS.
• Публикация закрытых данных. Архив сайта и журналы нельзя без необходимости отдавать внешнему сканеру.

Как выбрать подход к проверке и защите

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

Для сайта с личным кабинетом, оплатой или интеграциями дополнительно проверяют базу, задания, API-ключи, журналы, целостность и маршрут данных. После очистки настраивают обновления, резервные копии с проверкой восстановления и наблюдение за повторными признаками.

Как может помочь «Пятый фактор»

«Пятый фактор» может проверить файлы, базу, настройки веб-сервера, задания, доступы и связанные интеграции, найти механизм повторного заражения и подготовить безопасный план очистки. После восстановления мы проверяем ключевые сценарии сайта и повторные признаки в журналах и панелях вебмастеров.

Вывод

Надёжная проверка сочетает сигналы поисковых систем, сравнение HTTP-ответов и анализ серверной части. Результат считается подтверждённым, когда удалён посторонний код, найдена и закрыта точка входа, проверены доступы и задания, а контроль после запуска не показывает повторных признаков.

Источники

[1] Google Search Console — отчёт о проблемах безопасности — https://support.google.com/webmasters/answer/9044101?hl=ru

[2] Google Search Central — вредоносное ПО и нежелательное программное обеспечение — https://developers.google.com/search/docs/monitor-debug/security/malware?hl=ru

[3] Яндекс Вебмастер — угрозы безопасности — https://yandex.ru/support/webmaster/ru/service/security-threats

[4] Яндекс Вебмастер — диагностика сайта — https://yandex.ru/support/webmaster/ru/service/site-diagnostics

[5] curl — официальная документация командной строки — https://curl.se/docs/manpage.html

[6] OWASP Web Security Testing Guide — https://owasp.org/www-project-web-security-testing-guide/

[7] 1С-Битрикс — Поиск троянов — https://dev.1c-bitrix.ru/learning/course/?COURSE_ID=35&LESSON_ID=26614

[8] NIST SP 800-61 Rev. 3 — Incident Response Recommendations and Considerations — https://doi.org/10.6028/NIST.SP.800-61r3