Содержание:
После взлома недостаточно удалить найденный вредоносный файл и открыть сайт. Нужно остановить дальнейшие изменения, сохранить сведения об инциденте, определить масштаб, вернуть чистую версию и закрыть путь, которым воспользовался злоумышленник. Иначе сайт может быть заражён снова через несколько часов.
Для бизнеса важны три параллельные задачи: ограничить ущерб, сохранить доказательства и восстановить продажи или приём заявок. Порядок зависит от проекта, но хаотичная очистка почти всегда осложняет расследование.
Как понять, что сайт действительно взломан
Признаками компрометации могут быть неизвестные администраторы, редиректы на посторонние сайты, SEO-страницы и ссылки, изменения файлов без релиза, рассылка спама, предупреждение браузера, новые задания cron, подозрительные процессы или обращения платёжного сервиса.
Один сбой не всегда означает атаку. Например, ошибка 500 может быть следствием обновления, а редирект — неправильного правила. Поэтому фиксируют индикаторы компрометации и проверяют их по журналам.
| Признак | Что сохранить | Какой риск проверять |
|---|---|---|
| Неизвестный администратор | ID, время создания, журнал входов | Захват учётной записи |
| Посторонний редирект | URL, устройство, заголовки и время | Вредоносный код, реклама, подмена DNS |
| Новые PHP- или JS-файлы | Хеш, дату, владельца, копию файла | Веб-шелл или скрипт кражи данных |
| SEO-страницы и ссылки | Список URL и результаты поиска | Спам-вставка, скрытые маршруты |
| Предупреждение браузера или поисковика | Скриншот и сообщение панели вебмастера | Распространение вредоносного содержимого |
| Подозрительные платежи | Идентификаторы операций без публикации данных карт | Подмена формы или логики заказа |
Первый час: зафиксировать и локализовать
Запишите, кто и когда обнаружил проблему, какие признаки видны и какие изменения выполнялись перед этим. Сохраните журналы веб-сервера, приложения, авторизации, панели хостинга и CDN. Создайте снимок текущего состояния, даже если он заражён: он не предназначен для возврата в работу, но может понадобиться для анализа.
Далее ограничивают дальнейший ущерб. В зависимости от ситуации сайт переводят в режим обслуживания, закрывают опасную функцию, ограничивают административный доступ, останавливают подозрительный процесс или изолируют скомпрометированный узел. Для магазина особенно важно не оставлять работающую форму оплаты, если есть подозрение на подмену кода.
Не нужно немедленно удалять все подозрительные файлы и очищать журналы. Это может уничтожить время входа, путь загрузки и другие данные, необходимые для поиска первопричины.
Какие доступы менять и в какой момент
Если злоумышленник сохраняет активный доступ, реквизиты нужно отозвать быстро. Но смена паролей выполняется системно: хостинг, облако, CMS, SFTP/SSH, база, CDN, DNS, репозиторий, CI/CD, почта и внешние API. Один новый пароль в административной панели проблему не решает.
После фиксации состояния завершают активные сессии, удаляют неизвестные учётные записи, меняют секреты и включают многофакторную аутентификацию там, где она доступна. Рабочие компьютеры администраторов также проверяют: украденный локально пароль может снова открыть доступ к уже очищенному сайту.
| Контур | Что проверить | Действие после фиксации |
|---|---|---|
| CMS | Администраторов, сессии, роли | Отозвать сессии, удалить неизвестных пользователей, сменить пароли |
| Хостинг и SSH/SFTP | Входы, ключи, новые задания | Отозвать ключи и создать новые доступы |
| База данных | Пользователей и внешние подключения | Сменить секрет, ограничить сеть и права |
| DNS/CDN | Изменения записей и правил | Вернуть подтверждённые настройки, включить MFA |
| Git и CI/CD | Токены, релизы, вебхуки | Отозвать токены, проверить историю сборок |
| Внешние сервисы | API-ключи и подозрительные операции | Ротация по приоритету и журналирование |
Как определить масштаб взлома
Проверяют не только каталог сайта. Если несколько проектов размещены в одном аккаунте, заражение может переходить между ними. Анализируют системных пользователей, процессы, cron, временные директории, почтовую отправку, базы, соседние сайты и резервные копии.
Файлы сравнивают с доверенной версией в репозитории или официальным дистрибутивом. Проверяют изменения темы, модулей, загрузок, конфигурации и правил веб-сервера. Для базы ищут неизвестных пользователей, скрипты в содержимом, изменённые настройки и подозрительные задания.
В WordPress особое внимание уделяют ядру, плагинам, теме, папке загрузок, конфигурации и правилам веб-сервера. Но автоматический сканер не даёт полной гарантии: он может не увидеть новый или хорошо скрытый механизм доступа.
Восстанавливать чистую копию или очищать текущую версию
| Вариант | Когда подходит | Основной риск |
|---|---|---|
| Развернуть подтверждённо чистую копию | Есть известная дата заражения и пригодная копия | Потерять новые заявки, заказы и изменения |
| Пересобрать код из доверенных источников | Код хранится в Git, зависимости воспроизводимы | Оставить вредоносные данные или загрузки |
| Очистить текущую систему | Нет полной копии, важны актуальные данные | Пропустить бэкдор или изменённый компонент |
| Создать новую среду и перенести проверенные данные | Высокая критичность и сомнение в сервере | Больше времени на перенос и проверку |
Для коммерческого проекта часто используют комбинацию: чистая инфраструктура, код из доверенного источника, проверенная база и выборочный перенос актуальных данных. Старую среду оставляют изолированной для анализа, а не подключают обратно к посетителям.
Если резервная копия была создана после проникновения, она может содержать вредоносный код. Поэтому важна не только дата архива, но и предполагаемое начало компрометации.
Найти и закрыть точку входа
Типичные направления проверки: уязвимый компонент, украденный пароль, чрезмерные права, открытая панель, небезопасная загрузка файлов, старое ПО, скомпрометированный компьютер, секрет в репозитории или соседний сайт на общем аккаунте.
Удаление симптома без устранения причины почти гарантирует повторный инцидент. После определения вектора обновляют или заменяют компонент, закрывают лишний доступ, исправляют код, ограничивают права и настраивают контроль изменений.
Что проверить перед возвратом сайта
На чистой среде повторно сканируют файлы и базу, проверяют пользователей, задания, исходящие запросы, почту, редиректы и ключевые бизнес-функции. Для магазина проходят карточку, корзину, оплату в тестовом режиме и передачу заказа в CRM или 1С.
Проверяют HTTPS, заголовки, DNS, robots.txt, sitemap, поисковую выдачу и панели вебмастеров. Если сайт был помечен как опасный, после очистки запрашивают повторную проверку через соответствующий сервис.
Официальная инструкция WordPress рекомендует документировать признаки, проверить локальное окружение, сбросить все точки доступа, сохранить копию заражённой среды для анализа, найти вредоносные изменения и после очистки снова сменить пароли. Эти действия описаны в руководстве WordPress по восстановлению после взлома.
Нужно ли уведомлять клиентов и партнёров
Решение зависит от того, какие данные могли быть затронуты, договоров и применимых требований. Техническая команда должна определить период, затронутые системы и тип данных, а владелец — подключить юриста или ответственного за соответствие требованиям. Нельзя без проверки заявлять, что утечки точно не было.
Даже если персональные данные не затронуты, бизнесу может потребоваться уведомить сотрудников о смене доступов, платёжного провайдера о подозрительных операциях и рекламную команду о временном отключении сайта.
Как снизить риск повторного взлома
После инцидента составляют перечень обязательных изменений: обновление поддерживаемых компонентов, минимальные права, MFA, отдельные учётные записи, контроль целостности, журналирование, внешние копии, тест восстановления и мониторинг подозрительных событий.
Для небольшого сайта необязательно сразу строить сложный центр безопасности. Но должны быть назначены ответственные, срок установки критичных обновлений и понятный канал оповещения. Для магазина и B2B-портала дополнительно проверяют интеграции и действия привилегированных пользователей.
Частые вопросы
Можно ли просто удалить найденный вирусный файл?
Нет. Он может быть только одним из симптомов. Нужно определить, как файл появился, есть ли другие точки доступа и какие данные были затронуты.
Нужно ли сразу восстанавливать резервную копию?
Только после оценки даты заражения и новых данных. Копия может уже содержать вредоносный код, а откат — удалить свежие заказы и заявки.
Когда менять пароли?
После фиксации необходимых сведений — как можно быстрее, начиная с наиболее привилегированных доступов. После полной очистки секреты меняют повторно, чтобы исключить их сохранение злоумышленником.
Достаточно ли антивирусного плагина?
Нет. Он полезен как один источник сигналов, но не заменяет проверку сервера, пользователей, журналов, базы, репозитория и внешних аккаунтов.
Можно ли оставить сайт открытым во время очистки?
Если есть риск заражения посетителей, подмены формы или дальнейшей утечки, опасную функцию или весь сайт изолируют. Решение зависит от масштаба и должно ограничивать ущерб.
Как доказать, что сайт очищен?
Сравнить код с доверенным источником, проверить базу и доступы, закрыть точку входа, пройти сканирование и бизнес-сценарии, а затем наблюдать за журналами и изменениями.
Сайт взломан и требуется срочное восстановление?
German Web может зафиксировать инцидент, локализовать заражение, проверить код и базу, развернуть чистую версию и подготовить перечень защитных мер. Первичная работа ограничивается согласованным объёмом диагностики; ставка разработчика — 2 300 ₽ в час. Обратиться можно через раздел технической поддержки сайтов.
