Сайт помечен как опасный в браузере: как снять метку

MAATRIX

Посетитель открывает ваш сайт и вместо страницы видит красный экран на весь браузер: «Обманный сайт впереди» или «Этот сайт пытается заразить ваше устройство». Трафик обрушивается за час, письма от клиентов и партнёров сыплются с вопросом «у вас всё в порядке?», а паника подсказывает сразу бежать разбираться с браузером. Разбираться нужно, но не с браузером — сначала с сайтом: метка почти всегда следствие, а не причина, и снять её без устранения причины либо вообще не получится, либо она вернётся через день-два.

Что вообще произошло и откуда взялась метка

Крупные браузеры не придумывают репутацию сайтов сами — они берут данные из общих баз репутации веб-ресурсов, которые ведут несколько независимых систем:

• Google Safe Browsing — база, которую использует Chrome, а также (через API) Firefox и многие другие браузеры и почтовые клиенты. Проверить статус конкретного домена можно на странице transparencyreport.google.com/safe-browsing/search.
• Microsoft SmartScreen — своя база для Edge и частично для Outlook/Bing, независимая от Google.
• Яндекс.Безопасный поиск — используется в Яндекс.Браузере и учитывается при индексации в Яндекс.Поиске, статус виден в Яндекс.Вебмастере во вкладке «Безопасность и нарушения».
• Ряд более узких списков (антивирусные вендоры, репутационные сервисы почтовых провайдеров) — их предупреждения обычно менее заметны для обычного посетителя, но тоже бьют по доверию к домену.

Важно понимать: у каждой системы своя база и свой краулер, который переобходит сайты с разной периодичностью. Домен может быть помечен в Google Safe Browsing и при этом чист в SmartScreen, или наоборот — и снимать метку придётся отдельно в каждой системе, где она появилась.

Причин попадания в список практически всегда две:

1. Реальная компрометация. На сайте (или на сервере рядом с ним) размещён вредоносный код: инъекция JS, ведущая на сторонний вредоносный ресурс, фишинговая страница-клон банка или почтового сервиса, скрытый редирект на скачивание вредоносного файла, веб-шелл, через который заливают что угодно. Краулер репутационной системы находит это при очередном обходе и помечает домен.
2. Ложное срабатывание. Реже, но случается: сайт использует легитимный, но подозрительно выглядящий JS (обфусцированный код трекера, старая версия рекламного скрипта с плохой репутацией у конкретного вендора), поддомен на общем хостинге раньше принадлежал кому-то скомпрометированному и репутация не до конца очистилась, либо краулер ошибочно классифицировал контент (бывает с сайтами про безопасность, где в примерах кода буквально встречаются сигнатуры малвари).

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

Как отличить реальный взлом от ложного срабатывания

Не гадайте — проверьте по фактам, это займёт 10-15 минут и сразу задаст правильное направление.

Шаг 1. Прочитайте детали предупреждения. В Chrome под красным экраном обычно есть ссылка «Подробности» или «See more details», которая ведёт на страницу Safe Browsing с указанием, что именно найдено: конкретные URL на сайте, тип угрозы (malware / social engineering — то есть фишинг / unwanted software), дата последнего обнаружения. Это самая ценная информация на старте — она сразу говорит, где искать.

Шаг 2. Подключите панель для владельца сайта. Если у вас ещё не подключены официальные инструменты для веб-мастеров — сделайте это в первую очередь, до всех остальных действий:

• Google Search Console (search.google.com/search-console) — раздел «Проблемы безопасности» покажет список заражённых URL и тип угрозы куда подробнее, чем публичная страница проверки.
• Яндекс.Вебмастер (webmaster.yandex.ru) — вкладка «Безопасность и нарушения» покажет аналогичную информацию для Яндекса.
• Bing Webmaster Tools — для статуса в экосистеме Microsoft/SmartScreen.

Подключение требует подтверждения владения доменом (DNS TXT-запись, файл на сервере или мета-тег) — если панелей ещё нет, разумно подключить их заранее, а не в момент паники.

Шаг 3. Сверьте список заражённых URL с логами сервера. Если Search Console показывает конкретные адреса вида /wp-content/uploads/2026/08/xyz.php или /wp-includes/random-name.php — это почти наверняка реальный взлом: такие пути не появляются от ложных срабатываний. Проверьте:

# когда файл появился и кто его создал (владелец процесса = обычно www-data)
stat /var/www/site/wp-content/uploads/2026/08/xyz.php

# что реально в файле
cat /var/www/site/wp-content/uploads/2026/08/xyz.php | head -50

Если файл содержит eval(base64_decode(...)), assert($_POST[...]), system($_GET[...]) или похожие конструкции — это веб-шелл, сомнений в реальной компрометации быть не должно. Похожая история подробно разобрана в статье про веб-шелл, найденный в папке загрузок, через который сервер рассылал фишинг — стоит свериться с чек-листом оттуда.

Если же заражённые URL в панели не указаны, а найденный "подозрительный" код — это ваш собственный, читаемый, объяснимый скрипт (например, легитимный, но старый виджет с внешнего CDN, который сам был скомпрометирован на стороне вендора) — вероятность ложного срабатывания или "заражения через третью сторону" выше, и стоит проверить именно внешние подключаемые ресурсы (<script src="..."> на чужих доменах).

Ищем и удаляем вредоносный контент

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

Порядок работы:

1. Снимите снапшот / бэкап текущего состояния до чистки — он понадобится для анализа, что именно было изменено, и как доказательство при необходимости.
2. Найдите все недавно изменённые файлы — вход обычно свежий:

# файлы, изменённые за последние N дней (подставьте примерную дату инцидента)
find /var/www/site -type f -mtime -14 -printf '%T+ %p\n' | sort

# php-файлы вне обычных директорий с кодом (частое место для веб-шеллов)
find /var/www/site/wp-content/uploads -name "*.php"
find /var/www/site -type f -name "*.php" -newer /var/www/site/wp-config.php

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

# ClamAV с актуальными базами
freshclam
clamscan -r --bell -i /var/www/site

# rkhunter — проверка руткитов и подозрительных бинарников
rkhunter --check

# Linux Malware Detect (maldet), если установлен — заточен именно под веб-шеллы
maldet -a /var/www/site

1. Проверьте типовые точки внедрения отдельно от общего сканирования:

• .htaccess — частое место для условных редиректов ("покажи чистую страницу гуглоботу, а обычному посетителю — редирект на фишинг"). Ищите директивы RewriteCond %{HTTP_USER_AGENT} с нетипичной логикой.
• wp-config.php и аналогичные конфиги CMS — на добавленный код в самом начале или конце файла.
• crontab -l и /etc/cron.d/ — на подозрительные задания, которые перезаписывают файлы обратно после чистки (частая причина, почему "мы же удалили, а оно снова появилось").
• Таблицы БД для CMS типа WordPress/Joomla — вредоносный JS иногда хранится в контенте страниц или виджетах, а не в файлах.
• Пользователи и SSH-ключи — cat /etc/passwd, ls -la ~/.ssh/authorized_keys на всех аккаунтах с доступом к серверу.

1. Удалите найденное и сравните с чистым бэкапом, если он есть от даты до заражения — это надёжнее построчной чистки, особенно для файлов ядра CMS, которые проще перезалить из официального дистрибутива, чем вычищать построчно.

Если сайт на WordPress — типовые сценарии компрометации (уязвимый плагин, подобранный пароль админки, устаревшее ядро) и конкретные команды разобраны в статье взломали сайт на WordPress: причины и решение. Общий порядок действий при взломе сервера целиком, если под удар попал не только один сайт — в статье взломали сервер: пошаговый план.

Закрываем вход, которым воспользовался злоумышленник

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

Проверьте по порядку, от самого вероятного к менее вероятному:

• Уязвимый плагин или тема CMS. Смотрите changelog установленных плагинов на предмет security-фиксов в версиях новее вашей — если между вашей версией и текущей был патч безопасности, это первый кандидат. Обновите всё до актуальных версий, даже то, что кажется не связанным с инцидентом.
• Слабый или скомпрометированный пароль админки. Проверьте лог попыток входа (для WordPress — плагины логирования, либо access-лог nginx/apache на POST-запросы к /wp-login.php с большим количеством попыток подряд). Смените все пароли администраторов и API-ключи/токены интеграций — не только тот, что "подозрительный".
• Устаревшее ядро CMS или зависимости. Версии CMS старше пары релизов от актуальной на конец августа 2026 года — частая причина, особенно если автообновления безопасности были отключены.
• Открытый порт или сервис без нужды. Проверьте ss -tulnp на предмет сервисов, слушающих на всех интерфейсах без необходимости, и правила firewall — не открыт ли админ-доступ (phpMyAdmin, панель CMS, SSH) наружу без ограничения по IP.
• Скомпрометированный сосед на общем хостинге. Если сайт на shared-хостинге или в контейнере рядом с другими проектами того же владельца — проверьте, не был ли вход через другой, менее защищённый сайт на том же аккаунте.

Только после того, как вход закрыт и вы можете объяснить себе (не браузеру, а именно себе) конкретный механизм, как малварь попала на сайт — переходите к запросу на пересмотр. Заявка "почистили, но не знаем как попало" почти гарантированно означает повторную блокировку в течение недель.

Подаём запрос на пересмотр через официальные инструменты

Каждая система репутации предоставляет собственный механизм запроса на пересмотр (review request) — это не единая точка входа, а отдельная процедура в каждой панели.

Google Safe Browsing / Search Console. В разделе «Проблемы безопасности» после устранения проблем появляется кнопка запроса на проверку. Система просит коротко описать, что было не так и что исправлено — отвечайте конкретно (тип угрозы, что нашли, что сделали): у истории сайта есть значение, и расплывчатое «всё почистили» без деталей чаще приводит к повторному запросу.

Яндекс.Вебмастер. Во вкладке «Безопасность и нарушения» после устранения появляется аналогичная кнопка запроса на снятие статуса.

Microsoft SmartScreen. Для Edge/SmartScreen предусмотрена отдельная форма отправки сайта на пересмотр через панель для веб-мастеров Microsoft — процедура структурно похожа, но полностью независима от Google, статус нужно проверять и снимать отдельно.

Общие правила для любой из систем:

• Подавайте заявку только после полной чистки. Один неучтённый заражённый файл — и заявку отклонят, а следующая попытка может рассматриваться дольше первой.
• Не подавайте заявку повторно раньше срока, указанного системой (обычно есть минимальный интервал между запросами) — спам заявками не ускоряет рассмотрение.
• Сохраните доказательства чистки — список удалённых файлов, дату патча уязвимости, смену паролей. Некоторые формы прямо просят это описать, и наличие конкретики повышает шанс на положительное решение с первого раза.
• Если у вас несколько поддоменов, часть заявки может касаться только конкретного заражённого поддомена/пути — уточните в форме, если инструмент это позволяет, чтобы не размазывать статус на весь домен без необходимости.

Сколько занимает пересмотр и как проверять статус

Точных гарантированных сроков ни одна из систем не публикует — это стоит сразу проговорить с клиентами или руководством, если вы отвечаете за сайт не только перед собой. По опыту владельцев сайтов, пересмотр в Google Safe Browsing при явно устранённой проблеме обычно занимает от нескольких часов до нескольких дней, но может растянуться и дольше — это ориентир, а не обещание. У Яндекс.Вебмастера и SmartScreen сроки того же порядка, но не идентичны — снятие статуса в одной системе не снимает его в другой.

Пока заявка на рассмотрении, статус можно проверять вручную, не дожидаясь письма-уведомления:

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

Если репутация пострадала не только на уровне браузера, но и на уровне почтового домена или IP (письма с того же сервера начали биться в спам или bounce) — это отдельный процесс с другими сроками и инструментами, он разобран в статье IP попал в чёрные списки: восстановление репутации по шагам. Не путайте эти две ситуации: чистая репутация в Safe Browsing не гарантирует чистую репутацию у почтовых DNSBL, и наоборот.

Частые вопросы