7 проверок сайта на вирусы: одного сканера мало

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

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

Какие признаки искать

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

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

1. Проверьте отчёт Google Search Console

В Search Console откройте раздел «Проблемы безопасности». Официальное описание отчёта Google указывает, что в нём показываются обнаруженные признаки взлома, вредоносное и нежелательное ПО, а также социальная инженерия.

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

2. Сопоставьте оценки в VirusTotal

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

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

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

3. Сравните ответы для разных посетителей

Если есть подозрение на заражение, не открывайте потенциально опасную страницу в обычном браузере на рабочем компьютере. Используйте инструмент проверки URL в Search Console либо получите ответ через cURL или аналогичное средство в изолированной среде.

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

4. Проверьте целостность файлов

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

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

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

5. Запустите сканирование на сервере

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

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

6. Изучите базу данных и учётные записи

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

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

7. Свяжите журналы сервера с изменениями

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

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

Что делать, если заражение подтвердилось

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

Зафиксируйте текущее состояние сайта и ограничьте доступ.
Замените скомпрометированные компоненты официальными чистыми копиями.
Удалите неизвестные аккаунты, ключи, задания и вредоносные записи базы данных.
Обновите CMS, расширения, тему, серверное ПО и зависимости.
Смените пароли и секреты с чистого устройства, включите многофакторную аутентификацию.
Повторите семь проверок и запросите пересмотр в Search Console, если там было предупреждение.

Для WordPress защита не сводится к одному плагину. Руководство WordPress по усилению защиты рекомендует обновлять систему, хранить резервные копии, устанавливать темы и расширения из доверенных источников, пользоваться SFTP, применять сильные пароли и дополнительную проверку входа.

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

7 проверок сайта на вирусы: одного сканера недостаточно