Что делать если ваш сервер взломали: пошаговый план реакции

Три часа ночи. На VPS зашли с IP из Нигерии, сайт гонит пользователей на казино, и уже пришел email с требованием биткоинов. Паника — понятная реакция. Но именно в первые минуты можно как спасти ситуацию, так и окончательно уничтожить доказательную базу. Здесь — конкретный порядок действий, команды и инструменты.

Меня зовут Евгений Семёнов, я владелец ITfresh. В инфраструктуре работаю с 2010 года. За это время мы разбирали разное: веб-шеллы на сайтах-визитках, шифровальщики на бухгалтерских серверах, тихую эксфильтрацию данных, которую никто не замечал месяцами. Этот текст — то, что я обычно рассказываю техдиректорам клиентов на первой встрече после инцидента.

Признаки взлома, которые часто игнорируют

"Сервер тормозит" — слышу это постоянно. Девять из десяти раз действительно нагрузка или диск. Но один из десяти — это майнер или DDoS-агент, который уже несколько дней молча качает ресурсы. Вот признаки, при которых нужно расследовать, а не просто перезагружать:

• Резкие скачки CPU или трафика, которые не объясняются графиком бизнес-нагрузки.
• Неизвестные процессы с подозрительными именами (kdevtmpfsi, xmrig, kinsing, perfctl, случайные хеши).
• Исходящие соединения с IP из стран, с которыми вы явно не работаете — особенно по нестандартным портам.
• Новые пользователи в /etc/passwd или в AD без записи в журнале.
• Изменённые или удалённые логи в /var/log, особенно auth.log, secure, btmp, wtmp.
• Незнакомые задачи в crontab у root или www-data, scheduled tasks с командами, которые вы не добавляли.
• Системные файлы с датой изменения позже даты установки — или наоборот, слишком старой датой (подделка mtime).
• Сертификаты в Certificate Transparency Log для доменов, которые вы не заказывали. Проверяется на crt.sh за минуту.
• Предупреждения от Яндекс.Вебмастера или Google Search Console о вредоносных страницах на вашем сайте.
• Письмо от хостинга с жалобой на исходящий спам или DDoS с вашего адреса.

Шаг 1. Изоляция, а не выключение

# Linux: разрешить только себя
iptables -I INPUT 1 -s YOUR_HOME_IP -j ACCEPT
iptables -I INPUT 2 -j DROP
iptables -I OUTPUT 1 -d YOUR_HOME_IP -j ACCEPT
iptables -I OUTPUT 2 -j DROP

# Сохранить, чтобы пережили рестарт
iptables-save > /etc/iptables/rules.v4

New-NetFirewallRule -DisplayName "EMERGENCY-block-all-in" `
  -Direction Inbound -Action Block -RemoteAddress Any -Enabled True `
  -Profile Any -Priority 1
New-NetFirewallRule -DisplayName "EMERGENCY-allow-admin-in" `
  -Direction Inbound -Action Allow -RemoteAddress YOUR_HOME_IP `
  -Enabled True -Profile Any -Priority 0

Шаг 2. Снимок памяти и диска

wget https://github.com/microsoft/avml/releases/download/v0.13.0/avml
chmod +x avml
./avml /mnt/external/memory_dump_$(date +%Y%m%d_%H%M).lime

# Подключаем внешний диск, например /dev/sdb
dd if=/dev/sda of=/mnt/external/disk.img bs=4M status=progress
sha256sum /mnt/external/disk.img > /mnt/external/disk.img.sha256

Шаг 3. Идентификация вектора и масштаба

Снимки на месте. Теперь включаем голову. На этом этапе важно не чистить, не переустанавливать — а понять. Нужно ответить на пять вопросов:

1. Когда зашли? (timeline)
2. Откуда зашли — вектор: брутфорс SSH, уязвимость в веб-приложении, открытый RDP, фишинг по почте?
3. Под каким аккаунтом работали — root, www-data, или конкретный пользователь?
4. Что успели сделать — загрузили файлы, добавили пользователей, запустили процесс, вытащили данные?
5. Где ещё могут быть — другие серверы, рабочие станции, бэкапные системы?

Linux: что смотреть

# История shell-команд root и пользователей
cat /root/.bash_history
find /home -name '.bash_history' -exec ls -la {} \; -exec cat {} \;

# Кто и когда логинился
last -F | head -50
lastb | head -50         # неудачные попытки
who                      # активные сессии прямо сейчас

# Аутентификация (ищем подозрительные SSH-сессии)
grep -E "Accepted|Failed" /var/log/auth.log | tail -100
grep "Accepted" /var/log/auth.log | awk '{print $11}' | sort -u

# Активные процессы и сетевые соединения
ps auxf
ss -tunap | grep ESTAB
netstat -tunap | grep LISTEN

# Файлы, изменённые за последние 7 дней
find / -type f -mtime -7 -not -path '/proc/*' -not -path '/sys/*' \
  -not -path '/var/log/*' 2>/dev/null | head -100

# Подозрительные SUID-бинарники (часто следы)
find / -perm -4000 -type f 2>/dev/null

# Crontab и systemd-таймеры
crontab -l
ls -la /etc/cron.* /etc/systemd/system/*.timer
systemctl list-timers --all

# LD_PRELOAD-инжекты
cat /etc/ld.so.preload 2>/dev/null
env | grep LD_

# Скрытые процессы (несовпадение между ps и /proc)
for pid in $(ls /proc | grep -E '^[0-9]+$'); do
  ps -p $pid > /dev/null 2>&1 || echo "Hidden process: $pid"
done

Windows: что смотреть

# Активные сессии и подключения
quser
Get-NetTCPConnection -State Established | Select LocalPort, RemoteAddress, RemotePort, OwningProcess

# Журналы безопасности — 4624 (logon), 4625 (failed logon), 4672 (priv assignment)
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624} -MaxEvents 100 |
  Where-Object {$_.Properties[8].Value -in 3,10} |  # типы 3 (network), 10 (RemoteInteractive)
  Format-Table TimeCreated, @{n='Account';e={$_.Properties[5].Value}}, @{n='IP';e={$_.Properties[18].Value}}

# Запланированные задачи — частая точка персистенса
Get-ScheduledTask | Where-Object {$_.State -eq 'Ready'} |
  Where-Object {$_.Author -notmatch 'Microsoft|Windows'}

# Автозагрузка
Get-CimInstance Win32_StartupCommand
Get-Service | Where-Object {$_.Status -eq 'Running' -and $_.StartType -eq 'Automatic'}

# WMI-подписки (часто скрытый канал персистенса)
Get-WMIObject -Namespace root\subscription -Class __EventConsumer
Get-WMIObject -Namespace root\subscription -Class __FilterToConsumerBinding

# Локальные пользователи и группа администраторов
Get-LocalUser | Format-Table Name, Enabled, LastLogon
Get-LocalGroupMember -Group "Administrators"

Что показывают типовые находки

Шаг 4. Проверка остальной инфраструктуры

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

• Логи фаервола на необычные внутренние соединения от скомпрометированной машины.
• Логи AD на использование украденных учёток (event ID 4624 type 3 с подозрительных IP).
• Бэкапные серверы — атакующие в первую очередь идут к ним.
• Хеши IoC — найденные файлы прогоните через VirusTotal, чтобы узнать, не зафиксированы ли они в других кампаниях.
• Учётные записи приложений — все API-ключи, токены, базы данных, к которым имел доступ скомпрометированный сервер, считаем утекшими.

Шаг 5. Восстановление: всегда с нуля

Шаг 6. Превенция: чтобы не повторилось

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

SSH-харденинг

# /etc/ssh/sshd_config
Port 22                          # можно сменить на нестандарт, но не надейтесь, что это защитит
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
AllowUsers admin deploy
ClientAliveInterval 300
ClientAliveCountMax 2
MaxAuthTries 3
LoginGraceTime 30s
AllowAgentForwarding no
AllowTcpForwarding no
X11Forwarding no
UseDNS no
PermitEmptyPasswords no

Fail2ban с агрессивной политикой

# /etc/fail2ban/jail.local
[sshd]
enabled = true
port = ssh
filter = sshd
maxretry = 3
findtime = 600
bantime = 86400      # сутки
backend = systemd

[recidive]
enabled = true
filter = recidive
maxretry = 3
findtime = 86400
bantime = 604800     # неделя для повторных нарушителей

Автоматические обновления

# Debian/Ubuntu
apt install -y unattended-upgrades
dpkg-reconfigure -plow unattended-upgrades

# В /etc/apt/apt.conf.d/50unattended-upgrades:
Unattended-Upgrade::Allowed-Origins {
  "${distro_id}:${distro_codename}-security";
};
Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "03:30";

Мониторинг и SIEM

Начать можно с малого: Wazuh-агент на каждом сервере и отдельная виртуалка под центральный узел. Из коробки получаете:

• Централизованный сбор логов
• Файловый интегрити-мониторинг: любое изменение в /etc, /usr/sbin, /usr/bin — сразу алерт.
• Детект подозрительных процессов и нетипичных сетевых соединений.
• Готовые правила обнаружения для типовых атак по базам CIS, MITRE ATT&CK и OWASP.

Установка Wazuh agent в одну строку:

curl -s https://packages.wazuh.com/key/GPG-KEY-WAZUH | gpg --no-default-keyring \
  --keyring gnupg-ring:/usr/share/keyrings/wazuh.gpg --import && \
  chmod 644 /usr/share/keyrings/wazuh.gpg && \
  echo "deb [signed-by=/usr/share/keyrings/wazuh.gpg] https://packages.wazuh.com/4.x/apt/ stable main" \
  | tee /etc/apt/sources.list.d/wazuh.list && \
  apt update && WAZUH_MANAGER='siem.example.local' apt install wazuh-agent -y

Бэкапы по правилу 3-2-1-1-0

Классическое правило 3-2-1 давно устарело — в эпоху шифровальщиков добавились ещё два условия:

• 3 копии данных,
• 2 разных носителя,
• 1 офсайт-копия,
• 1 оффлайн или иммутабельная копия,
• 0 ошибок при тестовом восстановлении (раз в квартал).

Юридическая часть

Вот что я регулярно объясняю клиентам: при взломе у вас могут возникнуть не только технические, но и юридические обязательства. Малый бизнес об этом, как правило, не думает — и зря.

• ФЗ-152 "О персональных данных" — при утечке персональных данных оператор обязан уведомить Роскомнадзор в течение 24 часов с момента обнаружения и в течение 72 часов предоставить расследование. Шаблон уведомления есть на сайте РКН.
• УК РФ ст. 272-273 — неправомерный доступ к компьютерной информации и распространение вредоносного ПО. Заявление подаётся через сайт МВД или подразделение К.
• Договорные обязательства — у вас могут быть SLA с клиентами, требующие уведомления о компрометации.

Сводный чек-лист первых 4 часов

Главные мысли

1. Взломанный сервер — не выключать. Изолировать фаерволом. RAM — это улика, которую вы потеряете при отключении питания.
2. Снапшоты RAM и диска — до любых чисток. Без них нет ни доказательной базы, ни возможности понять, что на самом деле произошло.
3. Не лечите взломанный сервер — переустанавливайте. Попытка "вылечить" оставляет шанс атакующему вернуться.
4. Все пароли и токены, к которым у скомпрометированного сервера был доступ — меняйте немедленно. Считайте их публичными.
5. После инцидента: Wazuh, fail2ban, MFA везде, иммутабельные бэкапы. Без этого следующий взлом — не "если", а "когда".
6. Если не уверены в своих силах — в первый же час звоните в команду incident response. Час с экспертом экономит двое суток самостоятельного разбирательства.

Часто задаваемые вопросы