Сайт взломали: что делать в первые 24 часа

Какие изменения указывают на взлом сайта?

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

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

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

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

Первый час: ограничьте ущерб, не уничтожая доказательства

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

0-15 минут: зафиксируйте ситуацию и локализуйте атаку

1. Зафиксируйте обнаружение проблемы. Запишите, кто сообщил о ней, когда она появилась и какие URL были затронуты. Сделайте снимки экрана и используйте единый часовой пояс.
2. Защитите посетителей. Показывайте статическую страницу технических работ с кодом состояния HTTP 503 через доверенный прокси-сервер или из отдельной среды. Убедитесь, что заражённые страницы недоступны напрямую.
3. Свяжитесь с хостинг-провайдером. Попросите помочь локализовать атаку, предоставить доступные журналы событий, снимки системы и любые данные о точке входа.
4. Изолируйте пострадавшую систему. Заблокируйте ненужные сетевые подключения, сохранив контролируемый доступ для расследования. Не перезагружайте и не переустанавливайте систему, пока не соберёте доказательства.

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

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

15-60 минут: ограничьте доступ и сохраните журналы событий

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

• Экспортируйте журналы веб-сервера, приложения, базы данных, SSH/FTP и панели управления хостингом.
• Сохраните доступные журналы CDN, межсетевого экрана и аутентификации до истечения срока их хранения.
• Сделайте снимок пострадавших файлов и базы данных. Пометьте его как доказательство взлома, а не резервную копию для восстановления.
• Ограничьте доступ к панели администратора, заблокируйте неизвестные учётные записи и временно отключите ненужный доступ подрядчиков.
• Сообщите сотрудникам поддержки, куда отправлять обращения клиентов и снимки экрана.

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

1-4 часа: выясните, к чему мог получить доступ злоумышленник

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

• Аутентификация: сопоставьте неудачные и успешные входы, создание сеансов, появление новых пользователей и изменения прав.
• Действия в системе: изучите историю команд с повышенными правами, незнакомые SSH-ключи и задания планировщика, например cron.
• Изменения приложения: проверьте недавно загруженные файлы, исполняемые файлы в папках загрузок и изменённый код приложения.
• Связанные среды: проверьте тестовые сайты, общие базы данных, системы развёртывания и другие сайты в той же учётной записи хостинга.
• Действия злоумышленника: ищите публикации спама, фишинговые страницы, выгрузки данных или исходящие атаки.

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

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

4-12 часов: закройте точку входа и подготовьте чистую среду

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

Поиск первопричины

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

• Устаревшие компоненты CMS, плагины или серверное ПО.
• Слабые пароли или украденные учётные данные.
• Уязвимый собственный код или небезопасная загрузка файлов.
• Доступные извне инструменты администрирования с недостаточным контролем доступа.
• Скомпрометированные учётные записи подрядчиков или систем развёртывания.

Сопоставьте свои находки с данными хостинг-провайдера. Если приложение работает на PHP, наш разбор критических уязвимостей PHP октября 2026 года поможет проверить, уязвима ли среда выполнения. Опубликованная уязвимость - повод для проверки, а не доказательство того, как произошёл этот инцидент.

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

Удаление вредоносного ПО с сайта или развёртывание с нуля?

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

Базовые рекомендации Google для взломанных сайтов описывают переустановку из доверенных источников и проверку резервных копий перед восстановлением. Статья опубликована в 2008 году, поэтому её принципы восстановления следует отделять от устаревших названий инструментов.

На управляемом или виртуальном хостинге договоритесь с провайдером о новой среде, а не пытайтесь самостоятельно переустановить операционную систему. Направление DevOps и инфраструктура Webdelo охватывает инфраструктурные работы, которые могут понадобиться при таком восстановлении.

Как восстановить взломанный сайт из резервной копии

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

1. Восстановите выбранную резервную копию в изолированной среде с отключёнными исходящими интеграциями.
2. Сравните файлы приложения с доверенными выпусками или проверенным репозиторием исходного кода.
3. Проверьте базу данных на неизвестных администраторов, внедрённые скрипты и изменённые настройки.
4. Проверьте загруженные файлы и просканируйте их на вредоносное содержимое.
5. Установите обновления безопасности и закройте выявленную точку входа до начала тестирования.

В проверенной старой копии может не быть реальных недавних заказов или заявок. Восстановите эти записи отдельно после сверки, а не импортируйте всю скомпрометированную базу данных без проверки.

Смените секреты из доверенной среды

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

• Смените учётные данные администраторов, хостинга, электронной почты и систем развёртывания.
• Смените пароли баз данных, SSH-ключи и ключи API.
• Замените токены платёжных систем, CRM и других интеграций.
• Завершите активные сеансы и проверьте способы восстановления доступа.
• Включите многофакторную аутентификацию, или MFA, для административного доступа.

Проверьте адреса электронной почты сотрудников по известным базам утечек с помощью сервиса вроде Have I Been Pwned. Никогда не отправляйте действующие пароли или закрытые ключи в незнакомый сервис проверки.

12-24 часа: проверьте бизнес-функции и решите, можно ли возобновить работу

Для возобновления работы нужны подтверждения, что точка входа закрыта, развёрнутая система чиста, а бизнес-функции работают правильно. Смена учётных данных и активный мониторинг также обязательны для запуска. Если проверки не пройдены, продлите изоляцию, а не считайте 24-й час крайним сроком.

Проверка форм, CRM и платежей

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

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

Предупреждения в поиске и спам-URL

Проверьте отчёты "Проблемы безопасности" и "Меры, принятые вручную" в Google Search Console. Удалите созданный злоумышленником контент в самом источнике. Настройте для удалённых спам-URL подходящий код ответа 404 или 410.

Если нужно временно скрыть страницы из поиска, используйте инструмент "Удаления". Он не удаляет контент с сервера и не устраняет проблему безопасности. После исправления запросите соответствующую проверку. Учтите, что снятие предупреждений и восстановление видимости в поиске займут время.

Назначьте ответственных и критерии завершения

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

Проверьте, получил ли злоумышленник доступ к данным клиентов и не стали ли они общедоступными

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

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

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

Пересмотрите права доступа поставщиков услуг и подтвердите заявленные исправления тестами или журналами событий. Наше руководство по защите клиентской базы при работе с IT-подрядчиком рассматривает границы доступа, важные для этой проверки.

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

Избегайте действий, которые скрывают причину или сохраняют доступ злоумышленника

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

• Немедленное удаление подозрительных файлов: сохраняйте доказательства до внесения изменений.
• Доверие одному сканеру или плагину: дополняйте сканирование проверкой доступа, настроек и кода.
• Автоматическое восстановление последней резервной копии: сначала проверьте её содержимое и время создания.
• Смена паролей на скомпрометированном устройстве: используйте доверенную рабочую станцию и чистую целевую среду.
• Забытые учётные записи интеграций: учитывайте подрядчиков, API, инструменты развёртывания и активные сеансы.
• Остановка мониторинга после запуска: продолжайте отслеживать исходную точку входа и признаки повторного доступа.

Оценивайте затраты на восстановление и сбои в работе бизнеса отдельно

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

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

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

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

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

Чтобы предотвратить повторный взлом, устраните то, что сделало его возможным

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

Почему сайты взламывают снова после восстановления

Восстановление резервной копии и смена одного пароля администратора не закрывают другие пути доступа. Уязвимый плагин или украденный ключ развёртывания всё ещё могут позволить проникнуть в систему.

Мы предпочитаем устранять причину до открытия сайта для посетителей. Для этого используем доверенный код приложения и проверенные данные, полностью меняем учётные данные и ограничиваем доступ. Затем мониторинг помогает проверить, работают ли эти меры.

Проверьте меры защиты с помощью аудита безопасности сайта

Аудит безопасности сайта должен подтверждать, что меры защиты работают, включая восстановление из резервных копий и доставку оповещений. Рекомендации Cloudflare по восстановлению включают обновление ПО, защиту административного доступа, резервное копирование и управляемые правила межсетевого экрана веб-приложений. Межсетевой экран веб-приложений, или WAF, фильтрует подозрительные веб-запросы, но не заменяет исправление приложения.

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

Как Webdelo оценивает инцидент и планирует восстановление

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

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

Оценка охватывает:

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

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

Возобновляйте работу только после подтверждения готовности

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

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