Как проверить сайт на вирусы и признаки взлома
Как проверить сайт на вирусы и признаки взлома: внешние сервисы, серверные файлы, журналы и безопасный порядок действий без ложных гарантий.
Self-hosted проекты, безопасность и почта
Она объясняет почтовый хостинг, базовую безопасность, VPS для личных проектов и разумные границы самостоятельности.
Проверка сайта на вирусы не сводится к одному онлайн-сканеру. Сначала проверьте внешние предупреждения и видимые страницы, затем файлы и задания на сервере, после чего вручную разберите журналы, доступы и источник изменений. Чистый отчёт снижает подозрения, но не доказывает отсутствие взлома.
Слово «вирус» удобно для поиска, но на сайте проблема часто выглядит иначе: внедрённый JavaScript, скрытый редирект, фишинговая страница, новый администратор, изменённый шаблон или постороннее задание. Поэтому полезен не список сервисов, а порядок проверки с понятными границами каждого метода.
Что делать при явном предупреждении или редиректе
Если браузер показывает опасное предупреждение, посетителей перенаправляет на чужой домен или на сайте появилась неизвестная страница, не открывайте подозрительный адрес на основном рабочем компьютере. Google также советует владельцам не просматривать заражённые страницы обычным способом: вредоносный код может атаковать браузер, а содержимое может меняться для разных посетителей.
Сначала сохраните следы. Зафиксируйте время, адрес страницы, текст предупреждения, снимки экрана, журналы веб-сервера и перечень недавно изменённых файлов. Первый найденный файл хочется удалить немедленно, но такая уборка заметает следы раньше, чем закрывает вход злоумышленника.
Затем ограничьте риск для посетителей. В зависимости от ситуации это может быть режим обслуживания, отключение скомпрометированного приложения от сети или временная изоляция отдельного узла. Не заменяйте рабочие файлы до снимка диска или другой пригодной копии, если инцидент серьёзный и потребуется расследование.
Меняйте пароли с чистого устройства, когда есть подозрение на посторонний доступ. Учитывайте не только панель сайта, но и хостинг, SSH, базу данных, почту, хранилище резервных копий, ключи развёртывания и учётные записи администраторов. Если неизвестен путь проникновения, одной смены пароля недостаточно.
Три уровня проверки сайта
Каждый уровень отвечает на свой вопрос. Внешний сервис видит репутацию и доступный ему ответ сайта. Серверный сканер видит файлы в пределах своих прав и правил. Ручная диагностика связывает изменения, доступы и события в одну картину.
| Уровень | Что можно обнаружить | Что останется за границей |
|---|---|---|
| Внешняя проверка | Известную опасную репутацию, фишинг, вредоносную загрузку, видимый редирект или внедрение | Скрытые файлы, базу данных, задания, закрытые страницы и условную выдачу |
| Проверка сервера | Сигнатурные совпадения, изменённые файлы, неожиданные скрипты и расхождения с эталоном | Новую неизвестную технику, легитимный на вид код и смысл действий учётной записи |
| Ручная диагностика | Связь между журналами, пользователями, файлами, процессами и причиной проникновения | То, для чего не сохранились журналы, копии или достаточные права доступа |

Главное ограничение: отсутствие находки не равно отсутствию компрометации. Проверка показывает, что конкретный инструмент увидел при конкретном доступе и в конкретный момент. Не берите красивую зелёную плашку за сертификат безопасности.
Внешние репутационные проверки
Начните с Google Search Console, если сайт подтверждён в вашем аккаунте. Отчёт о проблемах безопасности показывает обнаруженные Google случаи взломанного содержимого, вредоносных загрузок и социальной инженерии. Указанные адреса являются примерами, а не полным перечнем поражённых страниц.
Google Safe Browsing позволяет проверить адрес по спискам известных опасных ресурсов. Такой результат полезен, когда посетители видят предупреждение браузера или сайт потерял доверие поисковой системы. Но список репутации не читает каталоги сервера и не знает обо всех новых заражениях.
VirusTotal агрегирует сигналы разных антивирусных движков, анализаторов адресов и списков блокировки. Несогласие движков нормально: один сигнал требует проверки, а не немедленного удаления файла. Столь же неверно считать сайт чистым только потому, что большинство источников ничего не отметило.
Не отправляйте секретные адреса бездумно. VirusTotal сообщает, что основные результаты отправленных файлов и адресов доступны участникам анализа. Не передавайте адреса с токенами сброса пароля, закрытые панели, временные ссылки на документы и другие данные, которые не должны становиться внешним сигналом.
Для внешнего теста выберите несколько страниц разных типов: главную, материал, форму входа, страницу загрузки и адрес, на который пожаловался посетитель. Проверьте ответы с настольного и мобильного устройства, но подозрительное содержимое исследуйте из изолированной среды или через безопасный просмотр ответа.
Почему онлайн-сканер может ничего не найти
Вредоносный код умеет показываться только посетителям из определённой страны, с мобильного устройства, из поисковой выдачи или без административной cookie. Он может срабатывать не при каждом запросе. Обычный сканер увидит чистую версию и честно сообщит лишь о ней.
Некоторые внедрения живут не в HTML-ответе, а в базе данных, задании планировщика, загрузочном файле, расширении CMS или чужой учётной записи. Пока условие не выполнено, внешний обход не увидит полезной нагрузки.
Поэтому зелёный отчёт отвечает на узкий вопрос: известна ли сервису проблема и воспроизвелась ли она сейчас. Для владельца это начало проверки, а не её финал.
Проверка файлов и заданий на сервере
Следующий слой требует доступа к хостингу или серверу. Перед изменениями сделайте копию файлов, базы данных, конфигурации и доступных журналов. Резервная копия после взлома не считается чистой, но сохраняет материал для сравнения и расследования.
Антивирусный сканер ищет известные сигнатуры и подозрительные конструкции. ClamAV умеет проверять каталоги и разные типы файлов, включая нормализованный HTML и JavaScript. У него, как у любого сигнатурного инструмента, возможны пропуски и ложные срабатывания; проект отдельно описывает порядок сообщения о ложной тревоге.
Не настраивайте автоматическое удаление на первом проходе. Помещайте подозрительные файлы в отдельную копию или карантин после сохранения доказательств. Проверьте путь, владельца, время изменения, процесс создания и обращения к файлу. Название вроде cache или update ещё ничего не доказывает.
Сравнение с эталоном часто полезнее поиска пугающих строк. Для CMS и библиотек сверяйте системные файлы с официальным дистрибутивом той же версии. Собственные загрузки, темы, расширения и конфигурация требуют отдельного сравнения с репозиторием или заведомо чистой копией.
Проверьте не только каталог сайта:
- задания планировщика пользователя и системы;
- процессы, которые запускаются не из ожидаемых путей;
- новые ключи SSH и неизвестные учётные записи;
- конфигурацию веб-сервера и файлы переопределения правил;
- каталоги временных файлов и загрузок;
- базу данных на внедрённые скрипты, ссылки и администраторов;
- правила развёртывания, хуки и ключи доступа к репозиторию.
Если доступен только файловый менеджер панели, попросите хостинг предоставить журналы и результаты серверной проверки. Сканирование небольшого набора файлов через браузер не заменяет обзор процессов, заданий и событий входа.
Проверка WordPress по контрольным суммам
Для WordPress официальный WP-CLI умеет сравнивать файлы ядра с контрольными суммами WordPress.org, причём проверка запускается до загрузки самого WordPress. Это снижает риск, что внедрённое расширение повлияет на результат команды.
wp core verify-checksums
wp plugin verify-checksums --all --strict
Несовпадение не всегда означает вредоносный код. Причиной может быть повреждённый файл, ручная правка или неверно указанная версия. Для коммерческого или собственного расширения официальной контрольной суммы может не быть; WP-CLI в таком случае сообщает, что проверка недоступна, а не подтверждает заражение.
Успешная проверка ядра тоже не закрывает инцидент. Она не проверяет базу данных, содержимое загрузок, конфигурацию, задания планировщика, пользователей и расширения без доступных сумм. Используйте результат как один слой доказательств.
Ручная диагностика причины взлома
Удалить внедрение мало. Нужно понять, как оно появилось и что ещё затронуто. Сопоставьте время первого предупреждения с журналами входов, запросов, развёртываний, обновлений и изменений файлов. Ищите не только один адрес злоумышленника: доступ мог идти через украденную учётную запись или уязвимое расширение.
Проверьте административных пользователей и активные сеансы. Неизвестный пользователь, изменённая почта владельца или новый ключ доступа — самостоятельные признаки инцидента. Завершите сеансы и отзовите ключи, но сначала сохраните данные, необходимые для понимания хронологии.
Изучите механизм повторного запуска. Если вредоносный файл возвращается после удаления, его может восстанавливать задание, загрузчик, процесс, правило развёртывания или запись в базе. Файл здесь как сорняк: пока корень на месте, уборку придётся повторять.
Журналы важнее догадок. Запросы к необычным административным путям, неожиданные успешные входы, запуск интерпретатора из каталога загрузок и исходящие соединения после изменения файла помогают отделить случайную правку от компрометации.
Если сайт обрабатывает персональные данные, платежи или важные учётные записи, привлеките специалиста по реагированию. Масштаб утечки и обязательства по уведомлению нельзя определить по отчёту онлайн-сканера.
Как очищать сайт без самообмана
Сначала ограничьте активность злоумышленника, затем устраните путь входа и только после этого восстанавливайте работу. CISA включает сохранение доказательств в план сдерживания и рекомендует изоляцию затронутых систем, а при подозрении на компрометацию — смену административных паролей, ключей и секретов сервисов.
Надёжнее восстановить приложение из заведомо чистого источника, чем вручную вырезать отдельные фрагменты из десятков файлов. Пользовательские данные переносите отдельно и проверяйте. Резервную копию выбирайте по дате и признакам, а не только по факту успешного восстановления.
После очистки обновите уязвимый компонент, удалите неиспользуемые расширения, исправьте права, замените секреты и включите наблюдение за изменениями. Если причина не найдена, риск повторения остаётся высоким, даже когда страницы снова выглядят нормально.
Затем повторите все уровни проверки. Убедитесь, что внешние предупреждения исчезли, файлы соответствуют ожидаемому состоянию, неизвестные задания и пользователи удалены, а журналы не показывают прежний сценарий. Запрос на пересмотр в Search Console отправляйте после полной очистки, а не после первого зелёного скана.
Короткий план проверки
Чек-лист
- Сдерживание: ограничьте доступ к подтверждённо заражённому узлу, сохранив журналы и копию состояния до очистки.
- Внешние сигналы: проверьте Search Console, Safe Browsing и несколько типов страниц, не передавая секретные адреса.
- Сервер: сравните файлы с эталоном и проверьте задания, пользователей, процессы, базу данных и журналы.
- Причина: устраните уязвимый компонент или украденный доступ до восстановления сайта и повторной проверки.
Когда пора остановиться и позвать специалиста
Не продолжайте самостоятельную очистку, если не можете безопасно изолировать сайт, сохранить доказательства или определить затронутые системы. То же относится к повторному заражению, неизвестному административному доступу, подозрению на утечку данных и компрометации нескольких узлов.
Честная граница важнее бодрого отчёта. Онлайн-сервис не видит весь сервер, антивирус не знает смысл каждого файла, а владелец без журналов не восстановит полную хронологию. В такой ситуации правильный результат проверки — не слово «чисто», а перечень неизвестных и решение, кто их закроет.
Частые вопросы
Можно ли проверить сайт на вирусы бесплатно?
Зелёный результат VirusTotal означает, что сайт безопасен?
Почему вредоносный файл появляется после удаления?
Достаточно ли восстановить сайт из резервной копии?
Статью подготовили
Self-hosted проекты, безопасность и почта
Она объясняет почтовый хостинг, базовую безопасность, VPS для личных проектов и разумные границы самостоятельности.
Проверка фактов
HostScout editorial