Проверка сайта на вирусы: онлайн-сервисы, проверка сервера и лечение

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

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

Признаки заражения: когда пора проверять сайт

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

• Редиректы только с мобильных. С десктопа сайт открывается нормально, а со смартфона при переходе из поиска посетителя перекидывает на казино, «выигрыш» или платные подписки. Условия бывают хитрее: только для трафика из поисковиков, только для первого визита, только для определённых стран. Администратор с прямым заходом из закладки ничего не замечает.
• Спам-страницы в индексе. Запрос site:вашдомен.ru в Яндексе или Google показывает страницы про фарму, казино, реплики часов или иероглифы, которых вы не создавали. В Вебмастере резко растёт число страниц в поиске, в Метрике появляются входы на неизвестные URL.
• Метка в выдаче. Яндекс показывает под сниппетом предупреждение, что сайт может угрожать безопасности компьютера или мобильного устройства, а браузеры (Яндекс Браузер, Chrome) выводят красную страницу-заглушку. Трафик из поиска падает в разы за несколько дней.
• Письма хостера. Уведомления о найденном вредоносном коде, массовой рассылке спама с аккаунта, аномальной нагрузке на CPU (майнеры), блокировке исходящей почты или отдельных скриптов.
• Изменения, которые никто не вносил. Новые администраторы в CMS, незнакомые файлы в корне и в /upload/, посторонние скрипты в коде страницы (Ctrl+U), изменённый .htaccess, падение скорости без видимых причин.
• Жалобы клиентов. Антивирус ругается на сайт, при оплате открывается чужая форма, в браузере всплывают уведомления о «подписке». Скиммеры на странице оформления заказа выглядят именно так.

Внешняя проверка: онлайн-сервисы и поисковики

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

Яндекс Вебмастер: «Безопасность и нарушения»

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

Что видит: заражение, которое робот Яндекса поймал при обходе, включая редиректы и вредоносные скрипты. Чего не видит: код, который прячется от поисковых ботов (проверяет User-Agent или IP), и бэкдоры, которые ждут своего часа. Детект приходит с задержкой: сайт может быть заражён неделями до появления метки.

Google Safe Browsing и Search Console

Статус сайта в базе Google проверяется на странице Safe Browsing в Transparency Report (transparencyreport.google.com/safe-browsing/search). Для владельца подробнее раздел «Проблемы безопасности» в Google Search Console: там же отправляется запрос на повторную проверку. Эта база важна, даже если трафик из Google небольшой, потому что по ней работают предупреждения Chrome и ряда других браузеров.

VirusTotal, Dr.Web, Kaspersky

VirusTotal (вкладка URL) прогоняет адрес через несколько десятков антивирусных движков и репутационных баз и показывает, кто из них считает ссылку опасной. Удобен для понимания, в чьих чёрных списках вы оказались: после чистки каждому вендору придётся писать отдельно. Российские сервисы Dr.Web (проверка ссылки на vms.drweb.ru) и Kaspersky Threat Intelligence Portal (opentip.kaspersky.com) показывают вердикт своих баз. Это полезно, если посетители жалуются на блокировку сайта антивирусом.

Ограничение у всех одинаковое: проверяется репутация URL и одна загруженная страница. Файлы на сервере, база данных и условные редиректы остаются за кадром.

Sucuri SiteCheck и Quttera

Sucuri SiteCheck загружает страницы сайта, ищет внедрённые скрипты, iframe, спам-ссылки, признаки дефейса, устаревшую CMS и сверяет домен с чёрными списками. Quttera делает похожий динамический анализ. Оба бесплатны в базовом режиме, но это зарубежные сервисы: из РФ они работают нестабильно, а платные тарифы недоступны для российских карт. Считайте их дополнением, а не основой.

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

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

Сканеры: ImunifyAV (бывший AI-Bolit), ClamAV, Maldet

• ImunifyAV / AI-Bolit. Сканер AI-Bolit от российской Revisium много лет был стандартом для поиска шеллов, дорвеев и инжектов в PHP-сайтах. Revisium вошла в CloudLinux, продукт развивается как ImunifyAV и Imunify360, а отдельная версия AI-Bolit больше не поддерживается: старые сборки из интернета со старыми базами лучше не использовать. Бесплатный ImunifyAV (ручной запуск сканирования файлов) встроен во многие зарубежные панели, но в РФ и Беларуси его установка недоступна: CloudLinux в 2022 году прекратил сотрудничество с ispmanager, в панели вместо него предлагается платная интеграция с Dr.Web. На российских хостингах ищите встроенный антивирус в панели провайдера: если хостинг даёт такую кнопку, это самый быстрый первый шаг.
• ClamAV. Открытый антивирус для Linux (clamscan -ri /var/www/site). Хорошо ловит известные файлы и вложения, хуже — свежие обфусцированные PHP-бэкдоры. Сам по себе недостаточен, но вместе с Maldet работает заметно лучше.
• Linux Malware Detect (Maldet). Сканер от R-fx Networks, заточенный под угрозы в среде виртуального хостинга. Проверяет по MD5, HEX-паттернам и YARA, умеет использовать движок ClamAV и отправлять находки в карантин. Актуальная ветка 2.0.x (v2.0.1 вышла в апреле 2026 года). Запуск: maldet -a /var/www/site, отчёт: maldet --report.

У любого сканера бывают ложные срабатывания (минифицированный JS, легитимные библиотеки с base64) и пропуски. Поэтому результат сканера — список кандидатов, который разбирает человек.

Поиск по сигнатурам вручную

Вредоносный PHP почти всегда что-то декодирует и исполняет. Первый проход:

grep -rnE 'eval\s*\(|assert\s*\(|base64_decode|gzinflate|gzuncompress|str_rot13|create_function|shell_exec|passthru|\$_(POST|GET|REQUEST|COOKIE)\[.{1,20}\]\s*\(' --include='*.php' /var/www/site

Совпадений в большой CMS будут сотни, так что смотрите на контекст: длинные строки из случайных символов, переменные вида $O00O0O, вызов функции из переменной ($f($_POST['x'])), код в одну строку в начале легитимного файла, вставки перед <?php.

Изменённые файлы и подозрительные места

• Файлы, изменённые за N дней: find /var/www/site -type f -name "*.php" -mtime -14 -ls. Дату модификации взломщик может подделать, поэтому смотрите и -ctime: время изменения inode через PHP так просто не подделать.
• PHP в папках загрузок: find /var/www/site/wp-content/uploads /var/www/site/upload -type f -name "*.ph*". В uploads WordPress и /upload/ Битрикса исполняемых скриптов быть не должно. Ищите также .phtml, .php7, .suspected и двойные расширения вроде image.jpg.php.
• Сверка с эталоном. Для WordPress есть WP-CLI: wp core verify-checksums и wp plugin verify-checksums --all сравнивают файлы с оригиналами из репозитория. В Битриксе — модуль «Проактивная защита»: контроль целостности и сканер безопасности. Если сайт деплоится из git, git status и git diff сразу покажут чужие правки.
• Планировщик: crontab -l для пользователя сайта и системные cron. Типичная закладка — задание, которое раз в час скачивает и заново восстанавливает бэкдор. Из-за неё сайт «сам заражается» после чистки.
• .htaccess и конфиги: правила RewriteCond %{HTTP_USER_AGENT} или %{HTTP_REFERER} на мобильные и поисковые источники с редиректом на чужой домен, директивы auto_prepend_file в .htaccess, .user.ini и php.ini. Проверяйте все .htaccess по дереву, а не только корневой.
• Пользователи CMS и хостинга: незнакомые администраторы, лишние FTP- и SSH-аккаунты, новые ключи в ~/.ssh/authorized_keys.

Проверка базы данных: WordPress и Битрикс

Всё больше инжектов живёт не в файлах, а в БД. Поиск по файлам их не найдёт.

• WordPress: ищите <script, <iframe, eval(, atob(, fromCharCode в wp_posts.post_content и wp_options.option_value. Проверьте siteurl и home в wp_options, список active_plugins, а также администраторов: пользователей, у которых в wp_usermeta ключ wp_capabilities содержит administrator. Отдельно загляните в wp-content/mu-plugins: плагины оттуда грузятся автоматически и не видны в обычном списке.
• 1С-Битрикс: участники группы администраторов (группа с ID 1 в b_user_group), агенты в b_agent с подозрительным кодом, обработчики событий в b_module_to_module, вставки в шаблонах и включаемых областях, настройки в b_option. Сценарии массовых атак на Битрикс и срочные шаги после взлома мы разобрали в отдельной статье, здесь только суть проверки.

Что делать, если вирус найден

Типичная ошибка — удалить найденный файл и выдохнуть. Через несколько дней вирус возвращается, потому что уязвимость и бэкдоры остались. Рабочая последовательность такая:

1. Изоляция. Закройте сайт заглушкой или ограничьте доступ по IP, особенно при редиректах на мошеннические ресурсы или скиммере на оплате. Отключите исходящую почту, если с аккаунта идёт спам.
2. Снимок для анализа. Сделайте полную копию файлов, дамп БД и сохраните логи веб-сервера. По логам (POST-запросы к нетипичным скриптам, обращения к /upload/*.php) определяется точка входа. Без неё чистка превращается в игру в угадайку.
3. Чистка или откат. Если есть бэкап, сделанный заведомо до заражения, восстановление из него обычно надёжнее ручной чистки. Но это возможно только когда известна дата взлома, и всё равно придётся закрыть уязвимость и перенести свежие данные (заказы, заявки). Иначе — ручная чистка: ядро CMS и плагины заменяются эталонными копиями, а не лечатся построчно, вручную разбираются только собственный код, шаблон и БД.
4. Смена всех секретов. Пароли админки CMS, хостинга, FTP/SSH, базы данных, почтовых ящиков; SSH-ключи; соли и ключи в wp-config.php; токены API, ключи платёжных систем и интеграций. Смену делайте после чистки, иначе бэкдор перехватит новые пароли.
5. Обновления. Ядро CMS, плагины, модули, тема, версия PHP. Брошенные и «нулёные» плагины удалить.
6. Закрытие уязвимости. Найти, через что зашли: дыра в плагине, слабый пароль, утёкший доступ подрядчика, соседний заражённый сайт на том же аккаунте хостинга. Пока вход не закрыт, работа не закончена.
7. Перепроверка в поисковиках. В Яндекс Вебмастере на странице «Безопасность и нарушения» опишите, что исправлено, поставьте отметку «Нарушение исправлено» и нажмите «Отправить на проверку». Проверка занимает до 30 дней. Если алгоритмы снова найдут проблему, следующая заявка будет доступна только через 30 дней, поэтому отправлять стоит только полностью вычищенный сайт. В Google — запрос повторной проверки в Search Console, антивирусным вендорам — отдельные обращения.

Если на сайте идут продажи, а внутри нет специалиста, последовательность «анализ → чистка → закрытие уязвимости → снятие санкций» разумнее доверить профильной команде по восстановлению сайта после взлома. Каждый день метки «сайт может угрожать» — это прямые потери трафика и заявок.

Профилактика: как не допустить повторного заражения

• Регулярные обновления CMS и расширений. Большинство массовых заражений идёт через известные уязвимости, для которых патч уже вышел.
• Автоматические бэкапы вне основного сервера с глубиной хранения не меньше 30 дней, чтобы было из чего восстановиться, если заражение обнаружили поздно.
• Запрет исполнения PHP в папках загрузок, права 644/755 без 777, отдельный системный пользователь для каждого сайта.
• Двухфакторная аутентификация и ограничение входа в админку по IP, уникальные пароли, отдельные временные доступы для подрядчиков и их отзыв после работ.
• WAF на уровне хостинга или отдельного сервиса.
• Мониторинг: уведомления Вебмастера, регулярный запуск сканера на сервере, контроль изменений файлов, алерт на появление новых администраторов.

Точечная проверка отвечает на вопрос «заражён ли сайт сейчас». Чтобы найти слабые места до того, как ими воспользуются, нужен аудит безопасности сайта. А обновления, бэкапы и мониторинг удобно закрыть регламентной технической поддержкой сайта.

Сравнение сервисов и сканеров

Чек-лист проверки сайта на вирусы

• Проверен раздел «Безопасность и нарушения» в Яндекс Вебмастере и «Проблемы безопасности» в Search Console
• Сайт открыт с мобильного через мобильный интернет, в инкогнито и переходом из поиска
• Запрос site:домен просмотрен на чужие страницы
• URL прогнан через VirusTotal и Dr.Web
• Сделана копия файлов, дамп БД и сохранены логи до любых изменений
• Запущен серверный сканер (антивирус в панели хостинга или Maldet с ClamAV)
• Выполнен поиск по сигнатурам eval/base64_decode/gzinflate
• Найдены PHP-файлы, изменённые за последние 2–4 недели
• Папки загрузок проверены на исполняемые скрипты
• Проверены crontab, все .htaccess, .user.ini, auto_prepend_file
• Проверены администраторы CMS, FTP/SSH-аккаунты, authorized_keys
• База данных проверена на скрипты, iframe и подменённые настройки
• Ядро и плагины сверены с эталоном (checksums, контроль целостности, git)
• После чистки сменены все пароли, ключи и токены, закрыта точка входа
• Отправлен запрос на перепроверку в Вебмастер и Search Console

Вывод

Проверить сайт на вирусы только онлайн-сервисом — всё равно что мерить температуру через окно. Внешние инструменты показывают, как вас видят поисковики и антивирусы, и нужны для снятия санкций. Но заражение находят и лечат на сервере: сканеры, поиск по сигнатурам, сверка с эталоном, ревизия БД, cron и пользователей. И работа закончена только тогда, когда найдена и закрыта точка входа, иначе через неделю всё повторится.