План действий при взломе или падении сервера: восстановление из бэкапа
Дата публикации: 24.04.2026

План действий при взломе или падении сервера: восстановление из бэкапа

ccb9a536

План действий при взломе или падении сервера: восстановление из бэкапа

Представьте: вы просыпаетесь утром, пьёте кофе, открываете сайт — и вместо привычной главной страницы видите белое полотно с надписью "Hacked by..." или ошибку 500 Internal Server Error. Сердце уходит в пятки, руки дрожат, а в голове одна мысль: "Что делать?!"

Этот урок — ваш спасательный круг. Здесь нет паники, только чёткий алгоритм: как быстро восстановить сервер из бэкапа, минимизировать ущерб и вернуть всё в рабочее состояние. Вы узнаете: ✅ Как определить, что сервер действительно взломан (а не просто упал) ✅ Пошаговый план восстановления — от изоляции до финальной проверки ✅ Какие инструменты использовать, чтобы ускорить процесс ✅ Как избежать повторного взлома после восстановления

1. Диагностика: взлом или технический сбой?

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

Признаки взлома (красные флаги 🚩)

Симптом Что это значит Действие
Неизвестные файлы в корне сайта (например, hacked.php, shell.php) Злоумышленник загрузил бэкдор для удалённого управления. Удалить, но не сразу — сначала скопируйте для анализа.
Изменённые файлы (например, index.php с подозрительным кодом в начале) В код внедрён вредоносный скрипт (часто для редиректов или майнинга). Сравнить с оригинальной версией.
Новые пользователи в базе данных или на сервере (/etc/passwd) Атакующий создал аккаунт для постоянного доступа. Удалить, заблокировать.
Подозрительные процессы в top или htop (например, ./xmrig, ./ldd) Сервер используется для майнинга криптовалюты или DDoS-атак. Убить процесс (kill -9 PID).
Необычный трафик в логах (/var/log/auth.log, /var/log/nginx/access.log) Брутфорс паролей, сканирование уязвимостей. Анализировать логи.
Редиректы на сторонние сайты (например, на фишинг или порно) Код сайта изменён для перенаправления посетителей. Проверять .htaccess, JS-файлы.

Признаки технического сбоя (не взлом)

  • 502 Bad Gateway — проблема с прокси (Nginx, Cloudflare).
  • 504 Gateway Timeout — сервер не успевает ответить (перегрузка, медленный PHP).
  • Ошибки базы данных (SQLSTATE[HY000] [2002] Connection refused) — MySQL не запущен.
  • Диск заполнен (df -h показывает 100% использования) — логи раздулись или бэкапы не очищаются.

→ Если это сбой, а не взлом — перезагрузите сервис (systemctl restart nginx mysql), освободите место, проверьте логи. Если проблема повторяется, ищите корень (например, неоптимизированные запросы в базе).

→ Если это взлом — переходите к следующему шагу.

2. Немедленные действия: изоляция и фиксация доказательств

Шаг 1. Отключите сервер от сети (если возможно)

  • Для VPS/выделенного сервера:

    sudo ifconfig eth0 down  # Отключает сетевой интерфейс

    Или через панель хостинга (например, Hetzner Cloud, DigitalOcean) — просто выключите сервер.

  • Для shared-хостинга: Обратитесь в поддержку с просьбой приостановить сайт до восстановления.

Почему это важно? Атакующий может продолжать загружать вредоносные файлы или использовать ваш сервер для атак на другие сайты. Изоляция останавливает утечку данных и распространение заразы.

Шаг 2. Сделайте снимок (snapshot) диска

Перед любыми изменениями сохраните текущее состояние сервера:

  • В VirtualBox/VMware — сделайте снимок виртуальной машины.
  • В облачных сервисах (AWS, Google Cloud) — создайте snapshot диска.
  • На физическом сервере — склонируйте диск с помощью dd: 
    sudo dd if=/dev/sda of=/backup/sda_backup.img bs=4M

Это ваша "страховка" на случай, если что-то пойдёт не так при восстановлении.

Шаг 3. Соберите доказательства для анализа

Скопируйте ключевые файлы и логи в отдельную папку:

mkdir ~/incident_evidence
cp -r /var/log ~/incident_evidence/logs
cp /etc/passwd /etc/shadow ~/incident_evidence/
find / -name "*.php" -mtime -1 -exec cp {} ~/incident_evidence/new_files \;

Зачем? Позже вы сможете проанализировать, как произошёл взлом (через уязвимость в CMS, слабый пароль, открытый порт) и закрыть дыру.

3. Восстановление из бэкапа: пошаговая инструкция

Шаг 1. Выберите чистый бэкап

  • Идеальный вариант: бэкап до даты взлома (проверьте метки времени).
  • Если бэкапов нет — придётся восстанавливать вручную (об этом ниже).
Где искать бэкапы? Источник Где лежит Как восстановить
Автоматические бэкапы хостинга Панель управления (cPanel, Plesk) Нажмите "Restore" рядом с нужной датой.
Ручные бэкапы /backup/, внешний HDD, облако (S3, Google Drive) Скопируйте файлы обратно.
Бэкапы базы данных .sql-дампы в /var/backups/mysql/ Импортируйте через mysql -u user -p db_name < backup.sql
Снимки (snapshots) VPS Панель облачного провайдера Восстановите сервер из снимка.

⚠️ Внимание! Если бэкап сделан после взлома, он может содержать вредоносный код. Проверьте его антивирусом (clamav) или вручную.

Шаг 2. Восстановление файлов сайта

  1. Удалите все файлы в корневой директории сайта (например, /var/www/html/): 
    sudo rm -rf /var/www/html/*
  2. Распакуйте чистый бэкап: 
    sudo tar -xzvf /backup/clean_backup.tar.gz -C /var/www/html/
  3. Проверьте права доступа: 
    sudo chown -R www-data:www-data /var/www/html/
sudo chmod -R 755 /var/www/html/

Шаг 3. Восстановление базы данных

  1. Удалите текущую базу (если она заражена): 
    mysql -u root -p -e "DROP DATABASE my_site_db;"
  2. Создайте новую и импортируйте бэкап: 
    mysql -u root -p -e "CREATE DATABASE my_site_db;"
mysql -u root -p my_site_db < /backup/my_site_db.sql
  3. Обновите пароли пользователей БД (на случай, если они скомпрометированы): 
    ALTER USER 'db_user'@'localhost' IDENTIFIED BY 'новый_сложный_пароль';

Шаг 4. Проверка конфигурационных файлов

Вредоносный код может прятаться в:

  • .htaccess (редиректы)
  • wp-config.php (для WordPress)
  • config.php (для других CMS)

Откройте их и проверьте на подозрительные строки, например:

eval(base64_decode("DQplcnJvcl9yZXBvcnRpbmc..."));

или

RewriteRule ^(.*)$ http://hacker-site.com [R=301,L]

→ Удалите всё подозрительное.

Шаг 5. Обновление системы и софта

После восстановления обновите всё до последних версий:

sudo apt update && sudo apt upgrade -y  # Для Debian/Ubuntu
sudo yum update -y                     # Для CentOS

Особое внимание:

  • CMS (WordPress, Joomla — обновите ядро и плагины).
  • PHP (актуальная версия закрывает уязвимости).
  • Nginx/Apache (проверьте конфиги на изменения).

4. Защита после восстановления: как предотвратить повторный взлом

Шаг 1. Смените все пароли

  • Пароль root и пользователей сервера: 
    passwd root
passwd ваш_пользователь
  • Пароли базы данных (см. шаг 3.3).
  • Пароли FTP/SSH/Panel (cPanel, Plesk).
  • Ключи API (если используете Cloudflare, payment gateways).

⚠️ Правила для паролей:

  • Минимум 12 символов.
  • Без словарных слов (используйте генератор, например, Bitwarden).
  • Разные пароли для каждого сервиса.

Шаг 2. Настройте брандмауэр (firewall)

Ограничьте доступ к портам:

sudo ufw allow 22/tcp   # SSH (меняйте порт!)
sudo ufw allow 80/tcp   # HTTP
sudo ufw allow 443/tcp  # HTTPS
sudo ufw deny all       # Заблокировать всё остальное
sudo ufw enable

Дополнительно:

  • Fail2Ban — блокирует IP после нескольких неудачных попыток входа: 
    sudo apt install fail2ban
sudo systemctl enable fail2ban

Шаг 3. Отключите ненужные службы

Проверьте, какие сервисы запущены:

sudo netstat -tulnp

Удалите или отключите лишнее:

sudo systemctl stop apache2   # Если используете Nginx
sudo systemctl disable apache2

Шаг 4. Настройте мониторинг

  • Logwatch — анализирует логи на подозрительную активность: 
    sudo apt install logwatch
sudo logwatch --output mail --mailto admin@example.com --detail high
  • AIDE — проверяет изменения в системных файлах: 
    sudo apt install aide
sudo aideinit
sudo aide --check

Шаг 5. Автоматические бэкапы

Настройте ежедневные бэкапы с отправкой на внешний сервер:

sudo tar -czvf /backup/site_$(date +%Y-%m-%d).tar.gz /var/www/html/
sudo scp /backup/site_*.tar.gz user@backup-server:/backups/

Или используйте готовые решения:

  • Duplicati (с открытым исходным кодом).
  • BorgBackup (инкрементальные бэкапы).
  • Плагины для CMS (UpdraftPlus для WordPress).

5. Если бэкапа нет: восстановление вручную

Ситуация: бэкапов нет, или они тоже заражены. Что делать?

Шаг 1. Установите чистую CMS

Скачайте последнюю версию вашей CMS (WordPress, OpenCart etc.) и установите её в новую папку:

wget https://wordpress.org/latest.tar.gz
tar -xzvf latest.tar.gz -C /var/www/html_new/

Шаг 2. Перенесите контент

  • Медиафайлы (/wp-content/uploads/) — скопируйте из старой папки (предварительно проверьте на вирусы).
  • Тема и плагины — скачайте чистые версии с официальных источников.
  • База данных — экспортируйте таблицы с контентом (wp_posts, wp_options), но не пользователей (они могли быть скомпрометированы).

Шаг 3. Восстановите критические настройки

  • .htaccess — возьмите стандартный из новой установки.
  • wp-config.php — скопируйте только уникальные настройки (например, ключи безопасности).

Шаг 4. Проверьте сайт на уязвимости

Используйте сканеры:

  • WPScan (для WordPress): 
    wpscan --url ваш-сайт.ru
  • Nikto (для поиска уязвимостей сервера): 
    nikto -h ваш-сайт.ru

Практика для закрепления

Упражнение 1. Анализ логов

📌 Задание: Перед вами фрагмент лога /var/log/auth.log:

Jun 10 03:45:22 server sshd[12345]: Failed password for root from 192.168.1.100 port 44332 ssh2
Jun 10 03:45:25 server sshd[12347]: Failed password for root from 192.168.1.100 port 44335 ssh2
Jun 10 03:45:28 server sshd[12349]: Failed password for admin from 192.168.1.100 port 44338 ssh2

Вопросы:

  1. Что происходит в этом логе?
  2. Какую меру защиты вы примените прямо сейчас?

Упражнение 2. Восстановление базы данных

📌 Задание: У вас есть бэкап базы my_site_db.sql, но при импорте возникает ошибка:

ERROR 1044 (42000): Access denied for user 'root'@'localhost' to database 'my_site_db'

Вопросы:

  1. В чём проблема?
  2. Какую команду вы выполните для решения?

Упражнение 3. Поиск вредоносного кода

📌 Задание: В файле index.php вашего сайта появилась строка:

<?php @error_reporting(0); if (!isset($GLOBALS['x'])) { $GLOBALS['x'] = "..."; } ?>

Вопросы:

  1. Что это за код?
  2. Как его безопасно удалить?

Упражнение 4. Настройка бэкапов

📌 Задание: Напишите cron-задачу, которая будет:

  1. Архивировать папку /var/www/html/ каждый день в 3:00.
  2. Удалять бэкапы старше 7 дней.
  3. Отправлять архив на удалённый сервер backup@example.com по SFTP.

Упражнение 5. Аварийный план

📌 Задание: Составьте личный чек-лист из 10 пунктов: "Что делать, если сервер взломан?" (на основе этого урока). Распечатайте и держите под рукой.

Заключение: ваш антикризисный план

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

Краткая памятка:

  1. Изолируйте сервер (отключите сеть).
  2. Сделайте снимок диска (для анализа).
  3. Восстановите из чистого бэкапа (файлы + база).
  4. Обновите всё (CMS, PHP, ОС).
  5. Закройте дыры (пароли, firewall, мониторинг).

⚠️ Важно:

  • Тестируйте бэкапы (убедитесь, что они работают).
  • Автоматизируйте защиту (Fail2Ban, AIDE).
  • Следите за новостями о новых уязвимостях (например, CVE Details).

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


Генератор паролей с длинной 64 символа
Женская одежда с бахромой
Кадастровые работы в Бийске
Как Aptum хостинг помогает малым бизнесам в управлении CRM-системами
Как выбрать планировку сайта для блогов на DreamHost
Как выбрать Vdsina вечный хостинг для своего проекта
Казань окна VEKA - профессионализм и опыт
Курьерская вода
Новостройки Оренбурга: недвижимость с отличной ценой
Онлайн чат-партнерство
Пиломатериалы для возведения бани
Почему VDSina — лучший выбор хостинга
Секреты Вконтакте: тонкости и хитрости
Скидки до 50% на тур в Коста-Рике
Видеочат рулетка бесплатно
рейтинг хостингов 2026 Быстрые VDS серверы