Взломали сайт: что делать в первые часы, сутки и неделю

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

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

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

Как понять, что сайт взломали

Проверьте самостоятельно:

• Есть ли предупреждение «угроза безопасности» в браузере или уведомление хостинга.
• Появились ли неизвестные администраторы, чужие ссылки, подменённые контакты или перенаправления.
• Видны ли в поиске страницы казино вместо продукции; сохраните их адреса, не открывая на рабочем компьютере подозрительные загрузки.
• Совпадает ли дата падения обращений с изменением файлов, блокировкой или простоем.

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

Шаг 1В первые часы изолируйте сайт и доступы

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

Если посетители получают вредоносный код, попросите включить безопасную статическую заглушку с временным кодом HTTP 503 — это сигнал временной недоступности. Длительная заглушка может привести к выпадению URL из индекса; её срок согласуйте с администратором. Это задача хостинга или администратора: заглушка внутри заражённой CMS может не остановить заражение. Приостановите кампании Яндекс Директа и другую рекламу на опасные страницы, предупредите отдел продаж об альтернативном приёме запросов КП.

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

Попросите ограничить административный доступ доверенными IP-адресами, если это поддерживает хостинг. Используйте отдельные сложные пароли и защищённое подключение SFTP/SSH вместо обычного FTP. Проверьте антивирусом устройства всех пользователей с доступом: злоумышленники могли похитить сохранённые пароли.

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

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

Шаг 2Сохраните копию до чистки

В панели хостинга найдите резервное копирование и журналы. Их названия и расположение зависят от провайдера: уточните путь в его справке или тикете. Закажите отдельную копию текущих файлов, базы данных, журналов веб-сервера, входов и доступных FTP/SSH-событий. Бэкап — резервная копия; не перезаписывайте старые архивы новой заражённой копией.

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

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

Типичная ошибка: нажать «Восстановить» раньше сохранения текущего состояния и потерять следы проникновения или последние заявки.

Шаг 3В первые сутки выясните причину взлома

Запустите файловую проверку аккаунта. Например, у Спринтхоста доступен «ХакСкан» в панели управления; порядок запуска сверьте в кабинете и справке хостинга. Основание срабатывания смотрите в подробностях файла; для другого хостинга используйте его инструкцию.

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

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

Для поиска причины взлома специалист сопоставляет находки с логами и изменениями. Он проверяет, могли ли злоумышленники воспользоваться уязвимостью модуля, украденным паролем, лишней учётной записью или заражённым соседним проектом. Проверяются база, шаблоны, загрузки, .htaccess, задания по расписанию и настройки сервера. Отдельно сверьте поддержку версий PHP, CMS и расширений: обновления должны закрывать выявленные уязвимости. Проверьте поддомены и другие сайты под тем же системным пользователем. Соседство само по себе не доказывает заражение.

Проверка результата: для каждой находки есть решение и основание; причина отделена от предположения. Если логов нет, точка входа может остаться неподтверждённой.

Типичная ошибка: удалить один файл, не проверив способ его появления.

Шаг 4Восстановите сайт и закройте уязвимости

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

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

Попросите заменить изменённые системные файлы официальными, проверить пользовательский код, расширения и содержимое базы. Обновляйте CMS и плагины после проверки совместимости; ненужные компоненты удаляйте после сохранения копии. Для WordPress проверьте темы и плагины; для других CMS используйте документацию установленной версии. Для 1С-Битрикс контроль целостности полезен при наличии эталона, созданного до взлома. Новый эталон заражённой установки не подтвердит её чистоту. Для Joomla старые инструкции могут не подходить.

Перед открытием повторно смените пароли всех пользователей с доступом, базы, FTP/SFTP/SSH, почты отправки; замените скомпрометированные SSH-ключи, ключи сеансов и токены интеграций. Обновите их в конфигурации и отзовите старые. Проверьте права владельцев в Вебмастере и Search Console↗. Согласуйте возврат к проверенной чистой сборке, сохранив новые обращения отдельно.

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

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

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

Шаг 5Проверьте поисковые метки и чужие страницы

Откройте нужный сайт в Яндекс Вебмастере↗. По действующей справке путь — «Оптимизация сайта → Безопасность и нарушения»; название раздела сверьте в кабинете. Раскройте нарушение и сохраните примеры. После исправления опишите изменения, отметьте «Нарушение исправлено» и нажмите «Отправить на проверку» с подтверждением. Обычное скрытие уведомления не снимает ограничение.

В Google Search Console откройте группу «Проблемы безопасности и меры, принятые вручную». Проверьте оба отчёта отдельно. В «Проблемах безопасности» изучите типы угроз и примеры URL; после полного устранения запросите проверку. Если есть мера, принятая вручную, устраните указанное нарушение и запросите проверку в этом отчёте. Если мер нет, отправлять запрос на их снятие не нужно.

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

После открытия чистого сайта проверьте скрытую выдачу: в Search Console вставьте подозрительный URL в верхнюю строку проверки → «Проверить опубликованную страницу» → просмотр проверенной страницы. Сопоставьте HTML и скриншот с обычным просмотром. Инструмент проверки URL показывает текущую проверку отдельно от индексированной версии; его робот Google-InspectionTool не полностью равнозначен Googlebot.

В Вебмастере откройте «Инструменты → Проверка ответа сервера», впишите URL, выберите доступный тип робота и запустите проверку; изучите содержимое ответа. Яндекс предупреждает: ответ инструменту может отличаться от ответа реальному роботу. Одна подмена User-Agent не исключает скрытой подмены. Попросите специалиста сопоставить логи обращений настоящих поисковых роботов с содержимым, которое им выдаётся.

Для легальных URL с обновлённым содержимым при необходимости запросите переобход в Яндекс Вебмастере и индексирование в Search Console. Эти действия не заменяют проверку безопасности и не гарантируют включение в поиск. Если нарушений в отчётах нет, запрос на их снятие не требуется.

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

Типичная ошибка: проверить только главную и сразу отправить сайт на пересмотр.

Шаг 6В первую неделю примите работу и настройте наблюдение

При приёмке используйте порядок проверки безопасности сайта. После снятия изоляции пройдите путь покупателя с компьютера и телефона:

• Откройте карточку промышленного продукта, документы и контакты.
• Отправьте помеченную тестовую заявку на расчёт и запрос КП; проверьте письмо и запись в CRM, получателя и переданную модель оборудования.
• Проверьте номер телефона и фактический дозвон; клик по номеру сам по себе не подтверждает звонок.
• Убедитесь, что цель отправки в Яндекс Метрике фиксируется после успешной заявки.

Для защиты от повторного взлома согласуйте обновления CMS и расширений, сканирование, уведомления и резервное копирование вне рабочего аккаунта. Назначьте ответственных и проверьте восстановление из бэкапа.

Удалите неиспользуемые доступы и отделите другие проекты в самостоятельные аккаунты, если это возможно. Планируйте наблюдение за целевыми запросами и страницами на 2–4 недели, продолжая его при нерешённых проблемах. Это контрольный период, не обещание возврата позиций. Сравнивайте показы, клики, доступность и обращения; при новом предупреждении вернитесь к изоляции и разбору причины взлома.

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

Типичная ошибка: принять работу по фразе «вирусов нет», не проверив формы и повторное появление файлов.

Что делать, если казино убрали, а Google просел: типовой случай

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

Проверьте варианты: спам остался в базе или выдаётся только роботам; старые URL ещё находятся в индексе; действует мера вручную; при откате появились запрет индексирования, ошибки сервера или неверно задан основной адрес страницы (canonical). Просадка сама по себе не доказывает санкцию.

Соберите список чужих URL из отчётов и поиска по своему домену. Удалённые спам-адреса должны возвращать настоящий 404 или 410, а не пустую страницу с кодом 200 и не массовый редирект на главную. Не закрывайте удалённые адреса в robots.txt: робот должен увидеть код удаления. Уберите их из Sitemap и внутренних ссылок. Страницу контактов, если она нужна покупателям, сохраните по прежнему адресу с правильными данными и кодом 200.

Проверьте контакты и коммерческие страницы инструментами шага 5, затем статусы обхода и индексирования. Возвращение нормального HTML и обновление поискового индекса — разные события.

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

Итог

Если после восстановления нужно проверить, как сайт снова принимает обращения из поиска и рекламы, рассмотрите аудит интернет-маркетинга: он помогает разобрать сайт, SEO, аналитику и путь заявки и определить приоритеты доработок.

Получить аудит

Ссылки со значком ↗ ведут на сторонние сайты и открываются в новой вкладке.