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

Фаза 1: Экстренное реагирование и изоляция (Stop the Bleeding)

Первый и самый важный шаг — остановить распространение вредоносного ПО и предотвратить доступ хакера.

1.1. Изолируйте сайт

Немедленно отключите сайт от публичного доступа, не удаляя файлы. Это можно сделать несколькими способами:

  1. Блокировка трафика: Временно закройте порты 80/443 на уровне файрвола (если у вас VPS/dedicated) или через настройки хостинг-провайдера.
  2. Режим обслуживания: Если используете CMS (например, WordPress), активируйте плагин или настройку, показывающую заглушку только для администратора.
  3. Изоляция DNS: Перенаправьте DNS-записи на техническую страницу-заглушку, не связанную с вашим сервером.

1.2. Создайте Форензик-Копию

Прежде чем что-либо чистить, сделайте полный бэкап скомпрометированного состояния. Эта “грязная” копия необходима для дальнейшего анализа (поиска корневой уязвимости) и может быть использована для восстановления данных, если что-то пойдет не так.

  • Сохраните все файлы и базу данных в отдельное, изолированное место, не на том же сервере.

1.3. Смените Все Учетные Данные

Предполагайте, что все пароли скомпрометированы. Немедленно смените пароли для:

  • FTP/SFTP/SSH.
  • Базы данных (MySQL/PostgreSQL).
  • Административных аккаунтов CMS.
  • Аккаунта хостинг-панели (cPanel/Plesk).

Фаза 2: Искоренение и глубокая очистка (The Deep Clean)

Эта фаза нацелена на удаление вредоносного кода и устранение лазейки, через которую хакер получил доступ.

2.1. Идентификация Корневой Уязвимости (Root Cause)

Устранение уязвимости — ключ к предотвращению повторного взлома.

  1. Аудит Логирования: Проанализируйте логи веб-сервера (access.log, error.log) на предмет подозрительных запросов POST/GET, особенно с большой длиной строк или запросов к исполняемым файлам (wp-login.php, admin.php).
  2. Обнаружение Бэкдоров: Запустите Maldet (Linux Malware Detect) или ClamAV (как обсуждалось ранее) для сканирования всех публичных директорий. Ищите PHP-шеллы, обфусцированный код (eval(base64_decode), и любые исполняемые файлы в директориях загрузок.
  3. Проверка ПО: Определите, было ли взломано устаревшее ПО.

2.2. Восстановление из Чистого Бэкапа (Приоритетный метод)

Если у вас есть бэкап, сделанный до даты взлома и вы на 100% уверены в его чистоте — это самый быстрый и безопасный способ.

  1. Очистите сервер: Полностью удалите весь скомпрометированный код и базу данных с сервера.
  2. Восстановите чистую копию: Загрузите чистые файлы и базу данных.
  3. Примените последние изменения: Если были внесены важные данные после даты бэкапа, вручную перенесите их (но только чистые данные!) в восстановленную базу.

2.3. Ручная Чистка (Если нет чистого бэкапа)

Если восстановление невозможно, проведите хирургическую чистку:

  • Файлы CMS/Ядра: Замените все файлы ядра CMS (WordPress, Drupal и т.д.) на чистые, свежескачанные копии. Никогда не доверяйте коду, который был на сервере.
  • .htaccess и index.php: Это самые частые точки инъекции. Сравните эти файлы с эталонными копиями CMS и удалите все несанкционированные строки, особенно правила RewriteRule или PHP-команды header('Location: ...').
  • База данных: Проверьте таблицы пользователей (новые администраторы), настроек (измененный siteurl) и контента (скрытые <script> или <iframe> в постах).

2.4. Укрепление Системы (Hardening)

  1. Полное Обновление: Обновите CMS, темы, плагины и PHP до последних стабильных версий.
  2. Права Доступа: Установите правильные, ограничивающие права: 755 для папок и 644 для файлов. Критические файлы (например, wp-config.php) должны иметь права 400 или 440.
  3. Удаление лишнего: Удалите все неактивные, неиспользуемые плагины и темы.

Фаза 3: Верификация и восстановление (Go-Live)

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

3.1. Финальная Проверка

  • Проведите финальное сканирование Maldet.
  • Используйте Google Search Console (GSC): проверьте, нет ли скрытых ссылок (спама) или редиректов, используя инструмент “Проверить URL”. Убедитесь, что Googlebot видит чистую страницу (код 200).

3.2. Снятие Санкций Поисковых Систем

Если Google наложил ручные меры (Manual Actions):

  1. Устраните все угрозы, указанные в GSC.
  2. В разделе “Меры, принятые вручную” отправьте запрос на повторную проверку (“Request Review”), четко описав, какие шаги по очистке и укреплению были предприняты.

3.3. Возврат Онлайн и Мониторинг

  1. Снимите блокировку трафика.
  2. Наблюдайте за логами: В течение первых 48 часов внимательно следите за серверными логами и логами CMS на предмет любой необычной активности, попыток повторного входа или аномального потребления ресурсов.

Фаза 4: Пост-анализ и предотвращение (Long-Term Security)

Взлом — это не конец, а начало более строгой политики безопасности.

  1. Установка WAF: Используйте Web Application Firewall (Cloudflare, Sucuri, или ModSecurity на сервере) для фильтрации вредоносного трафика до того, как он достигнет вашего приложения.
  2. Мониторинг Целостности Файлов (FIM): Настройте FIM-систему (например, с помощью Cron, который отслеживает SHA-256 хеши ключевых файлов) для немедленного оповещения о любом несанкционированном изменении кода.
  3. Двухфакторная Аутентификация (2FA): Включите 2FA для всех административных входов в CMS и на хостинг.
  4. Постоянное Обновление: Настройте автоматическое обновление для незначительных версий CMS и регулярно вручную обновляйте крупные компоненты.

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

Похожие записи

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *