Как проверить сайт на вирусы и вредоносный код
Чтобы проверить сайт на вирусы, нужно сопоставить несколько источников: предупреждения поисковых систем, результаты внешних сканеров и состояние файлов, базы данных и учётных записей. Один сервис видит известную репутацию адреса, другой анализирует публичную страницу, а внутренние изменения доступны владельцу и администратору. Поэтому зелёный отчёт по главной не заменяет проверку всего проекта.
Ниже — порядок действий для владельца сайта и вебмастера: какие признаки сохранить, какими инструментами пользоваться, как читать результаты и когда передавать задачу специалисту. Материал посвящён диагностике своего ресурса. Проверка честности интернет-магазина перед покупкой и восстановление после подтверждённого взлома требуют отдельных решений. Все адреса на example.com в примерах условные.
Что означает проверка сайта на вирусы
В разговоре «вирусом на сайте» называют разные проблемы: чужой код, вредоносное перенаправление, подменённые страницы, опасные загрузки и поисковый спам. Для выбора действия важно выяснить, что именно обнаружено и где находится источник. Предупреждение о фишинге и изменённый серверный файл — связанные с безопасностью наблюдения, но они не дают одинакового описания инцидента.
Практически проверку удобно разделить на три уровня. Они дополняют друг друга: внешний результат помогает выбрать направление, а внутренняя проверка — установить источник и масштаб. Вывод должен соответствовать реально изученной области.
| Уровень | Что можно узнать | Что остаётся за пределами |
|---|---|---|
| Репутация URL или домена | Есть ли известные сервису признаки опасности и предупреждения | Полный состав файлов, базы и настроек сервера |
| Удалённая проверка страницы | Что получает внешний посетитель в условиях анализа: контент, ресурсы, переходы | Закрытые области и скрытый серверный код, не проявившийся в ответе |
| Внутренняя проверка владельца | Изменения файлов, данных, прав, расписаний и журналов | Автоматическая гарантия обнаружения всех угроз без анализа результатов |
Антивирус на рабочем компьютере решает ещё одну задачу — защищает это устройство. Успешная проверка ноутбука администратора не означает, что удалённый хостинг чист. Аналогично отсутствие предупреждения браузера не подтверждает неизменность сайта.
Какие признаки требуют проверки
Начинайте с наблюдаемого факта. Вместо «кажется, сайт заражён» запишите: «после открытия страницы посетитель попал на неизвестный ресурс» или «в CMS появился администратор, которого никто не создавал». Так проще проверить повторяемость и назначить ответственного. Официальная памятка WordPress по подозрению на взлом также предлагает сначала описать конкретные признаки.
- Посетители или системы защиты сообщают о вредоносном содержимом.
- Появились несанкционированные перенаправления, объявления или предложения скачать программу.
- В поиске обнаружены чужие страницы и тексты, которые команда не публиковала.
- Изменились шаблоны, платёжные реквизиты или внешние подключения без согласованного выпуска.
- Найдены неизвестные администраторы, задания по расписанию или новые файлы с непонятным назначением.
- Хостинг сообщил о подозрительной активности или ограничил работу ресурса.
Каждый такой сигнал требует уточнения. Неизвестная учётная запись может принадлежать подрядчику, а редирект — оказаться ошибкой настройки. Но объяснение должно быть подтверждено владельцем изменения и его назначением. Не закрывайте обращение предположением «наверное, это разработчик».
Сами по себе минифицированный JavaScript, iframe, строка base64, медленная загрузка или ошибка 404 не доказывают заражение. Эти конструкции и симптомы встречаются в обычной работе сайтов. Значение имеют происхождение, поведение и соответствие согласованной конфигурации. Автоматическое удаление всего, что выглядит необычно, может сломать сайт и уничтожить полезные следы.
Что подготовить до запуска проверки
Составьте небольшую карточку наблюдения: точный URL, дата и время с часовым поясом, устройство, источник сообщения, скриншот предупреждения и ожидаемое поведение. Укажите, открывалась ли главная или внутренняя страница. Проблема на одном поддомене не должна незаметно превращаться в заключение о другом.
- Определите область. Какие домены, шаблоны, файлы и учётные записи относятся к задаче.
- Соберите исходные сведения. Версия CMS, недавние обновления, смена подрядчика, перенос хостинга и подключение сторонних модулей.
- Сохраните наблюдения. Не редактируйте подозрительный файл до фиксации его содержания и контекста; храните материалы с ограниченным доступом.
- Назначьте контакт. Кто может проверить сервер, остановить опасное действие и объяснить штатные изменения.
- Разделите проверку и исправление. Просмотр отчёта не даёт основания сразу удалять файлы или переустанавливать систему.
Если посетителям уже причиняется вред, сбор идеального набора отчётов не должен задерживать ограничение опасной функции. Обратитесь к администратору или хостингу и переходите к плану реагирования. При подозрении на заражение не обходите предупреждение браузера и не запускайте найденные программы ради проверки.
Какие данные нельзя отправлять публичному сканеру
До отправки URL проверьте его параметры. Ссылка сброса пароля, адрес закрытой CRM, платёжная сессия или токен доступа могут раскрывать сведения даже без загрузки файла. В публичные анализаторы не следует передавать резервную копию сайта, конфигурацию с паролями, выгрузку клиентов и другие закрытые материалы.
Например, VirusTotal описывает обмен результатами с партнёрами и сообществом, а также возможную доступность содержимого отправок отдельным клиентам сервиса. Стандартную отправку нельзя считать конфиденциальной. Для закрытых данных согласуйте подходящую среду анализа и режим обращения с материалами; доступ к ним предоставляют по задаче, а не всем участникам переписки.
Как проверить предупреждения Google и Яндекса
Начните с официальных кабинетов, если права на сайт уже подтверждены. Они могут показать проблему, которая не воспроизводится у владельца при обычном открытии главной. Сохраняйте текст сообщения и связанные адреса, чтобы дальнейшая работа опиралась на исходные данные.
Google Safe Browsing и статус сайта
На странице Google Safe Browsing описан инструмент проверки статуса сайта; из неё можно перейти к Site Status в отчёте о прозрачности. Он помогает узнать, обнаружил ли Safe Browsing опасное содержимое. Это проверка конкретного сигнала Google, а не инвентаризация файлов хостинга.
Сверьте проверенный адрес, полученное сообщение и дату. Не распространяйте результат одного URL на все поддомены, закрытые разделы и будущие версии сайта. Если предупреждение есть, сохраните его и переходите к описанию причины. Если предупреждения нет, сопоставьте это с остальными наблюдениями.
Отчёт «Проблемы безопасности» в Search Console
Google Search Console показывает проблемы безопасности, включая взломанное содержимое, вредоносное или нежелательное ПО и социальную инженерию. Откройте описание каждой обнаруженной проблемы и примеры URL. Google предупреждает: примеры не обязательно охватывают все затронутые страницы, а отсутствие примеров не означает отсутствие проблемы.
Не смешивайте этот отчёт с мерами, принятыми вручную за нарушения правил поиска. Различие важно для выбора процедуры проверки и последующего обращения. Снижение поискового трафика само по себе не доказывает заражение: нужен конкретный технический или поисковый сигнал.
Яндекс Вебмастер
Проверьте раздел «Оптимизация сайта → Безопасность и нарушения» и сообщения диагностики. Читайте причину, а не только общий статус: нарушения правил поиска и опасное поведение могут требовать разных действий. Отсутствие действующего ограничения не является отчётом о проверке каждого серверного файла. Уведомление о нарушении, техническое исправление и обновление поискового статуса фиксируйте отдельно.
Чем проверить сайт на вирусы онлайн
Выбирайте инструменты по тому, какую неопределённость они уменьшают. Несколько одинаковых репутационных проверок не заменяют просмотр внутреннего источника подмены. Для начала достаточно отчётов поисковиков, одного агрегатора репутации и удалённого сканера публичной страницы; дополнительные средства подключают по найденным признакам.
VirusTotal: сопоставить вердикты и сведения об адресе
VirusTotal, который часто ищут как «Вирус Тотал», объединяет результаты разных участников. Для публичного URL просмотрите дату последнего анализа, точный адрес, характер срабатываний и сведения о конечном адресе после перенаправления, если они доступны. Устройство отчёта объясняется в официальном руководстве VirusTotal.
Число срабатываний помогает ориентироваться, но не является математической вероятностью заражения. Участники используют разные способы оценки; репутационный вердикт не сообщает, в каком PHP-файле находится причина. Комментарии сообщества также отделяйте от результатов анализирующих систем.
В описании данных URL различаются harmless и undetected: отсутствие обнаружения не равнозначно положительному заключению о безопасности. Проверьте также ошибки и незавершённые проверки. Если отчёт относится к старой версии страницы, зафиксируйте это ограничение вместо вывода о сегодняшнем состоянии.
Отдельно различайте адрес загрузки и сам загружаемый файл. В модели VirusTotal предусмотрены анализы URL и файлов: заключение по странице не заменяет проверку конкретного документа или архива. Если жалоба относится к скачиванию, установите точный файл, его версию и адрес выдачи. Не запускайте образец для воспроизведения жалобы; способ безопасного получения и анализа определяет ответственный специалист с учётом конфиденциальности содержимого.
Sucuri SiteCheck: увидеть внешние проявления
Sucuri SiteCheck удалённо исследует доступную страницу и ищет признаки вредоносного содержимого, подмены и других проблем. Сам сервис подчёркивает ограничение: внешний анализ видит то, что доступно на уровне браузера, и не проверяет всё серверное содержимое.
Для владельца это полезный способ сопоставить публичный ответ с ожидаемым видом страницы. Но закрытая база, неиспользуемая в ответе вредоносная вставка или скрытый серверный файл могут остаться вне такого анализа. В отчёте обязательно сохраняйте охват и факт успешного получения страницы: ошибка загрузки не означает «угроз нет».
Kaspersky Threat Intelligence Portal: уточнить репутацию
Для проверки адреса в экосистеме Kaspersky существует Threat Intelligence Portal. Его справка отчёта домена и веб-адреса описывает доступные категории и связанные сведения. Состав отчёта зависит от имеющихся данных и доступа; не ожидайте одинаковой детализации для любого URL.
Различайте отсутствие данных и отсутствие обнаруженных угроз. В документации статусов No threats detected связано с проведённым анализом и его результатом на тот момент. Такая онлайн-проверка Kaspersky не запускает полную инвентаризацию вашего хостинга и не заменяет анализ файлов владельцем.
Как читать результаты без ложных выводов
Сопоставляйте одинаковые объекты и время. Отчёт по https://example.com/, проверка https://shop.example.com/ и анализ отдельного файла относятся к разным целям. Даже для одного адреса CDN, изменения публикации или перенаправление могут привести к изучению разных ответов. Сохраняйте исходный и конечный URL вместе.
| Наблюдение | Корректный вывод | Следующее действие |
|---|---|---|
| Срабатывание одного участника | Есть сигнал, который требует проверки | Изучить категорию, дату, объект и независимые свидетельства |
| Ни один участник не сообщил об угрозе | В указанной проверке угроза не обнаружена | Сверить охват с симптомами и внутренними данными |
| Сканер не смог получить страницу | Проверка ограничена или не состоялась | Выяснить причину доступа, не засчитывать результат как чистый |
| Старое предупреждение после изменения сайта | Нужна сверка версии и даты анализа | Подтвердить исправление и следовать процедуре сервиса |
Одиночный детект нельзя автоматически считать ложным: он может оказаться первым полезным сигналом. Но и объявлять весь сайт заражённым только по счётчику недостаточно. Ищите связку «предупреждение → конкретный объект → несогласованное изменение или опасное поведение». Когда причина не установлена, так и запишите.
Проверка сайта на вирусы по ссылке особенно полезна для первичной оценки и поиска направления. Её результат должен отвечать на вопрос «что обнаружено этим методом сейчас», а не подменять собой заключение обо всех компонентах проекта.
Что проверить внутри сайта владельцу и администратору
Внутреннюю проверку проводят с разрешённым доступом, начиная с фиксации состояния. Сравнение выполняют доверенными инструментами в подготовленной среде. Не переносите подозрительный проект на обычный рабочий компьютер для запуска и не устанавливайте случайный «лечащий» скрипт из сообщения или форума.
Файлы и конфигурация
Сопоставьте файлы с официальным дистрибутивом той же версии либо с проверенным исходным состоянием проекта. Изучите несогласованные добавления и изменения в шаблонах, модулях, загрузках и правилах маршрутизации. Отдельно отметьте, какие файлы вообще не входят в выбранный эталон. Дата изменения помогает построить хронологию, но сама по себе не доказывает вредоносность: обновление или развёртывание также меняет время файлов.
Для каждой находки выясните назначение и автора изменения. Фраза «файл появился недавно» должна дополняться объяснением его поведения и связи с симптомом. Если сравнение показывает массовые различия после штатного обновления, сначала выберите правильную версию для сравнения.
База данных и учётные записи
Проверьте несанкционированные изменения материалов, настроек, блоков, ссылок и реквизитов, а также новых пользователей и расширение прав существующих. Чужая вставка может храниться в базе и попадать в ответ через исправный шаблон. Поэтому замена файлов CMS без проверки данных не объясняет весь источник проблемы.
Список администраторов сверяйте с ответственными лицами. Запишите, кто подтвердил принадлежность аккаунта и необходимость доступа. Не публикуйте выгрузку пользователей вместе с техническим отчётом: исполнителю передают необходимую часть данных по согласованному каналу.
Расписания, доступы и журналы
Изучите задания по расписанию, способы развёртывания, изменения доступов и доступные журналы хостинга и приложения. Сопоставьте время событий с первым наблюдением и последними выпусками. Отсутствие записи в одном журнале не доказывает отсутствие действия: заранее выясните, что логировалось и за какой период сохранились данные.
При признаках компрометации самого серверного окружения задача шире сайта. Подключите администратора хостинга или специалиста по реагированию. Продолжать доверять только отчёту внутри уже изменённой CMS в такой ситуации недостаточно.
Как проверить WordPress и не переоценить контрольные суммы
Для WordPress существуют официальные средства сравнения файлов с эталоном. Команда wp core verify-checksums сопоставляет файлы ядра с контрольными суммами WordPress.org. Важно выбрать соответствующие версию и локализацию. Это конкретная проверка целостности ядра, а не заключение о всём сайте.
Для плагинов есть отдельная проверка по данным WordPress.org. В официальном разборе проверок безопасности объясняется, что для собственного или коммерческого плагина вне каталога контрольные суммы могут отсутствовать. Такой пропуск не доказывает ни заражение, ни исправность.
Успешное сравнение ядра не охватывает автоматически темы, загрузки, все плагины, базу и серверные настройки. Попросите администратора явно перечислить проверенные области. Инструмент и среду запуска также выбирают осознанно: не следует выполнять содержимое подозрительного проекта на доверенной машине, полагаясь только на название диагностической команды.
Почему проблема видна не всем и при чём здесь внешние компоненты
Несовпадение наблюдений владельца и посетителя не делает обращение ошибочным. Подмена может проявляться только в отдельных условиях, а страницы могут отдаваться из разных кэшей. Google в справке по проблемам безопасности также описывает случаи, когда владелец и поисковая система получают различное содержимое.
Сохраните условия исходного сообщения: тип страницы, устройство, время, был ли пользователь авторизован и откуда пришёл. Не просите посетителя повторно обходить предупреждение или вводить данные ради записи видео. Специалисту передают наблюдения для безопасного воспроизведения в изолированной среде; обычную рабочую сессию для таких экспериментов не используют.
Проверьте и происхождение сторонних скриптов, виджетов, рекламных блоков и ресурсов. Сайт может подключать изменившийся внешний компонент при неизменных собственных файлах. При этом сам факт внешнего запроса не является доказательством: сверьте адрес и назначение с утверждёнными интеграциями. Удаление нужного платёжного или аналитического компонента без проверки создаст новую неисправность.
Как оформить результаты проверки
Хороший отчёт сохраняет связь между сигналом, доказательством и следующим действием. Используйте состояния «подозрение», «подтверждено» и «недостаточно данных» с объяснением, к чему относится статус. Подтверждённое изменение одного файла не означает автоматически установленный масштаб всего инцидента.
Ниже приведён учебный образец, а не результаты проверки реального сайта. Короткие пути относятся к example.com. В рабочем журнале дополнительно сохраняйте время, источник сообщения, ответственного и безопасное расположение материалов.
| Объект и факт | Свидетельство | Охват | Состояние | Следующий шаг |
|---|---|---|---|---|
/catalog/: посетитель сообщил о чужом переходе | Скриншот и время обращения | Один описанный сценарий | Подозрение | Сопоставить с журналами и ответом страницы |
| В шаблон внесена несанкционированная вставка | Сравнение с доверенной версией и подтверждение команды | Шаблон; зависимые страницы уточняются | Изменение подтверждено | Оценить поведение, ограничить вред и расследовать источник |
/docs/: внешний сервис не получил ответ | Ошибка загрузки в отчёте | Проверка не выполнена | Недостаточно данных | Разобрать доступность и выбрать другой разрешённый метод |
Не заменяйте журнал подборкой скриншотов без подписей. Исполнитель должен понимать, какой адрес и момент они отражают. Пароли, токены и полные конфигурации не вставляйте в общий отчёт; укажите способ передачи необходимых данных с ограничением доступа.
Что делать после проверки: выбрать следующий шаг
Если сигналы не подтвердились, зафиксируйте использованные методы, охват и ограничения. Например, «публичные страницы из выборки не показали заявленный переход» точнее, чем «сайт абсолютно безопасен». Сохраните исходное обращение и назначьте наблюдение, если проблема может повторяться.
Если данные противоречат друг другу, передайте специалисту конкретную задачу: проверить источник определённого редиректа, объяснить изменённый файл или сверить неизвестную учётную запись. Продолжать бесконечно отправлять главную в похожие сервисы менее полезно, чем устранить установленный пробел в данных.
Если опасное поведение или несанкционированные изменения подтверждены, переходите к реагированию: ограничению вреда, сохранению материалов и восстановлению из доверенного состояния с устранением причины. Не ограничивайтесь удалением видимой строки и заявкой на снятие предупреждения. Когда нужны срочные решения, владелец, администратор и хостинг должны согласовать ответственность и порядок действий.
Как проверить результат после исправления
Повторная проверка должна закрывать исходные находки и их общий источник. Сопоставьте те же адреса и условия с новым состоянием. Дополнительно проверьте связанные шаблоны и внутренние области, которые были затронуты; исправление одного показанного URL не устанавливает состояние остальных.
- Подтвердите устранение конкретного опасного поведения и несогласованных изменений.
- Проверьте, что восстановлены доверенные компоненты и устранён выявленный источник повторного появления проблемы.
- Убедитесь, что основные действия посетителя работают и исправления не повредили формы, загрузки и оплату.
- Сохраните новые результаты внутренних и внешних проверок с датами.
- После фактического устранения следуйте процедуре повторной проверки поисковой системы или поставщика защиты.
Принятая заявка не равна снятому предупреждению, а обновившийся репутационный статус не заменяет внутреннюю приёмку. Нулевое число детектов — полезное наблюдение в определённом охвате, но не универсальный сертификат безопасности. Итоговый отчёт должен показывать, какие причины устранены, что проверено и кто продолжает наблюдение.
Частые вопросы о проверке сайта на вирусы
Достаточно ли проверить только главную страницу?
Нет, если симптомы относятся к другим адресам или шаблонам. Выберите проблемный URL и представителей связанных групп. Главная может получать другой набор ресурсов и не показывать вставку, присутствующую в карточках или статьях.
Можно ли считать один детект ложным срабатыванием?
Только после проверки причины. Изучите объект, дату, тип вердикта и независимые свидетельства. При подтверждённой ошибке передайте поставщику защиты необходимые сведения по его процедуре; количество срабатываний само по себе вопрос не решает.
Почему сканер ничего не нашёл, а браузер предупреждает?
Сервисы могут использовать разные данные и анализировать разные ответы в разное время. Сверьте адрес, переходы и даты. Не обходите предупреждение ради проверки: начните с отчётов и безопасного анализа ответственным специалистом.
Нужно ли удалить все неизвестные JavaScript-файлы?
Нет. Сначала определите происхождение и назначение. У сайта могут быть штатные сборки, внешние библиотеки и служебные компоненты с непривычными именами. Удаление без анализа способно сломать интерфейс и не затронуть реальный источник.
Доказывает ли проверка ядра WordPress безопасность сайта?
Она подтверждает результат сравнения определённого набора файлов. База, загрузки, темы, часть плагинов и окружение требуют отдельного рассмотрения. В отчёте должны быть перечислены проверенные области и пропуски.
Что подготовить для обращения к специалисту?
Точные адреса, время и описание симптомов, отчёты с датами, сведения о CMS, недавних изменениях и доступных резервных копиях. Доступы передавайте только по согласованному каналу; не размещайте их в публичной форме диагностики.
После проверки безопасности включите важные публичные страницы в регулярный контроль доступности. Оцените SiteGuard для мониторинга сайта и назначьте ответственного за реакцию на сбои. Сохраните результаты проверки безопасности и перечень устранённых причин: они помогут команде разобраться при повторении прежних симптомов.